From adurand@juniper.net Wed Jun 1 09:10:58 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 E130EE0851 for ; Wed, 1 Jun 2011 09:10:58 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Kqe+o2AjfTu for ; Wed, 1 Jun 2011 09:10:58 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id F2311E084F for ; Wed, 1 Jun 2011 09:10:57 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTeZkj5tnirJKcN6VAip/YMevsYQ0z4Y7@postini.com; Wed, 01 Jun 2011 09:10:58 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 1 Jun 2011 09:08:59 -0700 From: Alain Durand To: Dan Wing Date: Wed, 1 Jun 2011 09:08:57 -0700 Thread-Topic: [pcp] WGLC: draft-ietf-pcp-base-12.txt Thread-Index: AcwgdjcBtHVFK0PARGuFfd1VNKLWZA== Message-ID: <1C74ED2D-468A-405B-A66F-27D06596F7CC@juniper.net> References: <9B57C850BB53634CACEC56EF4853FF653B0BA0FD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <04ce01cc1fc2$3fa360d0$beea2270$@com> In-Reply-To: <04ce01cc1fc2$3fa360d0$beea2270$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.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, 01 Jun 2011 16:10:59 -0000 On May 31, 2011, at 2:40 PM, Dan Wing wrote: >=20 >=20 >> - UNAUTH_THIRD_PARTY_INTERNAL_ADDRESS could be removed, and replaced >> with NOT_AUTHORIZED (more on that inline). >>=20 >> - There is no discussion about levels of conformance. There's some >> discussion about particular options being optional (e.g. THIRD_PARTY >> not supported in certain deployment scenarios), but no overall >> statement of what features must be supported by all conformant >> implementations. e.g. If I had a small embedded server that supported >> MAP opcodes but not PEER, would it be conformant? >=20 > Nobody has initiated discussion or provided a straw-man on conformance > levels. What do we want? Myself, if there is any chance of a wireless > devices (which is approximately 100% chance), PEER needs to be supported > because it allows the wireless device to optimize its NAT keepalive > traffic. But, to me, MAP doesn't need to necessarily be supported. I think we should stay away from conformance levels. This gets very complex= , very quickly, and does not help interoperability. The argument that MAP or PEER are only useful in a wireline or wireless sce= nario seams a bit weak to me. We are now seeing fixed wireless environment... Which profile should they h= ave? I believe that unless there is a very strong reason against against, we sho= uld keep MAP & PEER functionality. - Alain. From dthaler@microsoft.com Fri Jun 3 13:02: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 7E9BFE07BE for ; Fri, 3 Jun 2011 13:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 CoEfZwd7MNbX for ; Fri, 3 Jun 2011 13:02:18 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id DF069E067F for ; Fri, 3 Jun 2011 13:02:17 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 3 Jun 2011 13:02:16 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.289.8; Fri, 3 Jun 2011 13:02:16 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.165]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Fri, 3 Jun 2011 13:02:16 -0700 From: Dave Thaler To: "pcp@ietf.org" Thread-Topic: WGLC: draft-ietf-pcp-base-12.txt Thread-Index: AcwXKk61FuyajK7hRbulosJtjQ9K5wK/sVTg Date: Fri, 3 Jun 2011 20:02:15 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B0E7836@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <9B57C850BB53634CACEC56EF4853FF653B0BA0FD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B0BA0FD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B0E7836TK5EX14MBXW601w_" MIME-Version: 1.0 Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.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: Fri, 03 Jun 2011 20:02:18 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B0E7836TK5EX14MBXW601w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Some comments on -12 are in the marked up copy at http://research.microsoft.com/users/dthaler/draft-ietf-pcp-base-12.pdf -Dave From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dave = Thaler Sent: Friday, May 20, 2011 1:18 PM To: pcp@ietf.org Subject: [pcp] WGLC: draft-ietf-pcp-base-12.txt This message starts a two-week WGLC on http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-12.txt This last call will conclude on June 3rd at 5pm EST. Please send your comments to the list. We are scheduling a WebEx call shortly after the WGLC concludes, and will send out details in separate email. Thanks, -Dave and Alain --_000_9B57C850BB53634CACEC56EF4853FF653B0E7836TK5EX14MBXW601w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Some comments on -12 a= re in the marked up copy at

http://researc= h.microsoft.com/users/dthaler/draft-ietf-pcp-base-12.pdf

 

-Dave

 

From: pcp-boun= ces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dave Thaler
Sent: Friday, May 20, 2011 1:18 PM
To: pcp@ietf.org
Subject: [pcp] WGLC: draft-ietf-pcp-base-12.txt

 

This message starts a two-week WGLC on

http://www.ietf.org/internet-drafts/draft-ietf-pcp-b= ase-12.txt

 

This last call will conclude on June 3rd = at 5pm EST.

 

Please send your comments to the list.

 

We are scheduling a WebEx call shortly after the WGL= C concludes,

and will send out details in separate email.

 

Thanks,

-Dave and Alain

 

 

--_000_9B57C850BB53634CACEC56EF4853FF653B0E7836TK5EX14MBXW601w_-- From tena@huawei.com Fri Jun 3 22:26:17 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 7A80FE0676 for ; Fri, 3 Jun 2011 22:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.141 X-Spam-Level: X-Spam-Status: No, score=-106.141 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 X5xM2lEn5lQK for ; Fri, 3 Jun 2011 22:26:15 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 6C450E0674 for ; Fri, 3 Jun 2011 22:26:15 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LM900MIL33Q7C@usaga04-in.huawei.com> for pcp@ietf.org; Sat, 04 Jun 2011 00:26:15 -0500 (CDT) Received: from TingZousc1 ([10.212.245.166]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LM90093Y33KRU@usaga04-in.huawei.com> for pcp@ietf.org; Sat, 04 Jun 2011 00:26:14 -0500 (CDT) Date: Fri, 03 Jun 2011 22:26:07 -0700 From: Tina Tsou In-reply-to: <9B57C850BB53634CACEC56EF4853FF653B0E7836@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> To: 'Dave Thaler' , pcp@ietf.org Message-id: <01bb01cc2277$eb072b70$c1158250$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_O8HxpRLAQmXsrSiOZg+aOA)" Content-language: en-us Thread-index: AcwXKk61FuyajK7hRbulosJtjQ9K5wK/sVTgABOocjA= References: <9B57C850BB53634CACEC56EF4853FF653B0BA0FD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B0E7836@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.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: Sat, 04 Jun 2011 05:26:17 -0000 This is a multi-part message in MIME format. --Boundary_(ID_O8HxpRLAQmXsrSiOZg+aOA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all, In section7, there is one description: "It is REQUIRED that the PCP-controlled device assign the same external IP address to PCP-created explicit dynamic mappings and to implicit dynamic mappings." It is only a requirement to CGN, but some existing CGN may not support this requirement as defined in RFC4787-[REQ1]: "Some NATs use the external IP address mapping in an arbitrary fashion (i.e., randomly): one internal IP address could have multiple external IP address mappings active at the same time for different sessions" Therefore, I suggest the PCP client should also support this requirement which was actually defined in 00 version but deleted in later versions (maybe I missed the reason of the text change): If there is any existing PCP mapping, PCP client should only request the same external IP address as the one of those existing mappings. The reason is that it will allow applications that use multiple ports originating from the same internal IP address to also have the same external IP address. Have a good weekend. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dave Thaler Sent: Friday, June 03, 2011 1:02 PM To: pcp@ietf.org Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.txt Some comments on -12 are in the marked up copy at http://research.microsoft.com/users/dthaler/draft-ietf-pcp-base-12.pdf -Dave From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of Dave Thaler Sent: Friday, May 20, 2011 1:18 PM To: pcp@ietf.org Subject: [pcp] WGLC: draft-ietf-pcp-base-12.txt This message starts a two-week WGLC on http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-12.txt This last call will conclude on June 3rd at 5pm EST. Please send your comments to the list. We are scheduling a WebEx call shortly after the WGLC concludes, and will send out details in separate email. Thanks, -Dave and Alain --Boundary_(ID_O8HxpRLAQmXsrSiOZg+aOA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Dear = all,

In section7, there is = one description:

“It is REQUIRED that = the PCP-controlled device assign the same

   external IP address to PCP-created explicit dynamic = mappings and to

   implicit dynamic = mappings.”

=

It is only a = requirement to CGN, but some existing CGN may not support this = requirement as defined in RFC4787-[REQ1]:

“Some NATs use the = external IP address mapping in an arbitrary = fashion

   (i.e., randomly): one = internal IP address could have multiple

   external IP address mappings active at the same = time for different

   sessions”

=

Therefore, I suggest = the PCP client should also support this requirement which was actually = defined in 00 version but deleted in later = versions (maybe I missed the reason of the text = change):

If there is any = existing PCP mapping, PCP client should only request the same external = IP address as the one of those existing mappings. The reason is that it = will allow applications that use multiple ports originating from the = same internal IP address to also have the same external IP = address.

 

 

Have a good = weekend.

 

We = keep our promises with one another – no matter = what!

 

Best = Regards,

Tina = TSOU

http://tinatsou.weebly.com/contact= .html

 

From: pcp-bounces@ietf.org = [mailto:pcp-bounces@ietf.org] On Behalf Of Dave = Thaler
Sent: Friday, June 03, 2011 1:02 PM
To: = pcp@ietf.org
Subject: Re: [pcp] WGLC: = draft-ietf-pcp-base-12.txt

 

Some comments on -12 are in the marked up copy = at

http://research.microsoft.com/users/dthaler/draft-ietf-pcp-base-12= .pdf

 

-Dave

 

From:= = pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of = Dave Thaler
Sent: Friday, May 20, 2011 1:18 = PM
To: pcp@ietf.org
Subject: [pcp] WGLC: = draft-ietf-pcp-base-12.txt

 

This message = starts a two-week WGLC on

h= ttp://www.ietf.org/internet-drafts/draft-ietf-pcp-base-12.txt

 

This last call will conclude on June 3rd at = 5pm EST.

 

Please send your comments to the = list.

 

We are scheduling a WebEx call shortly after the WGLC = concludes,

and will send out details = in separate email.

 

Thanks,

-Dave and = Alain

 

 

