[pcp] Comments on draft-ietf-pcp-upnp-igd-interworking-04
"Reinaldo Penno (repenno)" <repenno@cisco.com> Wed, 07 November 2012 05:26 UTC
Return-Path: <repenno@cisco.com>
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 6D38311E809A for <pcp@ietfa.amsl.com>; Tue, 6 Nov 2012 21:26:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.199
X-Spam-Level:
X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_SUB_RAND_LETTRS4=0.799]
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 RBxKB9YG-YuY for <pcp@ietfa.amsl.com>; Tue, 6 Nov 2012 21:26:03 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id BE29B11E8099 for <pcp@ietf.org>; Tue, 6 Nov 2012 21:26:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2700; q=dns/txt; s=iport; t=1352265964; x=1353475564; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=o6rWUtLVR5zedNCV+tejdP1SV/mA4kTe5Do6YRas5CY=; b=bSCWiRBWHjJYnKKv+/idAWnrO3ASQ4RYvt0l4jsx7JX5qprrY9kP/FVl vBDm5iwlzWq6wOEwQFDmtptx/DlTrlUGBp9YxtuoP7wzQUSfJQK4+a1A+ 3wayo13cUIR0ZQe1/JAmJxd1XunYaPWRVTEY3iWCngdWiwEEaZxtJk8Oe 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqoIAKPvmVCtJXG//2dsb2JhbABEgknBHIEBB4IgAQQSAXgBDAEdC0slAQEEGxqHaJoAgSugHo8ZglBhA6RUgWuCb4IZ
X-IronPort-AV: E=Sophos; i="4.80,726,1344211200"; d="scan'208,217"; a="139600591"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 07 Nov 2012 05:26:03 +0000
Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA75Q3oT030006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <pcp@ietf.org>; Wed, 7 Nov 2012 05:26:03 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 23:26:02 -0600
From: "Reinaldo Penno (repenno)" <repenno@cisco.com>
To: "pcp@ietf.org" <pcp@ietf.org>
Thread-Topic: Comments on draft-ietf-pcp-upnp-igd-interworking-04
Thread-Index: Ac28o14Epyd9sM+yRaS2NP4CqQyCpQACg8eAAADVFoA=
Date: Wed, 07 Nov 2012 05:26:01 +0000
Message-ID: <45A697A8FFD7CF48BCF2BE7E106F0604139AF6@xmb-rcd-x04.cisco.com>
In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F0604139ACC@xmb-rcd-x04.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.13.0.110805
x-originating-ip: [10.21.72.24]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19344.002
x-tm-as-result: No--31.629600-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_45A697A8FFD7CF48BCF2BE7E106F0604139AF6xmbrcdx04ciscocom_"
MIME-Version: 1.0
Subject: [pcp] Comments on draft-ietf-pcp-upnp-igd-interworking-04
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2012 05:26:04 -0000
One important comment as I review the draft: Section 5.9 needs to be rewritten taking into account that PCP can not delete a mapping on the far NAT if it is considered a LSN (LSN Req-9), but UPnP Control Points expect to be able to delete mappings. Same for NAT-PMP? It is not clear to me at this point how to reconcile this behavior because UPnP Control Points will not change their behavior. Therefore if UPnP tries to delete a mapping (as it is expected it can) PCP will not be able to…This is true if IWF also implements a NAT (NAT444 scenario) or not (DS-Lite, etc). It seems to me this applies to chained Firewalls as well. Thanks, Reinaldo
- [pcp] Comments on draft-ietf-pcp-upnp-igd-interwo… Reinaldo Penno (repenno)