From Francis.Dupont@fdupont.fr Fri Apr 1 00:17:25 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CDDC3A6849 for ; Fri, 1 Apr 2011 00:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 JJVHP+I8A2WL for ; Fri, 1 Apr 2011 00:17:12 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 158653A691A for ; Fri, 1 Apr 2011 00:17:09 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p317InIF065535; Fri, 1 Apr 2011 09:18:49 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201104010718.p317InIF065535@givry.fdupont.fr> From: Francis Dupont To: "pcp issue tracker" In-reply-to: Your message of Thu, 31 Mar 2011 19:58:34 -0000. <074.f38b78e6cec71eba79906380615fd0d9@tools.ietf.org> Date: Fri, 01 Apr 2011 09:18:49 +0200 Sender: Francis.Dupont@fdupont.fr Cc: cheshire@apple.com, pcp@ietf.org Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:17:25 -0000 This error exists just because some NATs can't create a new mapping when it will conflict with an already existing implicit dynamic mapping so I am sorry but I can't see how your proposal solves the problem. Regards Francis.Dupont@fdupont.fr PS: I propose to give up on this ticket: from the beginning it is hopeless as the problem and any solution are out of the scope of PCP. From margaretw42@gmail.com Fri Apr 1 00:24:06 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F2A3A6AC3 for ; Fri, 1 Apr 2011 00:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.69 X-Spam-Level: X-Spam-Status: No, score=-3.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 x9y-l9xf7P7l for ; Fri, 1 Apr 2011 00:23:41 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 1E1353A6B32 for ; Fri, 1 Apr 2011 00:23:38 -0700 (PDT) Received: by bwz13 with SMTP id 13so2510542bwz.31 for ; Fri, 01 Apr 2011 00:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:content-type :content-transfer-encoding:mime-version:subject:date:x-mailer; bh=9kyRRMepCL9hMV+k1IwMyBeQFulmJ8jT6iRbuiQ8QVI=; b=AYa2syYqTHHrk0Wsa0qbUmDEi6QnQz68uAgxgwQ50qQvf9lDt6RuOhOR4fxgvvKoZs XWC2oKTQZxbJCE1JJ0mrl4we+LCRhqpIMaE5nkbjI9rmJmK6jg7gUhSOR84gJRx9NlVm T/SUbcyztSChjGfABUAKLUGYkyU2X44Focqq0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=h7ByZmZ2U3dOV+T5F7bSrf87V5Tdo6z8PD3MjG4nolUkgEAjIYxhp5tOCrcqbbjwR5 2l3NPpm2pav1v6mJ3tk2X0Rhv/bnQvzzYluStzLXSSCgNL1FMRb8NKXwGgJ181mKkpFA 82va7KRzaFrUYIyIV5jj2x2z6t3uEzpYlmyys= Received: by 10.204.22.194 with SMTP id o2mr3360854bkb.67.1301642717903; Fri, 01 Apr 2011 00:25:17 -0700 (PDT) Received: from dhcp-1138.meeting.ietf.org (dhcp-1138.meeting.ietf.org [130.129.17.56]) by mx.google.com with ESMTPS id v21sm1182585bkt.23.2011.04.01.00.25.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 00:25:16 -0700 (PDT) Message-Id: <1321ABE5-30E5-4EE0-A9E6-88DE127DA892@lilacglade.org> From: Margaret Wasserman To: pcp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 1 Apr 2011 09:25:13 +0200 X-Mailer: Apple Mail (2.936) Subject: [pcp] Security Issues with Base Spec X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:24:06 -0000 I read the base specification last night, in preparation for this morning's meeting, and I have some concerns which I will cover in a few separate, topical messages. I'll start with security issues. 1) I understand that the group reached consensus that security is not needed in the protocol itself, and that it will be provided by the underlying transport. However, there is no text in the document that even describes how PCP would be run over a secure transport, should security be needed. 2) The Security Considerations section does not, IMO, adequately describe how/when security is (or isn't) needed in deployments. In particular, the Security Considerations section should, at least, cover the notion of source address spoofing and its impacts on PCP. Margaret From Francis.Dupont@fdupont.fr Fri Apr 1 00:27:39 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9608B3A69D3 for ; Fri, 1 Apr 2011 00:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 ivo+hunCvFTT for ; Fri, 1 Apr 2011 00:27:37 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 6FDE53A69B5 for ; Fri, 1 Apr 2011 00:27:37 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p317TGLL066214; Fri, 1 Apr 2011 09:29:16 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201104010729.p317TGLL066214@givry.fdupont.fr> From: Francis Dupont To: "pcp issue tracker" In-reply-to: Your message of Thu, 31 Mar 2011 20:15:03 -0000. <078.9387e6b3322230657e8d57acce639b85@tools.ietf.org> Date: Fri, 01 Apr 2011 09:29:16 +0200 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] #47: PCP Port Number 5351 or 44323? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:27:39 -0000 As the current editor of the NAT-PMP PCP IWF document I have a formal concern with references to NAT-PMP expired drafts. It doesn't make sense to not have at least Stuart's I-D as a normative reference. BTW I expect the solution to be in the IWF document status... Thanks Francis.Dupont@fdupont.fr PS: version 00 is 'Intended status: Standards Track' just because other IWF & co documents are. It is just a line to change in the XML source. From Francis.Dupont@fdupont.fr Fri Apr 1 00:37:30 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4923A6AF8 for ; Fri, 1 Apr 2011 00:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.235 X-Spam-Level: X-Spam-Status: No, score=-3.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 LOrDeuylRC2M for ; Fri, 1 Apr 2011 00:37:30 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id E3AED3A691A for ; Fri, 1 Apr 2011 00:37:29 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p317d9lE066833; Fri, 1 Apr 2011 09:39:09 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201104010739.p317d9lE066833@givry.fdupont.fr> From: Francis Dupont To: Dave Thaler In-reply-to: Your message of Thu, 31 Mar 2011 20:37:07 -0000. <9B57C850BB53634CACEC56EF4853FF653B00FE75@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 01 Apr 2011 09:39:09 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] request for a "PEER opcode as extension" tracker ticket X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:37:31 -0000 In your previous mail you wrote: I believe it falls out of the requirement to support existing APIs so that apps don't have to change: This eases the deployment of PCP in situations where applications have already changed to support the APIs necessary for communicating with UPnP-IGD or NAT-PMP. Those applications only work today when the home gateway gets a public address, but may no longer work in situations where the gateway is behind another NAT. Home gateways could use PCP to translate and relay those UPnP and NAP-PMP messages to the PCP server, thus allowing such applications to continue working as they do today. => this is explicitely about UPnP-IGD or NAT-PMP APIs so as the common feeling is UPnP-IGD nor NAT-PMP support a similar to PEER function I can't understand the relationship. > So I'd like to open a new tracker ticket about the idea to move the PEER > section 9 from the base spec document to an extension one. => please note I maintain this. In a parallel thread you asked the more general question: >> BTW I can ask the same question about the PEER stuff: >> the fact it is in the base document does mean it is mandatory to support? >> If this is the case be prepared to receive objections... Hence I am opening the ticket with all of the above info, but will title it as about whether PEER support is mandatory. => this is not what I asked for but it is an interesting question so I agree a ticket should be created for it. Regards Francis.Dupont@fdupont.fr From margaretw42@gmail.com Fri Apr 1 00:42:27 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21A73A6BFD for ; Fri, 1 Apr 2011 00:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.682 X-Spam-Level: X-Spam-Status: No, score=-3.682 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 MA1K68Jtb0v9 for ; Fri, 1 Apr 2011 00:42:27 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id CF32E3A6BEC for ; Fri, 1 Apr 2011 00:42:26 -0700 (PDT) Received: by bwz13 with SMTP id 13so2520782bwz.31 for ; Fri, 01 Apr 2011 00:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:from:to:content-type :content-transfer-encoding:mime-version:subject:date:x-mailer; bh=4KCOGhxqoMXeo04SHd1t+NLe+Uik1rPgBRmBfCCsUXg=; b=bdQG6zDm69ti64lPunfX+CnazhKhlGFxRWL1Dt2TR1kZydzxHNwWxD7qKTqBkXBcEP ExoUAtGfp03aeWLoUn4obiCSN/fN/DrTz2gQeMD+k53T0Uau2sz8XyYCytKGh3JDlQUE gRPnvZnt+4lJj2bK+bvoeEOuNRjVHSqbkIJFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=IEzWRRhf8YupJx2z2Up0/VaY6nuEPV0UUlEATUuqA0bcfsYralfrevHzHLIedlChPY RB2XHAOfp0EFMUrV85N6Z1tqp7eSL3mCNaScThNl6RF6oEktCuRD+zYpqu/8dqIxEIMq iHS96FfxNyDa2okH4Eo55lGziDrVloxYZDpNI= Received: by 10.204.20.143 with SMTP id f15mr3205779bkb.173.1301643845734; Fri, 01 Apr 2011 00:44:05 -0700 (PDT) Received: from dhcp-1138.meeting.ietf.org (dhcp-1138.meeting.ietf.org [130.129.17.56]) by mx.google.com with ESMTPS id x6sm1194711bkv.12.2011.04.01.00.44.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 00:44:04 -0700 (PDT) Message-Id: <48E765EC-5CCC-4027-B265-8FE412ED40DE@lilacglade.org> From: Margaret Wasserman To: pcp@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 1 Apr 2011 09:44:02 +0200 X-Mailer: Apple Mail (2.936) Subject: [pcp] THIRD-PARTY Option Issues X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 07:42:27 -0000 The THIRD-PARTY option indicates that it will be discarded if it contains the same address as the address in the packet. What are the implications of this choice for nodes that are behind more than one NAT? Could you be in a situation where the node _sent_ a valid THIRD- PARTY request, but that the IP addresses in the header were translated en route, such that the addresses are the same? In general, it is better _not_ to make behavior of an application depend on the addresses in the IP packet, for these reasons, unless those addresses are securely bound to the application protocol in some way. Margaret From cheshire@apple.com Fri Apr 1 08:05:42 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B18113A6881 for ; Fri, 1 Apr 2011 08:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WVXgvAPfxZ9o for ; Fri, 1 Apr 2011 08:05:42 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by core3.amsl.com (Postfix) with ESMTP id 05DEF3A687F for ; Fri, 1 Apr 2011 08:05:42 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay14.apple.com ([17.128.113.52]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LIZ009TMBC2OS32@localhost.apple.com> for pcp@ietf.org; Fri, 01 Apr 2011 08:07:22 -0700 (PDT) X-AuditID: 11807134-b7c8cae000005108-55-4d95ea2afee7 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with SMTP id 23.C2.20744.A2AE59D4; Fri, 01 Apr 2011 08:07:22 -0700 (PDT) Received: from [172.30.29.155] ([88.128.94.140]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LIZ006U1BC8YC40@et.apple.com> for pcp@ietf.org; Fri, 01 Apr 2011 08:07:22 -0700 (PDT) From: Stuart Cheshire Date: Fri, 01 Apr 2011 08:07:19 -0700 Message-id: <8DEE3224-5159-4290-978B-470786D0E2B1@apple.com> To: pcp@ietf.org X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: [pcp] PCP Error Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 15:05:42 -0000 I just submitted draft-cheshire-pcp-recovery-00.txt. Please review and send comments (you only have to read pages 2 and 3; the rest is boilerplate). I'd like to WG Last-Call this along with draft-ietf-pcp-base in two weeks. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From rpenno@juniper.net Fri Apr 1 12:15:16 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375A83A6930 for ; Fri, 1 Apr 2011 12:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 H2AMGKe-lF07 for ; Fri, 1 Apr 2011 12:15:15 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id A4C2F3A6920 for ; Fri, 1 Apr 2011 12:15:13 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTZYkpVGqH2rLTmLdA/0tBbKy4KNeiBy9@postini.com; Fri, 01 Apr 2011 12:16:54 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 1 Apr 2011 12:13:56 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 1 Apr 2011 15:15:30 -0400 From: Reinaldo Penno To: Stuart Cheshire , "pcp@ietf.org" Date: Fri, 1 Apr 2011 15:15:26 -0400 Thread-Topic: [pcp] PCP Error Recovery Thread-Index: AcvwfoL1aOlyD2+3QtWBl73X6aVF0QAIqTwI Message-ID: In-Reply-To: <8DEE3224-5159-4290-978B-470786D0E2B1@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [pcp] PCP Error Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 19:15:16 -0000 Hi Stuart, We had this in the first version of the base draft (based on NAT-PMP) but relying on Multicast was considered a roadblock. Was any change/consensus i= n the meeting about this? Thanks, Reinaldo On 4/1/11 8:07 AM, "Stuart Cheshire" wrote: > I just submitted draft-cheshire-pcp-recovery-00.txt. Please review and se= nd > comments (you only have to read pages 2 and 3; the rest is boilerplate). = I'd > like to WG Last-Call this along with draft-ietf-pcp-base in two weeks. >=20 > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * www.stuartcheshire.org >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From xiaohong.deng@orange-ftgroup.com Fri Apr 1 20:33:23 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3A5F3A69DB for ; Fri, 1 Apr 2011 20:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 cVFVp1ELf7Cj for ; Fri, 1 Apr 2011 20:33:20 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id EF2223A69D9 for ; Fri, 1 Apr 2011 20:33:19 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A5FAD778002; Sat, 2 Apr 2011 05:41:03 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 9CE93778001; Sat, 2 Apr 2011 05:41:03 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Apr 2011 05:34:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: quoted-printable Date: Sat, 2 Apr 2011 11:34:53 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0164EE17@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <09cb01cbee17$55e635c0$01b2a140$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[pcp] Hoping to eliminate MISORDERED_OPTIONS Thread-Index: AcvuFgH5JjNzuKowTn6abRX1CnHkmgAARxFwALO7pCA= References: Your message of Tue, 29 Mar 2011 14:44:46 +0200. <098501cbee0f$16a98680$43fc9380$@com> <201103291333.p2TDXWLo020860@givry.fdupont.fr> <09cb01cbee17$55e635c0$01b2a140$@com> From: To: , X-OriginalArrivalTime: 02 Apr 2011 03:34:58.0486 (UTC) FILETIME=[F0E4C560:01CBF0E6] Cc: pcp@ietf.org Subject: Re: [pcp] Hoping to eliminate MISORDERED_OPTIONS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 03:33:24 -0000 |> =3D> anything which can cause a lot of traffic (free tickets for the=20 |> social this night :-) and overload lines... the problem is=20 |an AFTR can=20 |> be used as a redirect device, of course here it hides the original=20 |> destination, not the original source which is more=20 |interesting for the=20 |> bad guy. | |I don't see the harm. Please walk me through the life of the=20 |malicious activity after the PCP MAP request containing THIRD_PARTY. If internal IP address presents in the common header, AFTR=20 could process packets as soon as PCP common header be parsed (by hardware); otherwise AFTR needs to parse all the (not-ordered) options to retrieve internal IP, which is a hurdle to hardware=20 parsing. As a result, if the AFTR has to implement options parsing by=20 software, it is likely to make PCP server a processing bottleneck. BR, Xiaohong opensource A+P: http://opensourceaplusp.weebly.com/ | |-d | | |> Regards |>=20 |> Francis.Dupont@fdupont.fr | | From xiaohong.deng@orange-ftgroup.com Fri Apr 1 23:15:57 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE5C53A68D9 for ; Fri, 1 Apr 2011 23:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 468YpYagXB7D for ; Fri, 1 Apr 2011 23:15:54 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 905ED3A69EB for ; Fri, 1 Apr 2011 23:15:53 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1EE26738002; Sat, 2 Apr 2011 08:18:07 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 13F456C0003; Sat, 2 Apr 2011 08:18:07 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Apr 2011 08:17:33 +0200 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: Sat, 2 Apr 2011 14:17:29 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <095601cbee08$9ef0c780$dcd25680$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS Thread-Index: AcvpgbZjqATPUsFnRFan3ixj2Y8FqQAlk4zAAAdKXvAAJLt/0AAPaQzwAI5RLNAAAOWpIAAs7yOgAARenKAAt94SIA== References: <0cb801cbe29e$ee401b80$cac05280$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01621A9D@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01621DA1@ch-mailsrv.rd.francetelecom.fr> <65E8E82B-3C4A-479A-B158-76E56E96DC47@apple.com> <0962B0BEF842A24191AD9BE41A8DD2FC01621FE6@ch-mailsrv.rd.francetelecom.fr> <1e6601cbea35$abd8f5c0$038ae140$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016221BC@ch-mailsrv.rd.francetelecom.fr> <22fd01cbeb06$c4793500$4d6b9f00$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E41B@ch-mailsrv.rd.francetelecom.fr> <03e101cbed42$d80d0ef0$88272cd0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E634@ch-mailsrv.rd.francetelecom.fr> <095601cbee08$9ef0c780$dcd25680$@com> From: To: , X-OriginalArrivalTime: 02 Apr 2011 06:17:33.0018 (UTC) FILETIME=[A70C3BA0:01CBF0FD] Cc: pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 06:15:58 -0000 |> My argument is that I don't think PCP client has the right to remove=20 |> NAT filter on behalf of another app. | |My argument is that it does not matter. The first application=20 |(which is a pure UDP or TCP client) sent a packet to the=20 |Internet, and has _no reasonable expectation_ that the network=20 |does any filtering. =20 |You're saying that, on your network, it gets some filtering. =20 |That's great. That's fine. =20 | |The next application, listening on the same port, wants to=20 |receive incoming packets. | |So, the filtering gets removed from that first application. | |I don't see a problem, because that first application had (and=20 |has) no reasonable expectation of the network doing filtering=20 |on its behalf. A nice point. I agree with you on this point. However, when it comes to PCP UPnP IWF, there is another issue according to our PCP UPnP IWF tests. It is likely that after an UPnP 1.0 client has established a dynamic session on an internal port, it will then requests the same internal port/external port to be forwarded, which will fail even if "promote" the conflict implicit mapping to the explicit mapping,=20 because the external port ( a random port ) is unlikely to be the=20 same as the internal port for implicit mappings but UPnP 1.0 asks for a specific port (internal port) as the external port.=20 Yet, it should not fail if you assume explicit mappings should prior=20 to implicit mappings. BR, Xiaohong opensource A+P: http://opensourceaplusp.weebly.com/ | |-d | | From cheshire@apple.com Sat Apr 2 00:10:26 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7256C3A69EC for ; Sat, 2 Apr 2011 00:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, 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 dBXoNa4efRLH for ; Sat, 2 Apr 2011 00:10:25 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by core3.amsl.com (Postfix) with ESMTP id A86DE3A6999 for ; Sat, 2 Apr 2011 00:10:25 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJ000CECK0659N0@localhost.apple.com> for pcp@ietf.org; Sat, 02 Apr 2011 00:12:06 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-06-4d96cc460c1a Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay15.apple.com (Apple SCV relay) with SMTP id DC.A6.18996.64CC69D4; Sat, 02 Apr 2011 00:12:06 -0700 (PDT) Received: from [10.0.1.2] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJ0003IQK05GX10@et.apple.com> for pcp@ietf.org; Sat, 02 Apr 2011 00:12:06 -0700 (PDT) From: Stuart Cheshire In-reply-to: Date: Sat, 02 Apr 2011 00:12:06 -0700 Message-id: References: To: Reinaldo Penno X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: "pcp@ietf.org" Subject: Re: [pcp] PCP Error Recovery X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 07:10:26 -0000 On 1 Apr 2011, at 12:15, Reinaldo Penno wrote: > Hi Stuart, > > We had this in the first version of the base draft (based on NAT-PMP) but > relying on Multicast was considered a roadblock. Was any change/consensus in > the meeting about this? > > Thanks, > > Reinaldo It's not relying on multicast. It says "MAY". A typical home gateway (DHCP+NAT) serving clients on a local link MAY notify clients by sending a multicast. If some scenarios (e.g. DS-Lite?) cannot make use of multicast, does that mean no one should be allowed to? In any case, according to some points of view a DS-Lite AFTR will exclusively utilize battery-backed double-redundant persistent storage which can never lose state, so it will never need to notify clients of a reset, so in practice it may only be consumer-grade home gateways that need to do this anyway. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Sat Apr 2 00:29:45 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A01DB3A6A53 for ; Sat, 2 Apr 2011 00:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.932 X-Spam-Level: X-Spam-Status: No, score=-106.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, 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 i8KdFODF0ICu for ; Sat, 2 Apr 2011 00:29:44 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by core3.amsl.com (Postfix) with ESMTP id AE6693A6768 for ; Sat, 2 Apr 2011 00:29:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJ000GUAKWDUN00@localhost.apple.com> for pcp@ietf.org; Sat, 02 Apr 2011 00:31:25 -0700 (PDT) X-AuditID: 11807137-b7c3cae0000010f5-51-4d96d0cd0780 Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay16.apple.com (Apple SCV relay) with SMTP id 0A.75.04341.DC0D69D4; Sat, 02 Apr 2011 00:31:25 -0700 (PDT) Received: from [10.0.1.2] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJ0003NJKVGGX10@et.apple.com> for pcp@ietf.org; Sat, 02 Apr 2011 00:31:25 -0700 (PDT) From: Stuart Cheshire In-reply-to: <48E765EC-5CCC-4027-B265-8FE412ED40DE@lilacglade.org> Date: Sat, 02 Apr 2011 00:31:25 -0700 Message-id: <9416E36A-D050-4C6D-8202-94E27DD06A4B@apple.com> References: <48E765EC-5CCC-4027-B265-8FE412ED40DE@lilacglade.org> To: Margaret Wasserman X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: pcp@ietf.org Subject: Re: [pcp] THIRD-PARTY Option Issues X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 07:29:45 -0000 On 1 Apr 2011, at 0:44, Margaret Wasserman wrote: > The THIRD-PARTY option indicates that it will be discarded if it contains the same address as the address in the packet. What are the implications of this choice for nodes that are behind more than one NAT? Could you be in a situation where the node _sent_ a valid THIRD-PARTY request, but that the IP addresses in the header were translated en route, such that the addresses are the same? > > In general, it is better _not_ to make behavior of an application depend on the addresses in the IP packet, for these reasons, unless those addresses are securely bound to the application protocol in some way. While this is generally good advice for most protocols, I think in this case we can say simply that PCP is a protocol that simply doesn't work though (uncooperative) NATs. If there's an uncooperative NAT between you and the PCP-enabled NAT you're talking to, then there's nothing we can do about that, but we can detect it and report the error so the user knows what to do about it (replace your uncooperative NAT with a PCP-enabled NAT). Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Sat Apr 2 02:14:40 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9AF3A65A5 for ; Sat, 2 Apr 2011 02:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 M4w9cF7Hqo3k for ; Sat, 2 Apr 2011 02:14:40 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by core3.amsl.com (Postfix) with ESMTP id 0A7833A63D3 for ; Sat, 2 Apr 2011 02:14:40 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by localhost.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJ000H92PR6N8D0@localhost.apple.com> for pcp@ietf.org; Sat, 02 Apr 2011 02:16:20 -0700 (PDT) X-AuditID: 11807137-b7c3cae0000010f5-86-4d96e96497c5 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay16.apple.com (Apple SCV relay) with SMTP id BF.84.04341.469E69D4; Sat, 02 Apr 2011 02:16:20 -0700 (PDT) Received: from [17.153.36.66] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJ0004VWPR87220@elliott.apple.com> for pcp@ietf.org; Sat, 02 Apr 2011 02:16:20 -0700 (PDT) From: Stuart Cheshire In-reply-to: <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> Date: Sat, 02 Apr 2011 02:16:20 -0700 Message-id: References: <0cb801cbe29e$ee401b80$cac05280$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01621A9D@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01621DA1@ch-mailsrv.rd.francetelecom.fr> <65E8E82B-3C4A-479A-B158-76E56E96DC47@apple.com> <0962B0BEF842A24191AD9BE41A8DD2FC01621FE6@ch-mailsrv.rd.francetelecom.fr> <1e6601cbea35$abd8f5c0$038ae140$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016221BC@ch-mailsrv.rd.francetelecom.fr> <22fd01cbeb06$c4793500$4d6b9f00$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E41B@ch-mailsrv.rd.francetelecom.fr> <03e101cbed42$d80d0ef0$88272cd0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E634@ch-mailsrv.rd.francetelecom.fr> <095601cbee08$9ef0c780$dcd25680$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> To: xiaohong.deng@orange-ftgroup.com X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 09:14:40 -0000 On 1 Apr 2011, at 23:17, xiaohong.deng@orange-ftgroup.com wrote: > It is likely that after an UPnP 1.0 client has established a > dynamic session on an internal port, it will then requests the same > internal port/external port to be forwarded, which will fail even if > "promote" the conflict implicit mapping to the explicit mapping, > because the external port ( a random port ) is unlikely to be the > same as the internal port for implicit mappings but UPnP 1.0 asks for > a specific port (internal port) as the external port. As you point out, UPnP IGD 1.0 is fundamentally flawed. The semantics it demands are fundamentally impossible to achieve in any shared NAT. If it weren't fundamentally flawed we wouldn't have needed NAT-PMP, or PCP (or UPnP IGD v2). Constraining PCP to achieve IGD's unachievable semantics ("give me the external port I demand") results in a protocol that doesn't work. There's no way for a shared NAT to provide the semantics demanded by UPnP IGD 1.0, regardless of whether it uses PCP or any other protocol. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From xiaohong.deng@orange-ftgroup.com Sat Apr 2 04:37:47 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C317A3A67C1 for ; Sat, 2 Apr 2011 04:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 34zMiUGZD4fy for ; Sat, 2 Apr 2011 04:37:46 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 780D13A67B5 for ; Sat, 2 Apr 2011 04:37:46 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6CE39FC4009; Sat, 2 Apr 2011 13:39:33 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 617A0FC4005; Sat, 2 Apr 2011 13:39:33 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Apr 2011 13:39:26 +0200 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: Sat, 2 Apr 2011 19:39:21 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC0164EEF8@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS Thread-Index: AcvxFqSetO0BPLQ2SrygNhxGTZaeQwABDHOw References: <0cb801cbe29e$ee401b80$cac05280$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01621A9D@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01621DA1@ch-mailsrv.rd.francetelecom.fr> <65E8E82B-3C4A-479A-B158-76E56E96DC47@apple.com> <0962B0BEF842A24191AD9BE41A8DD2FC01621FE6@ch-mailsrv.rd.francetelecom.fr> <1e6601cbea35$abd8f5c0$038ae140$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016221BC@ch-mailsrv.rd.francetelecom.fr> <22fd01cbeb06$c4793500$4d6b9f00$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E41B@ch-mailsrv.rd.francetelecom.fr> <03e101cbed42$d80d0ef0$88272cd0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E634@ch-mailsrv.rd.francetelecom.fr> <095601cbee08$9ef0c780$dcd25680$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 02 Apr 2011 11:39:26.0154 (UTC) FILETIME=[9E92EAA0:01CBF12A] Cc: pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 11:37:47 -0000 |As you point out, UPnP IGD 1.0 is fundamentally flawed. The=20 |semantics it demands are fundamentally impossible to achieve=20 |in any shared NAT. If it weren't fundamentally flawed we=20 |wouldn't have needed NAT-PMP, or PCP (or UPnP IGD v2).=20 |Constraining PCP to achieve IGD's unachievable semantics=20 |("give me the external port I demand") results in a protocol=20 |that doesn't work. There's no way for a shared NAT to provide=20 |the semantics demanded by UPnP IGD 1.0, regardless of whether=20 |it uses PCP or any other protocol. =20 Yes, UPnP IGD 1.0 is flawed, but we still want to make=20 as many UPnP 1.0 (AddPortMapping) requests work as possible,=20 because most of exist applications are using UPnP 1.0, right? Note that the case we've talked here is internal port conflict, so UPnP 1.0 is still likely to obtain demanded external port. If we assume explicit mappings are more important than implicit mappings, there is still a way to make UPnP 1.0 work; such as delete the (internal port )=20 conflict implicit mapping when the demanded external port is available. Besides, If we don't try to make it work and eliminate=20 IMPLICIT_MAPPING_EXISTS, in this case which error code should be returned to IWF?=20 BR, Xiaohong opensource A+P: http://opensourceaplusp.weebly.com/ | |Stuart Cheshire |* Wizard Without Portfolio, Apple Inc. |* www.stuartcheshire.org | | From Francis.Dupont@fdupont.fr Mon Apr 4 07:19:32 2011 Return-Path: X-Original-To: pcp@core3.amsl.com Delivered-To: pcp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45FC3A6803 for ; Mon, 4 Apr 2011 07:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=-0.730, BAYES_05=-1.11, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 Ko-RCFLDyI-l for ; Mon, 4 Apr 2011 07:19:32 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [91.121.26.85]) by core3.amsl.com (Postfix) with ESMTP id 12E1B3A69F0 for ; Mon, 4 Apr 2011 07:19:31 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p34ELDYC053083; Mon, 4 Apr 2011 16:21:13 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201104041421.p34ELDYC053083@givry.fdupont.fr> From: Francis Dupont To: xiaohong.deng@orange-ftgroup.com In-reply-to: Your message of Sat, 02 Apr 2011 11:34:53 +0800. <0962B0BEF842A24191AD9BE41A8DD2FC0164EE17@ch-mailsrv.rd.francetelecom.fr> Date: Mon, 04 Apr 2011 16:21:13 +0200 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] Hoping to eliminate MISORDERED_OPTIONS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 14:19:33 -0000 In your previous mail you wrote: As a result, if the AFTR has to implement options parsing by software, it is likely to make PCP server a processing bottleneck. => IMHO it doesn't make sense to process PCP by hardware (PCP is an extensible protocol so it will never work). Regards Francis.Dupont@fdupont.fr PS: this argument applies to the PCP server co-located with a CGN. From dwing@cisco.com Mon Apr 11 17:17:06 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D16FEE0731 for ; Mon, 11 Apr 2011 17:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.239 X-Spam-Level: X-Spam-Status: No, score=-110.239 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKfw61DTyPtj for ; Mon, 11 Apr 2011 17:17:05 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id E95F2E071B for ; Mon, 11 Apr 2011 17:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3208; q=dns/txt; s=iport; t=1302567425; x=1303777025; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=OCoKlAoafCXJGrHBfAG1racKHCpLlv/eq0asiBF1ySs=; b=auK/+qcZ96wTs0CIMvqw0N8Jd7/eWbDM/5fzHtwnI0YZ87VKZJ5IskoR rMSdor82qq3VatuwgfWTEaZ2CB98ts+OYAu0kfNzcGEagY+O1nP1c3pek 6eGVef+NpzZVm1UVpNnazhKqKusLvaQREkq3/apgM/AmPtulz9f/UZvHm c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAHOYo02rRDoJ/2dsb2JhbACYRoFji3h3pXGcWYVuBIVb X-IronPort-AV: E=Sophos;i="4.64,193,1301875200"; d="scan'208";a="294106853" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2011 00:10:17 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3C0AGq9006604; Tue, 12 Apr 2011 00:10:16 GMT From: "Dan Wing" To: "'Margaret Wasserman'" , References: <48E765EC-5CCC-4027-B265-8FE412ED40DE@lilacglade.org> In-Reply-To: <48E765EC-5CCC-4027-B265-8FE412ED40DE@lilacglade.org> Date: Mon, 11 Apr 2011 17:10:16 -0700 Message-ID: <0b3b01cbf8a6$00a787f0$01f697d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvwQJnarVbxKf9/RdSrQ+J20rPXdgIZCgwA Content-Language: en-us Subject: Re: [pcp] THIRD-PARTY Option Issues X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 00:17:07 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Margaret Wasserman > Sent: Friday, April 01, 2011 12:44 AM > To: pcp@ietf.org > Subject: [pcp] THIRD-PARTY Option Issues > > > The THIRD-PARTY option indicates that it will be discarded if it > contains the same address as the address in the packet. Section 10 in pcp-base-07 says: A THIRD_PARTY Option MUST NOT contain the same address as the source address of the packet. A PCP server receiving a THIRD_PARTY Option specifying the same address as the source address of the packet MUST return a MALFORMED_REQUEST result code. This is because many PCP servers may not implement the THIRD_PARTY Option at all, and a client using the THIRD_PARTY Option to specify the same address as the source address of the packet will cause mapping requests to fail where they would otherwise have succeeded. > What are the > implications of this choice for nodes that are behind more than one > NAT? The purpose of THIRD_PARTY is to convey a different address for the mapping. But there is never a different address for the mapping when a nested NAPT is involved, such as what you're describing: [PCP client]---[NAPT1]--[NAPT2]-----[CGN] In the above diagram, the PCP client would need to somehow obtain a mapping from NAPT1 (using perhaps UPnP IGD), and somehow obtain a mapping from NAPT2 (using perhaps PCP, because UPnP IGD won't work), and another mapping from the CGN. From each of those NAT's perspectives, there is one and only one IP address 'behind' it. That is, the CGN only sees one IP address (that of NAPT2), and NAPT2 only sees one IP address (that of NAPT1). The PCP request to NAPT2 and the PCP request to CGN would no need the THIRD_PARTY option. And if they included it, any value in the THIRD_PARTY option that differs from the IP address of the PCP request would fail the authorization checks described in Section 14.3. > Could you be in a situation where the node _sent_ a valid THIRD- > PARTY request, but that the IP addresses in the header were translated > en route, such that the addresses are the same? Sure. But when that happens, it is functionally the same as not sending the THIRD_PARTY option at all. I think what you're suggesting is that we have no reason for the MUST NOT in the following paragraph: A THIRD_PARTY Option MUST NOT contain the same address as the source address of the packet. A PCP server receiving a THIRD_PARTY Option specifying the same address as the source address of the packet MUST return a MALFORMED_REQUEST result code. This is because many PCP servers may not implement the THIRD_PARTY Option at all, and a client using the THIRD_PARTY Option to specify the same address as the source address of the packet will cause mapping requests to fail where they would otherwise have succeeded. > In general, it is better _not_ to make behavior of an application > depend on the addresses in the IP packet, for these reasons, unless > those addresses are securely bound to the application protocol in some > way. -d From dwing@cisco.com Mon Apr 11 17:29:06 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A4176E06BC for ; Mon, 11 Apr 2011 17:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.172 X-Spam-Level: X-Spam-Status: No, score=-110.172 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CFDIVmlqklO for ; Mon, 11 Apr 2011 17:29:04 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 70122E06B0 for ; Mon, 11 Apr 2011 17:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2045; q=dns/txt; s=iport; t=1302568144; x=1303777744; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=jSdhFTEG/zwz1S3xUghou/NkBLb87mkTOoHo/nEBsMI=; b=l0JoN0wL3H4dMZ/z93S0ti98QQO5zbFBj4Ok5LncXBhlRIJSNENQoeBz awx3trvhaxIDGCoEy5iZlfE3eMz+rtLU2T0j9FTIljwiqotihhBLw4thq /lUQCAWvO7RUWRbIXhJtPDM684ZHVHLsz/NmbJw3/gJPKRk2S77MUOCg8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8BAHebo02rRDoG/2dsb2JhbACYRoFji3h3iHqcYpxchW4EhVuOIA X-IronPort-AV: E=Sophos;i="4.64,193,1301875200"; d="scan'208";a="335046665" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 12 Apr 2011 00:27:28 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3C0RRxN005082; Tue, 12 Apr 2011 00:27:28 GMT From: "Dan Wing" To: "'Francis Dupont'" References: Your message of Thu, 31 Mar 2011 19:58:34 -0000. <074.f38b78e6cec71eba79906380615fd0d9@tools.ietf.org> <201104010718.p317InIF065535@givry.fdupont.fr> In-Reply-To: <201104010718.p317InIF065535@givry.fdupont.fr> Date: Mon, 11 Apr 2011 17:27:27 -0700 Message-ID: <0b3c01cbf8a8$673a2890$35ae79b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvwPRvIwQHz4jwSTmSpnimMIQkfNAIakD/g Content-Language: en-us Cc: cheshire@apple.com, pcp@ietf.org Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 00:29:06 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Francis Dupont > Sent: Friday, April 01, 2011 12:19 AM > To: pcp issue tracker > Cc: cheshire@apple.com; pcp@ietf.org > Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS > > This error exists just because some NATs can't create a new mapping > when it will conflict with an already existing implicit dynamic > mapping so I am sorry but I can't see how your proposal solves the > problem. Stuart's slide 14 at http://www.ietf.org/proceedings/80/slides/pcp-8.pdf has a reasonable suggestion, which is not rocket science to implement: Can be mitigated if NAT partitions its port space into ports for EDM use and ports for EIM use > Regards > > Francis.Dupont@fdupont.fr > > PS: I propose to give up on this ticket: from the beginning it is > hopeless > as the problem and any solution are out of the scope of PCP. I believe by "out of scope", you are referring to the WG consensus that PCP not change NAT behavior? The problem with IMPLICIT_MAPPING_EXISTS is that it would force application changes, in some cases very severe application changes (e.g., an application already listening on a port and accepting connections from internal hosts would have to change its listening port [or add an additional listening port] if it receives the infrequent IMPLICIT_MAPPING_EXISTS error.) I consider it more severe to require changes to millions of potential applications versus a change to a dozen NAT implementations (Linux and various vendors). It is especially troubling to expect applications to support IMPLICIT_MAPPING_EXISTS, because the error will be infrequently encountered in a lab or test bed unless explicitly tickled. Which means the application code is unlikely to be adequately tested for this error condition. -d > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Tue Apr 12 16:04:04 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id F2177E094B for ; Tue, 12 Apr 2011 16:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.352 X-Spam-Level: X-Spam-Status: No, score=-110.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC4BuTQNhVsl for ; Tue, 12 Apr 2011 16:04:03 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id EF8F7E094A for ; Tue, 12 Apr 2011 16:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2192; q=dns/txt; s=iport; t=1302649442; x=1303859042; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=0Eh1Dgpy3h45oPZ2bbSJ3nmCb28TTia51OypNmtOJs4=; b=JOL1lMjDB2aVbPFmTPJVV2bzZGuAW8NUUFn3KkOWvJuEzWVl/e5BV1fA 1rKyP8Z5pzorB4cokz5bAOAdfPplvfK++b5QYweFAwFckhGnA3Pids5Gn LaxR9AhfnXrIzcwZ/+Bh/7HkqhlF2GOdFlcFAwu796rjx6vL86B8tA8wY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFHZpE2rRDoH/2dsb2JhbACYHYFjjAV3iHqeVp0chW4EhVyOMA X-IronPort-AV: E=Sophos;i="4.64,200,1301875200"; d="scan'208";a="428613981" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 12 Apr 2011 23:04:02 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3CN41ww025312; Tue, 12 Apr 2011 23:04:02 GMT From: "Dan Wing" To: , References: <0cb801cbe29e$ee401b80$cac05280$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01621A9D@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01621DA1@ch-mailsrv.rd.francetelecom.fr> <65E8E82B-3C4A-479A-B158-76E56E96DC47@apple.com> <0962B0BEF842A24191AD9BE41A8DD2FC01621FE6@ch-mailsrv.rd.francetelecom.fr> <1e6601cbea35$abd8f5c0$038ae140$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016221BC@ch-mailsrv.rd.francetelecom.fr> <22fd01cbeb06$c4793500$4d6b9f00$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E41B@ch-mailsrv.rd.francetelecom.fr> <03e101cbed42$d80d0ef0$88272cd0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E634@ch-mailsrv.rd.francetelecom.fr> <095601cbee08$9ef0c780$dcd25680$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> Date: Tue, 12 Apr 2011 16:04:02 -0700 Message-ID: <0f7901cbf965$ea64aa70$bf2dff50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvpgbZjqATPUsFnRFan3ixj2Y8FqQAlk4zAAAdKXvAAJLt/0AAPaQzwAI5RLNAAAOWpIAAs7yOgAARenKAAt94SIAIfj1bA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 23:04:04 -0000 > -----Original Message----- > From: xiaohong.deng@orange-ftgroup.com [mailto:xiaohong.deng@orange- > ftgroup.com] > Sent: Friday, April 01, 2011 11:17 PM > To: dwing@cisco.com; cheshire@apple.com > Cc: pcp@ietf.org > Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS > > > |> My argument is that I don't think PCP client has the right to remove > |> NAT filter on behalf of another app. > | > |My argument is that it does not matter. The first application > |(which is a pure UDP or TCP client) sent a packet to the > |Internet, and has _no reasonable expectation_ that the network > |does any filtering. > |You're saying that, on your network, it gets some filtering. > |That's great. That's fine. > | > |The next application, listening on the same port, wants to > |receive incoming packets. > | > |So, the filtering gets removed from that first application. > | > |I don't see a problem, because that first application had (and > |has) no reasonable expectation of the network doing filtering > |on its behalf. > > A nice point. I agree with you on this point. > > However, when it comes to PCP UPnP IWF, there is another > issue according to our PCP UPnP IWF tests. > > It is likely that after an UPnP 1.0 client has established a > dynamic session on an internal port, it will then requests the same > internal port/external port to be forwarded, which will fail even if > "promote" the conflict implicit mapping to the explicit mapping, > because the external port ( a random port ) is unlikely to be the > same as the internal port for implicit mappings but UPnP 1.0 asks for > a specific port (internal port) as the external port. We should be able to make that work with PCP, as well, even with a (so-called) "endpoint-dependent mapping" NAT. (I say "so-called" because the issue isn't really EDM, but rather the issue is "port overloading" or "port reuse"). > Yet, it should not fail if you assume explicit mappings should prior > to implicit mappings. I'll work on some text for that. -d > BR, > Xiaohong > opensource A+P: http://opensourceaplusp.weebly.com/ > > > > | > |-d > | > > | From dwing@cisco.com Tue Apr 12 16:04:41 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 76CE5E094B for ; Tue, 12 Apr 2011 16:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.393 X-Spam-Level: X-Spam-Status: No, score=-110.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuuStyHpQRs7 for ; Tue, 12 Apr 2011 16:04:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 74AF5E094A for ; Tue, 12 Apr 2011 16:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1631; q=dns/txt; s=iport; t=1302649480; x=1303859080; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=aIqa1HvnEf/MAjZVj2/1bSfri9Gu3Pf+8blubzIW2QM=; b=eMLnYhAjK0j7G//V6TvkMVhP+JMh1NJ16DbSE8D9ZeHeRws9dpzIWr9q M4IIt9kgdImJ83Yu3Cd88lmtSUXWaBsTAlPJEbsbn3FjE/7JTLEcg03NB kYIVRS1uYQnEbqIvIZ9UDxrkbFtxzjn8y2JJ5XMOIGw8bIlmZSsvg9nAK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAFHZpE2rRDoJ/2dsb2JhbACYHYFjjAV3iHqeVp0chW4EhVyOMA X-IronPort-AV: E=Sophos;i="4.64,200,1301875200"; d="scan'208";a="428614243" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 12 Apr 2011 23:04:39 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3CN4dF0017445; Tue, 12 Apr 2011 23:04:39 GMT From: "Dan Wing" To: "'Stuart Cheshire'" , References: <0cb801cbe29e$ee401b80$cac05280$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01621A9D@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01621DA1@ch-mailsrv.rd.francetelecom.fr> <65E8E82B-3C4A-479A-B158-76E56E96DC47@apple.com> <0962B0BEF842A24191AD9BE41A8DD2FC01621FE6@ch-mailsrv.rd.francetelecom.fr> <1e6601cbea35$abd8f5c0$038ae140$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016221BC@ch-mailsrv.rd.francetelecom.fr> <22fd01cbeb06$c4793500$4d6b9f00$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E41B@ch-mailsrv.rd.francetelecom.fr> <03e101cbed42$d80d0ef0$88272cd0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E634@ch-mailsrv.rd.francetelecom.fr> <095601cbee08$9ef0c780$dcd25680$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: Date: Tue, 12 Apr 2011 16:04:40 -0700 Message-ID: <0f7a01cbf966$00da7b90$028f72b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvxFqKduQwUsfsMRsikomqO9B5bMQIT1CpQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 23:04:41 -0000 > -----Original Message----- > From: Stuart Cheshire [mailto:cheshire@apple.com] > Sent: Saturday, April 02, 2011 2:16 AM > To: xiaohong.deng@orange-ftgroup.com > Cc: dwing@cisco.com; pcp@ietf.org > Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS > > On 1 Apr 2011, at 23:17, xiaohong.deng@orange-ftgroup.com wrote: > > > It is likely that after an UPnP 1.0 client has established a > > dynamic session on an internal port, it will then requests the same > > internal port/external port to be forwarded, which will fail even if > > "promote" the conflict implicit mapping to the explicit mapping, > > because the external port ( a random port ) is unlikely to be the > > same as the internal port for implicit mappings but UPnP 1.0 asks for > > a specific port (internal port) as the external port. > > As you point out, UPnP IGD 1.0 is fundamentally flawed. The semantics > it demands are fundamentally impossible to achieve in any shared NAT. > If it weren't fundamentally flawed we wouldn't have needed NAT-PMP, or > PCP (or UPnP IGD v2). Constraining PCP to achieve IGD's unachievable > semantics ("give me the external port I demand") results in a protocol > that doesn't work. There's no way for a shared NAT to provide the > semantics demanded by UPnP IGD 1.0, regardless of whether it uses PCP > or any other protocol. I think I can craft text, and implementation, to get this working. Stay tuned for some proposed text on this in the next day or so. -d > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * www.stuartcheshire.org From cheshire@apple.com Wed Apr 13 09:25:13 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 47E88E077D for ; Wed, 13 Apr 2011 09:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.099 X-Spam-Level: X-Spam-Status: No, score=-107.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpdbWBNIKTHC for ; Wed, 13 Apr 2011 09:25:12 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfc.amsl.com (Postfix) with ESMTP id 31D7BE077C for ; Wed, 13 Apr 2011 09:25:12 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJL00HM7MUKLRK0@mail-out.apple.com> for pcp@ietf.org; Wed, 13 Apr 2011 09:25:11 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-f7-4da5ce66ec99 Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay15.apple.com (Apple SCV relay) with SMTP id A5.2B.18996.66EC5AD4; Wed, 13 Apr 2011 09:25:10 -0700 (PDT) Received: from [17.153.53.252] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJL007FRMXY1G50@elliott.apple.com> for pcp@ietf.org; Wed, 13 Apr 2011 09:25:10 -0700 (PDT) From: Stuart Cheshire In-reply-to: <0b3c01cbf8a8$673a2890$35ae79b0$@com> Date: Wed, 13 Apr 2011 09:25:10 -0700 Content-transfer-encoding: quoted-printable Message-id: <5F02A5A1-D6DA-482A-B747-2A8B603989FD@apple.com> References: "31 Mar 2011 19:58:34 -0000." <074.f38b78e6cec71eba79906380615fd0d9@tools.ietf.org> <201104010718.p317InIF065535@givry.fdupont.fr> <0b3c01cbf8a8$673a2890$35ae79b0$@com> To: pcp@ietf.org X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 16:25:13 -0000 On 11 Apr 2011, at 17:27, Dan Wing wrote: >> Francis.Dupont@fdupont.fr >>=20 >> PS: I propose to give up on this ticket: from the beginning it is >> hopeless as the problem and any solution are out of the scope of PCP. >=20 > I believe by "out of scope", you are referring to the WG=20 > consensus that PCP not change NAT behavior? The problem with > IMPLICIT_MAPPING_EXISTS is that it would force application > changes, in some cases very severe application changes (e.g., > an application already listening on a port and accepting > connections from internal hosts would have to change its > listening port [or add an additional listening port] if > it receives the infrequent IMPLICIT_MAPPING_EXISTS error.) >=20 > I consider it more severe to require changes to millions > of potential applications versus a change to a dozen=20 > NAT implementations (Linux and various vendors). It is > especially troubling to expect applications to support > IMPLICIT_MAPPING_EXISTS, because the error will be=20 > infrequently encountered in a lab or test bed unless > explicitly tickled. Which means the application code > is unlikely to be adequately tested for this error=20 > condition. >=20 > -d The point of my (admittedly complicated) slides at the Prague meeting = was to show that I believe that it *IS* feasible for an EDM NAT to honor = inbound mapping requests without just flinging its arms in the air and = throwing the problem back at the clients. Therefore what I propose is that we should not impose this unreasonable = burden on clients, and state that if an EDM NAT vendor wants to support = inbound mappings (using PCP or anything else), then it is the = responsibility of the EDM NAT vendor to make that work. It's not okay for an EDM NAT vendor to say, "We only handle the easy = cases; for the hard cases we give up and make it the client's problem." = UPnP IGD 2 suffers from this. =46rom reading it, it gives the impression = that a bunch of NAT vendors (not the client writers who will be using = the protocol) got together and all wanted the spec to vindicate their = different implementations, so the spec allows each NAT to do pretty much = whatever it feels like, and leaves it up to the client writers (who = weren't represented at the meetings) to sort out the mess. I also get = the feeling that the people at the meetings generally weren't the = engineers actually writing the NAT code, so they had no power to change = that code. This meant that the only avenue open to them was to fight to = have the spec state that whatever their current NAT code happens to do = is the right thing, instead of accepting that maybe it's not the right = thing in every case and maybe they should change their code. This makes = IGD 2 more of a survey of what the current state of the NAT industry = happens to be, rather than a specification of how it *ought* to be, = moving forward. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Wed Apr 13 22:58:23 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 87A22E07D9 for ; Wed, 13 Apr 2011 22:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.932 X-Spam-Level: X-Spam-Status: No, score=-106.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTlcHvXtIzWc for ; Wed, 13 Apr 2011 22:58:22 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfc.amsl.com (Postfix) with ESMTP id 68B52E06FB for ; Wed, 13 Apr 2011 22:58:22 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay16.apple.com ([17.128.113.55]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJM006N1OKJ57Z0@mail-out.apple.com> for pcp@ietf.org; Wed, 13 Apr 2011 22:58:21 -0700 (PDT) X-AuditID: 11807137-b7cd4ae000003108-6b-4da68cfd585a Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay16.apple.com (Apple SCV relay) with SMTP id 3B.97.12552.DFC86AD4; Wed, 13 Apr 2011 22:58:21 -0700 (PDT) Received: from [17.153.53.252] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJM004SROL8MI20@elliott.apple.com> for pcp@ietf.org; Wed, 13 Apr 2011 22:58:21 -0700 (PDT) From: Stuart Cheshire Date: Wed, 13 Apr 2011 22:58:20 -0700 Message-id: <80EBBFF1-E3B5-4F9D-B697-64B29FCE769D@apple.com> To: pcp@ietf.org X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: [pcp] External_AF X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 05:58:23 -0000 I think I worked out what External_AF is for. When used with NAT64, the client may have an IPv6 address, and think the remote peer has an IPv6 address, and therefore use a PEER6 request, but in fact the NAT64 will allocate an external address that is IPv4. If this is true, then MAP requests may also need an External_AF field in the reply, to signify that the assigned external address is actually IPv4 when the NAT gateway is NAT64. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Wed Apr 13 22:58:45 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4BA53E0804 for ; Wed, 13 Apr 2011 22:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.849 X-Spam-Level: X-Spam-Status: No, score=-106.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8qtbS9cEVt7 for ; Wed, 13 Apr 2011 22:58:44 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfc.amsl.com (Postfix) with ESMTP id 3BC76E07FC for ; Wed, 13 Apr 2011 22:58:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJM00FGSOLVNO51@mail-out.apple.com> for pcp@ietf.org; Wed, 13 Apr 2011 22:58:43 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-d0-4da68d13797c Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay15.apple.com (Apple SCV relay) with SMTP id 1E.5E.18996.31D86AD4; Wed, 13 Apr 2011 22:58:43 -0700 (PDT) Received: from [17.153.53.252] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LJM004SROL8MI20@elliott.apple.com> for pcp@ietf.org; Wed, 13 Apr 2011 22:58:43 -0700 (PDT) From: Stuart Cheshire Date: Wed, 13 Apr 2011 22:58:43 -0700 Message-id: To: pcp@ietf.org X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: [pcp] Ephemeral port range X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 05:58:45 -0000 I believe this is a mistake in the document: > to ensure that it can get exclusive use of that port it needs to choose a port that is not in the operating system's ephemeral port range. This statement is not true. Binding to a port provides exclusive use of that port -- for any port. That is what binding means. Another client attempting to bind the same port will get an "in use" error. e.g. see SO_REUSEADDR allows your server to bind to an address which is in a TIME_WAIT state. It does not allow more than one server to bind to the same address. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From simon.perreault@viagenie.ca Thu Apr 14 05:55:33 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4B93AE068E for ; Thu, 14 Apr 2011 05:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PMcvS9JtzDZ for ; Thu, 14 Apr 2011 05:55:32 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfc.amsl.com (Postfix) with ESMTP id B3381E065F for ; Thu, 14 Apr 2011 05:55:32 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 43BE52151D for ; Thu, 14 Apr 2011 08:55:31 -0400 (EDT) Message-ID: <4DA6EEC3.2040005@viagenie.ca> Date: Thu, 14 Apr 2011 08:55:31 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: pcp@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] Ephemeral port range X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 12:55:33 -0000 On 2011-04-14 01:58, Stuart Cheshire wrote: >> to ensure that it can get exclusive use of that port it needs to choose a port that is not in the operating system's ephemeral port range. > > This statement is not true. +1 The port number is irrelevant. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Thu Apr 14 08:39:44 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8FB42E08CC for ; Thu, 14 Apr 2011 08:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.428 X-Spam-Level: X-Spam-Status: No, score=-110.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qT6W0hn-FlrL for ; Thu, 14 Apr 2011 08:39:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 5D59EE08C5 for ; Thu, 14 Apr 2011 08:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1091; q=dns/txt; s=iport; t=1302795583; x=1304005183; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=Lq48Oxm8umfZfBh7X/EXZJX2WI+B7NHXW8x4prmCj9Q=; b=Y6oRszR62xF6aSVn0D35uZI0Rp/Cc1jAX4jBFn/AZQFWob+SU1kflAfY uwY8IaEHOj2WJ6aDn7+ZUtrhUCuOTSBj6PAYW/T1YB4M+k/dV1H7Bm0Nz gOZu3o+1YrlOOw7qbflYAtTX8+5PVzjHjIGB//jy6GXlyf4K+QMgtORcV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEBADwUp02rRDoG/2dsb2JhbACXeYFjjBl3iG+bU50EhW4EhVqORQ X-IronPort-AV: E=Sophos;i="4.64,212,1301875200"; d="scan'208";a="681362896" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-6.cisco.com with ESMTP; 14 Apr 2011 15:39:42 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3EFdgjm024982; Thu, 14 Apr 2011 15:39:42 GMT From: "Dan Wing" To: "'Stuart Cheshire'" , References: <80EBBFF1-E3B5-4F9D-B697-64B29FCE769D@apple.com> In-Reply-To: <80EBBFF1-E3B5-4F9D-B697-64B29FCE769D@apple.com> Date: Thu, 14 Apr 2011 08:39:42 -0700 Message-ID: <006701cbfaba$2cafa240$860ee6c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv6aPtPbSD22ZTIQX2olAthjp9HvwAUP4gw Content-Language: en-us Subject: Re: [pcp] External_AF X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 15:39:44 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Stuart Cheshire > Sent: Wednesday, April 13, 2011 10:58 PM > To: pcp@ietf.org > Subject: [pcp] External_AF > > I think I worked out what External_AF is for. > > When used with NAT64, the client may have an IPv6 address, and think > the remote peer has an IPv6 address, and therefore use a PEER6 request, > but in fact the NAT64 will allocate an external address that is IPv4. Right. > If this is true, then MAP requests may also need an External_AF field > in the reply, to signify that the assigned external address is actually > IPv4 when the NAT gateway is NAT64. The MAP request itself requests if the external address is IPv6 (MAP6) or IPv4 (MAP4). So I don't see a need for MAP to have External_AF. -d > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * www.stuartcheshire.org > > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Thu Apr 14 10:50:16 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A5780E0736 for ; Thu, 14 Apr 2011 10:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7YmJnzptkPB for ; Thu, 14 Apr 2011 10:50:16 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfc.amsl.com (Postfix) with ESMTP id EE03BE0690 for ; Thu, 14 Apr 2011 10:50:12 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5F23B20DFE; Thu, 14 Apr 2011 13:50:12 -0400 (EDT) Message-ID: <4DA733D3.2070904@viagenie.ca> Date: Thu, 14 Apr 2011 13:50:11 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: draft-boucadair-pcp-rtp-rtcp@tools.ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" Subject: [pcp] PORT_RESERVATION_OPTION interaction with PREFER_FAILURE X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 17:50:16 -0000 Hi, There is no mention of PREFER_FAILURE in draft-boucadair-pcp-rtp-rtcp-01. How about adding something along these lines? "If the request contains the PREFER_FAILURE option and one or both suggested external ports cannot be allocated, the PCP server SHALL reply with result code CANNOT_PROVIDE_EXTERNAL_PORT." Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From cheshire@apple.com Thu Apr 14 12:33:57 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DA15FE074A for ; Thu, 14 Apr 2011 12:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.799 X-Spam-Level: X-Spam-Status: No, score=-106.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0rLSStsRxdq for ; Thu, 14 Apr 2011 12:33:56 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfc.amsl.com (Postfix) with ESMTP id 65C58E073F for ; Thu, 14 Apr 2011 12:33:56 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJN00MN5QBFSJB0@mail-out.apple.com> for pcp@ietf.org; Thu, 14 Apr 2011 12:33:55 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-ed-4da74c2396ea Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id F4.2C.18996.32C47AD4; Thu, 14 Apr 2011 12:33:55 -0700 (PDT) Received: from [17.153.53.252] (unknown [17.153.53.252]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJN005NZQCIGZ90@cardamom.apple.com> for pcp@ietf.org; Thu, 14 Apr 2011 12:33:55 -0700 (PDT) From: Stuart Cheshire In-reply-to: <006701cbfaba$2cafa240$860ee6c0$@com> Date: Thu, 14 Apr 2011 12:33:54 -0700 Message-id: References: <80EBBFF1-E3B5-4F9D-B697-64B29FCE769D@apple.com> <006701cbfaba$2cafa240$860ee6c0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: pcp@ietf.org Subject: Re: [pcp] External_AF X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 19:33:58 -0000 On 14 Apr 2011, at 8:39, Dan Wing wrote: > The MAP request itself requests if the external address is IPv6 (MAP6) > or IPv4 (MAP4). So I don't see a need for MAP to have External_AF. How do we handle the case of an IPv6 client behind NAT64? In this case, the client may end up being reachable both via native (untranslated) IPv6 and via a translated IPv4 address:port. Should the client do two MAP requests, a MAP6 and a MAP4, to get both results to store in its rendezvous server? If every client needs to do two MAP requests, maybe we should combine MAP6 and MAP4 into a single "MAP" operation, which returns *both* the external IPv4 address:port and the external IPv6 address:port? Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From dwing@cisco.com Thu Apr 14 12:44:52 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 68A60E0696 for ; Thu, 14 Apr 2011 12:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.459 X-Spam-Level: X-Spam-Status: No, score=-110.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knEmmceda0rg for ; Thu, 14 Apr 2011 12:44:51 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 44D8BE0687 for ; Thu, 14 Apr 2011 12:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1474; q=dns/txt; s=iport; t=1302810291; x=1304019891; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=3W6WsGIAd5ZDGwelEkT9okbaxiJa5cpzyX0+8ULvA50=; b=UPJ5nz7mkkxdv1L/d5OGk2A+s2OcgwiWsSB7Hs6zWZR2Bx5xouXU7ubm QLlhuprby1hQN75pyYxCBGugLoiJwZlFI68fm+dmUhCo8SJc1unU7/zF1 QjVIIw2L06fHmizkVigQt5FfZhsbEQJK08BkT3TAn+H+kCOOukSJr7JI4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4BAM5Lp02rRDoG/2dsb2JhbACXfIFjjBp3iG+dRJ0LhW4EhVqORQ X-IronPort-AV: E=Sophos;i="4.64,213,1301875200"; d="scan'208";a="337608213" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2011 19:44:45 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3EJijjR022057; Thu, 14 Apr 2011 19:44:45 GMT From: "Dan Wing" To: "'Stuart Cheshire'" References: <80EBBFF1-E3B5-4F9D-B697-64B29FCE769D@apple.com> <006701cbfaba$2cafa240$860ee6c0$@com> In-Reply-To: Date: Thu, 14 Apr 2011 12:44:46 -0700 Message-ID: <019801cbfadc$6881fe90$3985fbb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv62u05doVSDCCXRDWgi/57XOEipQAASdHA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] External_AF X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 19:44:52 -0000 > -----Original Message----- > From: Stuart Cheshire [mailto:cheshire@apple.com] > Sent: Thursday, April 14, 2011 12:34 PM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] External_AF > > On 14 Apr 2011, at 8:39, Dan Wing wrote: > > > The MAP request itself requests if the external address is IPv6 > (MAP6) > > or IPv4 (MAP4). So I don't see a need for MAP to have External_AF. > > How do we handle the case of an IPv6 client behind NAT64? If it wants an IPv4 mapping, it sends a MAP4. If it wants an IPv6 mapping (e.g., from its CPE which implements Simple CPE Security), it sends a MAP6. In both cases, it sends the PCP message from its IPv6 interface. > In this case, the client may end up being reachable both via native > (untranslated) IPv6 and via a translated IPv4 address:port. > > Should the client do two MAP requests, a MAP6 and a MAP4, to get both > results to store in its rendezvous server? Yes. > If every client needs to do two MAP requests, maybe we should combine > MAP6 and MAP4 into a single "MAP" operation, which returns *both* the > external IPv4 address:port and the external IPv6 address:port? But they might go to different places or be processed by different components. Seems trickier than necessary. Perhaps something to optimize with a new OpCode in a later document? -d > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * www.stuartcheshire.org From cheshire@apple.com Thu Apr 14 12:58:44 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7589E0681 for ; Thu, 14 Apr 2011 12:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.766 X-Spam-Level: X-Spam-Status: No, score=-106.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vUBQquBnemk for ; Thu, 14 Apr 2011 12:58:43 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfc.amsl.com (Postfix) with ESMTP id CAFC5E067F for ; Thu, 14 Apr 2011 12:58:43 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay15.apple.com ([17.128.113.54]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTP id <0LJN00J1GRGTGZ50@mail-out.apple.com> for pcp@ietf.org; Thu, 14 Apr 2011 12:58:43 -0700 (PDT) X-AuditID: 11807136-b7c6bae000004a34-71-4da751f25559 Received: from jimbu (jimbu.apple.com [17.151.62.37]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay15.apple.com (Apple SCV relay) with SMTP id DB.53.18996.3F157AD4; Thu, 14 Apr 2011 12:58:43 -0700 (PDT) Received: from [17.153.53.252] (unknown [17.153.53.252]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LJN005XJRHUGZ90@cardamom.apple.com> for pcp@ietf.org; Thu, 14 Apr 2011 12:58:42 -0700 (PDT) From: Stuart Cheshire In-reply-to: <019801cbfadc$6881fe90$3985fbb0$@com> Date: Thu, 14 Apr 2011 12:58:41 -0700 Message-id: References: <80EBBFF1-E3B5-4F9D-B697-64B29FCE769D@apple.com> <006701cbfaba$2cafa240$860ee6c0$@com> <019801cbfadc$6881fe90$3985fbb0$@com> To: Dan Wing X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: pcp@ietf.org Subject: Re: [pcp] External_AF X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 19:58:44 -0000 On 14 Apr 2011, at 12:44, Dan Wing wrote: > If it wants an IPv4 mapping, it sends a MAP4. If it wants an IPv6 mapping > (e.g., from its CPE which implements Simple CPE Security), it sends a MAP6. > In both cases, it sends the PCP message from its IPv6 interface. The problem is that the client doesn't *want* a mapping; it *wants* connectivity. Mappings are just a means to that end -- an unfortunate necessity in today's world. A pure IPv6 client typically won't even know it's behind a NAT64. The only way it finds out is by asking for a MAP4 and seeing if it gets one. So, in reality, every IPv6 client has to ask for both MAP4 and MAP6. Maybe that's not a problem -- I was just pointing out the issue. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From simon.perreault@viagenie.ca Thu Apr 14 13:12:44 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2CD28E07D5 for ; Thu, 14 Apr 2011 13:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FWgJGWRlLI1 for ; Thu, 14 Apr 2011 13:12:43 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfc.amsl.com (Postfix) with ESMTP id 37BC0E07A8 for ; Thu, 14 Apr 2011 13:12:43 -0700 (PDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 964D221C9D for ; Thu, 14 Apr 2011 16:12:42 -0400 (EDT) Message-ID: <4DA7553A.1000601@viagenie.ca> Date: Thu, 14 Apr 2011 16:12:42 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: pcp@ietf.org References: <80EBBFF1-E3B5-4F9D-B697-64B29FCE769D@apple.com> <006701cbfaba$2cafa240$860ee6c0$@com> <019801cbfadc$6881fe90$3985fbb0$@com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] External_AF X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 20:12:44 -0000 On 2011-04-14 15:58, Stuart Cheshire wrote: > So, in reality, every IPv6 client has to ask for both MAP4 and MAP6. Maybe that's not a problem -- I was just pointing out the issue. That's very similar to what ICE does. Every ICE client asks separately for two TURN allocations: an IPv4 one and an IPv6 one. They both get advertised to the peer through the rendez-vous server (SIP proxy). I would envision an ICE client doing a similar procedure with PCP... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Thu Apr 14 13:43:38 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 48916E085F for ; Thu, 14 Apr 2011 13:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.471 X-Spam-Level: X-Spam-Status: No, score=-110.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agV7cYeom9od for ; Thu, 14 Apr 2011 13:43:36 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 9E8DAE07AB for ; Thu, 14 Apr 2011 13:43:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1706; q=dns/txt; s=iport; t=1302813816; x=1304023416; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=v2LfSGVaKA2qzrEOVkBET1E2UUijDxaWTstubsB9oPU=; b=Q9KN2MWuC0JbtS3Zbc/DB+5q9/u4p2dYvddfLiGbxz7nClq/b0U9+1MP bCGrVPVUjBxjziyPY7Nuqxg0HLj8t99+1vIv1rSlHfRa7EuXK4elU694D sVBnv2gsSgWmLRQOekGfqdWs2aHBofyxQ6A7pFlaJh5pzjOATpnaewnoV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4BALpbp02rRDoJ/2dsb2JhbACXfIFjjBp3iG+dTZ0KhW4EhVqORQ X-IronPort-AV: E=Sophos;i="4.64,213,1301875200"; d="scan'208";a="430313246" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 14 Apr 2011 20:43:36 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3EKhZ1k013273; Thu, 14 Apr 2011 20:43:36 GMT From: "Dan Wing" To: "'Stuart Cheshire'" References: <80EBBFF1-E3B5-4F9D-B697-64B29FCE769D@apple.com> <006701cbfaba$2cafa240$860ee6c0$@com> <019801cbfadc$6881fe90$3985fbb0$@com> In-Reply-To: Date: Thu, 14 Apr 2011 13:43:37 -0700 Message-ID: <01dc01cbfae4$a1373b30$e3a5b190$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv63mOMfXOobA67Tjquu9ceN1G2CQABcSgQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] External_AF X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 20:43:38 -0000 > -----Original Message----- > From: Stuart Cheshire [mailto:cheshire@apple.com] > Sent: Thursday, April 14, 2011 12:59 PM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] External_AF > > On 14 Apr 2011, at 12:44, Dan Wing wrote: > > > If it wants an IPv4 mapping, it sends a MAP4. If it wants an IPv6 > mapping > > (e.g., from its CPE which implements Simple CPE Security), it sends a > MAP6. > > In both cases, it sends the PCP message from its IPv6 interface. > > The problem is that the client doesn't *want* a mapping; it *wants* > connectivity. > > Mappings are just a means to that end -- an unfortunate necessity in > today's world. > > A pure IPv6 client typically won't even know it's behind a NAT64. The > only way it finds out is by asking for a MAP4 and seeing if it gets > one. > > So, in reality, every IPv6 client has to ask for both MAP4 and MAP6. If it needs to accept incoming connections from both IPv4 and IPv6, yes. Same with a dual-stack host, which (today) would need to send MAP4 (from its IPv4 interface) and MAP6 (from its IPv6 interface). > Maybe that's not a problem -- I was just pointing out the issue. I agree the two PCP requests could be optimized to one, in some cases; but it also complicates situations where there is an IPv6 CPE doing Simple CPE Security, and a NAT64 in the ISP's network -- the CPE would need to proxy the new MAP-BOTH opcode towards the NAT64, and then there are issues around possible differences in maximum lifetime allowed by the IPv6 CPE versus the ISP's NAT64. -d > Stuart Cheshire > * Wizard Without Portfolio, Apple Inc. > * www.stuartcheshire.org From dwing@cisco.com Mon Apr 18 08:54:21 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1DE50E06DD for ; Mon, 18 Apr 2011 08:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.332 X-Spam-Level: X-Spam-Status: No, score=-110.332 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0R2wHOYPvVk7 for ; Mon, 18 Apr 2011 08:54:20 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 21F12E068E for ; Mon, 18 Apr 2011 08:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2626; q=dns/txt; s=iport; t=1303142060; x=1304351660; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=WogWgoUnML+MsuMZkKMuw7S7kw+f5zhdCIjr0hifyIM=; b=M6iTAEC5T4IUkXHHYDslwWHIlvHpZRb9V/GF5Uq59kcT8NQC3mDQftUZ HkpMM1vdbESfNbZ4GaN/i2FlsGPY5gi8nQk/j6SPKWUh73U14xTSxViJd Lj3jM82i6dUoznV9lP9FaoR5oBs1m5qRHqVIrVLkAoJRL6NkEmKvXQWzY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcBAHpdrE2rRDoH/2dsb2JhbACXWj+BJIwgd4hvnmycH4VxBIVijlc X-IronPort-AV: E=Sophos;i="4.64,232,1301875200"; d="scan'208";a="339791073" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 18 Apr 2011 15:54:19 +0000 Received: from dwingWS (sjc-vpn4-1435.cisco.com [10.21.85.154]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3IFsHWK017974; Mon, 18 Apr 2011 15:54:17 GMT From: "Dan Wing" To: References: Your message of Mon, 11 Apr 2011 17:27:27 PDT. <0b3c01cbf8a8$673a2890$35ae79b0$@com> <201104180717.p3I7HmlH050344@givry.fdupont.fr> In-Reply-To: <201104180717.p3I7HmlH050344@givry.fdupont.fr> Date: Mon, 18 Apr 2011 08:54:17 -0700 Message-ID: <08fd01cbfde0$df8be4e0$9ea3aea0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv9mL0fjLC6Y+2/T0yd/mC8jJkwGwAR8uaw Content-Language: en-us Cc: cheshire@apple.com, pcp@ietf.org Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 15:54:21 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Monday, April 18, 2011 12:18 AM > To: Dan Wing > Cc: cheshire@apple.com; pcp@ietf.org > Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS > > > In your previous mail you wrote: > > Stuart's slide 14 at http://www.ietf.org/proceedings/80/slides/pcp- > 8.pdf has > a reasonable suggestion, which is not rocket science to implement: > > Can be mitigated if NAT partitions its port space > into ports for EDM use and ports for EIM use > > => I can't say because I still don't understand Stuart's idea > and the slides, in particular the slide 9, don't seem to be > about the IMPLICIT_MAPPING_EXISTS issue which is a problem > of collision on the *internal* port. The NAT, in Stuart's slides, is preserving the internal port and that NAT is so determined to preserve the internal port that it overloads two connections on the same public port. So, it's violating one MUST and one SHOULD in the RFC4787 (UDP) and one MUST and one SHOULD in RFC5382 (TCP). -d > I believe by "out of scope", you are referring to the WG > consensus that PCP not change NAT behavior? > > => yes. > > The problem with IMPLICIT_MAPPING_EXISTS is that it would force > application changes, in some cases very severe application changes > > => anyway the presence of a NAT in the path can cause application > changes so I don't buy your argument. > > (e.g., an application already listening on a port and accepting > connections from internal hosts would have to change its listening > port [or add an additional listening port] if it receives the > infrequent IMPLICIT_MAPPING_EXISTS error.) > > => if the PCP server/NAT doesn't lose its explicit dynamic mapping > state this is impossible: the existence of an explicit dynamic mapping > prevents the creation of an implicit dynamic mapping. > If the PCP server/NAT loses its explicit dynamic mapping state > then the application can get another port when it tries to renew > and can have to change its listening port. > This has nothing to do with IMPLICIT_MAPPING_EXISTS... > > I consider it more severe to require changes to millions of > potential applications versus a change to a dozen NAT > implementations (Linux and various vendors). > > => have we a way to change any NAT implementation? If the > answer is no why we have this discussion? > > Regards > > Francis.Dupont@fdupont.fr > > PS: Stuart, what is the status of your slides? From dwing@cisco.com Tue Apr 19 12:34:43 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3F06BE0869 for ; Tue, 19 Apr 2011 12:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.616 X-Spam-Level: X-Spam-Status: No, score=-110.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sq+g3X4yaV10 for ; Tue, 19 Apr 2011 12:34:42 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 43391E0866 for ; Tue, 19 Apr 2011 12:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=398; q=dns/txt; s=iport; t=1303241682; x=1304451282; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=UyPYQFL2QtvIv/ybjAty923HRVvaLEB9IjXfYXfpU/Y=; b=cae4pW3wzbs+G7aCE/hxmhHF5PRjxiXy2FHp+OZX+Iyb6a+PlUwHxc7d 8pb2/ydg/0NSai1A89p8Jfw0x8FA5R2KIeYDl2nI6C7Yw8sTew1uJA2QB 9mrt+hX78pjU129N+yWmF+1dHdepk8qdVoqpC7O0e8aMl9bfgCmDvzr4k I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwGAI/irU2rRDoH/2dsb2JhbACXYoEkjCh3qFWccoVxBIVn X-IronPort-AV: E=Sophos;i="4.64,241,1301875200"; d="scan'208";a="340727564" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 19 Apr 2011 19:34:41 +0000 Received: from dwingWS (sjc-vpn2-1440.cisco.com [10.21.117.160]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3JJYfbt019570 for ; Tue, 19 Apr 2011 19:34:41 GMT From: "Dan Wing" To: Date: Tue, 19 Apr 2011 12:34:39 -0700 Message-ID: <10fe01cbfec8$d31341c0$7939c540$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv+yNLO0U6GZHgeSciQKuKpjKbxyg== Content-Language: en-us Subject: [pcp] PCP Port Number 5351 or 44323? - ticket #47 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:34:43 -0000 http://trac.tools.ietf.org/wg/pcp/trac/ticket/47 Question for the PCP working group: we can get both NAT-PMP and PCP to run over the same port. Major advantage is that a client capable of both PCP and NAT-PMP can quickly determine (without timeouts) if the server supports PCP or NAT-PMP. Disadvantage is effectively none, because it does not change PCP at all. Please discuss. -d From dwing@cisco.com Tue Apr 19 12:37:48 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 63520E086D for ; Tue, 19 Apr 2011 12:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.615 X-Spam-Level: X-Spam-Status: No, score=-110.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKVMqzcqCONW for ; Tue, 19 Apr 2011 12:37:47 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 8C4EFE086B for ; Tue, 19 Apr 2011 12:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=801; q=dns/txt; s=iport; t=1303241867; x=1304451467; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=po2Aj/oOHL3JFUkAb1QzfDC7GqO/rGo6M8/cmEJWysM=; b=eao+Wc8o524JRV9P236n91eO+tEhhv3YpBlbTbPL+vpN35OzOcI+ahsL cQCGM3Ivro21KmhtdEgLIO1EwaMHVHOciuXo9xDlkAhMvP+CffWPhWK1k ++4IO35iMpUR/2F+noHxqTVyuj1jYmNt+waw1vKNBeuzS+4dai212q/R6 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwGAJDjrU2rRDoJ/2dsb2JhbACXYoEkjCh3qGKccoVxBIVn X-IronPort-AV: E=Sophos;i="4.64,241,1301875200"; d="scan'208";a="297849699" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 19 Apr 2011 19:37:46 +0000 Received: from dwingWS (sjc-vpn2-1440.cisco.com [10.21.117.160]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3JJbkHa011740 for ; Tue, 19 Apr 2011 19:37:46 GMT From: "Dan Wing" To: Date: Tue, 19 Apr 2011 12:37:43 -0700 Message-ID: <10ff01cbfec9$41818540$c4848fc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv+yUCc82IXVeM2SrGv0feZZKb8LQ== Content-Language: en-us Subject: [pcp] PEER creates implicit dynamic mapping - ticket #46 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:37:48 -0000 In -07, the PEER OpCode can cause the error NONEXIST_PEER to be returned, if there is not already an implicit dynamic mapping (e.g., created with a TCP SYN) in the NAT or firewall. There is a worry that the application's response to this error would be poorly handled because the error would seldom (if ever) occur in a lab environment, but could occur in the field (packet loss combined with non-blocking TCP client connection could cause it, for example). The proposal is to: * modify PEER so that it creates a mapping, which functions exactly like an implicit dynamic mapping. That is, exactly as if a TCP SYN were seen by the NAT or firewall. * eliminate the NONEXIST_PEER error code http://trac.tools.ietf.org/wg/pcp/trac/ticket/46 Please discuss. -d From dwing@cisco.com Tue Apr 19 12:38:49 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6FC16E0689 for ; Tue, 19 Apr 2011 12:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.614 X-Spam-Level: X-Spam-Status: No, score=-110.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGDhu9wXkQBZ for ; Tue, 19 Apr 2011 12:38:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id D64ABE0670 for ; Tue, 19 Apr 2011 12:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=151; q=dns/txt; s=iport; t=1303241928; x=1304451528; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=HF/O8e1FVFPzcx27VVHYlwdsO/c3zQFzDr13tmiXAmQ=; b=dSBUDQtcAg67gBHxc8Q4LlbNn6GZRpZfLDBw5zVlX1OFG3favS+VrNqS 9v+jKWGSYPAo5GTQ63bIZa6Vo3lIIX0g4erH+juxNjcrABuPFoVlN4ACG Zq/jSM3M8ZfVZW26oUoOz1K1sJ6srRaoffMJ+mx6CW5Hict8S9EovS84s s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwGAG/krU2rRDoI/2dsb2JhbACXYoEkjCh3qEqcc4VxBIVn X-IronPort-AV: E=Sophos;i="4.64,241,1301875200"; d="scan'208";a="433042320" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 19 Apr 2011 19:38:48 +0000 Received: from dwingWS (sjc-vpn2-1440.cisco.com [10.21.117.160]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3JJclNj019251 for ; Tue, 19 Apr 2011 19:38:47 GMT From: "Dan Wing" To: Date: Tue, 19 Apr 2011 12:38:45 -0700 Message-ID: <110001cbfec9$65df84a0$319e8de0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv+yWWeEqchCkc7T4+CCWmqblRdqQ== Content-Language: en-us Subject: [pcp] PEER opcode in base PCP specification, ticket #48 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:38:49 -0000 There is a proposal to remove the PEER OpCode from the base specification, http://trac.tools.ietf.org/wg/pcp/trac/ticket/48 Please comment. -d From trac@tools.ietf.org Tue Apr 19 12:40:24 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 37423E0689 for ; Tue, 19 Apr 2011 12:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRhRNJZMCz7I for ; Tue, 19 Apr 2011 12:40:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 0B4FFE0670 for ; Tue, 19 Apr 2011 12:40:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QCGmX-0002ZH-7g; Tue, 19 Apr 2011 12:40:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Tue, 19 Apr 2011 19:40:17 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/44#comment:2 Message-ID: <066.4e112cbc4b4f4c1de4257a41b7bdbe51@tools.ietf.org> References: <057.99dd77f4434a9a3ab98334aac6f68884@tools.ietf.org> X-Trac-Ticket-ID: 44 In-Reply-To: <057.99dd77f4434a9a3ab98334aac6f68884@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #44: support DMZ host X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:40:24 -0000 #44: support DMZ host Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: consensus at IETF80 was to not support DMZ host. Closed. -- ---------------------------------+------------------------------------------ Reporter: adurand@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------------+------------------------------------------ Ticket URL: pcp From trac@tools.ietf.org Tue Apr 19 12:51:30 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 950D9E0774 for ; Tue, 19 Apr 2011 12:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIDhlHMl-MA3 for ; Tue, 19 Apr 2011 12:51:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id E6E6AE069C for ; Tue, 19 Apr 2011 12:51:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QCGxM-0002Dj-6S; Tue, 19 Apr 2011 12:51:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Tue, 19 Apr 2011 19:51:28 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/41#comment:3 Message-ID: <062.fa19b34cc796807de4d35b5c5586c8b1@tools.ietf.org> References: <053.c37df69b4fd40c068b4bcba0ef1fe3c6@tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <053.c37df69b4fd40c068b4bcba0ef1fe3c6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #41: PCP Options need to have a specific order, to ease processing X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:51:30 -0000 #41: PCP Options need to have a specific order, to ease processing Changes (by dwing@…): * status: reopened => closed * resolution: => fixed Comment: consensus at IETF80 (in the room) was to remove all ordering. -08 will do that. Closed. -- -----------------------------+---------------------------------------------- Reporter: dwing@… | Owner: dwing@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Ticket URL: pcp From dwing@cisco.com Tue Apr 19 16:30:25 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DD730E075C for ; Tue, 19 Apr 2011 16:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.614 X-Spam-Level: X-Spam-Status: No, score=-110.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfGoX3y2uKS8 for ; Tue, 19 Apr 2011 16:30:25 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id 2399DE06E2 for ; Tue, 19 Apr 2011 16:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=376; q=dns/txt; s=iport; t=1303255825; x=1304465425; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=IhWEk3qLa50hPBoJOo9Fb1wYAaxccRoLPfHc11ScxLI=; b=C96dhMXgcLtgnxK39mYInFGPpqjfchqozM7K49qDawdqlaCRBfirxhc3 vVJIZ2FKaWYb+Sc0/41J8qW5Ve88rW+lh/9Mu+b510o2MCifqz5mwYV5o Z/p+AzV2KLSqGFKHNuGNKlr5m0kUPXCXsPAxSBq/X2BrTLRcvI8xSB7Qs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwGAJgark2rRDoJ/2dsb2JhbACXa4EkjCh3iG+fV50NhXEEhWc X-IronPort-AV: E=Sophos;i="4.64,242,1301875200"; d="scan'208";a="297993746" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 19 Apr 2011 23:30:24 +0000 Received: from dwingWS (sjc-vpn2-1440.cisco.com [10.21.117.160]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3JNUOkY021012; Tue, 19 Apr 2011 23:30:24 GMT From: "Dan Wing" To: References: Your message of Tue, 19 Apr 2011 12:38:45 PDT. <110001cbfec9$65df84a0$319e8de0$@com> <201104192236.p3JMa9Fw095496@givry.fdupont.fr> In-Reply-To: <201104192236.p3JMa9Fw095496@givry.fdupont.fr> Date: Tue, 19 Apr 2011 16:30:21 -0700 Message-ID: <128a01cbfee9$c08cf750$41a6e5f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv+4jJKtTWiv+aQSGavlxt05BDAogAB1rRQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PEER opcode in base PCP specification, ticket #48 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 23:30:26 -0000 > IMHO the PEER opcode is not in the WG charter so is a good > candidate for an extension. Charter includes this sentence: "A PCP client can be used by applications to directly dialog with the middlebox running a PCP server." PEER allows an application to ask a question of the middlebox, namely: "what is the lifetime of my implicit dynamic mapping". -d From dwing@cisco.com Tue Apr 19 16:30:45 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CB0A3E0862 for ; Tue, 19 Apr 2011 16:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.613 X-Spam-Level: X-Spam-Status: No, score=-110.613 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR6vwcXQpaMN for ; Tue, 19 Apr 2011 16:30:45 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 30344E06E2 for ; Tue, 19 Apr 2011 16:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=124; q=dns/txt; s=iport; t=1303255845; x=1304465445; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=2YStpIGMlS5QLgbNZHGyKwcaAL/07iokeFA/dJI/4kI=; b=bfuud8mpcEQyQI6TOsOxMm6R3/Qeen5aP6ZSX7HWy3u7r/OeH7WFxnJx 6ak4qaTxYhSTajvSr/KuTdBkIgJ3ShC0SspooRtZCS06RPKuLdQiKerzp D5YjWdhZV2KDB2jX7lPhRK62SiNRRaUvjTdLPPU2+PCna8+WO05idoEcH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFcark2rRDoG/2dsb2JhbACZD4wod4hoB59YnQ2FcQSFZw X-IronPort-AV: E=Sophos;i="4.64,242,1301875200"; d="scan'208";a="433172915" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 19 Apr 2011 23:30:44 +0000 Received: from dwingWS (sjc-vpn2-1440.cisco.com [10.21.117.160]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3JNUip7010969; Tue, 19 Apr 2011 23:30:44 GMT From: "Dan Wing" To: , "'pcp issue tracker'" References: Your message of Tue, 19 Apr 2011 19:40:17 -0000. <066.4e112cbc4b4f4c1de4257a41b7bdbe51@tools.ietf.org> <201104192237.p3JMbsf6095568@givry.fdupont.fr> In-Reply-To: <201104192237.p3JMbsf6095568@givry.fdupont.fr> Date: Tue, 19 Apr 2011 16:30:41 -0700 Message-ID: <128b01cbfee9$cc851560$658f4020$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv+4m59JQPBsuZ9R6KV1na9sCOlpQAB1PDQ Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] #44: support DMZ host X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 23:30:46 -0000 > I believe it is "not support in the base spec", i.e., > it can be the object of an extension, cannot it? Sure. -d From dwing@cisco.com Tue Apr 19 16:36:07 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 310D3E069C for ; Tue, 19 Apr 2011 16:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.612 X-Spam-Level: X-Spam-Status: No, score=-110.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDlWl-giG7-W for ; Tue, 19 Apr 2011 16:36:06 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 414BDE069A for ; Tue, 19 Apr 2011 16:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1882; q=dns/txt; s=iport; t=1303256166; x=1304465766; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=PLpXrJTkNigMrMn+DhjJP0Cgz/4v0trLulYeuzj1pB8=; b=IGm6X5Xbcaz6nJjDPQAglpCXjbDBYhPeDNpWvPp+5bF6lZnyUELsWVv9 tZKL4b+cc7mUnxL++izEoWzUh3LQlzTGPEzv/rW65QshIvbSq11IDJ/BP h1gozLFL2QrgTU5rQD8cfuAWFvrPyzrsbTHDBAJAvtIm/xpFcBJVXr47F Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwBAFMbrk2rRDoI/2dsb2JhbACXLD+BJIwod6g3nQ+FcQSFZw X-IronPort-AV: E=Sophos;i="4.64,242,1301875200"; d="scan'208";a="433174823" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 19 Apr 2011 23:36:05 +0000 Received: from dwingWS (sjc-vpn2-1440.cisco.com [10.21.117.160]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3JNa53J014557; Tue, 19 Apr 2011 23:36:05 GMT From: "Dan Wing" To: References: Your message of Tue, 19 Apr 2011 12:37:43 PDT. <10ff01cbfec9$41818540$c4848fc0$@com> <201104192234.p3JMYKRk095367@givry.fdupont.fr> In-Reply-To: <201104192234.p3JMYKRk095367@givry.fdupont.fr> Date: Tue, 19 Apr 2011 16:36:03 -0700 Message-ID: <128c01cbfeea$8be23050$a3a690f0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv+4fKDcqG0GIFpQTGay71iz/0w0QAB+60w Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PEER creates implicit dynamic mapping - ticket #46 X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 23:36:07 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Tuesday, April 19, 2011 3:34 PM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] PEER creates implicit dynamic mapping - ticket #46 > > I vote to keep the 07 behavior (PEER doesn't create mapping > and NONEXIST_PEER can be returned), mainly because the propose > change defines two different ways to do the same thing > (to create an implicit dynamic mapping) which is both > for formal and security considerations a bad thing. > > BTW I am not convinced a common programmer knows how to > open a socket with a priori addresses and ports, so (s)he has > no use of this proposed capability to PEER then connect(), > and to get an error when one tries to poll or extend the > lifetime of a not existing mapping is IMHO far better than > to hide the problem. It's not for such a programmer the concern was raised. Rather, it's for the case of a program which does a non-blocking TCP connection and the TCP SYN is dropped, and does a non-blocking PCP PEER request. On many a lab configuration, there isn't packet loss and the programmer may never include support for NONEXIST_PEER at all, or (if present) that code may never be exercised. As for the value / benefit of returning an error when a mapping doesn't exist -- we should only have that problem if the PCP message goes to the wrong PCP server, on a network with multiple PCP servers and/or multiple NATs and/or multiple firewalls. But multiple PCP servers are out of scope, except for our support of discovering one to talk with on each interface (e.g., one PCP server on IPv4, another PCP server on IPv6) -- there has not been any discussion on the mailing list nor in the I-D how to handle multiple simultaneously-active PCP servers and choosing which to use. -d From mohamed.boucadair@orange-ftgroup.com Wed Apr 20 05:47:19 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7ADA1E06AE for ; Wed, 20 Apr 2011 05:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E02VvpLQF5RU for ; Wed, 20 Apr 2011 05:47:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfc.amsl.com (Postfix) with ESMTP id BAB55E0655 for ; Wed, 20 Apr 2011 05:47:18 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id D89612DC371; Wed, 20 Apr 2011 14:47:17 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 25DF727C053; Wed, 20 Apr 2011 14:47:17 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.10]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Wed, 20 Apr 2011 14:47:17 +0200 From: To: Simon Perreault , "draft-boucadair-pcp-rtp-rtcp@tools.ietf.org" Date: Wed, 20 Apr 2011 14:47:14 +0200 Thread-Topic: [pcp] PORT_RESERVATION_OPTION interaction with PREFER_FAILURE Thread-Index: Acv6zGuvNDyxA3nXSdG+cRXu/Ze9hwEjHbxA Message-ID: <94C682931C08B048B7A8645303FDC9F33C50DEF512@PUEXCB1B.nanterre.francetelecom.fr> References: <4DA733D3.2070904@viagenie.ca> In-Reply-To: <4DA733D3.2070904@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.20.121215 Cc: "pcp@ietf.org" Subject: Re: [pcp] PORT_RESERVATION_OPTION interaction with PREFER_FAILURE X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 12:47:19 -0000 Dear Simon, Thank you for the input. I updated the I-D with your proposed text; see: http://tools.ietf.org/rfcdi= ff?url2=3Ddraft-boucadair-pcp-rtp-rtcp-02 Cheers, Med=20 -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Simon= Perreault Envoy=E9 : jeudi 14 avril 2011 19:50 =C0 : draft-boucadair-pcp-rtp-rtcp@tools.ietf.org Cc : pcp@ietf.org Objet : [pcp] PORT_RESERVATION_OPTION interaction with PREFER_FAILURE Hi, There is no mention of PREFER_FAILURE in draft-boucadair-pcp-rtp-rtcp-01. How about adding something along these lines? "If the request contains the PREFER_FAILURE option and one or both suggested external ports cannot be allocated, the PCP server SHALL reply with result code CANNOT_PROVIDE_EXTERNAL_PORT." Thanks, Simon --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Wed Apr 20 06:35:42 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C335BE0674 for ; Wed, 20 Apr 2011 06:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgQLZbGyWCSL for ; Wed, 20 Apr 2011 06:35:42 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfc.amsl.com (Postfix) with ESMTP id 364B9E065A for ; Wed, 20 Apr 2011 06:35:42 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 783F321B98; Wed, 20 Apr 2011 09:35:41 -0400 (EDT) Message-ID: <4DAEE12C.6000406@viagenie.ca> Date: Wed, 20 Apr 2011 09:35:40 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: draft-ietf-pcp-base@tools.ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" Subject: [pcp] Merging UNAUTH_TARGET_ADDRESS with NOT_AUTHORIZED X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 13:35:42 -0000 Hi, I was wondering why there are two error codes for doing basically the same thing. Why is it important for the client to know what caused the authorization failure? Couldn't we eliminate UNAUTH_TARGET_ADDRESS and return NOT_AUTHORIZED instead? Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Wed Apr 20 11:07:10 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 14A53E06DD for ; Wed, 20 Apr 2011 11:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.611 X-Spam-Level: X-Spam-Status: No, score=-110.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhbVzzYJFsza for ; Wed, 20 Apr 2011 11:07:09 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 49CEBE0695 for ; Wed, 20 Apr 2011 11:07:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1229; q=dns/txt; s=iport; t=1303322829; x=1304532429; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=nWG0mfcnORRr6D0jwDInpTbz+4VVfXvlEJEHR2YpkGU=; b=FeUxUNq9ujdzyA+6mEWV2jJZJmVvsui+2HAgOtzFThlaoh+50USKDZuO G0lMA8n65hpPv+AtvfP+EcXhgbTHncQLZ6Y2PPY32FkfyaN/fSYDLEP5S IYJO6/pvqpKBUsiTe8n2WVJEIr78yJSJrql4BvJHw5ORsPBfBA0c3zvxB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgBAKwfr02rRDoI/2dsb2JhbACXMoFjhW2GOneIb6IlnHmFcQSFdI5/ X-IronPort-AV: E=Sophos;i="4.64,247,1301875200"; d="scan'208";a="684727607" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 20 Apr 2011 18:07:08 +0000 Received: from dwingWS (sjc-vpn2-1440.cisco.com [10.21.117.160]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3KI78KK022499; Wed, 20 Apr 2011 18:07:08 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <4DAEE12C.6000406@viagenie.ca> In-Reply-To: <4DAEE12C.6000406@viagenie.ca> Date: Wed, 20 Apr 2011 11:07:04 -0700 Message-ID: <013701cbff85$c129b3a0$437d1ae0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv/X93lurpsrT9YT5uY6gbjWjlf7QAJbUYA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] Merging UNAUTH_TARGET_ADDRESS with NOT_AUTHORIZED X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 18:07:10 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Simon Perreault > Sent: Wednesday, April 20, 2011 6:36 AM > To: draft-ietf-pcp-base@tools.ietf.org > Cc: pcp@ietf.org > Subject: [pcp] Merging UNAUTH_TARGET_ADDRESS with NOT_AUTHORIZED > > Hi, > > I was wondering why there are two error codes for doing basically the > same thing. Why is it important for the client to know what caused the > authorization failure? Couldn't we eliminate UNAUTH_TARGET_ADDRESS and > return NOT_AUTHORIZED instead? UNAUTH_TARGET_ADDRESS is only returned if the address in THIRD_PARTY is being refused. NOT_AUTHORIZED isn't tied to THIRD_PARTY, and would be returned for other reasons. The separation is intended to allow better handling of authorization failures specific to third-party mapping requests. -d > Thanks, > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Wed Apr 20 12:15:40 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1CAD3E06F4 for ; Wed, 20 Apr 2011 12:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUvCzf5UUo7z for ; Wed, 20 Apr 2011 12:15:39 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfc.amsl.com (Postfix) with ESMTP id 3065BE06A4 for ; Wed, 20 Apr 2011 12:15:39 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A44E621EE3; Wed, 20 Apr 2011 15:15:38 -0400 (EDT) Message-ID: <4DAF30DA.5040803@viagenie.ca> Date: Wed, 20 Apr 2011 15:15:38 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: draft-boucadair-pcp-failure@tools.ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" Subject: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 19:15:40 -0000 Hi, >From draft-boucadair-pcp-failure-01 section 4.6: o if the NEXT Option in the request is an END one, the first mapping of the list is returned in an only NEXT option, marked END if the list contains only this mapping, marked MORE otherwise. o if the NEXT option in the request is a MORE one, as many as can fit mappings are returned in order in the response, marked as MORE but if the whole list can be returned the last is marked END. "Returned" means to include required options when they are defined for a mapping: if the mapping M has 3 REMOTE_PEER_FILTERs and the REMOTE_PEER_FILTER code was in the request NEXT, the NEXT carrying M will get the 3 REMOTE_PEER_FILTER options embedded. My question is: what happens when a single mapping with options is too large to fit in a PCP response? This can happen for example when many FILTER options were added in separate PCP requests. Do we strip off some options? Do we fragment somehow? All solutions I can think of are either too complex or don't fully solve this problem. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Wed Apr 20 17:21:04 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9409BE077E for ; Wed, 20 Apr 2011 17:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-SREddS7U8P for ; Wed, 20 Apr 2011 17:21:03 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfc.amsl.com (Postfix) with ESMTP id A1218E0721 for ; Wed, 20 Apr 2011 17:21:03 -0700 (PDT) Received: from balaise.nomis80.org (modemcable190.43-202-24.mc.videotron.ca [24.202.43.190]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 0D0B721EBE; Wed, 20 Apr 2011 20:21:02 -0400 (EDT) Message-ID: <4DAF786E.4000500@viagenie.ca> Date: Wed, 20 Apr 2011 20:21:02 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Thunderbird/3.1.9 MIME-Version: 1.0 To: Francis Dupont References: <201104202118.p3KLIQVQ078613@givry.fdupont.fr> In-Reply-To: <201104202118.p3KLIQVQ078613@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" , draft-boucadair-pcp-failure@tools.ietf.org Subject: Re: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:21:04 -0000 On 04/20/2011 05:18 PM, Francis Dupont wrote: > My question is: what happens when a single mapping with options is too > large to fit in a PCP response? This can happen for example when many > FILTER options were added in separate PCP requests. > > => it should not be possible. BTW the FILTER options don't accumulate > so they can't be easily used to overflow a single mapping. What do you mean they don't accumulate? On the contrary, they do accumulate. If I add filter A in one request then add filter B in another request, then a GET should return both A and B. > Do we strip off some options? Do we fragment somehow? All solutions I > can think of are either too complex or don't fully solve this problem. > > => it is a known limit of using UDP as the only transport. > IMHO we can live with it: there is no trivial real world example where > it can be a credible issue. Well, the maximal number of filters in a 1024-byte PCP message is around 80. It's easy to go over that limit. Anyway since PCP is not even born yet, I think it's premature to speculate about possible usage patterns. Another thing: right now FILTER is the only option I can think of that would trigger this. But we don't know about future PCP extensions. Other options could have the same effect. So are you suggesting that we truncate the mapping options in a GET response? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Internet-Drafts@ietf.org Wed Apr 20 17:30:03 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 43852E077E; Wed, 20 Apr 2011 17:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.749 X-Spam-Level: X-Spam-Status: No, score=-102.749 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8VlbQklqo1sp; Wed, 20 Apr 2011 17:30:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 90EE0E075C; Wed, 20 Apr 2011 17:30:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110421003002.12353.6558.idtracker@ietfc.amsl.com> Date: Wed, 20 Apr 2011 17:30:02 -0700 Cc: pcp@ietf.org Subject: [pcp] I-D Action:draft-ietf-pcp-base-08.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Port Control Protocol Working Group of the IETF. Title : Port Control Protocol (PCP) Author(s) : D. Wing, et al. Filename : draft-ietf-pcp-base-08.txt Pages : 65 Date : 2011-04-20 Port Control Protocol allows a host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a network address translator (NAT) or simple firewall to an IPv6 or IPv4 host, and also allows a host to optimize its NAT keepalive messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-08.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 Content-Type: Message/External-body; name="draft-ietf-pcp-base-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-20172225.I-D@ietf.org> --NextPart-- From dwing@cisco.com Wed Apr 20 17:33:40 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BE005E06E2 for ; Wed, 20 Apr 2011 17:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.61 X-Spam-Level: X-Spam-Status: No, score=-110.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-LVgB1k-I2z for ; Wed, 20 Apr 2011 17:33:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 9A2B2E0693 for ; Wed, 20 Apr 2011 17:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3587; q=dns/txt; s=iport; t=1303346019; x=1304555619; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=KRe8bxoZB72E0356TjkcpmeuubuRM9JexAGxpdsnc3c=; b=dFteUyZOy8/cXMixTf/GsNpC0fG000MTrT5JS8BXyqPDD2X0UOHXiua8 eBjjbcXJ87YlabkhbHfGUMhNPjc51P5qPDK5s8yu2In1kqxfRuL23HTJV Jx5j6JEYioNgVOuJhw12ShgH1Sjf0sF9AhX9NIjtT/PYeiu7ygs+HEzbx I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKx6r02rRDoH/2dsb2JhbACZIownd6pZnHOFdgSFdA X-IronPort-AV: E=Sophos;i="4.64,248,1301875200"; d="scan'208";a="433923636" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-1.cisco.com with ESMTP; 21 Apr 2011 00:33:39 +0000 Received: from dwingWS (sjc-vpn2-1440.cisco.com [10.21.117.160]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3L0Xc6Y015685 for ; Thu, 21 Apr 2011 00:33:38 GMT From: "Dan Wing" To: Date: Wed, 20 Apr 2011 17:33:34 -0700 Message-ID: <02ff01cbffbb$bfc33640$3f49a2c0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv/u7+M3eu51FRLRYWataXMiIa6aA== Content-Language: en-us Subject: [pcp] pcp-base-08 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:33:40 -0000 pcp-base-08 has been posted. Document is at . Side by side differences from -07 is at http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-08.txt Significant changes include: * elimination of IMPLICIT_MAPPING_EXISTS, which involves recommendations for how non-EIM NATs need to be implemented with PCP (see Section 8.9). This is from from Stuart Chesire's presentation at IETF80, specifically slides 7-15 at http://www.ietf.org/proceedings/80/slides/pcp-8.pdf. Based on some private emails this issue may not be fully resolved, but it is resolved to the best of my personal understanding. Tracker issue #45, http://trac.tools.ietf.org/wg/pcp/trac/ticket/45, which has been open for 3 weeks. * options no longer need to be ordered. Tracker issue #41, http://trac.tools.ietf.org/wg/pcp/trac/ticket/41, which was open for 5 weeks. * allow PEER to create a mapping that works exactly like an implicit dynamic mapping, and eliminated NONEXIST_PEER error. Tracker issue #46, http://trac.tools.ietf.org/wg/pcp/trac/ticket/46, which has been open for 3 weeks. * PCP runs on the same port as NAT-PMP (5351). Tracker issue #47, http://trac.tools.ietf.org/wg/pcp/trac/ticket/47, which has been open for 3 weeks. other changes are copied below (or see http://tools.ietf.org/html/draft-ietf-pcp-base-08#appendix-B.1). -d ----- B.1. Changes from draft-ietf-pcp-base-07 to -08 o moved all MAP4-, MAP6-, and PEER-specific options into a single section. o discussed NAPT port-overloading and its impact on MAP (new section Section 8.9), which allowed removing the IMPLICIT_MAPPING_EXISTS error. o eliminated NONEXIST_PEER error (which was returned if a PEER request was received without an implicit dynamic mapping already being created), and adjusted PEER so that it creates an implicit dynamic mapping. o Removed Deployment Scenarios section (which detailed NAT64, NAT44, Dual-Stack Lite, etc.). o Added Client's IP Address to PCP common header. This allows server to refuse a PCP request if there is a mismatch with the source IP address, such as when a non-PCP-aware NAT was on the path. This should reduce failure situations where PCP is deployed in conjunction with a non-PCP-aware NAT. This addition was consensus at IETF80. o Changed UNSPECIFIED_ERROR to PROCESSING_ERROR. Clarified that MALFORMED_REQUEST is for malformed requests (and not related to failed attempts to process the request). o Removed MISORDERED_OPTIONS. Consensus of IETF80. o SERVER_OVERLOADED is now a common PCP error (instead of specific to MAP). o Tweaked PCP retransmit/retry algorithm again, to allow more aggressive PCP discovery if an implementation wants to do that. o Version negotiation text tweaked to soften NAT-PMP reference, and more clearly explain exactly what UNSUPP_VERSION should return. o PCP now uses NAT-PMP's UDP port, 5351. There are no normative changes to NAT-PMP or PCP to allow them both to use the same port number. o New Appendix A to discuss NAT-PMP / PCP interworking. o improved pseudocode to be non-blocking. o clarified that PCP cannot delete a static mapping (i.e., a mapping created by CLI or other non-PCP means). o moved theft of mapping discussion from Epoch section to Security Considerations, (Section 12.5). From trac@tools.ietf.org Wed Apr 20 17:36:10 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 969DDE0721 for ; Wed, 20 Apr 2011 17:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2v5LiRR6zXL for ; Wed, 20 Apr 2011 17:36:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id E2510E0693 for ; Wed, 20 Apr 2011 17:36:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QChsM-0005Kk-SW; Wed, 20 Apr 2011 17:36:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Thu, 21 Apr 2011 00:36:06 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/45#comment:1 Message-ID: <083.830c1b4a1aa5cb732ce2f64f40f6a598@tools.ietf.org> References: <074.f38b78e6cec71eba79906380615fd0d9@tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <074.f38b78e6cec71eba79906380615fd0d9@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:36:10 -0000 #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: fixed in -08. The IMPLICIT_MAPPING_EXISTS error has been removed, and http://tools.ietf.org/html/draft-ietf-pcp-base-08#section-8.9 discusses what should happen: {{{ For implicit dynamic mappings, some existing NAT devices have endpoint-independent mapping (EIM) behavior while other NAT devices have non-endpoint-independent mapping (non-EIM) behavior. NATs which have EIM behavior do not suffer from the problem described in this section. EIM behavior is strongly encouraged by both [RFC4787] and [RFC5382]. In such non-EIM NAT devices, the same external port may be used by connections from different internal hosts. This complicates the interaction with the MAP4 and MAP6 OpCodes. With such NAT devices, there are two ways envisioned to implement the MAP4 and MAP6 OpCodes: 1. have implicit dynamic mappings (e.g., TCP SYN) use a different set of public ports than explicit dynamic mappings (e.g., those created with MAP4 or MAP6), thus avoiding the interaction problem between them. 2. on arrival of an incoming packet from the Internet, first attempt to process implicit dynamic mappings (as done today by existing port overload code), and if none of those can be processed then the incoming packet is for the explicit dynamic mapping. This effectively 'prioritizes' implicit dynamic mappings above explicit dynamic mappings. }}} -- --------------------------------------------------+------------------------- Reporter: Stuart Cheshire | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------------------------+------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Apr 20 17:36:41 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7DB2EE075C for ; Wed, 20 Apr 2011 17:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb0YIX+Bs+-4 for ; Wed, 20 Apr 2011 17:36:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id F3DA4E0693 for ; Wed, 20 Apr 2011 17:36:40 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QChsu-0006ht-Ga; Wed, 20 Apr 2011 17:36:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Thu, 21 Apr 2011 00:36:40 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/41#comment:4 Message-ID: <062.f32c3a3b13e4e8e7818b520b0008a67f@tools.ietf.org> References: <053.c37df69b4fd40c068b4bcba0ef1fe3c6@tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <053.c37df69b4fd40c068b4bcba0ef1fe3c6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #41: PCP Options need to have a specific order, to ease processing X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:36:41 -0000 #41: PCP Options need to have a specific order, to ease processing Comment(by dwing@…): resolved. -08 removes requirement that Options be ordered. -- -----------------------------+---------------------------------------------- Reporter: dwing@… | Owner: dwing@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Apr 20 17:37:57 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B545FE0721 for ; Wed, 20 Apr 2011 17:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4ynCnOKBtsP for ; Wed, 20 Apr 2011 17:37:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id 14DC3E0693 for ; Wed, 20 Apr 2011 17:37:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QChu8-00018I-G6; Wed, 20 Apr 2011 17:37:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Thu, 21 Apr 2011 00:37:56 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/46#comment:1 Message-ID: <083.d8d4207ffa66e56dac60fc92f73b4bc8@tools.ietf.org> References: <074.dcbc847720df56e7adc69dc0ea9814e7@tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <074.dcbc847720df56e7adc69dc0ea9814e7@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #46: NONEXIST_PEER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:37:57 -0000 #46: NONEXIST_PEER Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: resolved. In pcp-base-08, the PEER OpCode can create an implicit dynamic mapping, exactly the same as created by an inside->outside TCP SYN or inside->outside UDP packet. The error code NONEXIST_PEER is removed. -- --------------------------------------------------+------------------------- Reporter: Stuart Cheshire | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------------------------+------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Apr 20 17:39:57 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AFFB2E075C for ; Wed, 20 Apr 2011 17:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCMA1xrBfLj9 for ; Wed, 20 Apr 2011 17:39:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfc.amsl.com (Postfix) with ESMTP id DA137E0693 for ; Wed, 20 Apr 2011 17:39:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QChw4-0007hn-De; Wed, 20 Apr 2011 17:39:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "pcp issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: dwing@cisco.com X-Trac-Project: pcp Date: Thu, 21 Apr 2011 00:39:56 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/47#comment:1 Message-ID: <087.d66a447eae7f69cea6946d7c082b571f@tools.ietf.org> References: <078.9387e6b3322230657e8d57acce639b85@tools.ietf.org> X-Trac-Ticket-ID: 47 In-Reply-To: <078.9387e6b3322230657e8d57acce639b85@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dwing@cisco.com, pcp@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: pcp@ietf.org Subject: Re: [pcp] #47: PCP Port Number 5351 or 44323? X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 00:39:57 -0000 #47: PCP Port Number 5351 or 44323? Changes (by dwing@…): * status: new => closed * resolution: => fixed Comment: resolved. In pcp-base-08, an appendix describes how NAT-PMP and PCP work together on the same port. This requires no changes to PCP, and no changes to NAT-PMP. http://tools.ietf.org/html/draft-ietf-pcp-base-08#appendix-A says: {{{ Appendix A. NAT-PMP Transition The Port Control Protocol (PCP) is a successor to the NAT Port Mapping Protocol (NAT-PMP), and shares similar semantics, concepts, and packet formats. Because of this NAT-PMP and PCP both use the same port, and use the NAT-PMP and PCP's version negotiation capabilities to determine which version to use. This section describes how an orderly transition may be achieved. A client supporting both NAT-PMP and PCP SHOULD send its request using the PCP packet format. This will be received by a NAT-PMP server or a PCP server. If received by a NAT-PMP server, the response will be as indicated by [I-D.cheshire-nat-pmp], which will cause the client to downgrade to NAT-PMP and re-send its request in NAT-PMP format. If received by a PCP server, the response will be as described by this document and processing continues as expected. A PCP server supporting both NAT-PMP and PCP can respond to requests in either format. The first byte of the packet indicates if it is NAT-PMP (first byte zero) or PCP (first byte non-zero). A PCP-only gateway receiving a NAT-PMP request (identified by the first byte being zero) will interpret the request as a version mismatch. Normal PCP processing will emit a PCP response that is compatible with NAT-PMP, without any special handling by the PCP server. }}} the IANA Considerations section also asks IANA to relinquish the port previously assigned to PCP (44323). -- ------------------------------------------------------+--------------------- Reporter: cheshire@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | ------------------------------------------------------+--------------------- Ticket URL: pcp From mohamed.boucadair@orange-ftgroup.com Thu Apr 21 04:46:53 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BC3D5E0735 for ; Thu, 21 Apr 2011 04:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.093 X-Spam-Level: X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35mDQp+X6Q2n for ; Thu, 21 Apr 2011 04:46:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfc.amsl.com (Postfix) with ESMTP id 78049E06DA for ; Thu, 21 Apr 2011 04:46:52 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id A7A03374470; Thu, 21 Apr 2011 13:46:51 +0200 (CEST) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 8DADD18005C; Thu, 21 Apr 2011 13:46:51 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.10]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Thu, 21 Apr 2011 13:46:51 +0200 From: To: Simon Perreault , "draft-boucadair-pcp-failure@tools.ietf.org" Date: Thu, 21 Apr 2011 13:46:50 +0200 Thread-Topic: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response Thread-Index: Acv/j1dpvlYfiT7ESbe69OuljQUMTAAbYfNA Message-ID: <94C682931C08B048B7A8645303FDC9F33C50DEF87A@PUEXCB1B.nanterre.francetelecom.fr> References: <4DAF30DA.5040803@viagenie.ca> In-Reply-To: <4DAF30DA.5040803@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.21.100321 Cc: "pcp@ietf.org" Subject: Re: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 11:46:53 -0000 Hi Simon, This is indeed a case which may occur when a large number of FILTERs are de= fined. This may even be exacerbated if we associate "Description Option" (t= ext to describe a mapping) with each FILTER for instance. Note the GET mechanism allows to walk through mappings having the same inte= rnal IP@/port, external IP@/port and retrieve the list of FILTERs (i.e., di= stinct remote IP addresses/ports) if the same ordering is used to answer tw= o GET/NEXT requests; see the following example: | PCP GET Response | | MORE | | protocol=3D TCP | | internal-ip-address=3D 198.51.100.2 | | internal-port=3D 12354 | | external-ip-address=3D 192.0.2.1 | | external-port=3D 32654 | | remaining-lifetime=3D 3600 | | DESCRIPTION | | "My mapping for Server_A" | | FILTER | | remote-ip-address=3D 1.2.3.4 | | remote-port=3D 8965 | | FILTER | | remote-ip-address=3D 45.63.25.2 | | remote-port=3D 1454 | | FILTER | | remote-ip-address=3D 45.6.5.5 | | remote-port=3D 8965 | | ... | | FILTER | | remote-port=3D 25659 | | remaining-lifetime=3D 6000 | |<----------------------------------| | PCP GET Request | | MORE | | protocol=3D TCP | | internal-ip-address=3D 198.51.100.2 | | internal-port=3D 12354 | | external-ip-address=3D 192.0.2.1 | | external-port=3D 32654 | | remaining-lifetime=3D 3600 | | DESCRIPTION | | "My mapping for Server_A" | | FILTER | | remote-ip-address=3D 1.2.3.4 | | remote-port=3D 8965 | | FILTER | | remote-ip-address=3D 45.63.25.2 | | remote-port=3D 1454 | | FILTER | | remote-ip-address=3D 45.6.5.5 | | remote-port=3D 8965 | | ... | | FILTER | | remote-port=3D 25659 | | remaining-lifetime=3D 6000 | |---------------------------------->| | PCP GET Response | | MORE | | protocol=3D TCP | | internal-ip-address=3D 198.51.100.2 | | internal-port=3D 12354 | | external-ip-address=3D 192.0.2.1 | | external-port=3D 32654 | | remaining-lifetime=3D 3600 | | DESCRIPTION | | "My mapping for Server_A" | | FILTER | | remote-ip-address=3D 11.22.25.1 | | remote-port=3D 8965 | | FILTER | | remote-port=3D 25659 | | remaining-lifetime=3D 6000 | | MORE | | protocol=3D TCP | | internal-ip-address=3D 198.51.100.2 | | internal-port=3D 12354 | | external-ip-address=3D 192.0.2.1 | | external-port=3D 32654 | | remaining-lifetime=3D 3600 | | END | | protocol=3D TCP | | internal-ip-address=3D 198.51.100.2 | | internal-port=3D 8596 | | external-ip-address=3D 192.0.2.1 | | external-port=3D 25659 | | remaining-lifetime=3D 6000 | |<----------------------------------| Even if I think this is marginal for the NAT case, it would be useful to ha= ve some guidelines in the GET specification when it occurs such as:=20 * Options which apply to all mappings having the same internal IP @/port ar= e returned first * "specific" options (eg. FILTER) are then returned in subsequent GET/NEXT = messages. Any suggestion is welcome. Cheers, Med=20 -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Simon= Perreault Envoy=E9 : mercredi 20 avril 2011 21:16 =C0 : draft-boucadair-pcp-failure@tools.ietf.org Cc : pcp@ietf.org Objet : [pcp] When a single mapping is too large to fit in a PCP GET/NEXT r= esponse Hi, >From draft-boucadair-pcp-failure-01 section 4.6: o if the NEXT Option in the request is an END one, the first mapping of the list is returned in an only NEXT option, marked END if the list contains only this mapping, marked MORE otherwise. o if the NEXT option in the request is a MORE one, as many as can fit mappings are returned in order in the response, marked as MORE but if the whole list can be returned the last is marked END. "Returned" means to include required options when they are defined for a mapping: if the mapping M has 3 REMOTE_PEER_FILTERs and the REMOTE_PEER_FILTER code was in the request NEXT, the NEXT carrying M will get the 3 REMOTE_PEER_FILTER options embedded. My question is: what happens when a single mapping with options is too large to fit in a PCP response? This can happen for example when many FILTER options were added in separate PCP requests. Do we strip off some options? Do we fragment somehow? All solutions I can think of are either too complex or don't fully solve this problem. Simon --=20 DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From simon.perreault@viagenie.ca Thu Apr 21 05:47:47 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id BE8D0E071D for ; Thu, 21 Apr 2011 05:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUGeVwoa2s+F for ; Thu, 21 Apr 2011 05:47:47 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfc.amsl.com (Postfix) with ESMTP id E3816E06FD for ; Thu, 21 Apr 2011 05:47:46 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id F180620DFE; Thu, 21 Apr 2011 08:47:45 -0400 (EDT) Message-ID: <4DB02771.9010805@viagenie.ca> Date: Thu, 21 Apr 2011 08:47:45 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: mohamed.boucadair@orange-ftgroup.com References: <4DAF30DA.5040803@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C50DEF87A@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F33C50DEF87A@PUEXCB1B.nanterre.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" , "draft-boucadair-pcp-failure@tools.ietf.org" Subject: Re: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 12:47:47 -0000 On 2011-04-21 07:46, mohamed.boucadair@orange-ftgroup.com wrote: > Note the GET mechanism allows to walk through mappings having the same internal IP@/port, external IP@/port and retrieve the list of FILTERs (i.e., distinct remote IP addresses/ports) if the same ordering is used to answer two GET/NEXT requests; see the following example: Do you mean "allows as currently specified" or "could allow in a future draft revision"? I will assume the latter. > | PCP GET Response | > | MORE | > | protocol= TCP | > | internal-ip-address= 198.51.100.2 | > | internal-port= 12354 | > | external-ip-address= 192.0.2.1 | > | external-port= 32654 | > | remaining-lifetime= 3600 | > | DESCRIPTION | > | "My mapping for Server_A" | > | FILTER | > | remote-ip-address= 1.2.3.4 | > | remote-port= 8965 | > | FILTER | > | remote-ip-address= 45.63.25.2 | > | remote-port= 1454 | > | FILTER | > | remote-ip-address= 45.6.5.5 | > | remote-port= 8965 | > | ... | > | FILTER | > | remote-port= 25659 | > | remaining-lifetime= 6000 | > |<----------------------------------| > | PCP GET Request | > | MORE | > | protocol= TCP | > | internal-ip-address= 198.51.100.2 | > | internal-port= 12354 | > | external-ip-address= 192.0.2.1 | > | external-port= 32654 | > | remaining-lifetime= 3600 | > | DESCRIPTION | > | "My mapping for Server_A" | > | FILTER | > | remote-ip-address= 1.2.3.4 | > | remote-port= 8965 | > | FILTER | > | remote-ip-address= 45.63.25.2 | > | remote-port= 1454 | > | FILTER | > | remote-ip-address= 45.6.5.5 | > | remote-port= 8965 | > | ... | > | FILTER | > | remote-port= 25659 | > | remaining-lifetime= 6000 | > |---------------------------------->| > | PCP GET Response | > | MORE | > | protocol= TCP | > | internal-ip-address= 198.51.100.2 | > | internal-port= 12354 | > | external-ip-address= 192.0.2.1 | > | external-port= 32654 | > | remaining-lifetime= 3600 | > | DESCRIPTION | > | "My mapping for Server_A" | > | FILTER | > | remote-ip-address= 11.22.25.1 | > | remote-port= 8965 | > | FILTER | > | remote-port= 25659 | > | remaining-lifetime= 6000 | > | MORE | > | protocol= TCP | > | internal-ip-address= 198.51.100.2 | > | internal-port= 12354 | > | external-ip-address= 192.0.2.1 | > | external-port= 32654 | > | remaining-lifetime= 3600 | > | END | > | protocol= TCP | > | internal-ip-address= 198.51.100.2 | > | internal-port= 8596 | > | external-ip-address= 192.0.2.1 | > | external-port= 25659 | > | remaining-lifetime= 6000 | > |<----------------------------------| Yeah, that's one of the "too complex" solutions I was thinking of. It also adds a new ordering constraint on all mapping options. I'm not saying it would not work, but it doesn't look appealing at this point. > Even if I think this is marginal for the NAT case, it would be useful to have some guidelines in the GET specification when it occurs such as: > > * Options which apply to all mappings having the same internal IP @/port are returned first > * "specific" options (eg. FILTER) are then returned in subsequent GET/NEXT messages. If I understand this correctly, this would mitigate the problem but not eliminate it completely. It would just happen less often. So we would need something more. > Any suggestion is welcome. TCP? I'm not joking. To me, transferring state in bulk seems very appropriate for TCP. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Thu Apr 21 05:51:17 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CEA2BE06FD for ; Thu, 21 Apr 2011 05:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcPBHRLIlLIY for ; Thu, 21 Apr 2011 05:51:17 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfc.amsl.com (Postfix) with ESMTP id 339E3E06AB for ; Thu, 21 Apr 2011 05:51:17 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A840720DFE; Thu, 21 Apr 2011 08:51:16 -0400 (EDT) Message-ID: <4DB02844.7060609@viagenie.ca> Date: Thu, 21 Apr 2011 08:51:16 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Francis Dupont References: <201104211242.p3LCgsKT035193@givry.fdupont.fr> In-Reply-To: <201104211242.p3LCgsKT035193@givry.fdupont.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" , "draft-boucadair-pcp-failure@tools.ietf.org" Subject: Re: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 12:51:17 -0000 On 2011-04-21 08:42, Francis Dupont wrote: > IMHO the obvious solution is to convert FILTER to OpCodes, > something we should do anyway if we'd like to provide a real support > to firewalls... Yeah, that would work. > PS: I don't see messages from the PCP ML itself (pcp@ietf.org)??? I think Mailman doesn't send you a copy when it sees your address in the To: or Cc: headers. It's configurable per-user from the web interface... Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mohamed.boucadair@orange-ftgroup.com Thu Apr 21 07:20:59 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E70DBE06BA for ; Thu, 21 Apr 2011 07:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VoOLPmN70QZi for ; Thu, 21 Apr 2011 07:20:57 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfc.amsl.com (Postfix) with ESMTP id 0F82BE00BE for ; Thu, 21 Apr 2011 07:20:56 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 1CEB0324476; Thu, 21 Apr 2011 16:20:56 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id F325535C045; Thu, 21 Apr 2011 16:20:55 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.10]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Thu, 21 Apr 2011 16:20:55 +0200 From: To: Simon Perreault Date: Thu, 21 Apr 2011 16:20:54 +0200 Thread-Topic: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response Thread-Index: AcwAIlHb/7Bxo/npQkSrWhiXNWcCzAACnUhw Message-ID: <94C682931C08B048B7A8645303FDC9F33C50DEF992@PUEXCB1B.nanterre.francetelecom.fr> References: <4DAF30DA.5040803@viagenie.ca> <94C682931C08B048B7A8645303FDC9F33C50DEF87A@PUEXCB1B.nanterre.francetelecom.fr> <4DB02771.9010805@viagenie.ca> In-Reply-To: <4DB02771.9010805@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.21.133323 Cc: "pcp@ietf.org" , "draft-boucadair-pcp-failure@tools.ietf.org" Subject: Re: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 14:21:00 -0000 Re-, Please see inline. Cheers, Med=20 -----Message d'origine----- De : Simon Perreault [mailto:simon.perreault@viagenie.ca]=20 Envoy=E9 : jeudi 21 avril 2011 14:48 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : draft-boucadair-pcp-failure@tools.ietf.org; pcp@ietf.org Objet : Re: [pcp] When a single mapping is too large to fit in a PCP GET/NE= XT response On 2011-04-21 07:46, mohamed.boucadair@orange-ftgroup.com wrote: > Note the GET mechanism allows to walk through mappings having the same in= ternal IP@/port, external IP@/port and retrieve the list of FILTERs (i.e., = distinct remote IP addresses/ports) if the same ordering is used to answer = two GET/NEXT requests; see the following example: Do you mean "allows as currently specified" or "could allow in a future draft revision"? I will assume the latter. Med: I meant the currently defined mechanism could allow for it if the Opti= ons are part of the Locator.=20 > | PCP GET Response | > | MORE | > | protocol=3D TCP | > | internal-ip-address=3D 198.51.100.2 | > | internal-port=3D 12354 | > | external-ip-address=3D 192.0.2.1 | > | external-port=3D 32654 | > | remaining-lifetime=3D 3600 | > | DESCRIPTION | > | "My mapping for Server_A" | > | FILTER | > | remote-ip-address=3D 1.2.3.4 | > | remote-port=3D 8965 | > | FILTER | > | remote-ip-address=3D 45.63.25.2 | > | remote-port=3D 1454 | > | FILTER | > | remote-ip-address=3D 45.6.5.5 | > | remote-port=3D 8965 | > | ... | > | FILTER | > | remote-port=3D 25659 | > | remaining-lifetime=3D 6000 | > |<----------------------------------| > | PCP GET Request | > | MORE | > | protocol=3D TCP | > | internal-ip-address=3D 198.51.100.2 | > | internal-port=3D 12354 | > | external-ip-address=3D 192.0.2.1 | > | external-port=3D 32654 | > | remaining-lifetime=3D 3600 | > | DESCRIPTION | > | "My mapping for Server_A" | > | FILTER | > | remote-ip-address=3D 1.2.3.4 | > | remote-port=3D 8965 | > | FILTER | > | remote-ip-address=3D 45.63.25.2 | > | remote-port=3D 1454 | > | FILTER | > | remote-ip-address=3D 45.6.5.5 | > | remote-port=3D 8965 | > | ... | > | FILTER | > | remote-port=3D 25659 | > | remaining-lifetime=3D 6000 | > |---------------------------------->| > | PCP GET Response | > | MORE | > | protocol=3D TCP | > | internal-ip-address=3D 198.51.100.2 | > | internal-port=3D 12354 | > | external-ip-address=3D 192.0.2.1 | > | external-port=3D 32654 | > | remaining-lifetime=3D 3600 | > | DESCRIPTION | > | "My mapping for Server_A" | > | FILTER | > | remote-ip-address=3D 11.22.25.1 | > | remote-port=3D 8965 | > | FILTER | > | remote-port=3D 25659 | > | remaining-lifetime=3D 6000 | > | MORE | > | protocol=3D TCP | > | internal-ip-address=3D 198.51.100.2 | > | internal-port=3D 12354 | > | external-ip-address=3D 192.0.2.1 | > | external-port=3D 32654 | > | remaining-lifetime=3D 3600 | > | END | > | protocol=3D TCP | > | internal-ip-address=3D 198.51.100.2 | > | internal-port=3D 8596 | > | external-ip-address=3D 192.0.2.1 | > | external-port=3D 25659 | > | remaining-lifetime=3D 6000 | > |<----------------------------------| Yeah, that's one of the "too complex" solutions I was thinking of. It also adds a new ordering constraint on all mapping options. I'm not saying it would not work, but it doesn't look appealing at this point. > Even if I think this is marginal for the NAT case, it would be useful to = have some guidelines in the GET specification when it occurs such as:=20 >=20 > * Options which apply to all mappings having the same internal IP @/port = are returned first > * "specific" options (eg. FILTER) are then returned in subsequent GET/NEX= T messages. If I understand this correctly, this would mitigate the problem but not eliminate it completely. It would just happen less often. So we would need something more. Med: IMO, this is would be sufficient for the CGN case. > Any suggestion is welcome. TCP? I'm not joking. To me, transferring state in bulk seems very appropriate for TCP. Med: Why not but as you know the base PCP supports only UDP. From mohamed.boucadair@orange-ftgroup.com Thu Apr 21 07:22:06 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 1E348E06BA for ; Thu, 21 Apr 2011 07:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3Yj9oDPY3XR for ; Thu, 21 Apr 2011 07:22:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfc.amsl.com (Postfix) with ESMTP id 40B69E00BE for ; Thu, 21 Apr 2011 07:22:05 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 13E1F3B4577; Thu, 21 Apr 2011 16:22:04 +0200 (CEST) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id EF3E5384061; Thu, 21 Apr 2011 16:22:03 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.10]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Thu, 21 Apr 2011 16:22:03 +0200 From: To: "Francis.Dupont@fdupont.fr" Date: Thu, 21 Apr 2011 16:22:02 +0200 Thread-Topic: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response Thread-Index: AcwAIaQaA03xARMJS/ysAeBn3zoFSQADbXUA Message-ID: <94C682931C08B048B7A8645303FDC9F33C50DEF993@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Thu, 21 Apr 2011 13:46:50 +0200. <94C682931C08B048B7A8645303FDC9F33C50DEF87A@PUEXCB1B.nanterre.francetelecom.fr> <201104211242.p3LCgsKT035193@givry.fdupont.fr> In-Reply-To: <201104211242.p3LCgsKT035193@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.21.124221 Cc: "pcp@ietf.org" , "draft-boucadair-pcp-failure@tools.ietf.org" Subject: Re: [pcp] When a single mapping is too large to fit in a PCP GET/NEXT response X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 14:22:06 -0000 Hi Francis, Yes, you are right.=20 If we extend the Locator to include the Mapping Options this would be possi= ble then. Cheers, Med =20 -----Message d'origine----- De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 Envoy=E9 : jeudi 21 avril 2011 14:43 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP Cc : Simon Perreault; draft-boucadair-pcp-failure@tools.ietf.org; pcp@ietf.= org Objet : Re: [pcp] When a single mapping is too large to fit in a PCP GET/NE= XT response=20 Mohammed, your example doesn't work because the option is not part of the locator. IMHO the obvious solution is to convert FILTER to OpCodes, something we should do anyway if we'd like to provide a real support to firewalls... * "specific" options (eg. FILTER) are then returned in subsequent GET/NE= XT messages. =20 =3D> subsequent =3D=3D current location is in the request. Regards Francis.Dupont@fdupont.fr PS: I don't see messages from the PCP ML itself (pcp@ietf.org)??? From dwing@cisco.com Thu Apr 21 09:35:13 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B307DE0788 for ; Thu, 21 Apr 2011 09:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.61 X-Spam-Level: X-Spam-Status: No, score=-110.61 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtgXhYpNs80t for ; Thu, 21 Apr 2011 09:35:13 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfc.amsl.com (Postfix) with ESMTP id DF3D9E0780 for ; Thu, 21 Apr 2011 09:35:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1198; q=dns/txt; s=iport; t=1303403712; x=1304613312; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=lpS+TGL1TSo4EncGyZ+9LjDY6UoH79jKoCemqPmMtDc=; b=J4AYwS2x+DK0t9AyP14FRSShng3GX7vV0Nju/aoxj3CMs6r0OYb6ixvl OGNJ6EL7qJ6b1kGCN4K8MxsM18dyWfAraiPw+HbZ+ypwr6uiHddgs3R+6 xcp45XFgoq8YVtJ4PHJkEcuVPDf93JyeRwHBL3FQ/yrgsBGRhVzI3yxET g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsBAHtcsE2rRDoI/2dsb2JhbACXQj+BJIwld4hwnlycXoV2BIV0jw8 X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="299393166" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2011 16:35:12 +0000 Received: from dwingWS (sjc-vpn5-1129.cisco.com [10.21.92.105]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3LGZB9V003194; Thu, 21 Apr 2011 16:35:12 GMT From: "Dan Wing" To: References: Your message of Thu, 21 Apr 2011 00:36:06 -0000. <083.830c1b4a1aa5cb732ce2f64f40f6a598@tools.ietf.org> <201104210811.p3L8BpbP018716@givry.fdupont.fr> In-Reply-To: <201104210811.p3L8BpbP018716@givry.fdupont.fr> Date: Thu, 21 Apr 2011 09:35:08 -0700 Message-ID: <003f01cc0042$141a4810$3c4ed830$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv/+8eN3PKsEEUvT72LYjiPF/DDYQARiqyw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 16:35:13 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, April 21, 2011 1:12 AM > To: pcp issue tracker > Cc: dwing@cisco.com; pcp@ietf.org > Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS > > The general problem is: > "some NAT implementations don't support to have an implicit dynamic > mapping and an explicit dynamic mapping using the same address and > port at the same time." > > base 08 section 8.9 solves only the case where the colliding port > is the external port, not the case the colliding port is the > internal port, so: I do not understand what is meant by 'the case the colliding port is the internal port'. Can you please walk me through an example, using port numbers and hosts? I don't get it. -d > I ask the section 8.9 to be removed as it doesn't fulfill its goal. > > I ask the IMPLICIT_MAPPING_EXISTS to be defined, I offer the > problem definition from this message. > > It is my last message about this issue: anyway PROCESSING_ERROR > can be used, it is just a shame to rely on such a generic error... > > Regards > > Francis.Dupont@fdupont.fr From dwing@cisco.com Thu Apr 21 09:37:25 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4ACB9E0780 for ; Thu, 21 Apr 2011 09:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.609 X-Spam-Level: X-Spam-Status: No, score=-110.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 677i9MdQc4jT for ; Thu, 21 Apr 2011 09:37:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 992F7E0663 for ; Thu, 21 Apr 2011 09:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=460; q=dns/txt; s=iport; t=1303403844; x=1304613444; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=i0QYCOpcx5xZZB4iC8lqiQFRSml4L/Yt8tCY/DJicYU=; b=Lrxke7Tvfl1f+M8Z5uKcf0gABLjGASBL5Rd+6BkRhg6y9caZSAwwwNkb g9YzNdgs79XUcjQjRPiZHh0OeswDswRARE8OTf+LlJ/q0WALeCqlpPE4+ 9MEASwaxE/r36dOD0PEYCJjV1GF9YFVvVPyU7nVI+opqHxSLzhy3ZFdoM 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsBAB9csE2rRDoJ/2dsb2JhbACXQT+BJIwld6dKnF+FdgSFdI8P X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="685309176" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 21 Apr 2011 16:37:23 +0000 Received: from dwingWS (sjc-vpn5-1129.cisco.com [10.21.92.105]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3LGbNPf002120; Thu, 21 Apr 2011 16:37:23 GMT From: "Dan Wing" To: References: Your message of Thu, 21 Apr 2011 00:37:56 -0000. <083.d8d4207ffa66e56dac60fc92f73b4bc8@tools.ietf.org> <201104210815.p3L8FVDA018975@givry.fdupont.fr> In-Reply-To: <201104210815.p3L8FVDA018975@givry.fdupont.fr> Date: Thu, 21 Apr 2011 09:37:20 -0700 Message-ID: <004301cc0042$628a3cd0$279eb670$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv//EoWrQK5eW78QPKRginAlUNhIQARgZxw Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] #46: NONEXIST_PEER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 16:37:25 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, April 21, 2011 1:16 AM > To: pcp issue tracker > Cc: dwing@cisco.com; pcp@ietf.org > Subject: Re: [pcp] #46: NONEXIST_PEER > > I disagree: it should not be closed until tickets it depends on > are not closed... (#46 for instance). > > Francis.Dupont@fdupont.fr Ticket #46 should not be closed until ticket #46 is closed?? -d From dwing@cisco.com Thu Apr 21 18:38:41 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 93F59E0721 for ; Thu, 21 Apr 2011 18:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.609 X-Spam-Level: X-Spam-Status: No, score=-110.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioCzJkvgJT+D for ; Thu, 21 Apr 2011 18:38:40 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id C405AE06E2 for ; Thu, 21 Apr 2011 18:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1224; q=dns/txt; s=iport; t=1303436320; x=1304645920; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=eBEK8m3y0bnO/tYU1xzOA05s049p+zTY1aJBlp9WyJY=; b=R/HLq+zpkkRm63/3b9HOoIu534+x4agd8fj1JdWEfZPVChLlPBlOfpMq zR8AtPOiemdmXvasiQi9VnquJfRjwG9hFfAK6O1iLd/fggEf4jU20DZw3 TwCW1ODiEAV1CXoygpIeo7SDiY72D++Xq5Kb6BTzBu/ZCc8SKYxo24+WT 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0BANvbsE2rRDoJ/2dsb2JhbACXUz+BJIwmd6cinGWFdgSFdI8S X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="434632642" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 22 Apr 2011 01:38:40 +0000 Received: from dwingWS (sjc-vpn6-1064.cisco.com [10.21.124.40]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3M1cd0e005556; Fri, 22 Apr 2011 01:38:40 GMT From: "Dan Wing" To: References: Your message of Thu, 21 Apr 2011 09:37:20 PDT. <004301cc0042$628a3cd0$279eb670$@com> <201104211747.p3LHlrg3053743@givry.fdupont.fr> In-Reply-To: <201104211747.p3LHlrg3053743@givry.fdupont.fr> Date: Thu, 21 Apr 2011 18:38:39 -0700 Message-ID: <007501cc008e$01fc4dd0$05f4e970$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwATEHlJnbrPicwQsaMiNyqNYYpcgANRT2A Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] #46: NONEXIST_PEER X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 01:38:41 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, April 21, 2011 10:48 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] #46: NONEXIST_PEER > > > In your previous mail you wrote: > > > -----Original Message----- > > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > > Sent: Thursday, April 21, 2011 1:16 AM > > To: pcp issue tracker > > Cc: dwing@cisco.com; pcp@ietf.org > > Subject: Re: [pcp] #46: NONEXIST_PEER > > > > I disagree: it should not be closed until tickets it depends on > > are not closed... (#46 for instance). > > > > Francis.Dupont@fdupont.fr > > Ticket #46 should not be closed until ticket #46 is closed?? > > => typo: s/46/48/ http://trac.tools.ietf.org/wg/pcp/trac/ticket/48 proposes to remove PEER. I do not agree that removing PEER would improve the protocol. And, based on these 4-5 tickets that have been open since IETF80, it seems few people care enough to comment about issues on the mailing list. As editor, in the absence of guidance from the WG, I am left to figure out what I think improves the protocol. -d From dwing@cisco.com Thu Apr 21 18:38:41 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E4106E06E2 for ; Thu, 21 Apr 2011 18:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.609 X-Spam-Level: X-Spam-Status: No, score=-110.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxdlrIvYa5BQ for ; Thu, 21 Apr 2011 18:38:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfc.amsl.com (Postfix) with ESMTP id 3985BE0719 for ; Thu, 21 Apr 2011 18:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1856; q=dns/txt; s=iport; t=1303436321; x=1304645921; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=rizr5AKkYNc3i5FgnyNDT60o7gX0uPCpB/K/hKMdVmw=; b=Zd/YdpOR/LaFUcUyvxiWePXn0dMoknrlcUM46Uou35b21m+1OSUgf47A aRy+dmGzpit91Sqk8Mu8HJL6US57bqlE65AVpdtzGznhPP8w1SqBBQLSU waULmHt45c4YTRHFzshyPNtyooevVY3PJ7wIJNdL2dHrSRvaRvvlGmh72 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao0BAGHbsE2rRDoJ/2dsb2JhbACXUz+BJIwmd6c9nGWFdgSFdI8S X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208";a="342480876" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-2.cisco.com with ESMTP; 22 Apr 2011 01:38:40 +0000 Received: from dwingWS (sjc-vpn6-1064.cisco.com [10.21.124.40]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3M1cd0f005556; Fri, 22 Apr 2011 01:38:40 GMT From: "Dan Wing" To: References: Your message of Thu, 21 Apr 2011 09:35:08 PDT. <003f01cc0042$141a4810$3c4ed830$@com> <201104211745.p3LHjVs5053614@givry.fdupont.fr> In-Reply-To: <201104211745.p3LHjVs5053614@givry.fdupont.fr> Date: Thu, 21 Apr 2011 18:38:39 -0700 Message-ID: <007601cc008e$0222c190$066844b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwAS+3aO3Owt35iTt69D8Dd2zqzvQANDJFA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 01:38:42 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Thursday, April 21, 2011 10:46 AM > To: Dan Wing > Cc: pcp@ietf.org > Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS > > > In your previous mail you wrote: > > > -----Original Message----- > > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > > Sent: Thursday, April 21, 2011 1:12 AM > > To: pcp issue tracker > > Cc: dwing@cisco.com; pcp@ietf.org > > Subject: Re: [pcp] #45: hoping to eliminate > IMPLICIT_MAPPING_EXISTS > > > > The general problem is: > > "some NAT implementations don't support to have an implicit > dynamic > > mapping and an explicit dynamic mapping using the same address and > > port at the same time." > > > > base 08 section 8.9 solves only the case where the colliding port > > is the external port, not the case the colliding port is the > > internal port, so: > > I do not understand what is meant by 'the case the colliding port > is the internal port'. > > Can you please walk me through an example, using port numbers and > hosts? I don't get it. > > => host address 192.168.0.1, protocol TCP, an application using > port 12345 to connect somewhere, so has created an implicit dynamic > mapping, and a service at the same port 12345, trying to create > an explicit dynamic mapping. So internal address is 192.168.0.1, > internal port is 12345. > Do you really need me to get an address, a protocol and a port? And you're saying this problem exists on non-EIM NATs, and is not solvable by the two mechanisms in http://tools.ietf.org/html/draft-ietf-pcp-base-08#section-8.9 (the ones marked with "1." and "2."). If so, then I expect we all need more details. -d From Francis.Dupont@fdupont.fr Fri Apr 22 04:33:39 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE804E06B6 for ; Fri, 22 Apr 2011 04:33:39 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8Tgdqf-QSUj for ; Fri, 22 Apr 2011 04:33:39 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfc.amsl.com (Postfix) with ESMTP id 2B6D5E06B1 for ; Fri, 22 Apr 2011 04:33:39 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p3MBXcex018605 for ; Fri, 22 Apr 2011 13:33:38 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201104221133.p3MBXcex018605@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Fri, 22 Apr 2011 13:33:38 +0200 Sender: Francis.Dupont@fdupont.fr Subject: [pcp] test X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 11:33:40 -0000 Chasing posting issues, PLEASE DON'T REPLY! Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Fri Apr 22 04:46:52 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 85743E06FF for ; Fri, 22 Apr 2011 04:46:52 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIlFskWMKiTV for ; Fri, 22 Apr 2011 04:46:52 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfc.amsl.com (Postfix) with ESMTP id B7C64E06E1 for ; Fri, 22 Apr 2011 04:46:51 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p3MBknQ3019389 for ; Fri, 22 Apr 2011 13:46:49 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201104221146.p3MBknQ3019389@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Fri, 22 Apr 2011 13:46:49 +0200 Sender: Francis.Dupont@fdupont.fr Subject: [pcp] mailing list issues X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 11:46:52 -0000 The mailing list box, mail.ietf.org, changed its IPv4 address but there is still something at the old address which blindly eats messages... So if you (as me since the 4th) send messages to pcp@ietf.org and you don't get it back, no answer for no recipient, no trace of the message in the archive (http://www.ietf.org/mail-archive/web/pcp/current/maillist.html) so you have the same problem than I had. I consider old messages are being lost (even I archive most messages I send) so I don't propose to try to get back at least one week of history. But this means no feedback is not always what it was intented too... Regards Francis.Dupont@fdupont.fr PS: I forced the IPv4 address of mail.ietf.org because a long time ago messages using SMTP over IPv6 were refused (lack of a PTR, fixed a long time ago but of course the workaround was not removed...). From Francis.Dupont@fdupont.fr Fri Apr 22 05:18:18 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AE6F3E068A for ; Fri, 22 Apr 2011 05:18:18 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il5FfAfTuf3d for ; Fri, 22 Apr 2011 05:18:18 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfc.amsl.com (Postfix) with ESMTP id 04933E067C for ; Fri, 22 Apr 2011 05:18:17 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p3MCIHPP021407 for ; Fri, 22 Apr 2011 14:18:17 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201104221218.p3MCIHPP021407@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Fri, 22 Apr 2011 14:18:17 +0200 Sender: Francis.Dupont@fdupont.fr Subject: [pcp] maximum lifetime X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 12:18:18 -0000 The current base spec in section 8.6 page 34 RECOMMEND a maximum assigned lifetime of 24 hours. It makes sense for PCP itself but is not compatible with UPnP IGD 2: - I don't consider IGD 1 as it will be replaced by IGD 2 and about this particular point one can easily argue it was broken and fixed by IGD 2. - maximum IGD 2 PortMappingLeaseDuration is 604800 seconds (i.e., 7 days) - when a UPnP IGD 2 IWF creates an explicit dynamic mapping for a long lifetime, it renews the PCP mapping before it expires to make its apparent (to the IGD control point) lifetime equals to the PortMappingLeaseDuration - now if such a renewal PCP request fails the IWF has no way to recover. So I ask a new ticket to discuss about: - to increase the RECOMMEND maximum value at at least 7 days - to explain this value in order to make implementors or managers who could want to use a lower value aware of the consequences on UPnP IGD 2 IWF. Regards Francis.Dupont@fdupont.fr From mohamed.boucadair@orange-ftgroup.com Fri Apr 22 05:40:17 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 72057E067C for ; Fri, 22 Apr 2011 05:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnMoIDf6i8mI for ; Fri, 22 Apr 2011 05:40:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfc.amsl.com (Postfix) with ESMTP id B4402E0664 for ; Fri, 22 Apr 2011 05:40:16 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 7C79DC0153; Fri, 22 Apr 2011 14:40:15 +0200 (CEST) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 63AF9C8061; Fri, 22 Apr 2011 14:40:15 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.10]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Fri, 22 Apr 2011 14:40:15 +0200 From: To: Francis Dupont , "pcp@ietf.org" Date: Fri, 22 Apr 2011 14:40:13 +0200 Thread-Topic: [pcp] maximum lifetime Thread-Index: AcwA516itonQxE9NSk+0/raRjQfRigAAj4kg Message-ID: <94C682931C08B048B7A8645303FDC9F33C50DEFCE2@PUEXCB1B.nanterre.francetelecom.fr> References: <201104221218.p3MCIHPP021407@givry.fdupont.fr> In-Reply-To: <201104221218.p3MCIHPP021407@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.22.120320 Subject: Re: [pcp] maximum lifetime X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 12:40:17 -0000 Hi Francis, Wouldn't be more appropriate to discuss this point in the UPnP/PCP IWF docu= ment rather than the base PCP spec?=20 Note that recommending a longer lifetime would have some side effects such = as maintaining stale mappings for a long period (i.e., consume per-user quo= ta). Cheers, Med -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Franc= is Dupont Envoy=E9 : vendredi 22 avril 2011 14:18 =C0 : pcp@ietf.org Objet : [pcp] maximum lifetime The current base spec in section 8.6 page 34 RECOMMEND a maximum assigned lifetime of 24 hours. It makes sense for PCP itself but is not compatible with UPnP IGD 2: - I don't consider IGD 1 as it will be replaced by IGD 2 and about this particular point one can easily argue it was broken and fixed by IGD 2. - maximum IGD 2 PortMappingLeaseDuration is 604800 seconds (i.e., 7 days) - when a UPnP IGD 2 IWF creates an explicit dynamic mapping for a long lifetime, it renews the PCP mapping before it expires to make its apparent (to the IGD control point) lifetime equals to the PortMappingLeaseDuration - now if such a renewal PCP request fails the IWF has no way to recover. So I ask a new ticket to discuss about: - to increase the RECOMMEND maximum value at at least 7 days - to explain this value in order to make implementors or managers who could want to use a lower value aware of the consequences on UPnP IGD 2 IWF. Regards Francis.Dupont@fdupont.fr _______________________________________________ pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From Francis.Dupont@fdupont.fr Fri Apr 22 05:42:44 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D25E0E067C; Fri, 22 Apr 2011 05:42:44 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxOHQzPlvy-2; Fri, 22 Apr 2011 05:42:44 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfc.amsl.com (Postfix) with ESMTP id 231D2E0664; Fri, 22 Apr 2011 05:42:44 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p3MCghWW022871; Fri, 22 Apr 2011 14:42:43 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201104221242.p3MCghWW022871@givry.fdupont.fr> From: Francis Dupont To: pcp@ietf.org Date: Fri, 22 Apr 2011 14:42:43 +0200 Sender: Francis.Dupont@fdupont.fr Cc: behave@ietf.org Subject: [pcp] about PCP (in)security X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 12:42:45 -0000 I am afraid the current specs don't correctly assume the fact PCP no longer applies to residential gateways as NAT-PMP does, but is intended to be used with CGNs which have some critical security constraints (something clear now the definition of a CGN is based on security considerations). There are IMHO two ways to solve this problem: - to get all the security sensible requirements in the BEHAVE CGN requirements document and refers to it. This has some obvious drawbacks, in particular this creates a normative reference to a document which is far to be published if it will be one day. - the other solution is to duplicate the work and to put these requirements in the PCP base specs. Of course this is not fine: these requirements are not in general specific to PCP, it is a duplicated and out of scope work, etc. PCP WG chairs want to follow a third way: do nothing. I send this message to express my formal disapproval to this (non) solution. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Fri Apr 22 05:52:18 2011 Return-Path: X-Original-To: pcp@ietfc.amsl.com Delivered-To: pcp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E0D5DE067C for ; Fri, 22 Apr 2011 05:52:18 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqtri8NS-fPv for ; Fri, 22 Apr 2011 05:52:18 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfc.amsl.com (Postfix) with ESMTP id 2AC71E0664 for ; Fri, 22 Apr 2011 05:52:18 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p3MCqHJu023495; Fri, 22 Apr 2011 14:52:17 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201104221252.p3MCqHJu023495@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange-ftgroup.com In-reply-to: Your message of Fri, 22 Apr 2011 14:40:13 +0200. <94C682931C08B048B7A8645303FDC9F33C50DEFCE2@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 22 Apr 2011 14:52:17 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "pcp@ietf.org" Subject: Re: [pcp] maximum lifetime X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 12:52:19 -0000 In your previous mail you wrote: Wouldn't be more appropriate to discuss this point in the UPnP/PCP IWF document rather than the base PCP spec? => the recommendation is in the base spec. Perhaps you mean the explaination should be in the UPnP IGD IWF document and base spec should only refer to it? If the ticket is addressed the common way you are losing your time... Note that recommending a longer lifetime would have some side effects such as maintaining stale mappings for a long period (i.e., consume per-user quota). => I know: this is why I said it makes sense for PCP itself. Regards Francis.Dupont@fdupont.fr From dwing@cisco.com Mon Apr 25 22:00:25 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0E2E06EA for ; Mon, 25 Apr 2011 22:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.329 X-Spam-Level: X-Spam-Status: No, score=-110.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oarOXc5hmpjb for ; Mon, 25 Apr 2011 22:00:24 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 843F2E06D2 for ; Mon, 25 Apr 2011 22:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2853; q=dns/txt; s=iport; t=1303794024; x=1305003624; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=6Pzi+IVGgQNmR4oWViXFz0ReXQPpy6HwsbcIKf6R54s=; b=S7wxcBSp3S11PPe/V3wSTtALgQrvJ8tDKoDrIHGDH31UpNY6R+OUBZ+A 78qKq9dyjk+qaj0Ax1NRIVD/DLo4tb3zPhDKhYymYoQUI1RjEaapbxMTs F/OYy6GV8X3Itq5Mt/Cx8Yzi4FAOKFjeVMJ1RrdhL5wMZpTROD1MIB1x6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowHAEBQtk2rRDoI/2dsb2JhbACYFYEkjAN3qAydD4V2BIV3 X-IronPort-AV: E=Sophos;i="4.64,267,1301875200"; d="scan'208";a="686969271" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-6.cisco.com with ESMTP; 26 Apr 2011 05:00:24 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3Q50OuR021104 for ; Tue, 26 Apr 2011 05:00:24 GMT From: "Dan Wing" To: Date: Mon, 25 Apr 2011 22:00:24 -0700 Message-ID: <04c901cc03ce$da0e0540$8e2a0fc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwDztndZJn71T2fT0ybjr7A3iJ3mQ== Content-Language: en-us Subject: [pcp] pcp-base-09 posted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 05:00:25 -0000 pcp-base-09 has been posted. Document is at . Side by side differences from -08 is at http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-09.txt -d ----- B.1. Changes from draft-ietf-pcp-base-08 to -09 o Clarified in PEER OpCode introduction (Section 9) that they can also create mappings (as well as query and set existing mappings). o More clearly explained how PEER can re-create an implicit dynamic mapping, for purposes of rebuilding state to maintain an existing session (e.g., long-lived TCP connection to a server). o Added Suggested External IP Address to the PEER OpCodes, to allow more robust rebuilding of connections. Added related text to the PEER server processing section. o Removed text encouraging PCP server to statefully remember its mappings from Section 11.2.1, as it didn't belong there. Text in Section 13.4 already encourages persistent storage. o More clearly discussed how PEER is used to re-establish TCP mapping state. Moved it to a new section, as well (it is now Section 7.3). o MAP errors now copy the Requested IP Address (and port) fields to Assigned IP Address (and port), to allow PCP client to distinguish among many outstanding requests when using PREFER_FAILURE. o Mapping theft can also be mitigated by ensuring hosts can't re-use same IP address or port after state loss. o the UNPROCESSED option is renumbered to 0 (zero), which ensures no other option will be given 0 and be unable to be expressed by the UNPROCESSED option (due to its 0 padding). o created new Implementation Considerations section (Section 11) which discusses non-normative things that might be useful to implementors. Some new text is in here, and the Failure Scenarios text (Section 11.2) has been moved to here. o Tweaked wording of non-EIM NATs in Section 11.1 to clarify the problem occurs both inside->outside and outside->inside. o removed "Interference by Other Applications on Same Host" section from security considerations. o fixed zero/non-zero text in Section 8.6. o removed duplicate text saying MAP is allowed to delete an implicit dynamic mapping. It is still allowed to do that, but it didn't need to be said twice in the same paragraph. o Renamed error from UNAUTH_TARGET_ADDRESS to UNAUTH_THIRD_PARTY_INTERNAL_ADDRESS. o for FILTER option, removed unnecessary detail on how FILTER would be bad for PEER, as it is only allowed for MAP anyway. o In Security Considerations, explain that PEER can create a mapping which makes its security considerations the same as MAP. From simon.perreault@viagenie.ca Tue Apr 26 05:50:30 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83308E075D for ; Tue, 26 Apr 2011 05:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZDR6CW-EDeN for ; Tue, 26 Apr 2011 05:50:29 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 704D7E075A for ; Tue, 26 Apr 2011 05:50:29 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3661E21100; Tue, 26 Apr 2011 08:50:28 -0400 (EDT) Message-ID: <4DB6BF93.3010807@viagenie.ca> Date: Tue, 26 Apr 2011 08:50:27 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: draft-ietf-pcp-base@tools.ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" Subject: [pcp] PEER response should have same length as request X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 12:50:30 -0000 In draft-ietf-pcp-base-09, section 9.1, we have these figures: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Reserved (24 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internal Port | Suggested External Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Peer Port | Reserved (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Remote Peer IP Address (32 bits if PEER4, 128 bits if PEER6) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Suggested External IP address (always 128 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: PEER OpCode Request Packet Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | External_AF | Reserved (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Internal Port | External Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Remote Peer Port | Reserved (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Remote Peer IP Address (32 bits if PEER4, 128 bits if PEER6) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : External IP Address (32 bits if External_AF indicates IPv4 : : 128 bits if External_AF indicates IPv6) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: PEER OpCode Response Packet Format The problem is with the response's "External IP address" field. It is either 32 bits or 128 bits long depending on the contents of External_AF. The corresponding "Suggested External IP address" field is always 128 bits. This means that the response's length may be different from the request. This differs from MAP and I think it should be avoided to simplify server code. Therefore, I suggest that "External IP address" be always 128 bits, zero-padded when External-AF is IPv4. Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From simon.perreault@viagenie.ca Tue Apr 26 07:57:45 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90557E0772 for ; Tue, 26 Apr 2011 07:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjS+dqCTQLrZ for ; Tue, 26 Apr 2011 07:57:44 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB75E0769 for ; Tue, 26 Apr 2011 07:57:44 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 54B3A21F21; Tue, 26 Apr 2011 10:57:43 -0400 (EDT) Message-ID: <4DB6DD66.7060202@viagenie.ca> Date: Tue, 26 Apr 2011 10:57:42 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: draft-ietf-pcp-base@tools.ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" Subject: [pcp] Multiple issues with PEER external address X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 14:57:45 -0000 Issue 1: For the request, we have: Suggested External IP Address: always 128 reserved bits. If an IPv4 address, it is placed into the first 32 bits and the other 96 bits MUST be 0. Note that the External_AF field is not present in the request; this is by design so that 128 bits are unambiguously present in this field, no matter if an IPv4 or IPv6 address is present. The issue here is how to determine if this is supposed to be an IPv4 address or an IPv6 address. There is no External_AF field so we cannot use that as we would for the response. And the length is fixed to 128 bits so we cannot use that either. And there is no guarantee that it will be IPv4 for PEER4 and IPv6 for PEER6, because it would not hold for a mixed-family NAT (e.g. NAT64). Suggestion: Add External_AF to the request. Make the suggested external address length depend on it (32 bits for IPv4, 128 bits for IPv6). Make the response copy the External_AF value, so that the length of corresponding request and response is identical. This implies that error responses would no longer set External_AF to IPv4. (This suggestion overrides my previous one about fixing the response length to 128 bits.) Issue 2: For the response we have: External IP Address: For success responses, this contains the external IP address, assigned by the NAT (or firewall) to this mapping. This field allows the PCP client and its remote peer to determine if there is another NAT between the PCP-controlled NAT and remote peer. If the PCP-controlled device is a firewall, this will match the internal IP address. This field is 128 bits long if External_AF indicates IPv6, or 32 bits long if External_AF indicates IPv4. For error responses, this MUST be 0 (and is 32 bits long, because External_AF is IPv4 for error responses). The problem is with the last sentence. Since we now have a suggested external address in the request, we could do as we now do for MAP and simply copy the request's value in the response. It would have the same benefits as it has for MAP. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Tue Apr 26 11:36:15 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07939E0758 for ; Tue, 26 Apr 2011 11:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.359 X-Spam-Level: X-Spam-Status: No, score=-110.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crD0lma3GjBu for ; Tue, 26 Apr 2011 11:36:13 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 66D28E0715 for ; Tue, 26 Apr 2011 11:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3082; q=dns/txt; s=iport; t=1303842973; x=1305052573; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=G5b7ObhmXubYI1Njt8g3HHHCVBMd9JOrMVG19f7w/qE=; b=ct9Vp5x1E10hNsrcpZS172jETJJk1l/vaQw8a96QHe61SjFn2YQc7leb Qqz3mlAT8lN9Pca4ZLr4JMBS5GAjdwGgbCxD/KJHOkd+uLf1qZWjjlsOa RBBEDMH//LxtDXs2VCL0mrMT1SBE4gT4kBid6y6uUCzJaeQKgHypSq/8x s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgBAFEQt02rRDoI/2dsb2JhbACXdoFjhXCGGnepQp0qhXYEhX2XBA X-IronPort-AV: E=Sophos;i="4.64,270,1301875200"; d="scan'208";a="302420669" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2011 18:36:13 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3QIaCvu031847; Tue, 26 Apr 2011 18:36:13 GMT From: "Dan Wing" To: "'Simon Perreault'" , References: <4DB6DD66.7060202@viagenie.ca> In-Reply-To: <4DB6DD66.7060202@viagenie.ca> Date: Tue, 26 Apr 2011 11:36:12 -0700 Message-ID: <071701cc0440$d18ae2e0$74a0a8a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwEIlPnWmYpjOVjQMmSS1GpT0/AWwAHNNZA Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] Multiple issues with PEER external address X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 18:36:15 -0000 Thanks. These will be corrected in -10. (I don't recall why I was reluctant to include External_AF in the PEER request. I'll blame it on the mushrooms.) -d > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Simon Perreault > Sent: Tuesday, April 26, 2011 7:58 AM > To: draft-ietf-pcp-base@tools.ietf.org > Cc: pcp@ietf.org > Subject: [pcp] Multiple issues with PEER external address > > Issue 1: > > For the request, we have: > > Suggested External IP Address: always 128 reserved bits. If an > IPv4 > address, it is placed into the first 32 bits and the other 96 > bits > MUST be 0. Note that the External_AF field is not present in the > request; this is by design so that 128 bits are unambiguously > present in this field, no matter if an IPv4 or IPv6 address is > present. > > The issue here is how to determine if this is supposed to be an IPv4 > address or an IPv6 address. There is no External_AF field so we cannot > use that as we would for the response. And the length is fixed to 128 > bits so we cannot use that either. And there is no guarantee that it > will be IPv4 for PEER4 and IPv6 for PEER6, because it would not hold > for > a mixed-family NAT (e.g. NAT64). > > Suggestion: Add External_AF to the request. Make the suggested external > address length depend on it (32 bits for IPv4, 128 bits for IPv6). Make > the response copy the External_AF value, so that the length of > corresponding request and response is identical. This implies that > error > responses would no longer set External_AF to IPv4. > > (This suggestion overrides my previous one about fixing the response > length to 128 bits.) > > > Issue 2: > > For the response we have: > > External IP Address: For success responses, this contains the > external IP address, assigned by the NAT (or firewall) to this > mapping. This field allows the PCP client and its remote peer to > determine if there is another NAT between the PCP-controlled NAT > and remote peer. If the PCP-controlled device is a firewall, > this > will match the internal IP address. This field is 128 bits long > if External_AF indicates IPv6, or 32 bits long if External_AF > indicates IPv4. For error responses, this MUST be 0 (and is 32 > bits long, because External_AF is IPv4 for error responses). > > The problem is with the last sentence. Since we now have a suggested > external address in the request, we could do as we now do for MAP and > simply copy the request's value in the response. It would have the same > benefits as it has for MAP. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From mohamed.boucadair@orange-ftgroup.com Wed Apr 27 00:45:04 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0822FE0716 for ; Wed, 27 Apr 2011 00:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pvN9RveQcUe for ; Wed, 27 Apr 2011 00:44:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 9F12DE06FB for ; Wed, 27 Apr 2011 00:44:59 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 5FCF9324436; Wed, 27 Apr 2011 09:44:58 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 445724C015; Wed, 27 Apr 2011 09:44:58 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.10]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 27 Apr 2011 09:44:58 +0200 From: To: Dave Thaler , "pcp@ietf.org" Date: Wed, 27 Apr 2011 09:44:56 +0200 Thread-Topic: Comments on draft-bpw-pcp-dhcp-03.txt Thread-Index: AcvtYQLf1SLSd68SQ7y5b/O2nI8iKQXTXIZQ Message-ID: <94C682931C08B048B7A8645303FDC9F33C5120D14D@PUEXCB1B.nanterre.francetelecom.fr> References: <9B57C850BB53634CACEC56EF4853FF653B0064EA@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B0064EA@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.4.27.63314 Subject: Re: [pcp] Comments on draft-bpw-pcp-dhcp-03.txt X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 07:45:04 -0000 Dear Dave, all, Many thanks for your review and comments. We received also a detailed revie= w from Tomasz. A new version taking into account your comments and those of Tomasz has bee= n submitted. The new version is available at: https://datatracker.ietf.org/= doc/draft-bpw-pcp-dhcp/ FWIW, the diff can be found at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-bpw-pcp-dhcp-04 Any further comment is welcome. Cheers, Med =20 -----Message d'origine----- De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Dave = Thaler Envoy=E9 : lundi 28 mars 2011 20:19 =C0 : pcp@ietf.org Objet : [pcp] Comments on draft-bpw-pcp-dhcp-03.txt [personal opinions, no hats] I think this draft is a good starting point but has a couple of significant= problems that need to be fixed in my opinion. A summary is: 1) As written, it explicitly depends on DNS. Since this option is configur= ing a PCP client, *not* a DNS resolver, I do not believe this is appropriat= e. The PCP protocol should have no hard dependency on the DNS protocol. = Instead it should be configuring domain names, or "strings" that are passed= to a name resolution library. As explained in RFC 3493 and RFC 6055 and t= he POSIX API spec, name resolution APIs are NOT tied to DNS, but are protoc= ol agnostic. DNS is one of several mechanisms by which the name can be re= solved (others include hosts file, mDNS, LLMNR, NetBios, etc., and that's i= f the string isn't an IP literal). =20 2) As written, it may require code changes to DHCPv6 implementations. DHC= Pv6 clients and DHCPv6 servers that already support arbitrary options shoul= d be able to be compliant without any code changes. This is not the DHC W= G and we are not chartered to make DHCP protocol changes. I think the draf= t should just be defining options in a way that is consistent with the exis= ting protocol, and I believe it is straightforward to do so. 3) This copies some things that more properly belong in the PCP base spec, = or are already mentioned in the DHCP protocol spec and need not repeated (a= nd certainly not normatively). For detailed comments on specific text, refer to the attached PDF. -Dave From xiaohong.deng@orange-ftgroup.com Wed Apr 27 03:02:03 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB856E0698 for ; Wed, 27 Apr 2011 03:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaxCPeQiwgM9 for ; Wed, 27 Apr 2011 03:01:59 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 69886E068B for ; Wed, 27 Apr 2011 03:01:59 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5AF2C858008; Wed, 27 Apr 2011 12:08:31 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 53131858003; Wed, 27 Apr 2011 12:08:31 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 27 Apr 2011 12:01:57 +0200 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, 27 Apr 2011 18:01:53 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC016ED0E5@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0f7901cbf965$ea64aa70$bf2dff50$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS Thread-Index: AcvpgbZjqATPUsFnRFan3ixj2Y8FqQAlk4zAAAdKXvAAJLt/0AAPaQzwAI5RLNAAAOWpIAAs7yOgAARenKAAt94SIAIfj1bAAtYosmA= References: <0cb801cbe29e$ee401b80$cac05280$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01621A9D@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01621DA1@ch-mailsrv.rd.francetelecom.fr> <65E8E82B-3C4A-479A-B158-76E56E96DC47@apple.com> <0962B0BEF842A24191AD9BE41A8DD2FC01621FE6@ch-mailsrv.rd.francetelecom.fr> <1e6601cbea35$abd8f5c0$038ae140$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016221BC@ch-mailsrv.rd.francetelecom.fr> <22fd01cbeb06$c4793500$4d6b9f00$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E41B@ch-mailsrv.rd.francetelecom.fr> <03e101cbed42$d80d0ef0$88272cd0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E634@ch-mailsrv.rd.francetelecom.fr> <095601cbee08$9ef0c780$dcd25680$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> <0f7901cbf965$ea64aa70$bf2dff50$@com> From: To: , X-OriginalArrivalTime: 27 Apr 2011 10:01:57.0987 (UTC) FILETIME=[251F3330:01CC04C2] Cc: pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 10:02:04 -0000 |> However, when it comes to PCP UPnP IWF, there is another issue=20 |> according to our PCP UPnP IWF tests. |>=20 |> It is likely that after an UPnP 1.0 client has established a dynamic=20 |> session on an internal port, it will then requests the same internal=20 |> port/external port to be forwarded, which will fail even if=20 |"promote"=20 |> the conflict implicit mapping to the explicit mapping, because the=20 |> external port ( a random port ) is unlikely to be the same as the=20 |> internal port for implicit mappings but UPnP 1.0 asks for a specific=20 |> port (internal port) as the external port. | |We should be able to make that work with PCP, as well, even=20 |with a (so-called) "endpoint-dependent mapping" NAT. (I say=20 |"so-called" |because the issue isn't really EDM, but rather the issue is=20 |"port overloading" or "port reuse"). How does PCP server act when an IWF issues a request with=20 PREFER_FAILURE Option indicating the same Internal ip and=20 internal port as an implicit mapping?=20 In the current version (-09), section 11.1." Implementing MAP with non-EIM NATs" will make it work, and assumes an EIM NAT doesn't suffer this problem. However EIM NAT is highly likely to fail this request, because it is unlikely to make the PCP request reuse the same mapping/external port as the implicit mapping, since the requested external port is unlikely to be the same as the=20 one that implicit mapping is using. | |> Yet, it should not fail if you assume explicit mappings should prior=20 |> to implicit mappings. | |I'll work on some text for that. | |-d BR, Xiaohong opensource A+P: http://opensourceaplusp.weebly.com/ From simon.perreault@viagenie.ca Wed Apr 27 06:34:33 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC94AE06EC for ; Wed, 27 Apr 2011 06:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzjvC7z7ue+D for ; Wed, 27 Apr 2011 06:34:28 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 566BAE06DD for ; Wed, 27 Apr 2011 06:34:28 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C674B20D01; Wed, 27 Apr 2011 09:34:25 -0400 (EDT) Message-ID: <4DB81B61.8040001@viagenie.ca> Date: Wed, 27 Apr 2011 09:34:25 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: draft-boucadair-pcp-rtp-rtcp@tools.ietf.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "pcp@ietf.org" Subject: [pcp] MAP with PORT_RESERVATION_OPTION on existing mapping X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 13:34:33 -0000 Hi, How should a PCP server react when it receives a MAP request with a PORT_RESERVATION_OPTION and it turns out that the mapping already exists? This can happen with retransmissions, for example. Trying to refresh both mappings seems to go against text in section 5. ("Two mappings are therefore instantiated by the PCP Server with the same lifetime value. These mappings are treated as any individual mapping.") It's possible that the server would have no way to find the second mapping given the first since they're not linked. On the other hand, returning an error would go against the PCP design principle of indempotence. So I suggest that a MAP request with PORT_RESERVATION_OPTION on an existing mapping would refresh the first mapping and return success, just as a normal MAP request would. The second mapping would be unmodified. It would be refreshed separately, as shown in the examples. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Wed Apr 27 08:09:23 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E01E070B for ; Wed, 27 Apr 2011 08:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.412 X-Spam-Level: X-Spam-Status: No, score=-110.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+J9jtJuV7WW for ; Wed, 27 Apr 2011 08:09:19 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 61BB6E06DD for ; Wed, 27 Apr 2011 08:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2293; q=dns/txt; s=iport; t=1303916959; x=1305126559; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=o9E5q6Fh3mcuyFg83ADdhaOweWhFeH4IEBRZxQ5adsQ=; b=dJ9ZfLYMhjvkxgOkeOVQgDLE5NQGBTGauhVO2E3lr3y7Ko6POXe3FPfq HXxq3ndvAvJKhK8LutHjtakkpLDeLBmtsoyO/Ykmz3BHe0oS32O2FwSpn 0Viauj5YJRLAvH+CbwSrBSqhUB9iyG23u75OMz39BE8Y5mDGBb6jQMyMq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsBAHQwuE2rRDoH/2dsb2JhbACXf4FjjAp3pnacd4V2BIYDjzqHYA X-IronPort-AV: E=Sophos;i="4.64,274,1301875200"; d="scan'208";a="303200077" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 27 Apr 2011 15:09:18 +0000 Received: from dwingWS ([10.32.240.195]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RF9I5E014433; Wed, 27 Apr 2011 15:09:18 GMT From: "Dan Wing" To: , References: <0cb801cbe29e$ee401b80$cac05280$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01621A9D@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01621DA1@ch-mailsrv.rd.francetelecom.fr> <65E8E82B-3C4A-479A-B158-76E56E96DC47@apple.com> <0962B0BEF842A24191AD9BE41A8DD2FC01621FE6@ch-mailsrv.rd.francetelecom.fr> <1e6601cbea35$abd8f5c0$038ae140$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016221BC@ch-mailsrv.rd.francetelecom.fr> <22fd01cbeb06$c4793500$4d6b9f00$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E41B@ch-mailsrv.rd.francetelecom.fr> <03e101cbed42$d80d0ef0$88272cd0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E634@ch-mailsrv.rd.francetelecom.fr> <095601cbee08$9ef0c780$dcd25680$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> <0f7901cbf965$ea64aa70$bf2dff50$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016ED0E5@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC016ED0E5@ch-mailsrv.rd.francetelecom.fr> Date: Wed, 27 Apr 2011 08:09:17 -0700 Message-ID: <013001cc04ed$14550c20$3cff2460$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvpgbZjqATPUsFnRFan3ixj2Y8FqQAlk4zAAAdKXvAAJLt/0AAPaQzwAI5RLNAAAOWpIAAs7yOgAARenKAAt94SIAIfj1bAAtYosmAAC6vpAA== Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 15:09:23 -0000 > -----Original Message----- > From: xiaohong.deng@orange-ftgroup.com [mailto:xiaohong.deng@orange- > ftgroup.com] > Sent: Wednesday, April 27, 2011 3:02 AM > To: dwing@cisco.com; cheshire@apple.com > Cc: pcp@ietf.org > Subject: RE:[pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS > > |> However, when it comes to PCP UPnP IWF, there is another issue > |> according to our PCP UPnP IWF tests. > |> > |> It is likely that after an UPnP 1.0 client has established a dynamic > |> session on an internal port, it will then requests the same internal > |> port/external port to be forwarded, which will fail even if > |"promote" > |> the conflict implicit mapping to the explicit mapping, because the > |> external port ( a random port ) is unlikely to be the same as the > |> internal port for implicit mappings but UPnP 1.0 asks for a specific > |> port (internal port) as the external port. > | > |We should be able to make that work with PCP, as well, even > |with a (so-called) "endpoint-dependent mapping" NAT. (I say > |"so-called" > |because the issue isn't really EDM, but rather the issue is > |"port overloading" or "port reuse"). > > How does PCP server act when an IWF issues a request with > PREFER_FAILURE Option indicating the same Internal ip and > internal port as an implicit mapping? > > In the current version (-09), section 11.1." Implementing MAP with > non-EIM > NATs" will make it work, and assumes an EIM NAT doesn't suffer this > problem. > > However EIM NAT is highly likely to fail this request, because it is > unlikely to > make the PCP request reuse the same mapping/external port as the > implicit > mapping, since the requested external port is unlikely to be the same > as > the > one that implicit mapping is using. PREFER_FAILURE just says "if the PCP server cannot provide the Requested External Port, return an error". It doesn't control anything related to EDM or non-EDM NATs, and doesn't control or influence re-use of an implicit dynamic mapping. -d > | > |> Yet, it should not fail if you assume explicit mappings should prior > |> to implicit mappings. > | > |I'll work on some text for that. > | > |-d > > BR, > Xiaohong > opensource A+P: http://opensourceaplusp.weebly.com/ From xiaohong.deng@orange-ftgroup.com Wed Apr 27 21:50:34 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741FDE089F for ; Wed, 27 Apr 2011 21:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYFekbjVSxjo for ; Wed, 27 Apr 2011 21:50:33 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 723A6E0685 for ; Wed, 27 Apr 2011 21:50:32 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6D040FC4004; Thu, 28 Apr 2011 06:50:39 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 5DB24FC4001; Thu, 28 Apr 2011 06:50:39 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Apr 2011 06:50:30 +0200 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: Thu, 28 Apr 2011 12:50:26 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC016ED208@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <013001cc04ed$14550c20$3cff2460$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS Thread-Index: AcvpgbZjqATPUsFnRFan3ixj2Y8FqQAlk4zAAAdKXvAAJLt/0AAPaQzwAI5RLNAAAOWpIAAs7yOgAARenKAAt94SIAIfj1bAAtYosmAAC6vpAAAci1Mg References: <0cb801cbe29e$ee401b80$cac05280$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01621A9D@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01621DA1@ch-mailsrv.rd.francetelecom.fr> <65E8E82B-3C4A-479A-B158-76E56E96DC47@apple.com> <0962B0BEF842A24191AD9BE41A8DD2FC01621FE6@ch-mailsrv.rd.francetelecom.fr> <1e6601cbea35$abd8f5c0$038ae140$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016221BC@ch-mailsrv.rd.francetelecom.fr> <22fd01cbeb06$c4793500$4d6b9f00$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E41B@ch-mailsrv.rd.francetelecom.fr> <03e101cbed42$d80d0ef0$88272cd0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E634@ch-mailsrv.rd.francetelecom.fr> <095601cbee08$9ef0c780$dcd25680$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> <0f7901cbf965$ea64aa70$bf2dff50$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016ED0E5@ch-mailsrv.rd.francetelecom.fr> <013001cc04ed$14550c20$3cff2460$@com> From: To: , X-OriginalArrivalTime: 28 Apr 2011 04:50:30.0812 (UTC) FILETIME=[CD1C55C0:01CC055F] Cc: pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 04:50:34 -0000 |> How does PCP server act when an IWF issues a request with=20 |> PREFER_FAILURE Option indicating the same Internal ip and internal=20 |> port as an implicit mapping? |>=20 |> In the current version (-09), section 11.1." Implementing MAP with=20 |> non-EIM NATs" will make it work, and assumes an EIM NAT doesn't=20 |> suffer this problem. |>=20 |> However EIM NAT is highly likely to fail this request,=20 |because it is=20 |> unlikely to make the PCP request reuse the same=20 |mapping/external port=20 |> as the implicit mapping, since the requested external port=20 |is unlikely=20 |> to be the same as the one that implicit mapping is using. | |PREFER_FAILURE just says "if the PCP server cannot provide the=20 |Requested External Port, return an error". It doesn't control=20 |anything related to EDM or non-EDM NATs, and doesn't control=20 |or influence re-use of an implicit dynamic mapping. Are you suggesting PREFER_FAILURE should fail even if it's due to=20 internal port confilict (with an exist implicit mapping) instead of external port unavailable? BR, Xiaohong opensource A+P: http://opensourceaplusp.weebly.com/ | |-d | | |> | |> |> Yet, it should not fail if you assume explicit mappings should=20 |> |> prior to implicit mappings. |> | |> |I'll work on some text for that. |> | |> |-d |>=20 From dwing@cisco.com Wed Apr 27 23:36:24 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F27E064B for ; Wed, 27 Apr 2011 23:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p33x5wc1KXCK for ; Wed, 27 Apr 2011 23:36:23 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 94BE9E062A for ; Wed, 27 Apr 2011 23:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1824; q=dns/txt; s=iport; t=1303972583; x=1305182183; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=rXIMUTxnFNb87TnfbJcjVrFIFsbkBEGCleZim8QFZQY=; b=eEF5410ZV0Ul9QjO99qOo3mC4zFCIJbLUiUC3qdYIQJrrWOAo5/ZyOIx j1ZIqvZfnmE79ViwmJFAYkPzjfOIesEShKJ/2dwxq5W1AvPva38zBmxH6 Tbdyqr2tFIng71gp1Qpv0kyUNOw1blHpXo5eOUtQcsi4POSA0POGOIq+l o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoBAI4KuU2rRDoI/2dsb2JhbACYEoFjjAp3iHCdGJx/hXYEhgePQYdg X-IronPort-AV: E=Sophos;i="4.64,278,1301875200"; d="scan'208";a="303771015" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-3.cisco.com with ESMTP; 28 Apr 2011 06:36:23 +0000 Received: from dwingWS (dhcp-128-107-104-245.cisco.com [128.107.104.245]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3S6aNE3011980; Thu, 28 Apr 2011 06:36:23 GMT From: "Dan Wing" To: , References: <0cb801cbe29e$ee401b80$cac05280$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01621A9D@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01621DA1@ch-mailsrv.rd.francetelecom.fr> <65E8E82B-3C4A-479A-B158-76E56E96DC47@apple.com> <0962B0BEF842A24191AD9BE41A8DD2FC01621FE6@ch-mailsrv.rd.francetelecom.fr> <1e6601cbea35$abd8f5c0$038ae140$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016221BC@ch-mailsrv.rd.francetelecom.fr> <22fd01cbeb06$c4793500$4d6b9f00$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E41B@ch-mailsrv.rd.francetelecom.fr> <03e101cbed42$d80d0ef0$88272cd0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E634@ch-mailsrv.rd.francetelecom.fr> <095601cbee08$9ef0c780$dcd25680$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> <0f7901cbf965$ea64aa70$bf2dff50$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016ED0E5@ch-mailsrv.rd.francetelecom.fr> <013001cc04ed$14550c20$3cff2460$@com> <0962B0BEF842A24191AD9 BE41A8DD2FC016ED208@ch -mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC016ED208@ch-mailsrv.rd.francetelecom.fr> Date: Wed, 27 Apr 2011 23:36:23 -0700 Message-ID: <044a01cc056e$977c9f10$c675dd30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvpgbZjqATPUsFnRFan3ixj2Y8FqQAlk4zAAAdKXvAAJLt/0AAPaQzwAI5RLNAAAOWpIAAs7yOgAARenKAAt94SIAIfj1bAAtYosmAAC6vpAAAci1MgAAPZPWA= Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 06:36:24 -0000 > -----Original Message----- > From: xiaohong.deng@orange-ftgroup.com [mailto:xiaohong.deng@orange- > ftgroup.com] > Sent: Wednesday, April 27, 2011 9:50 PM > To: dwing@cisco.com; cheshire@apple.com > Cc: pcp@ietf.org > Subject: RE: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS > > > |> How does PCP server act when an IWF issues a request with > |> PREFER_FAILURE Option indicating the same Internal ip and internal > |> port as an implicit mapping? > |> > |> In the current version (-09), section 11.1." Implementing MAP with > |> non-EIM NATs" will make it work, and assumes an EIM NAT doesn't > |> suffer this problem. > |> > |> However EIM NAT is highly likely to fail this request, > |because it is > |> unlikely to make the PCP request reuse the same > |mapping/external port > |> as the implicit mapping, since the requested external port > |is unlikely > |> to be the same as the one that implicit mapping is using. > | > |PREFER_FAILURE just says "if the PCP server cannot provide the > |Requested External Port, return an error". It doesn't control > |anything related to EDM or non-EDM NATs, and doesn't control > |or influence re-use of an implicit dynamic mapping. > > Are you suggesting PREFER_FAILURE should fail even if it's due to > internal port confilict (with an exist implicit mapping) instead of > external port unavailable? No, the text for PREFER_FAILURE only talks about failing (returning an error) if the Requested External Port cannot be provided. -d > BR, > Xiaohong > opensource A+P: http://opensourceaplusp.weebly.com/ > > | > |-d > | > | > |> | > |> |> Yet, it should not fail if you assume explicit mappings should > |> |> prior to implicit mappings. > |> | > |> |I'll work on some text for that. > |> | > |> |-d > |> From Francis.Dupont@fdupont.fr Wed Apr 27 23:37:18 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95B3E064B for ; Wed, 27 Apr 2011 23:37:18 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siPV7ZvBBevB for ; Wed, 27 Apr 2011 23:37:14 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B6E062A for ; Wed, 27 Apr 2011 23:37:13 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p3S6b63t026211; Thu, 28 Apr 2011 08:37:06 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201104280637.p3S6b63t026211@givry.fdupont.fr> From: Francis Dupont To: xiaohong.deng@orange-ftgroup.com In-reply-to: Your message of Thu, 28 Apr 2011 12:50:26 +0800. <0962B0BEF842A24191AD9BE41A8DD2FC016ED208@ch-mailsrv.rd.francetelecom.fr> Date: Thu, 28 Apr 2011 08:37:06 +0200 Sender: Francis.Dupont@fdupont.fr Cc: cheshire@apple.com, pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 06:37:18 -0000 In your previous mail you wrote: Are you suggesting PREFER_FAILURE should fail even if it's due to internal port confilict (with an exist implicit mapping) instead of external port unavailable? => IMHO it must fail with the correct error (i.e., IMPLICIT_MAPPING_EXISTS as the recovery is not the same than for CANNOT_PROVIDE_EXTERNAL_PORT). Regards Francis.Dupont@fdupont.fr From xiaohong.deng@orange-ftgroup.com Thu Apr 28 00:33:47 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A9AE06A6 for ; Thu, 28 Apr 2011 00:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTbaC31dF49B for ; Thu, 28 Apr 2011 00:33:47 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id D8BBBE062A for ; Thu, 28 Apr 2011 00:33:46 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E1CF06D8001; Thu, 28 Apr 2011 09:34:20 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id D5C3F6C0007; Thu, 28 Apr 2011 09:34:20 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Apr 2011 09:33:45 +0200 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: Thu, 28 Apr 2011 15:33:41 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC016ED2AE@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <044a01cc056e$977c9f10$c675dd30$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS Thread-Index: AcvpgbZjqATPUsFnRFan3ixj2Y8FqQAlk4zAAAdKXvAAJLt/0AAPaQzwAI5RLNAAAOWpIAAs7yOgAARenKAAt94SIAIfj1bAAtYosmAAC6vpAAAci1MgAAPZPWAAAeTygA== References: <0cb801cbe29e$ee401b80$cac05280$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01621A9D@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01621DA1@ch-mailsrv.rd.francetelecom.fr> <65E8E82B-3C4A-479A-B158-76E56E96DC47@apple.com> <0962B0BEF842A24191AD9BE41A8DD2FC01621FE6@ch-mailsrv.rd.francetelecom.fr> <1e6601cbea35$abd8f5c0$038ae140$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016221BC@ch-mailsrv.rd.francetelecom.fr> <22fd01cbeb06$c4793500$4d6b9f00$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E41B@ch-mailsrv.rd.francetelecom.fr> <03e101cbed42$d80d0ef0$88272cd0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E634@ch-mailsrv.rd.francetelecom.fr> <095601cbee08$9ef0c780$dcd25680$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> <0f7901cbf965$ea64aa70$bf2dff50$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016ED0E5@ch-mailsrv.rd.francetelecom.fr> <013001cc04ed$14550c20$3cff2460$@com> <0962B0BEF842A24191AD9 BE41A8D D2FC016ED208 @ch-mailsrv.rd.francetelecom.fr> <044a01cc056e$977c9f10$c675dd30$@com> From: To: , X-OriginalArrivalTime: 28 Apr 2011 07:33:45.0739 (UTC) FILETIME=[9B5795B0:01CC0576] Cc: pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 07:33:47 -0000 |> |PREFER_FAILURE just says "if the PCP server cannot provide the=20 |> |Requested External Port, return an error". It doesn't control=20 |> |anything related to EDM or non-EDM NATs, and doesn't control or=20 |> |influence re-use of an implicit dynamic mapping. |>=20 |> Are you suggesting PREFER_FAILURE should fail even if it's due to=20 |> internal port confilict (with an exist implicit mapping) instead of=20 |> external port unavailable? | |No, the text for PREFER_FAILURE only talks about failing=20 |(returning an error) if the Requested External Port cannot be provided. Are you going to add some text talking about PREFER_FAILURE failure when internal port is unavailable? | |-d | | |> BR, |> Xiaohong |> opensource A+P: http://opensourceaplusp.weebly.com/ |>=20 |> | |> |-d |> | |> | |> |> | |> |> |> Yet, it should not fail if you assume explicit mappings should=20 |> |> |> prior to implicit mappings. |> |> | |> |> |I'll work on some text for that. |> |> | |> |> |-d |> |> | | From xiaohong.deng@orange-ftgroup.com Thu Apr 28 00:35:31 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF95E064A for ; Thu, 28 Apr 2011 00:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efDt4dchzklb for ; Thu, 28 Apr 2011 00:35:31 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 46454E062A for ; Thu, 28 Apr 2011 00:35:31 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E7CE3FC4007; Thu, 28 Apr 2011 09:35:38 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id DBE5FFC4001; Thu, 28 Apr 2011 09:35:38 +0200 (CEST) Received: from ch-mailsrv.rd.francetelecom.fr ([10.193.250.27]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Apr 2011 09:35:30 +0200 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: Thu, 28 Apr 2011 15:35:26 +0800 Message-ID: <0962B0BEF842A24191AD9BE41A8DD2FC016ED2AF@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <201104280637.p3S6b63t026211@givry.fdupont.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE:[pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS Thread-Index: AcwFbspC9NlMILYpTHK9tl8LiJIxEQAB9hLg References: Your message of Thu, 28 Apr 2011 12:50:26 +0800. <0962B0BEF842A24191AD9BE41A8DD2FC016ED208@ch-mailsrv.rd.francetelecom.fr> <201104280637.p3S6b63t026211@givry.fdupont.fr> From: To: X-OriginalArrivalTime: 28 Apr 2011 07:35:30.0632 (UTC) FILETIME=[D9DCFC80:01CC0576] Cc: cheshire@apple.com, pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 07:35:31 -0000 | In your previous mail you wrote: | | Are you suggesting PREFER_FAILURE should fail even if it's due to=20 | internal port confilict (with an exist implicit mapping) instead of | external port unavailable? | =20 |=3D> IMHO it must fail with the correct error (i.e.,=20 |IMPLICIT_MAPPING_EXISTS as the recovery is not the same than=20 |for CANNOT_PROVIDE_EXTERNAL_PORT). Right, that's the question: which error code should be returned in this case? | |Regards | |Francis.Dupont@fdupont.fr | From simon.perreault@viagenie.ca Thu Apr 28 05:34:12 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88BEE06BF for ; Thu, 28 Apr 2011 05:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvePH4Wulsa0 for ; Thu, 28 Apr 2011 05:34:11 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 77BF9E06A7 for ; Thu, 28 Apr 2011 05:34:11 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:21d:60ff:fed7:e732]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 6DC2421F07 for ; Thu, 28 Apr 2011 08:34:08 -0400 (EDT) Message-ID: <4DB95EBF.60806@viagenie.ca> Date: Thu, 28 Apr 2011 08:34:07 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110320 Fedora/3.1.9-4.fc16 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: pcp@ietf.org References: <0cb801cbe29e$ee401b80$cac05280$@com> <65E8E82B-3C4A-479A-B158-76E56E96DC47@apple.com> <0962B0BEF842A24191AD9BE41A8DD2FC01621FE6@ch-mailsrv.rd.francetelecom.fr> <1e6601cbea35$abd8f5c0$038ae140$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016221BC@ch-mailsrv.rd.francetelecom.fr> <22fd01cbeb06$c4793500$4d6b9f00$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E41B@ch-mailsrv.rd.francetelecom.fr> <03e101cbed42$d80d0ef0$88272cd0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E634@ch-mailsrv.rd.francetelecom.fr> <095601cbee08$9ef0c780$dcd25680$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> <0f7901cbf965$ea64aa70$bf2dff50$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016ED0E5@ch-mailsrv.rd.francetelecom.fr> <013001cc04ed$14550c20$3cff2460$@com> <0962B0BEF842A24191AD9 BE41A8D D2FC016ED208 @ch-mailsrv.rd.francetelecom.fr> <044a01cc056e$977c9f10$c675dd30$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016ED2AE@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC016ED2AE@ch-mailsrv.rd.francetelecom.fr> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 12:34:12 -0000 On 2011-04-28 03:33, xiaohong.deng@orange-ftgroup.com wrote: > Are you going to add some text talking about PREFER_FAILURE > failure when internal port is unavailable? IMHO, it's not that the internal port is unavailable. It's that the only external port available is the one that's currently assigned to that internal port. So I see this as just another instance of the CANNOT_PROVIDE_EXTERNAL_PORT error case. We currently have: This option indicates that if the PCP server is unable to MAP the suggested port, then instead of returning an available port that it *can* allocate, the PCP server should instead allocate no port and return result code CANNOT_PROVIDE_EXTERNAL_PORT. This seems to cover this error case perfectly. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From dwing@cisco.com Thu Apr 28 08:54:55 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C847E0670 for ; Thu, 28 Apr 2011 08:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.431 X-Spam-Level: X-Spam-Status: No, score=-110.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCXu4fOJaA9x for ; Thu, 28 Apr 2011 08:54:54 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 76CDAE0669 for ; Thu, 28 Apr 2011 08:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=2206; q=dns/txt; s=iport; t=1304006094; x=1305215694; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=1DgbngzE4krQ7Tbv8Aemt4lRsXRCytzJBLdNPhiDnzk=; b=QPJ3q7K8GNFUDR95FGF/pTqWQrGPWyH2Y6AytBZLh7murm9OfI/mCcQb q4eypzh5KHWF9cf154KgTy2fkAHW6I+VK1YrtqPZcYxSFusy2PupgW+xM wXkcg5nY1iOFMmGqyBPiuUnK1Za8zvP/8Bdih3OH5aciHZHjeEsPY+R73 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As0BANKMuU2rRDoH/2dsb2JhbACYEj+BJIwOd6YonQOFdgSGCY9Dhzk X-IronPort-AV: E=Sophos;i="4.64,281,1301875200"; d="scan'208";a="346505771" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2011 15:54:54 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3SFsrKB024606; Thu, 28 Apr 2011 15:54:53 GMT From: "Dan Wing" To: References: <0cb801cbe29e$ee401b80$cac05280$@com> <0962B0BEF842A24191AD9BE41A8DD2FC01621A9D@ch-mailsrv.rd.francetelecom.fr> <0962B0BEF842A24191AD9BE41A8DD2FC01621DA1@ch-mailsrv.rd.francetelecom.fr> <65E8E82B-3C4A-479A-B158-76E56E96DC47@apple.com> <0962B0BEF842A24191AD9BE41A8DD2FC01621FE6@ch-mailsrv.rd.francetelecom.fr> <1e6601cbea35$abd8f5c0$038ae140$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016221BC@ch-mailsrv.rd.francetelecom.fr> <22fd01cbeb06$c4793500$4d6b9f00$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E41B@ch-mailsrv.rd.francetelecom.fr> <03e101cbed42$d80d0ef0$88272cd0$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164E634@ch-mailsrv.rd.francetelecom.fr> <095601cbee08$9ef0c780$dcd25680$@com> <0962B0BEF842A24191AD9BE41A8DD2FC0164EE47@ch-mailsrv.rd.francetelecom.fr> <0f7901cbf965$ea64aa70$bf2dff50$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016ED0E5@ch-mailsrv.rd.francetelecom.fr> <013001cc04ed$14550c20$3cff2460$@com> <0962B0BEF842A24191AD9 BE41A8D D2FC016ED208 @ch-mailsrv.rd.francetelecom.fr> <044a01cc056e$977c9f10$c675dd30$@com> <0962B0BEF842A24191AD9BE41A8DD2FC016ED2AE@ch-mailsrv.rd.francetelecom.fr> In-Reply-To: <0962B0BEF842A24191AD9BE41A8DD2FC016ED2AE@ch-mailsrv.rd.francetelecom.fr> Date: Thu, 28 Apr 2011 08:54:53 -0700 Message-ID: <05c101cc05bc$9d5d9c10$d818d430$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvpgbZjqATPUsFnRFan3ixj2Y8FqQAlk4zAAAdKXvAAJLt/0AAPaQzwAI5RLNAAAOWpIAAs7yOgAARenKAAt94SIAIfj1bAAtYosmAAC6vpAAAci1MgAAPZPWAAAeTygAARimag Content-Language: en-us Cc: cheshire@apple.com, pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 15:54:55 -0000 > -----Original Message----- > From: xiaohong.deng@orange-ftgroup.com [mailto:xiaohong.deng@orange- > ftgroup.com] > Sent: Thursday, April 28, 2011 12:34 AM > To: dwing@cisco.com; cheshire@apple.com > Cc: pcp@ietf.org > Subject: RE: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS > > |> |PREFER_FAILURE just says "if the PCP server cannot provide the > |> |Requested External Port, return an error". It doesn't control > |> |anything related to EDM or non-EDM NATs, and doesn't control or > |> |influence re-use of an implicit dynamic mapping. > |> > |> Are you suggesting PREFER_FAILURE should fail even if it's due to > |> internal port confilict (with an exist implicit mapping) instead of > |> external port unavailable? > | > |No, the text for PREFER_FAILURE only talks about failing > |(returning an error) if the Requested External Port cannot be > provided. > > Are you going to add some text talking about PREFER_FAILURE > failure when internal port is unavailable? I wasn't planning on it. What is your suggested text? I slightly changed the wording of " Implementing MAP with non-EIM NATs", http://tools.ietf.org/html/draft-ietf-pcp-base-09#section-11.1, to cover both connections from separate hosts (using the same source port) and connections from the same host (using the same source port) -- a change which I think causes the text to include an issue Francis raised in private email. But I don't know if you're describing a similar, related problem with PREFER_FAILURE or what. Because, frankly, I don't understand the issue and need some hand-holding to understand the problem. With that understanding, I could have a chance to write text. But as I do not understand the problem, I cannot successfully write any text.. So: can you suggest text, please? -d > | > |-d > | > | > |> BR, > |> Xiaohong > |> opensource A+P: http://opensourceaplusp.weebly.com/ > |> > |> | > |> |-d > |> | > |> | > |> |> | > |> |> |> Yet, it should not fail if you assume explicit mappings should > |> |> |> prior to implicit mappings. > |> |> | > |> |> |I'll work on some text for that. > |> |> | > |> |> |-d > |> |> > | > | From Francis.Dupont@fdupont.fr Thu Apr 28 10:15:30 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59AEE071F for ; Thu, 28 Apr 2011 10:15:30 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itp88z5rsip8 for ; Thu, 28 Apr 2011 10:15:30 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 6A16EE071E for ; Thu, 28 Apr 2011 10:15:26 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id p3SHFO9K064903; Thu, 28 Apr 2011 19:15:24 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201104281715.p3SHFO9K064903@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Thu, 28 Apr 2011 08:34:07 EDT. <4DB95EBF.60806@viagenie.ca> Date: Thu, 28 Apr 2011 19:15:24 +0200 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 17:15:30 -0000 In your previous mail you wrote: On 2011-04-28 03:33, xiaohong.deng@orange-ftgroup.com wrote: > Are you going to add some text talking about PREFER_FAILURE > failure when internal port is unavailable? IMHO, it's not that the internal port is unavailable. => Simon, it is possible to get both errors, IMPLICIT_MAPPING_EXISTS from a collision on the internal port, and CANNOT_PROVIDE_EXTERNAL_PORT from an unavailable external port. In this case of both errors IMHO the server must return IMPLICIT_MAPPING_EXISTS. We currently have: This option indicates that if the PCP server is unable to MAP the suggested port, then instead of returning an available port that it *can* allocate, the PCP server should instead allocate no port and return result code CANNOT_PROVIDE_EXTERNAL_PORT. This seems to cover this error case perfectly. => I agree: implicitely it means there is no other errors. Regards Francis.Dupont@fdupont.fr From dwing@cisco.com Fri Apr 29 17:05:24 2011 Return-Path: X-Original-To: pcp@ietfa.amsl.com Delivered-To: pcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F20E07B7 for ; Fri, 29 Apr 2011 17:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.446 X-Spam-Level: X-Spam-Status: No, score=-110.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j6UzSHUzGo5 for ; Fri, 29 Apr 2011 17:05:23 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id DC49EE06A6 for ; Fri, 29 Apr 2011 17:05:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=362; q=dns/txt; s=iport; t=1304121923; x=1305331523; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=ANyNidaa14xC1sjZeKEeej/1/a+TAC7/KOG+q7xAOHs=; b=F1YY3o/FnPtWNOHiaZDBm0fIte3t+FsZLX5oCwqmnx54D2Fqm9mOOodo KAJZ6qVbapqv7Fk0DzwUy+gzyKJP3Q69uuT6wIEFVuB+7kNMEmnFMnqfd 6FIJhgTy6ow9gq68BaFYfndOIpS1/mCUi0mv+/eEmpmZ2c0/QlTC37X+V A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0HADhRu02rRDoH/2dsb2JhbACYUYEkjB13pymBHZxNhX4Ehg2XFQ X-IronPort-AV: E=Sophos;i="4.64,291,1301875200"; d="scan'208";a="347566999" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 30 Apr 2011 00:05:23 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3U05NP8016087 for ; Sat, 30 Apr 2011 00:05:23 GMT From: "Dan Wing" To: Date: Fri, 29 Apr 2011 17:05:23 -0700 Message-ID: <066e01cc06ca$4d248060$e76d8120$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwGykzhIwoHsWwqQ/+w7zLxBSHp5w== Content-Language: en-us Subject: [pcp] pcp-base-10 submitted X-BeenThere: pcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Apr 2011 00:05:24 -0000 file is at: http://tools.ietf.org/html/draft-ietf-pcp-base-10 side-by-side differences: http://tools.ietf.org/rfcdiff?url2=draft-ietf-pcp-base-10.txt Changes: o Added External_AF field to PEER requests. Made PEER's Suggested External IP Address and Assigned External IP Address always be 128 bits long. Have a good weekend, -d