= --Boundary_(ID_O8HxpRLAQmXsrSiOZg+aOA)-- From dwing@cisco.com Sat Jun 4 17:49:27 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 800C111E8072 for ; Sat, 4 Jun 2011 17:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108 X-Spam-Level: X-Spam-Status: No, score=-108 tagged_above=-999 required=5 tests=[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 InxMMk7u5JUT for ; Sat, 4 Jun 2011 17:49:26 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 53B8F11E8071 for ; Sat, 4 Jun 2011 17:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4148; q=dns/txt; s=iport; t=1307234966; x=1308444566; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=3B8K83aAKQdv5vQoQ/eOGJ0fGF1T0rZM5XtTgZlrVCs=; b=SimqrAig8a+Z49uNqGyJuZRLZwakuDGwjoAluPhRDH4/C6LgMGmawFKt PB//gTa4Mdu9zlLKLOMtRis3Ka+SOdTkvrRjzD0R/UyqT23G+4DpIetBu XCdKQoLopvu1SN/GWfG8fDVlLTmsFnbfg6CxSuCdeKGDoc7nFGV3k1CdP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYBAKPR6k2rRDoG/2dsb2JhbABTl2eBZox6d4hxoCicaYYhBIZ0mV8 X-IronPort-AV: E=Sophos;i="4.65,321,1304294400"; d="scan'208";a="459863198" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 05 Jun 2011 00:49:25 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p550nPPT028119; Sun, 5 Jun 2011 00:49:25 GMT From: "Dan Wing" To: "'Tina Tsou'" , "'Dave Thaler'" , References: <9B57C850BB53634CACEC56EF4853FF653B0BA0FD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B0E7836@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <01bb01cc2277$eb072b70$c1158250$@com> In-Reply-To: <01bb01cc2277$eb072b70$c1158250$@com> Date: Sat, 4 Jun 2011 17:49:25 -0700 Message-ID: <04d801cc231a$6b2747c0$4175d740$@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: AcwXKk61FuyajK7hRbulosJtjQ9K5wK/sVTgABOocjAAKHAzUA== Content-Language: en-us Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.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: Sun, 05 Jun 2011 00:49:27 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Tina Tsou > Sent: Friday, June 03, 2011 10:26 PM > To: 'Dave Thaler'; pcp@ietf.org > Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > Dear all, > In section7, there is one description: > "It is REQUIRED that the PCP-controlled device assign the same > external IP address to PCP-created explicit dynamic mappings and to > implicit dynamic mappings." > It is only a requirement to CGN, but some existing CGN may not support > this requirement as defined in RFC4787-[REQ1]: > "Some NATs use the external IP address mapping in an arbitrary fashion > (i.e., randomly): one internal IP address could have multiple > external IP address mappings active at the same time for different > sessions" You quoted non-normative text; later in that same section of RFC4787 it explains how random ("Arbitrary") assignment causes harm. REQ-2 says that "paired" is RECOMMENDED. > Therefore, I suggest the PCP client should also support this > requirement which was actually defined in 00 version but deleted in > later versions (maybe I missed the reason of the text change): > If there is any existing PCP mapping, PCP client should only request > the same external IP address as the one of those existing mappings. The > reason is that it will allow applications that use multiple ports > originating from the same internal IP address to also have the same > external IP address. We (the NAT and PCP server) can't know if, when there is an implicit dynamic connection from a host's source port, that connection was done by the same application as the explicit mapping, or if the OS happened to assign that source port to some other (unrelated) application. If the NAT is EIM, it will reuse the same mapping it already has. Because that is the definition of being a EIM NAT. And it is important that all implicit dynamic mappings use the same public IPv4 address (for all the reasons stated in the existing UDP and TCP RFCs). We don't want PCP to make that situation worse because some other un-related application did a MAP request. If it is a non-EIM NAT, I suppose there is a way to use separate pools, if the non-EIM NAT applies some sort of logic to the implicit sessions -- the logic described in #2 of http://tools.ietf.org/html/draft-ietf-pcp-base-12#section-11.1 If you want/need that, please provide text. But I fear the interaction that is created if non-EIM NAT could create mappings on arbitrary IP addresses while EIM NAT creates mappings on the same IP address. For example, if an application was tested with an EIM NAT (which always assigns PCP-created mappings and implicit mappings to the same external IP address), that application may well fail when deployed behind a non-EIM NAT that (a) allocates different IP addresses for different PCP mappings or (b) different IP addresses for PCP mappings versus implicit dynamic mappings. -d > > Have a good weekend. > > We keep our promises with one another - no matter what! > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Dave Thaler > Sent: Friday, June 03, 2011 1:02 PM > To: pcp@ietf.org > Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > Some comments on -12 are in the marked up copy at > http://research.microsoft.com/users/dthaler/draft-ietf-pcp-base-12.pdf > > -Dave > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Dave Thaler > Sent: Friday, May 20, 2011 1:18 PM > To: pcp@ietf.org > Subject: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > This message starts a two-week WGLC on > http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-12.txt > > This last call will conclude on June 3rd at 5pm EST. > > Please send your comments to the list. > > We are scheduling a WebEx call shortly after the WGLC concludes, > and will send out details in separate email. > > Thanks, > -Dave and Alain > > From trac@tools.ietf.org Mon Jun 6 16:54:05 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 12E2521F84D5 for ; Mon, 6 Jun 2011 16:54:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfRsTYiHoiWz for ; Mon, 6 Jun 2011 16:54:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 3018B21F8449 for ; Mon, 6 Jun 2011 16:54:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QTjcJ-0000Hf-Bh; Mon, 06 Jun 2011 16:53:55 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Mon, 06 Jun 2011 23:53:55 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/49 Message-ID: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-Trac-Ticket-ID: 49 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110606235404.3018B21F8449@ietfa.amsl.com> Resent-Date: Mon, 6 Jun 2011 16:54:04 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #49: Multihoming confusion 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: Mon, 06 Jun 2011 23:54:05 -0000 #49: Multihoming confusion Section 2.3: > The PCP machinery assumes a single-homed host model. That is, for a > given IP version, only one default route exists to reach the > Internet. I don’t think this is true. There’s no issue here with a host with multiple interfaces using the strong host model. And certainly no issue with a host with one IPv4 default route and one IPv6 default route on the same interface. I think it assumes a single-homed *address* model. That is, for a given IP address, only one default route exists usable by packets sourced from that address. Section 6.4: > As mentioned in Section 2.3, only single-homed CP routers are in > scope. Therefore, there is no viable scenario where a host located > behind a CP router is assigned with two Global Unicast Addresses > belonging to different global IPv6 prefixes. No this doesn’t follow at al. Section 2.3 just mentioned one default route (which I continue to disagree with, but anyway). It said nothing about multiple prefixes or addresses. As long as there’s only one router, what’s the problem? Section 7: > It takes the union of this > knowledge to decide to send a one or two MAP requests for each of its > interfaces. Glad to see that multiple interfaces is indeed in scope. Personally I believe that if you're behind a stateful NAT, then one PCP server will do (since it's the server with your external address and hence is guaranteed to be on-path). But if you're behind stateless boxes (e.g. firewall only, no NAT) then you probably want to talk to *all* PCP servers, since no single one is guaranteed to be on path. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Mon Jun 6 16:57:37 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 2BE8A21F84EB for ; Mon, 6 Jun 2011 16:57:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBlHU6JwoQ6L for ; Mon, 6 Jun 2011 16:57:36 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id C4BB321F84EE for ; Mon, 6 Jun 2011 16:57:36 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QTjfn-0005RC-Vf; Mon, 06 Jun 2011 16:57:31 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Mon, 06 Jun 2011 23:57:31 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/49#comment:1 Message-ID: <068.4ef59ca47b6f0acc04fc765da85dfac1@tools.ietf.org> References: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110606235736.C4BB321F84EE@ietfa.amsl.com> Resent-Date: Mon, 6 Jun 2011 16:57:36 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #49: Multihoming confusion 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: Mon, 06 Jun 2011 23:57:37 -0000 #49: Multihoming confusion Comment(by dthaler@…): Section 6.1: > 2. the address of the default router is used as the PCP server. Most hosts should have two… one for IPv4 and one for IPv6. (Some may have multiple for IPv6, or even IPv4 In my opinion it’s wrong to aply that such hosts simply cannot use PCP.) Suggest "2. the default router list is used as the list of PCP server(s)." Then, regardless of whether the list was obtained from 1 (configuration like DHCP) or 2, I think the client has to filter the list down to those usable with the internal address in the request, unless there are none (in which case it needs to use the THIRD_PARTY option). Otherwise, you might end up picking an IPv6 server address to request an IPv4 mapping: the source IP won’t match the internal IP in the request, and if the server doesn’t support the THIRD_PARTY option, this will fail. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Mon Jun 6 17:06:38 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 B43E621F85AF for ; Mon, 6 Jun 2011 17:06:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEZ3XB09wbGA for ; Mon, 6 Jun 2011 17:06:38 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9D721F85AC for ; Mon, 6 Jun 2011 17:06:38 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QTjoW-00037j-Jk; Mon, 06 Jun 2011 17:06:32 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 00:06:32 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/50 Message-ID: <059.3983d702876cabfa50cd4658b44167fa@tools.ietf.org> X-Trac-Ticket-ID: 50 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607000638.5F9D721F85AC@ietfa.amsl.com> Resent-Date: Mon, 6 Jun 2011 17:06:38 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #50: 128 bit PCP Client's IP Address and Suggested External IP Address fields 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, 07 Jun 2011 00:06:38 -0000 #50: 128 bit PCP Client's IP Address and Suggested External IP Address fields Section 5.1: > PCP Client's IP Address: The IP address of the PCP client, from the > PCP client's perspective. If IPv4, only the first 32 bits are > used, the other bits MUST be set to 0. Section 5.2: > PCP Client's IP Address: The IP address of the PCP client, > PCP server's perspective. If IPv4, only the first 32 bits are > used, the other bits MUST be set to 0. > Suggested External IP Address: always 128 reserved bits. If an IPv4 > address, it is placed into the first 32 bits and the other 96 > MUST be 0. Why not use IPv4-mapped format? That might make some code easier (e.g., in a tcpdump parser) since the field interpretation is then independent of other things, and you can never confuse IPv4 with IPv6. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: enhancement | Status: new Priority: minor | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Mon Jun 6 17:18:21 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 5195C21F85FE for ; Mon, 6 Jun 2011 17:18:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITKbpTSE3XY3 for ; Mon, 6 Jun 2011 17:18:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id A876421F85FD for ; Mon, 6 Jun 2011 17:18:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QTjzl-0000dO-83; Mon, 06 Jun 2011 17:18:09 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 00:18:09 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/pcp/trac/ticket/51 Message-ID: <059.63410ebe5d497d93b31b03826221e018@tools.ietf.org> X-Trac-Ticket-ID: 51 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607001820.A876421F85FD@ietfa.amsl.com> Resent-Date: Mon, 6 Jun 2011 17:18:20 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #51: Mapping vs Filtering effect confusion 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, 07 Jun 2011 00:18:21 -0000 #51: Mapping vs Filtering effect confusion RFC 4787 defines mapping and filtering state to be separate. Currently the PCP draft seems to confuse them into one piece of state and only explicitly mentions the mapping state. Section 3: > Mapping, Port Mapping, Port Forwarding: > A NAT mapping creates a relationship between an internal IP > address, protocol, and port and an external IP address, protocol, > and port. More specifically, it creates a translation rule where > packets destined to the external IP and port are translated to the > internal IP and port, and vice versa. In the case of a pure > firewall, the "Mapping" is the identity function, translating an > internal port number to the same external port number, and this > "Mapping" indicates to the firewall that traffic to and from this > internal port number is permitted to pass. Last phrase above confuses mapping state with filtering state. Somewhere in this doc needs to explain that MAP results in EIF. PEER (without MAP) only needs APDF to support uses 7.2 (Reducing NAT Keepalive Messages) and 7.3 (Restoring Lost Implicit TCP Dynamic Mapping State). Section 8.6: > If the PCP client attempts to delete an implicit dynamic > mapping (e.g., created by a TCP SYN), the PCP server deletes the > mapping and responds with the SUCCESS result code. This is confusing with respect to mapping vs filtering. On a TCP SYN, it will create an implicit dynamic mapping, and also an implicit dynamic filtering hole for the specific Remote Host. What would MAP remove? Both? What if the client wants to stop accepting *new* connections but wants existing connections to continue until it can close them gracefully (e.g. at the end of a data transfer)? Section 9.1 (PEER format): > Remote Peer IP Address: [...] Note > this field has no bearing whatsoever on any filtering associated > with the mapping. Why not? You can’t use this to refresh state for TCP as in section 7.3? To do that you have to re-create the filtering state somehow. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Mon Jun 6 17:26:20 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 E3AAB21F8604 for ; Mon, 6 Jun 2011 17:26:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X43JP6xiGsJR for ; Mon, 6 Jun 2011 17:26:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 566E521F85DC for ; Mon, 6 Jun 2011 17:26:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QTk7a-00081C-6M; Mon, 06 Jun 2011 17:26:14 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 00:26:14 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/52 Message-ID: <059.62dd03011306661e8e9adf9c3b25b18d@tools.ietf.org> X-Trac-Ticket-ID: 52 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607002620.566E521F85DC@ietfa.amsl.com> Resent-Date: Mon, 6 Jun 2011 17:26:20 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #52: More security considerations 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, 07 Jun 2011 00:26:21 -0000 #52: More security considerations Section 13.1 (Denial of Service) needs discussion of additional vectors. Another DOS vector is via spoofing a SERVER_OVERLOADED response and sending it to a victim, since per section 6.3: > If the result code is SERVER_OVERLOADED, clients SHOULD NOT send > *any* further requests to that PCP server for the indicated error > lifetime. Another DOS vector is by spoofing a victim’s IP and deleting all their mappings. Another vector is by spoofing a victim's IP and refreshing their mappings, thereby consuming bandwidth/CPU at the victim (or the next victim to get the same IP address). The rule in section 8.6: > When a PCP client first acquires a new IP > address (e.g., reboots or joins a new network), it SHOULD remove > mappings that may already be instantiated for that new Internal > Address. would, if the SHOULD is followed, simply result in the "refresh" being a "recreate". The "recreate" is mentioned in 13.2 but needs text in 13.1 to call it out as a DoS vector. Finally, section 13 says: > The MAP OpCode allows > creating a mapping so a host can receive incoming unsolicited > connections from the Internet in order to run a server. Should probably note that this is wider than what can be done with a TCP SYN and hence in some environments may be considered a security issue. It should probably be legal for such deployments to have a PCP server accept PEER but not MAP. This allows some uses (Reducing NAT Keepalive Messages, Restoring Lost Implicit TCP Dynamic Mapping State) but not others (Operating a Server). -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Mon Jun 6 17:36: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 6244E21F8584 for ; Mon, 6 Jun 2011 17:36:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyOf6iHK9nrX for ; Mon, 6 Jun 2011 17:36:02 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 63E9E21F8583 for ; Mon, 6 Jun 2011 17:36:02 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QTkH4-00020X-7G; Mon, 06 Jun 2011 17:36:02 -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: dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 00:36:02 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://zinfandel.levkowetz.com/wg/pcp/trac/ticket/38#comment:2 Message-ID: <072.d392fc85e732da79c2b58b227d11f823@tools.ietf.org> References: <063.06897a694fc1efd1fd9e3b89438a850e@tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <063.06897a694fc1efd1fd9e3b89438a850e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dthaler@microsoft.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] #38: state maintenance: create a general failure model, discussing how to recover from failures 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, 07 Jun 2011 00:36:04 -0000 #38: state maintenance: create a general failure model, discussing how to recover from failures Comment(by dthaler@…): As discussed at IETF, still need text saying to add mappings on a move. Page 36 says: > When a PCP client first acquires a new IP > address (e.g., reboots or joins a new network), it SHOULD remove > mappings that may already be instantiated for that new Internal > Address. The above only covers the "remove old" state, but if there are applications already listening (e.g. on INADDR_ANY), it needs to re- register. Section 8.7 (Subscriber Renumbering and Address Change Events) doesn't, and shouldn't, cover this, since it's not about a client moving into the network. And section 7.1 (pseudocode for operating a server) only says: > /* Note: the "time_to_send_pcp_request" check below includes: > * 1. Sending the first request > * 2. Retransmitting requests due to packet loss > * 3. Resending a request due to impending lease expiration > * The PCP packet sent is identical in all cases, apart from the > * Suggested External Address and Port which may change over time At a miminim the pseudocode in 7.1 needs to be updated, but as I consider the pseudocode to be purely an example, I'd also like to see in addition, text in the body of some section. -- ---------------------------------------+------------------------------------ Reporter: Francis.Dupont@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: pcp From trac@tools.ietf.org Mon Jun 6 17:37: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 31F4421F8583 for ; Mon, 6 Jun 2011 17:37:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9A22TjoTWWzL for ; Mon, 6 Jun 2011 17:37:24 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 350F821F8584 for ; Mon, 6 Jun 2011 17:37:24 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QTkIO-0005IA-1v; Mon, 06 Jun 2011 17:37:24 -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: dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 00:37:24 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/38#comment:3 Message-ID: <072.5744c16b350eaf99e887a0f8e253ba95@tools.ietf.org> References: <063.06897a694fc1efd1fd9e3b89438a850e@tools.ietf.org> X-Trac-Ticket-ID: 38 In-Reply-To: <063.06897a694fc1efd1fd9e3b89438a850e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dthaler@microsoft.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] #38: state maintenance: create a general failure model, discussing how to recover from failures 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, 07 Jun 2011 00:37:25 -0000 #38: state maintenance: create a general failure model, discussing how to recover from failures Comment(by dthaler@…): From IETF: Server/proxy reboot: * Client periodically refreshes some mapping at whatever the desired detection frequency is * Client detects server/proxy reboot via Epoch reduction * Client resends MAPs/PEERs for current listeners/connections Client reboot: * Client detects running application listeners/connections * Client tells server to delete all mappings * Client resends MAPs/PEERs for current listeners/connections (Non-PCP client) listener loss: * PCP client responsible for detecting and updating server Client address addition: * Client sends MAPs for IN{6}ADDR_ANY listeners Client address loss but has (or gets) another address on same network: * Client tells server to delete all mappings for old (THIRD_PARTY) address Client address change or network change * Both of above Most of the above is already in the doc, but not all, e.g., the client address addition piece. -- ---------------------------------------+------------------------------------ Reporter: Francis.Dupont@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: pcp From trac@tools.ietf.org Mon Jun 6 17:53:46 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 8D72721F85F0 for ; Mon, 6 Jun 2011 17:53:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLmH-F-0BDmy for ; Mon, 6 Jun 2011 17:53:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 3130821F85EF for ; Mon, 6 Jun 2011 17:53:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QTkY9-0007Pf-Va; Mon, 06 Jun 2011 17:53:41 -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: draft-ietf-pcp-base@tools.ietf.org, pselkirk@isc.org X-Trac-Project: pcp Date: Tue, 07 Jun 2011 00:53:41 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/53 Message-ID: <069.11450dd1df2bd3c998b52ffebbbbbce8@tools.ietf.org> X-Trac-Ticket-ID: 53 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, pselkirk@isc.org, 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 Resent-To: Resent-Message-Id: <20110607005346.3130821F85EF@ietfa.amsl.com> Resent-Date: Mon, 6 Jun 2011 17:53:46 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #53: Make PCP Client's IP Address field optional 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, 07 Jun 2011 00:53:46 -0000 #53: Make PCP Client's IP Address field optional > - I don't like the PCP Client's IP Address field. I don't think it > adds sufficient value to be worth spending 16 bytes in every packet, > plus additional processing time. I would support moving it to an > Option, or at least making it an optional field - e.g. if it's sent as > all-zeroes in the request, the server MUST process the request, and > MAY either fill it in, or leave it zeroed. The change log says "This > addition was consensus at IETF80", but that doesn't match my notes of > the meeting - it was discussed as a possible approach to a possible > problem, but no sense of the meeting was ever asked. -- ---------------------------------------------+------------------------------ Reporter: Paul Selkirk | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ Ticket URL: pcp From trac@tools.ietf.org Mon Jun 6 17:54:58 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 7490021F8457 for ; Mon, 6 Jun 2011 17:54:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrhwfmFwvvZ4 for ; Mon, 6 Jun 2011 17:54:58 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAB521F8455 for ; Mon, 6 Jun 2011 17:54:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QTkZG-0007Qa-Me; Mon, 06 Jun 2011 17:54:50 -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: draft-ietf-pcp-base@tools.ietf.org, pselkirk@isc.org X-Trac-Project: pcp Date: Tue, 07 Jun 2011 00:54:50 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/54 Message-ID: <069.21646df869fe401c02705a0d8d88d59d@tools.ietf.org> X-Trac-Ticket-ID: 54 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, pselkirk@isc.org, 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 Resent-To: Resent-Message-Id: <20110607005458.1EAB521F8455@ietfa.amsl.com> Resent-Date: Mon, 6 Jun 2011 17:54:58 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #54: PEER creating mappings 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, 07 Jun 2011 00:54:58 -0000 #54: PEER creating mappings I'm not happy with the way PEER has evolved, to where it can create mappings. It's heading in the direction of making MAP a special case of PEER (with remote port=0, remote peer=0 as wildcards). I also don't think the 7.3 use case is compelling enough to justify the added complexity in the protocol (or even the suggested added complexity in the client). -- ---------------------------------------------+------------------------------ Reporter: Paul Selkirk | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ Ticket URL: pcp From trac@tools.ietf.org Mon Jun 6 17:55:27 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 8231821F84B1 for ; Mon, 6 Jun 2011 17:55:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6jFDLmRFm+j for ; Mon, 6 Jun 2011 17:55:27 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 307EB21F84AF for ; Mon, 6 Jun 2011 17:55:27 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QTkZm-0007X7-0A; Mon, 06 Jun 2011 17:55:22 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 00:55:21 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/54#comment:1 Message-ID: <078.e33d8e263ecfc01a7395028d8c9d5773@tools.ietf.org> References: <069.21646df869fe401c02705a0d8d88d59d@tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <069.21646df869fe401c02705a0d8d88d59d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607005527.307EB21F84AF@ietfa.amsl.com> Resent-Date: Mon, 6 Jun 2011 17:55:27 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #54: PEER creating mappings 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, 07 Jun 2011 00:55:27 -0000 #54: PEER creating mappings Comment(by dthaler@…): This seems closely related to issue #51. -- ---------------------------------------------+------------------------------ Reporter: Paul Selkirk | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ Ticket URL: pcp From trac@tools.ietf.org Mon Jun 6 18:07:05 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 4BE4621F84FC for ; Mon, 6 Jun 2011 18:07:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MRJkoYHTLd6 for ; Mon, 6 Jun 2011 18:07:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id D306521F8477 for ; Mon, 6 Jun 2011 18:07:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.75) (envelope-from ) id 1QTkl0-0005Dk-3C; Mon, 06 Jun 2011 18:06:58 -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: draft-ietf-pcp-base@tools.ietf.org, pselkirk@isc.org X-Trac-Project: pcp Date: Tue, 07 Jun 2011 01:06:58 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/55 Message-ID: <070.efc6af3832843e5c6a67fe18d2059ada@tools.ietf.org> X-Trac-Ticket-ID: 55 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, pselkirk@isc.org, 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 Resent-To: Resent-Message-Id: <20110607010704.D306521F8477@ietfa.amsl.com> Resent-Date: Mon, 6 Jun 2011 18:07:04 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #55: MAP support mandatory or optional 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, 07 Jun 2011 01:07:05 -0000 #55: MAP support mandatory or optional Paul: > - There is no discussion about levels of conformance. There's some > discussion about particular options being optional (e.g. THIRD_PARTY > not supported in certain deployment scenarios), but no overall > statement of what features must be supported by all conformant > implementations. e.g. If I had a small embedded server that supported > MAP opcodes but not PEER, would it be conformant? Dan: > Nobody has initiated discussion or provided a straw-man on conformance > levels. What do we want? Myself, if there is any chance of a wireless > devices (which is approximately 100% chance), PEER needs to be supported > because it allows the wireless device to optimize its NAT keepalive > traffic. But, to me, MAP doesn't need to necessarily be supported. Alain: > I think we should stay away from conformance levels. This gets > very complex, very quickly, and does not help interoperability. > The argument that MAP or PEER are only useful in a wireline or > wireless scenario seams a bit weak to me. > We are now seeing fixed wireless environment... Which profile > should they have? > > I believe that unless there is a very strong reason against, > we should keep MAP & PEER functionality. Dave (from issue #52): > Should probably note [the hole created by MAP] is wider than > what can be done with a TCP SYN and hence in some environments > may be considered a security issue. It should probably be legal > for such deployments to have a PCP server accept PEER but not > MAP. This allows some uses (Reducing NAT Keepalive Messages, > Restoring Lost Implicit TCP Dynamic Mapping State) but not > others (Operating a Server). (Dave's comment was about configuration, whereas Paul's comment was specifically about implementation support.) -- ----------------------------------------------+----------------------------- Reporter: Paul Selkirk pcp From cheshire@apple.com Mon Jun 6 18:47:37 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 195E121F8561 for ; Mon, 6 Jun 2011 18:47:37 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ky-6qIdECV4t for ; Mon, 6 Jun 2011 18:47:36 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 959CF21F8562 for ; Mon, 6 Jun 2011 18:47:36 -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 <0LME003LMAXVJUD1@mail-out.apple.com> for pcp@ietf.org; Mon, 06 Jun 2011 18:47:35 -0700 (PDT) X-AuditID: 11807137-b7cd4ae000003108-61-4ded83375f81 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay16.apple.com (Apple SCV relay) with SMTP id 81.4A.12552.7338DED4; Mon, 06 Jun 2011 18:47:35 -0700 (PDT) Received: from [17.153.48.8] (unknown [17.153.48.8]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LME004BLCZ56Y80@koseret.apple.com> for pcp@ietf.org; Mon, 06 Jun 2011 18:47:35 -0700 (PDT) From: Stuart Cheshire In-reply-to: <069.11450dd1df2bd3c998b52ffebbbbbce8@tools.ietf.org> Date: Mon, 06 Jun 2011 18:47:28 -0700 Message-id: <1375E7E0-CE0A-48DE-8660-1B49236974E6@apple.com> References: <069.11450dd1df2bd3c998b52ffebbbbbce8@tools.ietf.org> To: Paul Selkirk X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: pcp@ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] #53: Make PCP Client's IP Address field optional 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, 07 Jun 2011 01:47:37 -0000 On 6 Jun 2011, at 17:53, pcp issue tracker wrote: > #53: Make PCP Client's IP Address field optional > >> - I don't like the PCP Client's IP Address field. I don't think it >> adds sufficient value to be worth spending 16 bytes in every packet, >> plus additional processing time. I would support moving it to an >> Option, or at least making it an optional field - e.g. if it's sent as >> all-zeroes in the request, the server MUST process the request, and >> MAY either fill it in, or leave it zeroed. The change log says "This >> addition was consensus at IETF80", but that doesn't match my notes of >> the meeting - it was discussed as a possible approach to a possible >> problem, but no sense of the meeting was ever asked. The document needs to explain this better. The PCP Client's IP Address field is necessary for detecting intervening NATs. Otherwise the client and PCP-enabled NAT may *think* they have a successful inbound mapping, but it won't work. Margaret Wasserman pointed this out this insight at the Prague meeting. Telling the user that PCP won't work for them until they get rid of (or upgrade) their intervening non-PCP-aware NAT is very important for usability. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Mon Jun 6 20:36:16 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 717F31F0C4A for ; Mon, 6 Jun 2011 20:36:16 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL7k+rnfLplt for ; Mon, 6 Jun 2011 20:36:15 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id A478A1F0C46 for ; Mon, 6 Jun 2011 20:36:15 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay11.apple.com ([17.128.113.48]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LME0033HI0DJUW1@mail-out.apple.com> for pcp@ietf.org; Mon, 06 Jun 2011 20:36:15 -0700 (PDT) X-AuditID: 11807130-b7c15ae000005aca-9b-4ded9cae6efb Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay11.apple.com (Apple SCV relay) with SMTP id 53.84.23242.FAC9DED4; Mon, 06 Jun 2011 20:36:15 -0700 (PDT) Received: from [10.0.1.2] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LME008A2I0DMF70@koseret.apple.com> for pcp@ietf.org; Mon, 06 Jun 2011 20:36:14 -0700 (PDT) From: Stuart Cheshire In-reply-to: <069.11450dd1df2bd3c998b52ffebbbbbce8@tools.ietf.org> Date: Mon, 06 Jun 2011 20:36:13 -0700 Message-id: References: <069.11450dd1df2bd3c998b52ffebbbbbce8@tools.ietf.org> To: Paul Selkirk X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Cc: pcp@ietf.org, draft-ietf-pcp-base@tools.ietf.org Subject: Re: [pcp] #53: Make PCP Client's IP Address field optional 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, 07 Jun 2011 03:36:16 -0000 On 6 Jun 2011, at 17:53, pcp issue tracker wrote: > #53: Make PCP Client's IP Address field optional I just remembered another thing too: We should probably include the client's apparent source port too. Do we know of cases where a NAT might rewrite the client port but not the IP address? If we're certain this can never happen then we don't need the port as well, but if we're not sure, it's safer to include it. We can save space in the reply by not including the client address and port. It's there for the PCP-enabled NAT to verify that the IP-level source address and port weren't modified in transit by an intervening non-PCP-aware NAT; there's nothing gained by echoing it back to the client. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Mon Jun 6 21:26: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 A01A011E808D for ; Mon, 6 Jun 2011 21:26:45 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TUnh38AJ-aB for ; Mon, 6 Jun 2011 21:26:44 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 697B311E8070 for ; Mon, 6 Jun 2011 21:26:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LME003GDKCIJUY1@mail-out.apple.com> for pcp@ietf.org; Mon, 06 Jun 2011 21:26:44 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-7c-4deda8830178 Received: from kencur (kencur.apple.com [17.151.62.38]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay13.apple.com (Apple SCV relay) with SMTP id 0A.19.29082.388ADED4; Mon, 06 Jun 2011 21:26:43 -0700 (PDT) Received: from [10.0.1.2] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LME003UCKCJDPB0@cardamom.apple.com> for pcp@ietf.org; Mon, 06 Jun 2011 21:26:43 -0700 (PDT) From: Stuart Cheshire In-reply-to: Date: Mon, 06 Jun 2011 21:26:42 -0700 Message-id: <1CA28184-59FD-4A32-B19E-8ECB3DACC3B4@apple.com> 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.12 Precedence: list List-Id: PCP wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2011 04:26:45 -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 This draft is not "relying" on multicast. It says that PCP servers which choose to implement Rapid Recovery choose to send restart announcements on their multicast-capable interfaces. Just because multicast is not available to some PCP servers shouldn't mean that no PCP servers are allowed to use it. Allowing Rapid Recovery where available gives PCP feature-parity with NAT-PMP. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From cheshire@apple.com Mon Jun 6 22:07: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 140F521F8541 for ; Mon, 6 Jun 2011 22:07:47 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUT9I+8fL8Db for ; Mon, 6 Jun 2011 22:07:46 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2263621F8535 for ; Mon, 6 Jun 2011 22:07:45 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay13.apple.com ([17.128.113.29]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LME003F3M8SJU02@mail-out.apple.com> for pcp@ietf.org; Mon, 06 Jun 2011 22:07:45 -0700 (PDT) X-AuditID: 1180711d-b7c70ae00000719a-78-4dedb221ad2c 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 relay13.apple.com (Apple SCV relay) with SMTP id B1.92.29082.122BDED4; Mon, 06 Jun 2011 22:07:45 -0700 (PDT) Received: from [10.0.1.2] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by cardamom.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LME002Z0M8VT020@cardamom.apple.com> for pcp@ietf.org; Mon, 06 Jun 2011 22:07:45 -0700 (PDT) From: Stuart Cheshire In-reply-to: <9B57C850BB53634CACEC56EF4853FF653B0BA0FD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Date: Mon, 06 Jun 2011 22:07:42 -0700 Message-id: References: <9B57C850BB53634CACEC56EF4853FF653B0BA0FD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> To: pcp@ietf.org X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: AAAAAA== Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.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: Tue, 07 Jun 2011 05:07:47 -0000 My comments are below. I have text in mind to fix these things, but I haven't had time to write it up yet. 1. The definition of "subscriber" needs to be tightened up. 2. Why are some IP address fields "always 128 bits", and others are "32 or 128 bits"? Can we make this consistent? 3. Where a 128-bit IP address field contains an IPv4 address, we need to ensure that it can't inadvertently look like a valid IPv6 address as well as being a zero-padded IPv4 address. 4. Handling of the "O" bit is not fully specified for clients. 5. The THIRD_PARTY scenarios are a bit confused and self-contradictory. 6. Security for the THIRD_PARTY option needs more detailed specification. 7. PROCESSING_ERROR is unused. 8. ADDRESS_MISMATCH value is undefined. 9. How to handle responses from multiple PCP servers is underspecified. Responses don't arrive simultaneously. One arrives first, and then the other arrives later. What should the client do when the later one arrives? Undo everything it did in response to the first one? 10. Document uses both "NAT" and "NAPT". We should pick one and be consistent. 11. Use of wildcard ("0") address, port and protocol fields could be explained more clearly. 12. Don't match External_AF when validating response. 13. Is option length in bytes or 32-bit words? 14. Is FILTER Option mandatory to implement? How many filters per mapping? 15. Non-EIM seems like a confusing double negative ("non-independent"). Can we just say "EDM" ("dependent") instead? 16. Saying that an "Ethernet switch needs to perform ingress filtering" seems to be putting unreasonable demands on devices that know nothing about PCP, NAT, or even IP. 17. Why are new OpCodes "Standards Action" but new Result Codes are only "Specification Required"? Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org From trac@tools.ietf.org Tue Jun 7 06:50: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 1112011E80E7 for ; Tue, 7 Jun 2011 06:50:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yKm912NRcO1 for ; Tue, 7 Jun 2011 06:50:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 964BD11E808E for ; Tue, 7 Jun 2011 06:50:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTwfV-0002fc-56; Tue, 07 Jun 2011 06:50:05 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 13:50:05 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/50#comment:1 Message-ID: <068.b3b738d26ce69a350beab3fc74dc7ace@tools.ietf.org> References: <059.3983d702876cabfa50cd4658b44167fa@tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <059.3983d702876cabfa50cd4658b44167fa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607135016.964BD11E808E@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 06:50:16 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #50: 128 bit PCP Client's IP Address and Suggested External IP Address fields 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, 07 Jun 2011 13:50:18 -0000 #50: 128 bit PCP Client's IP Address and Suggested External IP Address fields Changes (by dthaler@…): * priority: minor => major Comment: Stuart Cheshire wrote: > 2. Why are some IP address fields "always 128 bits", and others are "32 or 128 > bits"? Can we make this consistent? > > 3. Where a 128-bit IP address field contains an IPv4 address, we need to ensure > that it can't inadvertently look like a valid IPv6 address as well as being a > zero-padded IPv4 address. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: enhancement | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 06:51:57 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 CD5D711E8111 for ; Tue, 7 Jun 2011 06:51: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTZUoI0UMQri for ; Tue, 7 Jun 2011 06:51:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 5F91311E808E for ; Tue, 7 Jun 2011 06:51:57 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTwhD-0005oX-Cb; Tue, 07 Jun 2011 06:51:51 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 13:51:51 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/55#comment:1 Message-ID: <079.cc144bda8d46a75a6adfef11121ecc9e@tools.ietf.org> References: <070.efc6af3832843e5c6a67fe18d2059ada@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <070.efc6af3832843e5c6a67fe18d2059ada@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607135157.5F91311E808E@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 06:51:57 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #55: MAP support mandatory or optional 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, 07 Jun 2011 13:51:58 -0000 #55: MAP support mandatory or optional Comment(by dthaler@…): Stuart: > 14. Is FILTER Option mandatory to implement? How many filters per mapping? -- ----------------------------------------------+----------------------------- Reporter: Paul Selkirk pcp From trac@tools.ietf.org Tue Jun 7 06:53:05 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 8EEFF11E80E7 for ; Tue, 7 Jun 2011 06:53:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDRux-eGLKwd for ; Tue, 7 Jun 2011 06:53:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 3707E11E808E for ; Tue, 7 Jun 2011 06:53:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTwiG-0004yD-3R; Tue, 07 Jun 2011 06:52: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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 13:52:56 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/52#comment:1 Message-ID: <068.662ea192b8fe7e478aa425131a906196@tools.ietf.org> References: <059.62dd03011306661e8e9adf9c3b25b18d@tools.ietf.org> X-Trac-Ticket-ID: 52 In-Reply-To: <059.62dd03011306661e8e9adf9c3b25b18d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607135305.3707E11E808E@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 06:53:05 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #52: More security considerations 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, 07 Jun 2011 13:53:05 -0000 #52: More security considerations Comment(by dthaler@…): Stuart Cheshire writes: > 16. Saying that an "Ethernet switch needs to perform ingress filtering" seems > to be putting unreasonable demands on devices that know nothing about PCP, NAT, > or even IP. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 06:54:05 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 EEBE211E8107 for ; Tue, 7 Jun 2011 06:54:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sbkka-1eThqJ for ; Tue, 7 Jun 2011 06:54:05 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id A217F11E808E for ; Tue, 7 Jun 2011 06:54:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTwjE-000624-CL; Tue, 07 Jun 2011 06:53: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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 13:53:56 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/49#comment:2 Message-ID: <068.ad437b3d8646fb1dec963490714cf987@tools.ietf.org> References: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607135405.A217F11E808E@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 06:54:05 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #49: Multihoming confusion 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, 07 Jun 2011 13:54:06 -0000 #49: Multihoming confusion Comment(by dthaler@…): Stuart Cheshire writes: > 9. How to handle responses from multiple PCP servers is underspecified. > Responses don't arrive simultaneously. One arrives first, and then the other > arrives later. What should the client do when the later one arrives? Undo > everything it did in response to the first one? -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 06:57: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 F338111E810C for ; Tue, 7 Jun 2011 06:57:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zH6Wnts5zmc for ; Tue, 7 Jun 2011 06:57:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id A99A211E810B for ; Tue, 7 Jun 2011 06:57:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTwmL-000348-HR; Tue, 07 Jun 2011 06:57:09 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 13:57:09 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/52#comment:2 Message-ID: <068.c8325647f08217058353f25eb848e4c9@tools.ietf.org> References: <059.62dd03011306661e8e9adf9c3b25b18d@tools.ietf.org> X-Trac-Ticket-ID: 52 In-Reply-To: <059.62dd03011306661e8e9adf9c3b25b18d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607135714.A99A211E810B@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 06:57:14 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #52: More security considerations 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, 07 Jun 2011 13:57:15 -0000 #52: More security considerations Comment(by dthaler@…): Stuart: > 6. Security for the THIRD_PARTY option needs more detailed specification. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 07:10:32 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 687A411E8116 for ; Tue, 7 Jun 2011 07:10:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0ynlDby1o6K for ; Tue, 7 Jun 2011 07:10:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67211E8110 for ; Tue, 7 Jun 2011 07:10:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTwys-00012M-W2; Tue, 07 Jun 2011 07:10: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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 14:10:06 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/56 Message-ID: <074.24b4344b3178570d3b5a899c34b6f21f@tools.ietf.org> X-Trac-Ticket-ID: 56 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.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 Resent-To: Resent-Message-Id: <20110607141032.0E67211E8110@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 07:10:32 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #56: Handling of the "O" bit is not fully specified for clients 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, 07 Jun 2011 14:10:32 -0000 #56: Handling of the "O" bit is not fully specified for clients > 4. Handling of the "O" bit is not fully specified for clients. -- --------------------------------------------------+------------------------- Reporter: Stuart Cheshire | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: --------------------------------------------------+------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 07:11:09 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 AF5D711E80F0 for ; Tue, 7 Jun 2011 07:11:09 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ime9-LarYk5C for ; Tue, 7 Jun 2011 07:11:09 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 527A111E808E for ; Tue, 7 Jun 2011 07:11:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTwzn-00015d-DB; Tue, 07 Jun 2011 07:11:03 -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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 14:11:03 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/57 Message-ID: <074.6c6928f61b449b95d6c1732721d226e6@tools.ietf.org> X-Trac-Ticket-ID: 57 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.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 Resent-To: Resent-Message-Id: <20110607141109.527A111E808E@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 07:11:09 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: [pcp] #57: THIRD_PARTY scenarios are a bit confused and self-contradictory. 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, 07 Jun 2011 14:11:09 -0000 #57: THIRD_PARTY scenarios are a bit confused and self-contradictory. 5. The THIRD_PARTY scenarios are a bit confused and self-contradictory. -- --------------------------------------------------+------------------------- Reporter: Stuart Cheshire | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: --------------------------------------------------+------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 07:17: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 5911511E8124 for ; Tue, 7 Jun 2011 07:17:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYF2abSeEN6a for ; Tue, 7 Jun 2011 07:17:03 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id E50C511E8122 for ; Tue, 7 Jun 2011 07:17:03 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTx5b-0004pT-On; Tue, 07 Jun 2011 07:17:03 -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: dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 14:17:03 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/48#comment:1 Message-ID: <072.df88b923354e4ffb9a95a41ac5862091@tools.ietf.org> References: <063.f493f7da452a8af15a92348282ef53f8@tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <063.f493f7da452a8af15a92348282ef53f8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: dthaler@microsoft.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] #48: Is PEER opcode support mandatory? 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, 07 Jun 2011 14:17:04 -0000 #48: Is PEER opcode support mandatory? Comment(by dthaler@…): 6/7/2001 interim call: Dave, Alain, Stuart for mandatory. Paul no preference. Consensus: keep as mandatory. -- ---------------------------------------+------------------------------------ Reporter: Francis.Dupont@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: ---------------------------------------+------------------------------------ Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 07:22:57 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 1B35411E8134 for ; Tue, 7 Jun 2011 07:22:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYvNSAS+IHUI for ; Tue, 7 Jun 2011 07:22:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA9911E8132 for ; Tue, 7 Jun 2011 07:22:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTxB4-0006rR-4n; Tue, 07 Jun 2011 07:22:45 -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, 07 Jun 2011 14:22:41 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/24#comment:5 Message-ID: <062.024623328133f360910114c756a0c161@tools.ietf.org> References: <053.c36c1daca80be11ae021721d8d265b20@tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <053.c36c1daca80be11ae021721d8d265b20@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] #24: PCP mappings same public IP address as dynamic mappings 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, 07 Jun 2011 14:22:57 -0000 #24: PCP mappings same public IP address as dynamic mappings Changes (by dwing@…): * status: closed => reopened * resolution: fixed => Comment: re-opened due to Tina Tsou's email, http://www.ietf.org/mail- archive/web/pcp/current/msg01353.html -- --------------------------------+------------------------------------------- Reporter: dwing@… | Owner: Type: enhancement | Status: reopened Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 07:23:00 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 B6ACB11E8123 for ; Tue, 7 Jun 2011 07:23:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MV8NQj8URTD9 for ; Tue, 7 Jun 2011 07:23:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDAA11E8126 for ; Tue, 7 Jun 2011 07:23:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTxBE-0007Ck-Ep; Tue, 07 Jun 2011 07:22:53 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 14:22:52 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/55#comment:2 Message-ID: <079.e51f11685c8908b3dbf302c13080ab9e@tools.ietf.org> References: <070.efc6af3832843e5c6a67fe18d2059ada@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <070.efc6af3832843e5c6a67fe18d2059ada@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607142300.4CDAA11E8126@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 07:23:00 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #55: MAP support mandatory or optional 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, 07 Jun 2011 14:23:00 -0000 #55: MAP support mandatory or optional Comment(by dthaler@…): 6/7/2011: Alain, Stuart - MAP should be mandatory to implement, but optional to configure/enable. Francis, Paul - ok if PEER is mandatory. -- ----------------------------------------------+----------------------------- Reporter: Paul Selkirk pcp From trac@tools.ietf.org Tue Jun 7 07:31:20 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 EA38011E810C for ; Tue, 7 Jun 2011 07:31:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haOf2J1cZNvo for ; Tue, 7 Jun 2011 07:31:20 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 73F4E11E80F7 for ; Tue, 7 Jun 2011 07:31:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTxJK-0006Zw-5u; Tue, 07 Jun 2011 07:31:14 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 14:31:14 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/55#comment:3 Message-ID: <079.7e5c7ce4ef7892ade2c407097db0cb01@tools.ietf.org> References: <070.efc6af3832843e5c6a67fe18d2059ada@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <070.efc6af3832843e5c6a67fe18d2059ada@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607143120.73F4E11E80F7@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 07:31:20 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #55: MAP support mandatory or optional 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, 07 Jun 2011 14:31:21 -0000 #55: MAP support mandatory or optional Comment(by dthaler@…): FILTER support: Francis - mandatory to implement, with unspecified # required to support Stuart - no preference, since app has to do checks anyway but beneficial to avoid BW usage. Mandatory to implement & support at least 1 filter. Alain - maybe a "few"? Francis - "not zero" Francis - FTP ALG would want 1 address, any port, in filter Paul - 1 is something we can justify -- ----------------------------------------------+----------------------------- Reporter: Paul Selkirk pcp From trac@tools.ietf.org Tue Jun 7 07:43:42 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 3E6B321F8481 for ; Tue, 7 Jun 2011 07:43:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YsWYSGtf92C for ; Tue, 7 Jun 2011 07:43:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9BE21F8480 for ; Tue, 7 Jun 2011 07:43:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTxVG-0000Tx-9i; Tue, 07 Jun 2011 07:43:34 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 14:43:34 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/51#comment:1 Message-ID: <068.90a92ee2551d3940fa7a593a5c88138a@tools.ietf.org> References: <059.63410ebe5d497d93b31b03826221e018@tools.ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <059.63410ebe5d497d93b31b03826221e018@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607144341.9B9BE21F8480@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 07:43:41 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #51: Mapping vs Filtering effect confusion 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, 07 Jun 2011 14:43:42 -0000 #51: Mapping vs Filtering effect confusion Comment(by dthaler@…): June 7 webex call: Q1) Dan - MAP does EIM and EIF. PEER uses whatever filtering NAT does today. Will add new text. Q2) Stuart - agree there is no way to stop accepting new connections without closing own. Dan - app could use FILTER for this. Dave - UDP generally uses 1 socket, so doesn't arise. Closing TCP listen socket without accept can happen, but listen socket isn't a BW sink we care about. No new text needed -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 07:59:35 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 868B211E8123 for ; Tue, 7 Jun 2011 07:59:35 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBbV4HlD5lfu for ; Tue, 7 Jun 2011 07:59:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 31BA811E811A for ; Tue, 7 Jun 2011 07:59:35 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTxkb-0007Xx-Q5; Tue, 07 Jun 2011 07:59:25 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 14:59:25 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/54#comment:2 Message-ID: <078.64a29bb62d28bfc35e41ffa51fd5cfbb@tools.ietf.org> References: <069.21646df869fe401c02705a0d8d88d59d@tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <069.21646df869fe401c02705a0d8d88d59d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607145935.31BA811E811A@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 07:59:35 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #54: PEER creating mappings 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, 07 Jun 2011 14:59:35 -0000 #54: PEER creating mappings Comment(by dthaler@…): See also Q3 in issue #51. 7 June 2011: Stuart - allow PEER to recreate lost state. Just does what a SYN would do. Francis - would be ok not allowing PEER to create state. Dan, Dave - allow PEER to recreate lost state. PCP client state is its TCP state. Alain - this little feature gives us a lot, in favor of it. Francis - how do you get suggested external port? Stuart - not in TCP state, PCP client has to remember it from the previous PEER request, and store it. Need to make pseudocode show this. Consensus to retain use, update pseudocode, and update sentence quoted in Q3 of #51. -- ---------------------------------------------+------------------------------ Reporter: Paul Selkirk | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 08:20:48 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 97CBA21F848B for ; Tue, 7 Jun 2011 08:20:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBLA2kVJiPWK for ; Tue, 7 Jun 2011 08:20:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id A38EE21F8490 for ; Tue, 7 Jun 2011 08:20:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTy58-0007H3-Oq; Tue, 07 Jun 2011 08:20:38 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 15:20:38 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/49#comment:3 Message-ID: <068.140b60412a736fad0d4d950a91d59217@tools.ietf.org> References: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607152046.A38EE21F8490@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 08:20:46 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #49: Multihoming confusion 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, 07 Jun 2011 15:20:49 -0000 #49: Multihoming confusion Comment(by dthaler@…): 7 June: Alain - when we took out Zone id, we said we'd leave out multihoming from this spec (extensions ok). Strawman: assume 1 PCP server per IP version and leave list to extension spec. Fix text to pick PCP server by IP version. Multiple interfaces text in section 7 moves to extension. DHCP option spec also says client picks 1st one, but more is left to extension spec (to cover how to make multihoming work more generally, not DHCP specific) -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 08:30:21 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 53C6D11E8159 for ; Tue, 7 Jun 2011 08:30:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af4sbPbm2sgX for ; Tue, 7 Jun 2011 08:30:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 2895811E8118 for ; Tue, 7 Jun 2011 08:30:20 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTyEN-0002Sw-VY; Tue, 07 Jun 2011 08:30:11 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 15:30:11 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/52#comment:3 Message-ID: <068.0c4f77317648b39d00be9418ab125582@tools.ietf.org> References: <059.62dd03011306661e8e9adf9c3b25b18d@tools.ietf.org> X-Trac-Ticket-ID: 52 In-Reply-To: <059.62dd03011306661e8e9adf9c3b25b18d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607153020.2895811E8118@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 08:30:20 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #52: More security considerations 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, 07 Jun 2011 15:30:21 -0000 #52: More security considerations Comment(by dthaler@…): 7 June: Dave - add mitigation that MAP can be disabled if admin chooses, since hole is wider than SYN can do, if SYN doesn't create EIF. Stuart - home gateway should only accept PCP on the internal interface -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 08:38: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 DB6CF11E816B for ; Tue, 7 Jun 2011 08:38:55 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB378GpVzTN4 for ; Tue, 7 Jun 2011 08:38:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id F0C8B11E8162 for ; Tue, 7 Jun 2011 08:38:54 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTyMe-0003Dg-O3; Tue, 07 Jun 2011 08:38:44 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 15:38:44 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/53#comment:1 Message-ID: <078.8a95b8e23e5295cff3a0b52849c5ead6@tools.ietf.org> References: <069.11450dd1df2bd3c998b52ffebbbbbce8@tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <069.11450dd1df2bd3c998b52ffebbbbbce8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607153854.F0C8B11E8162@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 08:38:54 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #53: Make PCP Client's IP Address field optional 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, 07 Jun 2011 15:38:56 -0000 #53: Make PCP Client's IP Address field optional Comment(by dthaler@…): Dan - how would client decide whether to include? Stuart - apple has a lot of tech support calls that can't figure out why BackToMyMac won't work, and this should help Alain - against making it be optional, increases complexity -- ---------------------------------------------+------------------------------ Reporter: Paul Selkirk | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: ---------------------------------------------+------------------------------ Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 08:41:59 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 5AD6E11E816A for ; Tue, 7 Jun 2011 08:41:59 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh52TS8eeOHS for ; Tue, 7 Jun 2011 08:41:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id F1C0711E8162 for ; Tue, 7 Jun 2011 08:41:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTyPg-0005Ul-0t; Tue, 07 Jun 2011 08:41:52 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 15:41:52 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/56#comment:1 Message-ID: <083.345ba5c3f8037192d095ea58a6e93fcc@tools.ietf.org> References: <074.24b4344b3178570d3b5a899c34b6f21f@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <074.24b4344b3178570d3b5a899c34b6f21f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607154158.F1C0711E8162@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 08:41:58 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #56: Handling of the "O" bit is not fully specified for clients 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, 07 Jun 2011 15:41:59 -0000 #56: Handling of the "O" bit is not fully specified for clients Comment(by dthaler@…): Page 14 talks about what PCP server does, but doesn't say what client does on receiption. Stuart will propose text. Paul - Design principle is client does not send errors to server. Client can only ignore whether or not O bit is set. Stuart - so in server-client direction all options are optional Dan - agree -- --------------------------------------------------+------------------------- Reporter: Stuart Cheshire | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: --------------------------------------------------+------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 08:49:16 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 2BA8F11E818E for ; Tue, 7 Jun 2011 08:49:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgLTWz3fsBn7 for ; Tue, 7 Jun 2011 08:49:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 96D0111E817A for ; Tue, 7 Jun 2011 08:49:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTyWi-0002Tv-NR; Tue, 07 Jun 2011 08:49:08 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 15:49:08 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/57#comment:1 Message-ID: <083.77c366427d162a69eb6e88274f715e15@tools.ietf.org> References: <074.6c6928f61b449b95d6c1732721d226e6@tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <074.6c6928f61b449b95d6c1732721d226e6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607154915.96D0111E817A@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 08:49:15 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #57: THIRD_PARTY scenarios are a bit confused and self-contradictory. 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, 07 Jun 2011 15:49:16 -0000 #57: THIRD_PARTY scenarios are a bit confused and self-contradictory. Comment(by dthaler@…): Stuart: Definition of subscriber is an "entity", needs to be tightened up. maybe "a group of machines for purposes of billing" or "administrative grouping of machines where a server can tell whether clients belong to the same grouping", e.g. same DS-lite tunnel. (See also comments under issue #52) Couldn't follow text on using THIRD_PARTY with only one IP address. Need to clarify. Client behind a NAT would be using the NAT's address, not THIRD_PARTY, to open hole for another device behind same NAT. Dan: business class subscriber may be 5 or 6 addresses. Stuart to contribute text. Dave: you only use THIRD_PARTY if the PCP client does not have the ability to send its PCP request from the IP address that will receive the data traffic. -- --------------------------------------------------+------------------------- Reporter: Stuart Cheshire | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: --------------------------------------------------+------------------------- Ticket URL: pcp From trac@tools.ietf.org Tue Jun 7 09:01: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 EB90B21F84C0 for ; Tue, 7 Jun 2011 09:01:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15Bo3uE2mgWK for ; Tue, 7 Jun 2011 09:01:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 95CB921F84BA for ; Tue, 7 Jun 2011 09:01:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QTyiP-00030o-67; Tue, 07 Jun 2011 09:01:13 -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: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.com X-Trac-Project: pcp Date: Tue, 07 Jun 2011 16:01:13 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/50#comment:2 Message-ID: <068.97bfb77388d301f6ae3960e168ca6343@tools.ietf.org> References: <059.3983d702876cabfa50cd4658b44167fa@tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <059.3983d702876cabfa50cd4658b44167fa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110607160123.95CB921F84BA@ietfa.amsl.com> Resent-Date: Tue, 7 Jun 2011 09:01:23 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #50: 128 bit PCP Client's IP Address and Suggested External IP Address fields 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, 07 Jun 2011 16:01:24 -0000 #50: 128 bit PCP Client's IP Address and Suggested External IP Address fields Changes (by dthaler@…): * type: enhancement => defect Comment: Dan - make all address fields 128 bits, rather than mixing variable length & fixed length Alain - 6PE also uses IPv4 mapped addresses to denote IPv4. Strawman: remove address family field, just use IPv4 mapped prefix to denote it's an IPv4 address. Consistent with 6PE precedent. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From pselkirk@isc.org Tue Jun 7 09:38:54 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 D578011E81A9 for ; Tue, 7 Jun 2011 09:38:53 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3aSiRTxizTg for ; Tue, 7 Jun 2011 09:38:53 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 73FF611E81A8 for ; Tue, 7 Jun 2011 09:38:52 -0700 (PDT) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 1B9EDC9428 for ; Tue, 7 Jun 2011 16:38:49 +0000 (UTC) (envelope-from pselkirk@isc.org) Received: by bikeshed.isc.org (Postfix, from userid 10300) id 123CE216C7E; Tue, 7 Jun 2011 16:38:49 +0000 (UTC) From: Paul Selkirk To: pcp@ietf.org Date: Tue, 07 Jun 2011 16:38:49 +0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [pcp] interim meeting notes 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, 07 Jun 2011 16:38:54 -0000 [Note: Dave has notes in the issue tracker, that may differ slightly in language, but should reflect the same consensus decisions.] PCP Working Group Interim Meeting, 7 June 2011 Dan Wing Dave Thaler Alain Durand Felipe Miranda Costa Francis Dupont Jean-Phillipe Dionne Paul Selkirk Stuart Cheshire This call is to go over issues raised in the WGLC and come to closure, so we can spin a new final draft, possibly issue a new LC if warranted. #48: Is PEER opcode support mandatory? Dave, Stuart: Should be mandatory to implement. Consensus: Unless specified otherwise, all base-spec components are mandatory to implement. #55: MAP support mandatory or optional Alain, Stuart: MAP should be mandatory to implement, but optional to configure. Francis: Making PEER mandatory but MAP optional doesn't make sense, may be against the charter. Stuart: Is FILTER mandatory to implement? Having too many things optional makes it unclear what it means to implement the spec. Suggest mandatory to implement FILTER, mandatory to support at least one, but acceptable to support only one. Stuart: Not sure who's going to use it. If a client can't depend on it being there, it has to do its own source filtering. OTOH, it's an optimization that keeps unwanted traffic away in the first place. Paul: We can justify putting the minimum at one filter; if we try to set a minimum greater than one, we're picking an arbitrary number that we can't justify on engineering grounds. #51: Mapping vs Filtering effect confusion Dave: Somewhere in this doc needs to explain that MAP results in EIF. PEER (without MAP) only needs APDF to support uses 7.2 (Reducing NAT Keepalive Messages) and 7.3 (Restoring Lost Implicit TCP Dynamic Mapping State). Dan: For MAP, say explicitly that it creates EIM and EIF; for PEER, say that it's implementation dependent, and no different from what NAT does today. Stuart: Be careful not to have feature creep in the base spec. Let's not throw in this extra feature where we go into a partial shutdown where new connections are denied but existing connections are kept open. #54: PEER creating mappings Stuart: You can reboot an Airport, and it existing inbound connections are restored, but not existing outbound connections, and this asymmetry has always bothered me. If a client wants to take advantage of this new capability, it needs to issue a PEER request after connection. It makes a local copy of the NAT soft-state, which it can use to update the NAT. Dave: Rough consensus to keep this ability. Update pseudocode, add language that PEER has no effect on filtering state. #49: Multihoming confusion Dave: "Multihoming" encompasses multiple address families, multiple addresses in one address family, multiple default routers, and multiple PCP servers. Alain: We talked about this in relation to Zone ID. When we removed it, we decided to leave all multihoming discussion out of the base spec. Dave: At least some of this needs to be specified. Stuart: By analogy to DHCP, if there are multiple PCP responses, client picks the "best" response, but in practice picks the first response. Dave: In this case, the base spec shouldn't specify a "list" at all. Stuart: The DHCP extension spec (or some other extension spec) should say how the client should deal with multiple server addresses. Dave: Base spec should assume one PCP server per AF. #52: More security considerations Stuart: Tighten up the wording about ingress filtering. e.g. a HGW serving a local LAN should only accept requests on the LAN side, not the WAN side. Also tighten up language around THIRD_PARTY. Dave - add mitigation that MAP can be disabled if admin chooses, since hole is wider than SYN can do, if SYN doesn't create EIF. Stuart - home gateway should only accept PCP on the internal interface #53: Make PCP Client's IP Address field optional Paul: This is a diagnostic tool only, and there are scenarios that won't possibly have an on-path NAT. Stuart: The trade-off is worth the extra bytes and processing. Apple gets lots of tech support calls around misconfigured UPnP. Diagnostics are valuable. More complicated to make it optional than to put it in every packet. #56: Handling of the "O" bit is not fully specified for clients On the client side, all Options are truly optional; if it gets a success response with an Option that it doesn't understand, it ignores it, regardless of whether the "O" bit is set. #57: THIRD_PARTY scenarios are a bit confused and self-contradictory. Stuart: "Subscriber" is not well specified. THIRD_PARTY seems to be aimed at DS-Lite, without actually mentioning DS-Lite. Dave: You only use THIRD_PARTY if you can't send the PCP request from the IP address of the device that actually wants the mapping. #50: 128 bit PCP Client's IP Address and Suggested External IP Address fields Dave: Why not use IPv4-mapped IPv6 addresses? Dan: Kill the External_AF field then. Dan: We don't have industry consensus about whether mapped addresses can appear on the wire. Alain: AF fields create corner cases and complexity that we can live without; remove them. Stuart: Putting an IPv4 address as the first 32 bits of a 128-bit field could be misinterpreted as a v6 prefix. Putting a v4 address as the last 32 bits makes it a deprecated-form mapped address. Make it a current-form mapped address, with leading ::FFFF/96, and it's unambiguous. Consensus to make all address fields 128-bit fixed fields, remove AF fields. Next steps: We have multiple editors, so need to coordinate efforts. Paul will check in editorial nits, Dan will integrate Dave's changes. Stuart doesn't have time this week, will work on the plane this weekend, shooting for a deadline of next Tuesday. Start a new one-week WGLC as soon as the next draft is issued. From tena@huawei.com Tue Jun 7 11:17:53 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 11AEA11E8131 for ; Tue, 7 Jun 2011 11:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=-1.700, BAYES_00=-2.599, 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 s0XwbswYM40f for ; Tue, 7 Jun 2011 11:17:51 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by ietfa.amsl.com (Postfix) with ESMTP id 058C311E812E for ; Tue, 7 Jun 2011 11:17:51 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMF0065TMTQGX@usaga01-in.huawei.com> for pcp@ietf.org; Tue, 07 Jun 2011 13:17:50 -0500 (CDT) Received: from TingZousc1 ([12.133.183.34]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMF008C1MTPBA@usaga01-in.huawei.com> for pcp@ietf.org; Tue, 07 Jun 2011 13:17:50 -0500 (CDT) Date: Tue, 07 Jun 2011 11:17:14 -0700 From: Tina Tsou In-reply-to: <04d801cc231a$6b2747c0$4175d740$@com> To: 'Dan Wing' , 'Dave Thaler' , pcp@ietf.org Message-id: <004001cc253f$3600ef20$a202cd60$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwXKk61FuyajK7hRbulosJtjQ9K5wK/sVTgABOocjAAKHAzUACJWLSw References: <9B57C850BB53634CACEC56EF4853FF653B0BA0FD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B0E7836@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <01bb01cc2277$eb072b70$c1158250$@com> <04d801cc231a$6b2747c0$4175d740$@com> Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.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: Tue, 07 Jun 2011 18:17:53 -0000 Dan, Comments are in line beginning with [Tina: ...]. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Saturday, June 04, 2011 5:49 PM To: 'Tina Tsou'; 'Dave Thaler'; pcp@ietf.org Subject: RE: [pcp] WGLC: draft-ietf-pcp-base-12.txt > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Tina Tsou > Sent: Friday, June 03, 2011 10:26 PM > To: 'Dave Thaler'; pcp@ietf.org > Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > Dear all, > In section7, there is one description: > "It is REQUIRED that the PCP-controlled device assign the same > external IP address to PCP-created explicit dynamic mappings and to > implicit dynamic mappings." > It is only a requirement to CGN, but some existing CGN may not support > this requirement as defined in RFC4787-[REQ1]: > "Some NATs use the external IP address mapping in an arbitrary fashion > (i.e., randomly): one internal IP address could have multiple > external IP address mappings active at the same time for different > sessions" You quoted non-normative text; later in that same section of RFC4787 it explains how random ("Arbitrary") assignment causes harm. REQ-2 says that "paired" is RECOMMENDED. > Therefore, I suggest the PCP client should also support this > requirement which was actually defined in 00 version but deleted in > later versions (maybe I missed the reason of the text change): > If there is any existing PCP mapping, PCP client should only request > the same external IP address as the one of those existing mappings. The > reason is that it will allow applications that use multiple ports > originating from the same internal IP address to also have the same > external IP address. We (the NAT and PCP server) can't know if, when there is an implicit dynamic connection from a host's source port, that connection was done by the same application as the explicit mapping, or if the OS happened to assign that source port to some other (unrelated) application. [Tina: If the connection was done by one application as the explicit mapping, e.g., PCP mapping, the subsequent connection from the same internal IP address will use the same external IP address according to the PCP mapping. The implicit mapping will not match in this case. If the connection was done by one application as the implicit mapping, the subsequent connection can also use the same external IP address because the application can make the PCP client to meet the same requirement.] If the NAT is EIM, it will reuse the same mapping it already has. Because that is the definition of being a EIM NAT. And it is important that all implicit dynamic mappings use the same public IPv4 address (for all the reasons stated in the existing UDP and TCP RFCs). We don't want PCP to make that situation worse because some other un-related application did a MAP request. If it is a non-EIM NAT, I suppose there is a way to use separate pools, if the non-EIM NAT applies some sort of logic to the implicit sessions -- the logic described in #2 of http://tools.ietf.org/html/draft-ietf-pcp-base-12#section-11.1 If you want/need that, please provide text. [Tina: The proposed texts are as below: In non-EIM NAT case, PCP client should only request the same external IP address as the one of those existing links for one application. The reason is that it will allow application that use multiple ports originating from the same internal IP address to also have the same external IP address.] But I fear the interaction that is created if non-EIM NAT could create mappings on arbitrary IP addresses while EIM NAT creates mappings on the same IP address. For example, if an application was tested with an EIM NAT (which always assigns PCP-created mappings and implicit mappings to the same external IP address), that application may well fail when deployed behind a non-EIM NAT that (a) allocates different IP addresses for different PCP mappings or (b) different IP addresses for PCP mappings versus implicit dynamic mappings. -d > > Have a good weekend. > > We keep our promises with one another - no matter what! > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Dave Thaler > Sent: Friday, June 03, 2011 1:02 PM > To: pcp@ietf.org > Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > Some comments on -12 are in the marked up copy at > http://research.microsoft.com/users/dthaler/draft-ietf-pcp-base-12.pdf > > -Dave > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Dave Thaler > Sent: Friday, May 20, 2011 1:18 PM > To: pcp@ietf.org > Subject: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > This message starts a two-week WGLC on > http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-12.txt > > This last call will conclude on June 3rd at 5pm EST. > > Please send your comments to the list. > > We are scheduling a WebEx call shortly after the WGLC concludes, > and will send out details in separate email. > > Thanks, > -Dave and Alain > > From dwing@cisco.com Tue Jun 7 11:26:43 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 9A3BE11E8139 for ; Tue, 7 Jun 2011 11:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.3 X-Spam-Level: X-Spam-Status: No, score=-109.3 tagged_above=-999 required=5 tests=[AWL=1.300, 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 lK9aEi+irlJL for ; Tue, 7 Jun 2011 11:26:42 -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 079B111E8147 for ; Tue, 7 Jun 2011 11:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6773; q=dns/txt; s=iport; t=1307471202; x=1308680802; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=PUfpaub9bSWw2stDqtIuV/fCfJv91+PzbYWPJSrB9xc=; b=EX035WF054a/Rbb9ePfVy4Uw5lFFVG6+KSy7vMGYU9kaWbWnpCJkTbNY wFvCAa/caeh6E3oJY9uyYHErpKYQzzLofo0Ug9O2rZVrsDuQnHeEQ9r6s iZTSrCr7AmhAeDCPbeKMjNYUy9+DOrz9jxRsUfvmLKB14iPBBvvgEa89s o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwBAFps7k2rRDoG/2dsb2JhbABTlziBZo0Dd4hxommeEoYhBIZ4mXc X-IronPort-AV: E=Sophos;i="4.65,333,1304294400"; d="scan'208";a="372035707" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 07 Jun 2011 18:26:39 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p57IQdfS023919; Tue, 7 Jun 2011 18:26:39 GMT From: "Dan Wing" To: "'Tina Tsou'" , "'Dave Thaler'" , References: <9B57C850BB53634CACEC56EF4853FF653B0BA0FD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B0E7836@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <01bb01cc2277$eb072b70$c1158250$@com> <04d801cc231a$6b2747c0$4175d740$@com> <004001cc253f$3600ef20$a202cd60$@com> In-Reply-To: <004001cc253f$3600ef20$a202cd60$@com> Date: Tue, 7 Jun 2011 11:26:39 -0700 Message-ID: <02a201cc2540$7156a460$5403ed20$@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: AcwXKk61FuyajK7hRbulosJtjQ9K5wK/sVTgABOocjAAKHAzUACJWLSwAAAnAzA= Content-Language: en-us Subject: [pcp] PCP Issue #24, PCP mappings same public IP address as dynamic mappings [was RE: WGLC: draft-ietf-pcp-base-12.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: Tue, 07 Jun 2011 18:26:43 -0000 I changed the subject on this thread to better represent what is being discussed, which is http://trac.tools.ietf.org/wg/pcp/trac/ticket/24, "PCP mappings same public IP address as dynamic mappings". More below. > -----Original Message----- > From: Tina Tsou [mailto:tena@huawei.com] > Sent: Tuesday, June 07, 2011 11:17 AM > To: 'Dan Wing'; 'Dave Thaler'; pcp@ietf.org > Subject: RE: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > Dan, > Comments are in line beginning with [Tina: ...]. > > > We keep our promises with one another - no matter what! > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Saturday, June 04, 2011 5:49 PM > To: 'Tina Tsou'; 'Dave Thaler'; pcp@ietf.org > Subject: RE: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Tina Tsou > > Sent: Friday, June 03, 2011 10:26 PM > > To: 'Dave Thaler'; pcp@ietf.org > > Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > > > Dear all, > > In section7, there is one description: > > "It is REQUIRED that the PCP-controlled device assign the same > > external IP address to PCP-created explicit dynamic mappings and > to > > implicit dynamic mappings." > > It is only a requirement to CGN, but some existing CGN may not > support > > this requirement as defined in RFC4787-[REQ1]: > > "Some NATs use the external IP address mapping in an arbitrary > fashion > > (i.e., randomly): one internal IP address could have multiple > > external IP address mappings active at the same time for different > > sessions" > > You quoted non-normative text; later in that same section of RFC4787 > it explains how random ("Arbitrary") assignment causes harm. REQ-2 > says that "paired" is RECOMMENDED. > > > Therefore, I suggest the PCP client should also support this > > requirement which was actually defined in 00 version but deleted in > > later versions (maybe I missed the reason of the text change): > > If there is any existing PCP mapping, PCP client should only request > > the same external IP address as the one of those existing mappings. > The > > reason is that it will allow applications that use multiple ports > > originating from the same internal IP address to also have the same > > external IP address. > > > We (the NAT and PCP server) can't know if, when there is an implicit > dynamic connection from a host's source port, that connection was > done by the same application as the explicit mapping, or if the OS > happened to assign that source port to some other (unrelated) > application. > [Tina: If the connection was done by one application as the explicit > mapping, e.g., PCP mapping, the subsequent connection from the same > internal > IP address will use the same external IP address according to the PCP > mapping. Agreed. > The implicit mapping will not match in this case. If the connection > was done by one application as the implicit mapping, the subsequent > connection can also use the same external IP address because the > application > can make the PCP client to meet the same requirement.] Sorry, I do not understand the previous two sentences. > If the NAT is EIM, it will reuse the same mapping it already > has. Because that is the definition of being a EIM NAT. > And it is important that all implicit dynamic mappings use the > same public IPv4 address (for all the reasons stated in the > existing UDP and TCP RFCs). We don't want PCP to make that > situation worse because some other un-related application did > a MAP request. > > If it is a non-EIM NAT, I suppose there is a way to use separate > pools, if the non-EIM NAT applies some sort of logic to the > implicit sessions -- the logic described in #2 of > http://tools.ietf.org/html/draft-ietf-pcp-base-12#section-11.1 > If you want/need that, please provide text. > [Tina: The proposed texts are as below: > In non-EIM NAT case, PCP client should only request the same external > IP > address as the one of those existing links for one application. The > reason is that it will allow application that use multiple ports > originating > from the same internal IP address to also have the same > external IP address.] I think see what you're wanting the document to say. How about this proposed text, instead: If there is already an active explicit dynamic mapping, it will be mapped to a certain external IP address. When the PCP client makes another explicit dynamic mapping, it SHOULD place the external IP address of the existing mapping into the Requested External Address of the MAP request. By doing this, all of the PCP client's explicit dynamic mappings will be on the same external address. Does that say the same thing? Is it acceptable? -d > But I fear the interaction that is created if non-EIM NAT > could create mappings on arbitrary IP addresses while EIM > NAT creates mappings on the same IP address. For example, > if an application was tested with an EIM NAT (which always > assigns PCP-created mappings and implicit mappings to the > same external IP address), that application may well fail > when deployed behind a non-EIM NAT that (a) allocates different > IP addresses for different PCP mappings or (b) different IP > addresses for PCP mappings versus implicit dynamic mappings. > > -d > > > > > > Have a good weekend. > > > > We keep our promises with one another - no matter what! > > > > Best Regards, > > Tina TSOU > > http://tinatsou.weebly.com/contact.html > > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Dave Thaler > > Sent: Friday, June 03, 2011 1:02 PM > > To: pcp@ietf.org > > Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > > > Some comments on -12 are in the marked up copy at > > http://research.microsoft.com/users/dthaler/draft-ietf-pcp-base- > 12.pdf > > > > -Dave > > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Dave Thaler > > Sent: Friday, May 20, 2011 1:18 PM > > To: pcp@ietf.org > > Subject: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > > > This message starts a two-week WGLC on > > http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-12.txt > > > > This last call will conclude on June 3rd at 5pm EST. > > > > Please send your comments to the list. > > > > We are scheduling a WebEx call shortly after the WGLC concludes, > > and will send out details in separate email. > > > > Thanks, > > -Dave and Alain > > > > From Francis.Dupont@fdupont.fr Tue Jun 7 12:27: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 7B0C811E8214 for ; Tue, 7 Jun 2011 12:27:25 -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 YvpF0+9AUWQE for ; Tue, 7 Jun 2011 12:27:25 -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 8871211E8225 for ; Tue, 7 Jun 2011 12:27:24 -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 p57JPowg060680; Tue, 7 Jun 2011 21:25:50 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201106071925.p57JPowg060680@givry.fdupont.fr> From: Francis Dupont To: "Dan Wing" In-reply-to: Your message of Sat, 04 Jun 2011 17:49:25 PDT. <04d801cc231a$6b2747c0$4175d740$@com> Date: Tue, 07 Jun 2011 21:25:50 +0200 Sender: Francis.Dupont@fdupont.fr Cc: pcp@ietf.org Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.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: Tue, 07 Jun 2011 19:27:25 -0000 In your previous mail you wrote: If the NAT is EIM, it will reuse the same mapping it already has. Because that is the definition of being a EIM NAT. => this is a misconception: it can use it as to convert an implicit dynamic EIM/EIF mapping into an explicit dynamic mapping is more than easy but this doesn't mean it is the only way or there cannot be some constraint forbidding this. In particular when the explicit dynamic mappings use a different external port set (*). Regards Francis.Dupont@fdupont.fr PS (*): resource management is a good reason to split the external port space. Or the legal logging: explicit dynamic mappings have far longer lifetimes so the usual trick to log only the allocation of implicit mapping port sets is not adapted... From tena@huawei.com Tue Jun 7 18:19:50 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 CBDAD11E8136 for ; Tue, 7 Jun 2011 18:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.449 X-Spam-Level: X-Spam-Status: No, score=-105.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 aMhp3i7SYM3Z for ; Tue, 7 Jun 2011 18:19:49 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by ietfa.amsl.com (Postfix) with ESMTP id 7440E11E8073 for ; Tue, 7 Jun 2011 18:19:49 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMG006BR6D0YL@usaga03-in.huawei.com> for pcp@ietf.org; Tue, 07 Jun 2011 20:19:49 -0500 (CDT) Received: from TingZousc1 ([12.133.183.34]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMG004A96CZ81@usaga03-in.huawei.com> for pcp@ietf.org; Tue, 07 Jun 2011 20:19:48 -0500 (CDT) Date: Tue, 07 Jun 2011 18:19:12 -0700 From: Tina Tsou In-reply-to: <02a201cc2540$7156a460$5403ed20$@com> To: 'Dan Wing' , 'Dave Thaler' , pcp@ietf.org Message-id: <016f01cc257a$28c5c7f0$7a5157d0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcwXKk61FuyajK7hRbulosJtjQ9K5wK/sVTgABOocjAAKHAzUACJWLSwAAAnAzAADpT1cA== References: <9B57C850BB53634CACEC56EF4853FF653B0BA0FD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> <9B57C850BB53634CACEC56EF4853FF653B0E7836@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> <01bb01cc2277$eb072b70$c1158250$@com> <04d801cc231a$6b2747c0$4175d740$@com> <004001cc253f$3600ef20$a202cd60$@com> <02a201cc2540$7156a460$5403ed20$@com> Subject: Re: [pcp] PCP Issue #24, PCP mappings same public IP address as dynamic mappings [was RE: WGLC: draft-ietf-pcp-base-12.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, 08 Jun 2011 01:19:50 -0000 Dan, Replies are in line with [Tina 1: ...]. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -----Original Message----- From: Dan Wing [mailto:dwing@cisco.com] Sent: Tuesday, June 07, 2011 11:27 AM To: 'Tina Tsou'; 'Dave Thaler'; pcp@ietf.org Subject: PCP Issue #24, PCP mappings same public IP address as dynamic mappings [was RE: [pcp] WGLC: draft-ietf-pcp-base-12.txt] I changed the subject on this thread to better represent what is being discussed, which is http://trac.tools.ietf.org/wg/pcp/trac/ticket/24, "PCP mappings same public IP address as dynamic mappings". More below. > -----Original Message----- > From: Tina Tsou [mailto:tena@huawei.com] > Sent: Tuesday, June 07, 2011 11:17 AM > To: 'Dan Wing'; 'Dave Thaler'; pcp@ietf.org > Subject: RE: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > Dan, > Comments are in line beginning with [Tina: ...]. > > > We keep our promises with one another - no matter what! > > Best Regards, > Tina TSOU > http://tinatsou.weebly.com/contact.html > > > -----Original Message----- > From: Dan Wing [mailto:dwing@cisco.com] > Sent: Saturday, June 04, 2011 5:49 PM > To: 'Tina Tsou'; 'Dave Thaler'; pcp@ietf.org > Subject: RE: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > > -----Original Message----- > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Tina Tsou > > Sent: Friday, June 03, 2011 10:26 PM > > To: 'Dave Thaler'; pcp@ietf.org > > Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > > > Dear all, > > In section7, there is one description: > > "It is REQUIRED that the PCP-controlled device assign the same > > external IP address to PCP-created explicit dynamic mappings and > to > > implicit dynamic mappings." > > It is only a requirement to CGN, but some existing CGN may not > support > > this requirement as defined in RFC4787-[REQ1]: > > "Some NATs use the external IP address mapping in an arbitrary > fashion > > (i.e., randomly): one internal IP address could have multiple > > external IP address mappings active at the same time for different > > sessions" > > You quoted non-normative text; later in that same section of RFC4787 > it explains how random ("Arbitrary") assignment causes harm. REQ-2 > says that "paired" is RECOMMENDED. > > > Therefore, I suggest the PCP client should also support this > > requirement which was actually defined in 00 version but deleted in > > later versions (maybe I missed the reason of the text change): > > If there is any existing PCP mapping, PCP client should only request > > the same external IP address as the one of those existing mappings. > The > > reason is that it will allow applications that use multiple ports > > originating from the same internal IP address to also have the same > > external IP address. > > > We (the NAT and PCP server) can't know if, when there is an implicit > dynamic connection from a host's source port, that connection was > done by the same application as the explicit mapping, or if the OS > happened to assign that source port to some other (unrelated) > application. > [Tina: If the connection was done by one application as the explicit > mapping, e.g., PCP mapping, the subsequent connection from the same > internal > IP address will use the same external IP address according to the PCP > mapping. Agreed. > The implicit mapping will not match in this case. If the connection > was done by one application as the implicit mapping, the subsequent > connection can also use the same external IP address because the > application > can make the PCP client to meet the same requirement.] Sorry, I do not understand the previous two sentences. [Tina 1: I'm only talking about the PCP mapping case. If the previous connection is implicit mapping, it will not match.] > If the NAT is EIM, it will reuse the same mapping it already > has. Because that is the definition of being a EIM NAT. > And it is important that all implicit dynamic mappings use the > same public IPv4 address (for all the reasons stated in the > existing UDP and TCP RFCs). We don't want PCP to make that > situation worse because some other un-related application did > a MAP request. > > If it is a non-EIM NAT, I suppose there is a way to use separate > pools, if the non-EIM NAT applies some sort of logic to the > implicit sessions -- the logic described in #2 of > http://tools.ietf.org/html/draft-ietf-pcp-base-12#section-11.1 > If you want/need that, please provide text. > [Tina: The proposed texts are as below: > In non-EIM NAT case, PCP client should only request the same external > IP > address as the one of those existing links for one application. The > reason is that it will allow application that use multiple ports > originating > from the same internal IP address to also have the same > external IP address.] I think see what you're wanting the document to say. How about this proposed text, instead: If there is already an active explicit dynamic mapping, it will be mapped to a certain external IP address. When the PCP client makes another explicit dynamic mapping, it SHOULD place the external IP address of the existing mapping into the Requested External Address of the MAP request. By doing this, all of the PCP client's explicit dynamic mappings will be on the same external address. Does that say the same thing? Is it acceptable? [Tina 1: Yes, it is the same thing and I agree with the texts. Thank you, Dan.] -d > But I fear the interaction that is created if non-EIM NAT > could create mappings on arbitrary IP addresses while EIM > NAT creates mappings on the same IP address. For example, > if an application was tested with an EIM NAT (which always > assigns PCP-created mappings and implicit mappings to the > same external IP address), that application may well fail > when deployed behind a non-EIM NAT that (a) allocates different > IP addresses for different PCP mappings or (b) different IP > addresses for PCP mappings versus implicit dynamic mappings. > > -d > > > > > > Have a good weekend. > > > > We keep our promises with one another - no matter what! > > > > Best Regards, > > Tina TSOU > > http://tinatsou.weebly.com/contact.html > > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Dave Thaler > > Sent: Friday, June 03, 2011 1:02 PM > > To: pcp@ietf.org > > Subject: Re: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > > > Some comments on -12 are in the marked up copy at > > http://research.microsoft.com/users/dthaler/draft-ietf-pcp-base- > 12.pdf > > > > -Dave > > > > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > > Dave Thaler > > Sent: Friday, May 20, 2011 1:18 PM > > To: pcp@ietf.org > > Subject: [pcp] WGLC: draft-ietf-pcp-base-12.txt > > > > This message starts a two-week WGLC on > > http://www.ietf.org/internet-drafts/draft-ietf-pcp-base-12.txt > > > > This last call will conclude on June 3rd at 5pm EST. > > > > Please send your comments to the list. > > > > We are scheduling a WebEx call shortly after the WGLC concludes, > > and will send out details in separate email. > > > > Thanks, > > -Dave and Alain > > > > From mohamed.boucadair@orange-ftgroup.com Wed Jun 8 05:33:48 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 3C292228015 for ; Wed, 8 Jun 2011 05:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 kQGLwyppHhtP for ; Wed, 8 Jun 2011 05:33:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2AA228013 for ; Wed, 8 Jun 2011 05:33:47 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 14BBD2AC796; Wed, 8 Jun 2011 14:33:46 +0200 (CEST) Received: from PUEXCH51.nanterre.francetelecom.fr (unknown [10.101.44.31]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id BE57C18004D; Wed, 8 Jun 2011 14:33:45 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH51.nanterre.francetelecom.fr ([10.101.44.31]) with mapi; Wed, 8 Jun 2011 14:33:45 +0200 From: To: pcp issue tracker , "draft-ietf-pcp-base@tools.ietf.org" , "pselkirk@isc.org" Date: Wed, 8 Jun 2011 14:33:45 +0200 Thread-Topic: [pcp] #53: Make PCP Client's IP Address field optional Thread-Index: AcwkrVpcZMnsRW8qSuqx4tXq+Y4RsgBKO7Bw Message-ID: <94C682931C08B048B7A8645303FDC9F33E50161EE9@PUEXCB1B.nanterre.francetelecom.fr> References: <069.11450dd1df2bd3c998b52ffebbbbbce8@tools.ietf.org> In-Reply-To: <069.11450dd1df2bd3c998b52ffebbbbbce8@tools.ietf.org> 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.6.8.92420 Cc: "pcp@ietf.org" Subject: Re: [pcp] #53: Make PCP Client's IP Address field optional 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, 08 Jun 2011 12:33:48 -0000 Dear all, If I remember well, the decision to include the PCP Client IP address was a= greed in Prague as a mitigation solution to the interference problem. It ha= s been agreed also to document the NAT detection procedure in an extension = document. Perhaps, this is recorded in the minutes... If the WG decides to include the IP address of the PCP Client in all PCP re= quests to detect a NAT in the path, then the received port should be includ= ed too: see http://tools.ietf.org/html/draft-boucadair-pcp-extensions-01#se= ction-5 The PCP Client IP Address can also be used to avoid a PCP Client to clear t= he mappings of another PCP Client of the same subscriber. But if the host g= ets a new IP address, this may lead to stale mappings and consumes the per-= user port quota. Cheers, Med -----Message d'origine----- De : pcp issue tracker [mailto:trac@tools.ietf.org]=20 Envoy=E9 : mardi 7 juin 2011 02:54 =C0 : draft-ietf-pcp-base@tools.ietf.org; pselkirk@isc.org Cc : pcp@ietf.org Objet : [pcp] #53: Make PCP Client's IP Address field optional #53: Make PCP Client's IP Address field optional > - I don't like the PCP Client's IP Address field. I don't think it > adds sufficient value to be worth spending 16 bytes in every packet, > plus additional processing time. I would support moving it to an > Option, or at least making it an optional field - e.g. if it's sent as > all-zeroes in the request, the server MUST process the request, and > MAY either fill it in, or leave it zeroed. The change log says "This > addition was consensus at IETF80", but that doesn't match my notes of > the meeting - it was discussed as a possible approach to a possible > problem, but no sense of the meeting was ever asked. --=20 ---------------------------------------------+-----------------------------= - Reporter: Paul Selkirk | Owner: draft-ietf-pcp= -base@. =20 Type: defect | Status: new = =20 Priority: major | Milestone: = =20 Component: base | Version: = =20 Severity: Active WG Document | Keywords: = =20 ---------------------------------------------+-----------------------------= - Ticket URL: pcp From roberta.maglione@telecomitalia.it Mon Jun 13 01:32:49 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 17C7111E80AF for ; Mon, 13 Jun 2011 01:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 2I1ho2iXLF+3 for ; Mon, 13 Jun 2011 01:32:48 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 40F4111E80B0 for ; Mon, 13 Jun 2011 01:32:48 -0700 (PDT) Received: from GRFHUB703BA020.griffon.local (10.188.101.113) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 13 Jun 2011 10:32:46 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.15]) by GRFHUB703BA020.griffon.local ([10.188.101.113]) with mapi; Mon, 13 Jun 2011 10:32:45 +0200 From: Maglione Roberta To: "'pcp@ietf.org'" Date: Mon, 13 Jun 2011 10:32:44 +0200 Thread-Topic: New Version Notification for draft-maglione-pcp-radius-ext-01.txt Thread-Index: AcwlsDNijF9Dd/yzR06TfHemYZfxtQD9BYkg Message-ID: <282BBE8A501E1F4DA9C775F964BB21FE3EB35BEC34@GRFMBX704BA020.griffon.local> Accept-Language: en-US, it-IT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'Dean cheng' , Ullio Mario Subject: [pcp] FW: New Version Notification for draft-maglione-pcp-radius-ext-01.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: Mon, 13 Jun 2011 08:32:49 -0000 Hello, We submitted a new version of draft-maglione-pcp-radius-ext The basic idea is to combine the use of RADIUS + DHCP in order to automatic= ally provision the PCP server name on the CPE. Comments and feedback are welcome. Thanks Best regards, Roberta and Dean -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: mercoled=EC 8 giugno 2011 9.47 To: Maglione Roberta Cc: chengd@huawei.com; Maglione Roberta Subject: New Version Notification for draft-maglione-pcp-radius-ext-01.txt A new version of I-D, draft-maglione-pcp-radius-ext-01.txt has been success= fully submitted by Roberta Maglione and posted to the IETF repository. Filename: draft-maglione-pcp-radius-ext Revision: 01 Title: RADIUS Extensions for Port Control Protocol Creation date: 2011-06-08 WG ID: Individual Submission Number of pages: 10 Abstract: Port Control Protocol (PCP) provides a mechanism to pre-configure a port on a NAT device, a firewall, etc., so that IP packets of applications initiated from network side can be "port forwarded&quo= t; to the correct user. PCP is a client-server protocol and the PCP client needs to be provisioned with the FQDN of the server. In a broadband network, customer information is usually stored on a RADIUS server and DHC protocol is used to populate user's configuration information. This memo proposes a new RADIUS attribute to carry the FQDN of a PCP server, such that while the PCP server information is configured on a RADIUS server, the information can be conveyed to NAS via RADIUS protocol, and the co-located DHCP/DHCPv6 server can then populate the information to PCP client. The IETF Secretariat Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From rpenno@juniper.net Tue Jun 21 12:59:16 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 71A4D1F0C65 for ; Tue, 21 Jun 2011 12:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 f4tDmUUqbEH7 for ; Tue, 21 Jun 2011 12:59:16 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id A147D1F0C4C for ; Tue, 21 Jun 2011 12:59:15 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTgD4Eo1rcDpgs6yT7MvuglOnO+jz+Q5E@postini.com; Tue, 21 Jun 2011 12:59:15 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 21 Jun 2011 12:56:03 -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; Tue, 21 Jun 2011 15:55:23 -0400 From: Reinaldo Penno To: "pcp@ietf.org" Date: Tue, 21 Jun 2011 15:54:12 -0400 Thread-Topic: New Version Notification for draft-penno-pcp-zones-00.txt Thread-Index: Acwv/e5XiezbCH4pQwKT1kQw62RtxwATw9uV Message-ID: In-Reply-To: <20110621102813.11439.97589.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [pcp] FW: New Version Notification for draft-penno-pcp-zones-00.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: Tue, 21 Jun 2011 19:59:16 -0000 ------ Forwarded Message From: "internet-drafts@ietf.org" Date: Tue, 21 Jun 2011 06:28:13 -0400 To: Reinaldo Penno Cc: Reinaldo Penno Subject: New Version Notification for draft-penno-pcp-zones-00.txt A new version of I-D, draft-penno-pcp-zones-00.txt has been successfully submitted by Reinaldo Penno and posted to the IETF repository. Filename: draft-penno-pcp-zones Revision: 00 Title: PCP Support for Multi-Zone Environments Creation date: 2011-06-20 WG ID: Individual Submission Number of pages: 8 Abstract: A zone is a notion which denotes a routing instance, a set interfaces or prefixes characterized by having a different address realm and/or security policy. A NAT device can route packets with the same source IP address to different zones depending on configuration policies such as destination IP address. This functionality has been present for many years in NAT devices from multiple vendors. PCP allows a host to interact with a PCP-controlled NAT device and request an external IP and port. Therefore a PCP Server that controls the NAT device and receives a PCP request from a host needs to know from which NAT pool to allocate an external IP address and port. This document specifies an extension to PCP to support the zone concept. =20 The IETF Secretariat ------ End of Forwarded Message From trac@tools.ietf.org Wed Jun 22 08:20:01 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 E33D811E80BA for ; Wed, 22 Jun 2011 08:20:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykSuHSTVhF4v for ; Wed, 22 Jun 2011 08:20:01 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 8793B11E80B8 for ; Wed, 22 Jun 2011 08:20:01 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZPDa-0007Eq-8d; Wed, 22 Jun 2011 08:19:50 -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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Wed, 22 Jun 2011 15:19:50 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/56#comment:2 Message-ID: <083.785f8ad1789da2fabb9f1992faf276bd@tools.ietf.org> References: <074.24b4344b3178570d3b5a899c34b6f21f@tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <074.24b4344b3178570d3b5a899c34b6f21f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110622152001.8793B11E80B8@ietfa.amsl.com> Resent-Date: Wed, 22 Jun 2011 08:20:01 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #56: Handling of the "O" bit is not fully specified for clients 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: Wed, 22 Jun 2011 15:20:02 -0000 #56: Handling of the "O" bit is not fully specified for clients Changes (by cheshire@…): * status: new => closed * resolution: => fixed Comment: Added comment that clients may ignore any and all options. -- --------------------------------------------------+------------------------- Reporter: Stuart Cheshire | Owner: draft-ietf-pcp-base@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------------------------+------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Jun 22 08:21:54 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 44ACE11E80D7 for ; Wed, 22 Jun 2011 08:21:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFmTzsrRb9V0 for ; Wed, 22 Jun 2011 08:21:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 440C511E80BA for ; Wed, 22 Jun 2011 08:21:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZPFY-0003ED-OY; Wed, 22 Jun 2011 08:21:52 -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: cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Wed, 22 Jun 2011 15:21:52 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/48#comment:2 Message-ID: <072.e98b0b8a15effa9113af74a15e75f558@tools.ietf.org> References: <063.f493f7da452a8af15a92348282ef53f8@tools.ietf.org> X-Trac-Ticket-ID: 48 In-Reply-To: <063.f493f7da452a8af15a92348282ef53f8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: cheshire@apple.com, dthaler@microsoft.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] #48: Is PEER opcode support mandatory? 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: Wed, 22 Jun 2011 15:21:54 -0000 #48: Is PEER opcode support mandatory? Changes (by cheshire@…): * status: new => closed * resolution: => fixed Comment: Added comment that all PCP servers must support at least one filter per MAP mapping. -- ---------------------------------------+------------------------------------ Reporter: Francis.Dupont@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: pcp From trac@tools.ietf.org Wed Jun 22 08:24:32 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 CE74711E8159 for ; Wed, 22 Jun 2011 08:24:31 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z15say4lsRT for ; Wed, 22 Jun 2011 08:24:31 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 177C211E8151 for ; Wed, 22 Jun 2011 08:24:31 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZPI1-0000Dv-5R; Wed, 22 Jun 2011 08:24:25 -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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Wed, 22 Jun 2011 15:24:25 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/50#comment:3 Message-ID: <068.092d1d4c099bde20746c6e257e1cce8d@tools.ietf.org> References: <059.3983d702876cabfa50cd4658b44167fa@tools.ietf.org> X-Trac-Ticket-ID: 50 In-Reply-To: <059.3983d702876cabfa50cd4658b44167fa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110622152431.177C211E8151@ietfa.amsl.com> Resent-Date: Wed, 22 Jun 2011 08:24:31 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #50: 128 bit PCP Client's IP Address and Suggested External IP Address fields 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: Wed, 22 Jun 2011 15:24:32 -0000 #50: 128 bit PCP Client's IP Address and Suggested External IP Address fields Changes (by cheshire@…): * status: new => closed * resolution: => fixed Comment: Made all address fields fixed-size 128-bit IP fields -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Jun 22 08:26:57 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 4830511E80B8 for ; Wed, 22 Jun 2011 08:26: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQk-rDHAZZVQ for ; Wed, 22 Jun 2011 08:26:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB1911E807A for ; Wed, 22 Jun 2011 08:26:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZPKG-0005gm-Tw; Wed, 22 Jun 2011 08:26:45 -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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Wed, 22 Jun 2011 15:26:44 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/57#comment:2 Message-ID: <083.8737fc8eeb3dca93bd21ef5033766df8@tools.ietf.org> References: <074.6c6928f61b449b95d6c1732721d226e6@tools.ietf.org> X-Trac-Ticket-ID: 57 In-Reply-To: <074.6c6928f61b449b95d6c1732721d226e6@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110622152656.1CB1911E807A@ietfa.amsl.com> Resent-Date: Wed, 22 Jun 2011 08:26:56 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #57: THIRD_PARTY scenarios are a bit confused and self-contradictory. 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: Wed, 22 Jun 2011 15:26:57 -0000 #57: THIRD_PARTY scenarios are a bit confused and self-contradictory. Changes (by cheshire@…): * status: new => closed * resolution: => fixed Comment: Text fixed (or at least improved) -- --------------------------------------------------+------------------------- Reporter: Stuart Cheshire | Owner: draft-ietf-pcp-base@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | --------------------------------------------------+------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Jun 22 08:34:05 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 6E86E21F8491 for ; Wed, 22 Jun 2011 08:34:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBckkDWmQa33 for ; Wed, 22 Jun 2011 08:34:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id B7ECD21F8499 for ; Wed, 22 Jun 2011 08:34:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZPRE-0003Pl-GL; Wed, 22 Jun 2011 08:33: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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Wed, 22 Jun 2011 15:33:56 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/55#comment:4 Message-ID: <079.40b7183048d203c055fd76a041a52f05@tools.ietf.org> References: <070.efc6af3832843e5c6a67fe18d2059ada@tools.ietf.org> X-Trac-Ticket-ID: 55 In-Reply-To: <070.efc6af3832843e5c6a67fe18d2059ada@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110622153404.B7ECD21F8499@ietfa.amsl.com> Resent-Date: Wed, 22 Jun 2011 08:34:04 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #55: MAP support mandatory or optional 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: Wed, 22 Jun 2011 15:34:05 -0000 #55: MAP support mandatory or optional Changes (by cheshire@…): * status: new => closed * resolution: => fixed Comment: Added text saying that support of both MAP and PEER is mandatory. -- ----------------------------------------------+----------------------------- Reporter: Paul Selkirk pcp From trac@tools.ietf.org Wed Jun 22 08:37:42 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 8DE3F11E80EC for ; Wed, 22 Jun 2011 08:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, 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 2Xchg2ZH92xJ for ; Wed, 22 Jun 2011 08:37:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 39F8E11E80D8 for ; Wed, 22 Jun 2011 08:37:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZPUm-0003Ys-Et; Wed, 22 Jun 2011 08:37:36 -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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Wed, 22 Jun 2011 15:37:36 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/49#comment:4 Message-ID: <068.e6c9e399adb7f7d761094d745fc7282a@tools.ietf.org> References: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110622153742.39F8E11E80D8@ietfa.amsl.com> Resent-Date: Wed, 22 Jun 2011 08:37:42 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #49: Multihoming confusion 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: Wed, 22 Jun 2011 15:37:42 -0000 #49: Multihoming confusion Changes (by cheshire@…): * status: new => closed * resolution: => fixed Comment: Added text stating that all MAP mappings are EIM+EIF -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Jun 22 08:41:17 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 46E1611E80B2 for ; Wed, 22 Jun 2011 08:41:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, NO_RELAYS=-0.001, 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 0Vc4IJGZBeZ2 for ; Wed, 22 Jun 2011 08:41:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id B347111E809F for ; Wed, 22 Jun 2011 08:41:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZPYC-0006Il-CQ; Wed, 22 Jun 2011 08:41:08 -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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Wed, 22 Jun 2011 15:41:08 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/51#comment:2 Message-ID: <068.4d9a3a753e30aecae147f9173722e953@tools.ietf.org> References: <059.63410ebe5d497d93b31b03826221e018@tools.ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <059.63410ebe5d497d93b31b03826221e018@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110622154116.B347111E809F@ietfa.amsl.com> Resent-Date: Wed, 22 Jun 2011 08:41:16 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #51: Mapping vs Filtering effect confusion 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: Wed, 22 Jun 2011 15:41:17 -0000 #51: Mapping vs Filtering effect confusion Comment(by cheshire@…): Added text stating that all MAP mappings are EIM+EIF -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Jun 22 08:49:16 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 3A07B11E807A for ; Wed, 22 Jun 2011 08:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 f5BCIEwCIBLF for ; Wed, 22 Jun 2011 08:49:15 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 82FDA11E813F for ; Wed, 22 Jun 2011 08:49:15 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZPfx-0003Od-Pq; Wed, 22 Jun 2011 08:49:09 -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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Wed, 22 Jun 2011 15:49:09 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/49#comment:5 Message-ID: <068.867f5fc5eedf6b63ddeed923db29c2d0@tools.ietf.org> References: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110622154915.82FDA11E813F@ietfa.amsl.com> Resent-Date: Wed, 22 Jun 2011 08:49:15 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #49: Multihoming confusion 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: Wed, 22 Jun 2011 15:49:16 -0000 #49: Multihoming confusion Comment(by cheshire@…): Oops. Pasted in wrong comment. Comment for this change is: Changed text to say that only one PCP server is currently supported -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Jun 22 08:49:56 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 C198311E8149 for ; Wed, 22 Jun 2011 08:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 pJ2Zp+dJkZ+1 for ; Wed, 22 Jun 2011 08:49:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 564DF11E8148 for ; Wed, 22 Jun 2011 08:49:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZPgc-0004et-K5; Wed, 22 Jun 2011 08:49:50 -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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Wed, 22 Jun 2011 15:49:50 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/49#comment:6 Message-ID: <068.6749655e830dfff7dd80aeca59871ff9@tools.ietf.org> References: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-Trac-Ticket-ID: 49 In-Reply-To: <059.1abaaf1dbe2b764801b50b06a104fce1@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110622154956.564DF11E8148@ietfa.amsl.com> Resent-Date: Wed, 22 Jun 2011 08:49:56 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #49: Multihoming confusion 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: Wed, 22 Jun 2011 15:49:56 -0000 #49: Multihoming confusion Changes (by cheshire@…): * status: closed => reopened * resolution: fixed => Comment: We may still need more discussion of multihoming in general to close this ticket. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: reopened Priority: major | Milestone: Component: base | Version: Severity: - | Resolution: Keywords: | -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Jun 22 08:57:43 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 257BC11E8125 for ; Wed, 22 Jun 2011 08:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 bL-UmgZHStDR for ; Wed, 22 Jun 2011 08:57:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8CF11E807A for ; Wed, 22 Jun 2011 08:57:42 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZPnt-0004mX-7z; Wed, 22 Jun 2011 08:57:21 -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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Wed, 22 Jun 2011 15:57:21 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/51#comment:3 Message-ID: <068.075c21c187afda54393876c11312e3b7@tools.ietf.org> References: <059.63410ebe5d497d93b31b03826221e018@tools.ietf.org> X-Trac-Ticket-ID: 51 In-Reply-To: <059.63410ebe5d497d93b31b03826221e018@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110622155742.7D8CF11E807A@ietfa.amsl.com> Resent-Date: Wed, 22 Jun 2011 08:57:42 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #51: Mapping vs Filtering effect confusion 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: Wed, 22 Jun 2011 15:57:43 -0000 #51: Mapping vs Filtering effect confusion Changes (by cheshire@…): * status: new => closed * resolution: => fixed Comment: Added text stating that PEER mappings may be EIM or EDM, and EIF or EDF. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: pcp From trac@tools.ietf.org Wed Jun 22 09:20:46 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 E485311E8179 for ; Wed, 22 Jun 2011 09:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 SccmdTTJ4jGQ for ; Wed, 22 Jun 2011 09:20:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id E73E411E816E for ; Wed, 22 Jun 2011 09:20:30 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZQA9-00077m-PJ; Wed, 22 Jun 2011 09:20:21 -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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Wed, 22 Jun 2011 16:20:21 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/53#comment:2 Message-ID: <078.3db703b93bc1375ce51592592cd60340@tools.ietf.org> References: <069.11450dd1df2bd3c998b52ffebbbbbce8@tools.ietf.org> X-Trac-Ticket-ID: 53 In-Reply-To: <069.11450dd1df2bd3c998b52ffebbbbbce8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110622162030.E73E411E816E@ietfa.amsl.com> Resent-Date: Wed, 22 Jun 2011 09:20:30 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #53: Make PCP Client's IP Address field optional 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: Wed, 22 Jun 2011 16:20:47 -0000 #53: Make PCP Client's IP Address field optional Changes (by cheshire@…): * status: new => closed * resolution: => fixed Comment: Added text explaining how to use the getsockname() function to retrieve a sockaddr containing the source address and port the kernel will use for PCP request packets. -- ---------------------------------------------+------------------------------ Reporter: Paul Selkirk | Owner: draft-ietf-pcp-base@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------------+------------------------------ Ticket URL: pcp From trac@tools.ietf.org Wed Jun 22 09:38:17 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 5162C11E80E6 for ; Wed, 22 Jun 2011 09:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 LVUGWzsQuKAg for ; Wed, 22 Jun 2011 09:38:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id D20AD11E80EC for ; Wed, 22 Jun 2011 09:38:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZQRN-0003eM-99; Wed, 22 Jun 2011 09:38:09 -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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Wed, 22 Jun 2011 16:38:09 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/54#comment:3 Message-ID: <078.2c4f5b7e662b5610714a54f3078a6927@tools.ietf.org> References: <069.21646df869fe401c02705a0d8d88d59d@tools.ietf.org> X-Trac-Ticket-ID: 54 In-Reply-To: <069.21646df869fe401c02705a0d8d88d59d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110622163816.D20AD11E80EC@ietfa.amsl.com> Resent-Date: Wed, 22 Jun 2011 09:38:16 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #54: PEER creating mappings 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: Wed, 22 Jun 2011 16:38:17 -0000 #54: PEER creating mappings Changes (by cheshire@…): * status: new => closed * resolution: => fixed Comment: Added text explaining how to set the External IP Address and Port fields in a PEER request -- ---------------------------------------------+------------------------------ Reporter: Paul Selkirk | Owner: draft-ietf-pcp-base@… Type: defect | Status: closed Priority: major | Milestone: Component: base | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------------+------------------------------ Ticket URL: pcp From rpenno@juniper.net Wed Jun 22 15:38:01 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 25F261F0C44 for ; Wed, 22 Jun 2011 15:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.923 X-Spam-Level: X-Spam-Status: No, score=-5.923 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] 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 Y1iivPfQdSV3 for ; Wed, 22 Jun 2011 15:38:00 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 06BB41F0C41 for ; Wed, 22 Jun 2011 15:37:56 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTgJuw8joITyKiTu+2//ZIjVwa1uuTSO1@postini.com; Wed, 22 Jun 2011 15:38:00 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 22 Jun 2011 15:37:44 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 22 Jun 2011 18:37:43 -0400 From: Reinaldo Penno To: pcp issue tracker , "draft-ietf-pcp-base@tools.ietf.org" , "cheshire@apple.com" , "dthaler@microsoft.com" Date: Wed, 22 Jun 2011 18:37:39 -0400 Thread-Topic: [pcp] #51: Mapping vs Filtering effect confusion Thread-Index: Acww8tIZucv7hTsxRD2TEluyUxUEVAAOiuC8 Message-ID: In-Reply-To: <068.4d9a3a753e30aecae147f9173722e953@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] #51: Mapping vs Filtering effect confusion 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, 22 Jun 2011 22:38:01 -0000 Meaning that all MAP requests install and delete both EIM+EIF? On 6/22/11 8:41 AM, "pcp issue tracker" wrote: > #51: Mapping vs Filtering effect confusion >=20 >=20 > Comment(by cheshire@=8A): >=20 > Added text stating that all MAP mappings are EIM+EIF From rpenno@juniper.net Wed Jun 22 16:00:00 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 0E3B19E803F for ; Wed, 22 Jun 2011 16:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LYgglPy-H19r for ; Wed, 22 Jun 2011 15:59:59 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 376469E8042 for ; Wed, 22 Jun 2011 15:59:56 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTgJz53vcHAK1z4IoL0+90QHgj74Zo69Z@postini.com; Wed, 22 Jun 2011 15:59:59 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 22 Jun 2011 15:55:12 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 22 Jun 2011 18:55:11 -0400 From: Reinaldo Penno To: pcp issue tracker , "dthaler@microsoft.com" Date: Wed, 22 Jun 2011 18:55:09 -0400 Thread-Topic: PCP Infinite Lifetime - RE: ( Re: [pcp] #38: state maintenance: create a general failure model, discussing how to recover from failures) Thread-Index: AcwkqxhKvDuh3Tt9QYysXB3Ad5UQ6AMhFcq+ Message-ID: In-Reply-To: <072.5744c16b350eaf99e887a0f8e253ba95@tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: [pcp] PCP Infinite Lifetime - RE: ( Re: #38: state maintenance: create a general failure model, discussing how to recover from failures) 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, 22 Jun 2011 23:00:00 -0000 Is there a way in PCP request or response to specify 'infinite' lifetime since 0 already means 'delete'? In the case of Port Forwarding, current workings is never having to redo mappings. In other words, if PCP Client sees a reduction in Epoch, it can refresh/retry mappings, otherwise, it could be silent. The case in hand is related to a PCP Relay/IWF or intermediate NAT that has a considerable number of Port Forwarding rules and has to interact with a PCP Server. Thanks, Reinaldo On 6/6/11 5:37 PM, "pcp issue tracker" wrote: > #38: state maintenance: create a general failure model, discussing how > to recover from failures Comment(by dthaler@=8A): From IETF: Server/proxy > reboot: * Client periodically refreshes some mapping at whatever the desired > detection frequency is * Client detects server/proxy reboot via Epoch > reduction * Client resends MAPs/PEERs for current listeners/connections > Client reboot: * Client detects running application listeners/connections * > Client tells server to delete all mappings * Client resends MAPs/PEERs for > current listeners/connections (Non-PCP client) listener loss: * PCP client > responsible for detecting and updating server Client address addition: * > Client sends MAPs for IN{6}ADDR_ANY listeners Client address loss but has > (or gets) another address on same network: * Client tells server to delete > all mappings for old (THIRD_PARTY) address Client address change or network > change * Both of above Most of the above is already in the doc, but not > all, e.g., the client address addition piece. -- >=20 ---------------------------------------+-----------------------------------= - > Reporter: Francis.Dupont@=8A | Owner: =20 Type: > enhancement | Status: new Priority: major > | Milestone: =20 Component: base | Version: >=20 Severity: - | Keywords: >=20 ---------------------------------------+-----------------------------------= - >=20 Ticket URL: pcp > _______________________________________________ > pcp mailing list pcp@ietf.org https://www.ietf.org/mailman/listinfo/pcp From dwing@cisco.com Wed Jun 22 17:51: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 DA5C011E8092 for ; Wed, 22 Jun 2011 17:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.155 X-Spam-Level: X-Spam-Status: No, score=-110.155 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 uLRtCevW-eAQ for ; Wed, 22 Jun 2011 17:51:25 -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 8A2E411E808F for ; Wed, 22 Jun 2011 17:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=4299; q=dns/txt; s=iport; t=1308790285; x=1309999885; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=4LWv534gvdXzBcxjRRnNhqCWspF3FJ5ZEzcHrzxFi4A=; b=JrgX4OpwF0tJwcUBfbz4SWrbO4Q6mtdiNENRccod9a7Gb6zCIyEgolhm t4b2qERJLNuQmZHWb7Mgcf7d7ftQbH5mqpUuknV73sFe0pEU3/U+bB8k8 wFBwFQcyjMj/5lwIH1CCcQ3wG1xPEJUIZgZW2oiJ2NHDfAN+JfamPea65 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgAAFONAk6rRDoJ/2dsb2JhbABTmASBZo0yd6tgnjqGLQSHJZpx X-IronPort-AV: E=Sophos;i="4.65,409,1304294400"; d="scan'208";a="344543774" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 23 Jun 2011 00:48:46 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p5N0mkL7003297; Thu, 23 Jun 2011 00:48:46 GMT From: "Dan Wing" To: "'Reinaldo Penno'" References: <072.5744c16b350eaf99e887a0f8e253ba95@tools.ietf.org> In-Reply-To: Date: Wed, 22 Jun 2011 17:48:46 -0700 Message-ID: <0a3801cc313f$4eeda6c0$ecc8f440$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcwkqxhKvDuh3Tt9QYysXB3Ad5UQ6AMhFcq+AAPJsHA= Content-Language: en-us Cc: pcp@ietf.org Subject: Re: [pcp] PCP Infinite Lifetime - RE: ( Re: #38: state maintenance: create a general failure model, discussing how to recover from failures) 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, 23 Jun 2011 00:51:30 -0000 > -----Original Message----- > From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On Behalf Of > Reinaldo Penno > Sent: Wednesday, June 22, 2011 3:55 PM > To: pcp issue tracker; dthaler@microsoft.com > Cc: pcp@ietf.org > Subject: [pcp] PCP Infinite Lifetime - RE: ( Re: #38: state > maintenance: create a general failure model, discussing how to recover > from failures) >=20 > Is there a way in PCP request or response to specify 'infinite' > lifetime since 0 already means 'delete'? No. Nothing lasts forever. > In the case of Port Forwarding, current workings is never having to > redo > mappings. In other words, if PCP Client sees a reduction in Epoch, it > can > refresh/retry mappings, otherwise, it could be silent. >=20 > The case in hand is related to a PCP Relay/IWF or intermediate NAT = that > has > a considerable number of Port Forwarding rules and has to interact = with > a PCP Server. It can request a lifetime of 0xFFFFFFFF, which is about 136 years. The=20 PCP server would reasonably put a higher limit on that request, and the specification currently recommends the PCP server enforce a maximum of 24 hours: 8.6. Mapping Lifetime and Deletion The PCP client requests a certain lifetime, and the PCP server responds with the assigned lifetime. The PCP server MAY grant a lifetime smaller or larger than the requested lifetime. The PCP server SHOULD be configurable for permitted minimum and maximum lifetime, and the RECOMMENDED values are 120 seconds for the minimum value and 24 hours for the maximum. It is RECOMMENDED that the server be configured to restrict lifetimes to less than 24 hours, because they will consume ports even if the internal host is no longer interested in receiving the traffic or no longer connected to the network. These recommendations are not strict, and deployments should evaluate the tradeoffs to determine their own minimum and maximum lifetime values. -d >=20 > Thanks, >=20 > Reinaldo >=20 >=20 >=20 >=20 > On 6/6/11 5:37 PM, "pcp issue tracker" wrote: >=20 > > #38: state maintenance: create a general failure model, discussing > how > > to > recover from failures >=20 >=20 > Comment(by dthaler@=A9): >=20 > From IETF: >=20 > Server/proxy > > reboot: > * Client periodically refreshes some mapping at whatever the desired >=20 > > detection frequency is > * Client detects server/proxy reboot via Epoch > > reduction > * Client resends MAPs/PEERs for current listeners/connections >=20 >=20 > > Client reboot: > * Client detects running application listeners/connections > * > > Client tells server to delete all mappings > * Client resends MAPs/PEERs for > > current listeners/connections >=20 > (Non-PCP client) listener loss: > * PCP client > > responsible for detecting and updating server >=20 > Client address addition: > * > > Client sends MAPs for IN{6}ADDR_ANY listeners >=20 > Client address loss but has > > (or gets) another address on same network: > * Client tells server to delete > > all mappings for old (THIRD_PARTY) address >=20 > Client address change or network > > change > * Both of above >=20 >=20 > Most of the above is already in the doc, but not > > all, e.g., the client > address addition piece. >=20 > -- > > > = ---------------------------------------+------------------------------- > ----- >=20 > > Reporter: Francis.Dupont@=A9 | Owner: > Type: > > enhancement | Status: new > Priority: major > > | Milestone: > Component: base | Version: > > > Severity: - | Keywords: > > > = ---------------------------------------+------------------------------- > ----- >=20 > > > Ticket URL: > > pcp > > >=20 > _______________________________________________ >=20 > > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 >=20 > _______________________________________________ > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp From trac@tools.ietf.org Wed Jun 22 22:06: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 D4C3D1F0C38 for ; Wed, 22 Jun 2011 22:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 hZIAkqJelL11 for ; Wed, 22 Jun 2011 22:06:45 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:1112:1::2a]) by ietfa.amsl.com (Postfix) with ESMTP id 44DF31F0C42 for ; Wed, 22 Jun 2011 22:06:44 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.76) (envelope-from ) id 1QZc7e-0003J2-GB; Wed, 22 Jun 2011 22:06:34 -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: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.com X-Trac-Project: pcp Date: Thu, 23 Jun 2011 05:06:34 -0000 X-URL: http://tools.ietf.org/pcp/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/pcp/trac/ticket/52#comment:4 Message-ID: <068.1a831ef5bcd48f92dadb709859876ee5@tools.ietf.org> References: <059.62dd03011306661e8e9adf9c3b25b18d@tools.ietf.org> X-Trac-Ticket-ID: 52 In-Reply-To: <059.62dd03011306661e8e9adf9c3b25b18d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-pcp-base@tools.ietf.org, cheshire@apple.com, dthaler@microsoft.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 Resent-To: Resent-Message-Id: <20110623050645.44DF31F0C42@ietfa.amsl.com> Resent-Date: Wed, 22 Jun 2011 22:06:44 -0700 (PDT) Resent-From: trac@tools.ietf.org Cc: pcp@ietf.org Subject: Re: [pcp] #52: More security considerations 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, 23 Jun 2011 05:06:45 -0000 #52: More security considerations Comment(by cheshire@…): I've added text about ingress filtering, security for the THIRD_PARTY option, configuration options to disable MAP and PEER support, and only accepting PCP request on the internal interface. -- -----------------------------------+---------------------------------------- Reporter: dthaler@… | Owner: draft-ietf-pcp-base@… Type: defect | Status: new Priority: major | Milestone: Component: base | Version: Severity: - | Keywords: -----------------------------------+---------------------------------------- Ticket URL: pcp From dthaler@microsoft.com Thu Jun 23 10:22:49 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 5666311E818A for ; Thu, 23 Jun 2011 10:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.212 X-Spam-Level: X-Spam-Status: No, score=-110.212 tagged_above=-999 required=5 tests=[AWL=-0.213, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, 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 T2MGU0d0AGGR for ; Thu, 23 Jun 2011 10:22:48 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id BA31D11E8184 for ; Thu, 23 Jun 2011 10:22:48 -0700 (PDT) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 23 Jun 2011 10:22:48 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 23 Jun 2011 10:22:47 -0700 Received: from TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.165]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Thu, 23 Jun 2011 10:22:47 -0700 From: Dave Thaler To: Reinaldo Penno , pcp issue tracker Thread-Topic: PCP Infinite Lifetime - RE: ( Re: [pcp] #38: state maintenance: create a general failure model, discussing how to recover from failures) Thread-Index: AQHMMTAelsGvob+iik6PIheiFx2vw5TLMYQA Date: Thu, 23 Jun 2011 17:22:46 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B11F366@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> References: <072.5744c16b350eaf99e887a0f8e253ba95@tools.ietf.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PCP Infinite Lifetime - RE: ( Re: #38: state maintenance: create a general failure model, discussing how to recover from failures) 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, 23 Jun 2011 17:22:49 -0000 Reinaldo Penno writes: > Is there a way in PCP request or response to specify 'infinite' lifetime = since 0 > already means 'delete'? No. The IWF can pick a high number to request, and then must refresh at the interval returned by the server. That's because the server doesn't know when the client is no longer there, so in that sense "infinite" is not a good idea. We want the state to time out. -Dave >=20 > In the case of Port Forwarding, current workings is never having to redo > mappings. In other words, if PCP Client sees a reduction in Epoch, it can > refresh/retry mappings, otherwise, it could be silent. >=20 > The case in hand is related to a PCP Relay/IWF or intermediate NAT that h= as > a considerable number of Port Forwarding rules and has to interact with a > PCP Server. >=20 > Thanks, >=20 > Reinaldo >=20 >=20 >=20 >=20 > On 6/6/11 5:37 PM, "pcp issue tracker" wrote: >=20 > > #38: state maintenance: create a general failure model, discussing how > > to > recover from failures >=20 >=20 > Comment(by dthaler@=A9): >=20 > From IETF: >=20 > Server/proxy > > reboot: > * Client periodically refreshes some mapping at whatever the desired >=20 > > detection frequency is > * Client detects server/proxy reboot via Epoch > > reduction > * Client resends MAPs/PEERs for current listeners/connections >=20 >=20 > > Client reboot: > * Client detects running application listeners/connections > * > > Client tells server to delete all mappings > * Client resends MAPs/PEERs for > > current listeners/connections >=20 > (Non-PCP client) listener loss: > * PCP client > > responsible for detecting and updating server >=20 > Client address addition: > * > > Client sends MAPs for IN{6}ADDR_ANY listeners >=20 > Client address loss but has > > (or gets) another address on same network: > * Client tells server to delete > > all mappings for old (THIRD_PARTY) address >=20 > Client address change or network > > change > * Both of above >=20 >=20 > Most of the above is already in the doc, but not > > all, e.g., the client > address addition piece. >=20 > -- > > > ---------------------------------------+-------------------------------- > ---------------------------------------+---- >=20 > > Reporter: Francis.Dupont@=A9 | Owner: > Type: > > enhancement | Status: new > Priority: major > > | Milestone: > Component: base | Version: > > > Severity: - | Keywords: > > > ---------------------------------------+-------------------------------- > ---------------------------------------+---- >=20 > > > Ticket URL: > pcp > > >=20 > _______________________________________________ >=20 > > pcp mailing list > pcp@ietf.org > https://www.ietf.org/mailman/listinfo/pcp >=20 >=20 From rpenno@juniper.net Thu Jun 23 11:06:22 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 E879F11E819C for ; Thu, 23 Jun 2011 11:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.134 X-Spam-Level: X-Spam-Status: No, score=-6.134 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] 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 IMt2NjLCw3dN for ; Thu, 23 Jun 2011 11:06:22 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 004D511E817E for ; Thu, 23 Jun 2011 11:06:17 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTgOAlpGxjAhb3J9yTFXAuntTsqmuM8Rt@postini.com; Thu, 23 Jun 2011 11:06:22 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 23 Jun 2011 11:04:11 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 23 Jun 2011 14:04:10 -0400 From: Reinaldo Penno To: Dave Thaler , pcp issue tracker Date: Thu, 23 Jun 2011 14:04:07 -0400 Thread-Topic: PCP Infinite Lifetime - RE: ( Re: [pcp] #38: state maintenance: create a general failure model, discussing how to recover from failures) Thread-Index: AQHMMTAelsGvob+iik6PIheiFx2vw5TLMYQAgAAL/wc= Message-ID: In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B11F366@TK5EX14MBXW601.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.9.0.110114 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pcp@ietf.org" Subject: Re: [pcp] PCP Infinite Lifetime - RE: ( Re: #38: state maintenance: create a general failure model, discussing how to recover from failures) 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, 23 Jun 2011 18:06:23 -0000 Thanks for the answer Dave. I was trying to maintain the same 'static port forwarding' look and feel in a network where PCP Server is integrated with subscriber management. The PCP Client would be a PCP Relay and not really the CPEs. On 6/23/11 10:22 AM, "Dave Thaler" wrote: > Reinaldo Penno writes: >> Is there a way in PCP request or response to specify 'infinite' lifetime >> since 0 >> already means 'delete'? >=20 > No. The IWF can pick a high number to request, and then must refresh at > the interval returned by the server. That's because the server doesn't > know when the client is no longer there, so in that sense "infinite" is n= ot > a good idea. We want the state to time out. >=20 > -Dave >=20 >>=20 >> In the case of Port Forwarding, current workings is never having to redo >> mappings. In other words, if PCP Client sees a reduction in Epoch, it ca= n >> refresh/retry mappings, otherwise, it could be silent. >>=20 >> The case in hand is related to a PCP Relay/IWF or intermediate NAT that = has >> a considerable number of Port Forwarding rules and has to interact with = a >> PCP Server. >>=20 >> Thanks, >>=20 >> Reinaldo >>=20 >>=20 >>=20 >>=20 >> On 6/6/11 5:37 PM, "pcp issue tracker" wrote: >>=20 >>> #38: state maintenance: create a general failure model, discussing how >>> to >> recover from failures >>=20 >>=20 >> Comment(by dthaler@=A9): >>=20 >> From IETF: >>=20 >> Server/proxy >>> reboot: >> * Client periodically refreshes some mapping at whatever the desired >>=20 >>> detection frequency is >> * Client detects server/proxy reboot via Epoch >>> reduction >> * Client resends MAPs/PEERs for current listeners/connections >>=20 >>=20 >>> Client reboot: >> * Client detects running application listeners/connections >> * >>> Client tells server to delete all mappings >> * Client resends MAPs/PEERs for >>> current listeners/connections >>=20 >> (Non-PCP client) listener loss: >> * PCP client >>> responsible for detecting and updating server >>=20 >> Client address addition: >> * >>> Client sends MAPs for IN{6}ADDR_ANY listeners >>=20 >> Client address loss but has >>> (or gets) another address on same network: >> * Client tells server to delete >>> all mappings for old (THIRD_PARTY) address >>=20 >> Client address change or network >>> change >> * Both of above >>=20 >>=20 >> Most of the above is already in the doc, but not >>> all, e.g., the client >> address addition piece. >>=20 >> -- >>>=20 >> ---------------------------------------+-------------------------------- >> ---------------------------------------+---- >>=20 >>> Reporter: Francis.Dupont@=A9 | Owner: >> Type: >>> enhancement | Status: new >> Priority: major >>> | Milestone: >> Component: base | Version: >>>=20 >> Severity: - | Keywords: >>>=20 >> ---------------------------------------+-------------------------------- >> ---------------------------------------+---- >>=20 >>>=20 >> Ticket URL: >> pcp >>> >>=20 >> _______________________________________________ >>=20 >>> pcp mailing list >> pcp@ietf.org >> https://www.ietf.org/mailman/listinfo/pcp >>=20 >>=20 >=20 From cheshire@apple.com Thu Jun 23 22:05:07 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 EE38B11E81A5 for ; Thu, 23 Jun 2011 22:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, 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 7JcddwXU87Lp for ; Thu, 23 Jun 2011 22:05:04 -0700 (PDT) Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4149811E8105 for ; Thu, 23 Jun 2011 22:05:04 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay12.apple.com ([17.128.113.53]) by mail-out.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPS id <0LNA00KEJ3GATP90@mail-out.apple.com> for pcp@ietf.org; Thu, 23 Jun 2011 22:05:03 -0700 (PDT) X-AuditID: 11807135-b7b76ae000001169-4d-4e041b63c4e9 Received: from koseret (koseret.apple.com [17.151.62.39]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by relay12.apple.com (Apple SCV relay) with SMTP id C0.7C.04457.36B140E4; Thu, 23 Jun 2011 22:06:43 -0700 (PDT) Received: from [10.0.1.2] (173-164-252-149-SFBA.hfc.comcastbusiness.net [173.164.252.149]) by koseret.apple.com (Oracle Communications Messaging Exchange Server 7u4-20.01 64bit (built Nov 21 2010)) with ESMTPSA id <0LNA00ITR3GER270@koseret.apple.com> for pcp@ietf.org; Thu, 23 Jun 2011 22:05:03 -0700 (PDT) From: Stuart Cheshire In-reply-to: Date: Thu, 23 Jun 2011 22:05:01 -0700 Message-id: References: To: Reinaldo Penno X-Mailer: Apple Mail (2.1084) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUiON1OXTdZmsXPoHmHhMXkY79ZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8fi+V8Eh1oq3y/0aGLewdDFyckgImEj0vzvJCGGLSVy4t56t i5GLQ0igk0mi4/46NpAEr4CgxI/J94AaODiYBeQlDp6XBQkzC2hJfH/UygJRv4dJ4uHbaWCD hAVsJW5tWcMEYrMBFb34fAVsDqeAgcTBf7PAFrMIqErsOfuZEaSZWeAUo8SpJ9egltlINP9p BbOFBPQlGjvvgg0SEVCX+NH7iBnkCAkBWYmmZRkTGAVmITlvFsJ5s5Cct4CReRWjYFFqTmKl oZFeYkFBTqpecn7uJkZQ0DUUmu5gfLRQ/RCjAAejEg/vygRmPyHWxLLiytxDjBIczEoivCqr gEK8KYmVValF+fFFpTmpxYcYpTlYlMR539739BUSSE8sSc1OTS1ILYLJMnFwSjUw7j/qLCr7 Uz9F8EvtXFv2ipQ5BcKaH08dckg95PGff5Nfo6dQjp7RmzJFF+XK8DPsPbNulbaEvO/VPjlv 0gp3/jNCuq5xx8wPb/6w9/As5VvuhxeFJSeWL6+bGzpXMMDr9LaE8pnSDS8P1P3y26VcuPLD zk9h9idzrl7zeeh6d5LA68Ppxw6oKbEUZyQaajEXFScCAJ8jfvI2AgAA Cc: "pcp@ietf.org" , pcp issue tracker , "draft-ietf-pcp-base@tools.ietf.org" Subject: Re: [pcp] #51: Mapping vs Filtering effect confusion 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, 24 Jun 2011 05:05:08 -0000 On 22 Jun 2011, at 15:37, Reinaldo Penno wrote: > Meaning that all MAP requests install and delete both EIM+EIF? Yes: Note that all mappings created by PCP MAP requests are, by definition, Endpoint Independent Mappings with Endpoint Independent Filtering (unless the FILTER Option is used), even on a NAT that usually creates Endpoint Dependent Mappings or Endpoint Dependent Filtering for outgoing connections, since the purpose of an (unfiltered) MAP mapping is to receive inbound traffic from any remote endpoint, not from only one specific remote endpoint. Stuart Cheshire * Wizard Without Portfolio, Apple Inc. * www.stuartcheshire.org