[pcp] Review of draft-ietf-pcp-upnp-igd-interworking

Xiaohong Deng <dxhbupt@gmail.com> Tue, 14 August 2012 19:48 UTC

Return-Path: <dxhbupt@gmail.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9F49221E8086 for <pcp@ietfa.amsl.com>; Tue, 14 Aug 2012 12:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.199
X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3rkNIWJN7ppe for <pcp@ietfa.amsl.com>; Tue, 14 Aug 2012 12:48:23 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0E52221E8063 for <pcp@ietf.org>; Tue, 14 Aug 2012 12:48:22 -0700 (PDT)
Received: by lbbgg6 with SMTP id gg6so489644lbb.31 for <pcp@ietf.org>; Tue, 14 Aug 2012 12:48:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=WG77c8AFJllc7vk+jxLyLXLSqV5wbE6K2t5qZew+qAY=; b=xaR6KhuHHr7wpTTIyk0LgLXkyxDKDeOMVSz0xFzBtMmD67M6riAMk2eTZnEpgsBMna rGxeddmKc8sbIPbCx3/x/kHjmpf0FKI0nO1Wk3hSUQFiRaYdTr05pJSc82rAjQB0vv7j gOncIdHMOe6CtA0VO4qdr5GiZI9sAB5nWIv57ZnH2VgYoxHn2V84mG2p+YtpJsDvsm4/ /91GyNMIpXZXRVMpLqX91PNP3P6NERNmS5WrrF9J1KcYABmwcGU5UZJpsKQD+S9cdA87 niXKMA59dgGRNh7Mad2hLBiGrq7cIIBQhDbe/4bNZlIgTCTii9cNPIl4u5ADM9fQZvmc KBmg==
MIME-Version: 1.0
Received: by with SMTP id r9mr8469151lbm.81.1344973701999; Tue, 14 Aug 2012 12:48:21 -0700 (PDT)
Received: by with HTTP; Tue, 14 Aug 2012 12:48:21 -0700 (PDT)
Date: Tue, 14 Aug 2012 21:48:21 +0200
Message-ID: <CANb4OckhpkQH_Wkqyb1T6uuAO8ugLWZHHb_8L69DVe3bP8kUmQ@mail.gmail.com>
From: Xiaohong Deng <dxhbupt@gmail.com>
To: draft-ietf-pcp-upnp-igd-interworking@tools.ietf.org, pcp@ietf.org
Content-Type: multipart/alternative; boundary=f46d0401236fbd6c7b04c73f17f5
Subject: [pcp] Review of draft-ietf-pcp-upnp-igd-interworking
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: Tue, 14 Aug 2012 19:48:24 -0000

Hello authors and WG,

Here is my review of draft-ietf-pcp-upnp-igd-interworking-02.

Overall I think the draft is in a good shape, neat, easy to follow, and has
a good architecture for WGLC. Below are a couple of questions and thoughts
on text. Two types of them: the ones begin with +, are ones that, in my
point of view, are worth to be addressed, and the ones begin with *, are
minor ones that may make no significant difference. In both cases if I miss
something, please elaborate and clarify. Thanks.

  Interworking Function (IGD-PCP IWF) is required to be embedded in CP
+ CP -> Customer Premises (CP)

   Triggers for deactivating the UPnP IGD-PCP Interworking Function from
   the IGD and relying on a PCP-only mode are out of scope of this
+ I’m not sure I understand exactly "Triggers for deactivating the UPnP
IGD-PCP Interworking Function". what does that exactly mean? Deactivating
the whole IWF or IGD?

   (1)  Section 4.1 provides the mapping between WANIPConnection State
        Variables and PCP parameters;
+ would suggest using‘correspondence’ than ‘mapping’, as no mappings
required to store in IGD for that, and also for lowering confusion with NAT

      on a per UPnP CP basis.
+ UPnP CP -> UPnP Control Point? There are two 'CP' exit in the document,
which I suppose stand for different things respectively.

      PCP does not support deactivating the dynamic NAT mapping since
      the initial goal of PCP is to ease the traversal of Carrier Grade
      NAT.  Supporting such per-subscriber function may overload the
      Carrier Grade NAT.
+ What if the customer wants to deactivate a static NAT mappings on CGN? it
is not stated clearly that IWF should support it or not. My reading here is
that for the same reason: not to overload the carrier Grade NAT, it should
not support deactivate static mappings either. IMO,it’s worth to state
clearer that it applys to both static and dynamic mappings, if that is what
text here means.

      On reading the value is 1, writing a value different from 1 is not
+ what if on reading the value is 0, which means deactivating the mapping?

      Point, it must be resolved to an IP address by the Interworking
      Function when relying the message to the PCP Server.
+ Must? Does this mean IWF must have a DNS resolving function also?

   6 MALFORMED_OPTION:  501 "ActionFailed"
      Should not happen.
*It may happen when IWF is not correctly implemented, mistached version of
implementation with PCP server, and extra.

   7 NETWORK_FAILURE:  Not applicable
      Should not happen after communication was successfully established
     with a PCP Server.
*What if IWF/PCP Client fails to establish communication with a PCP server?
In that case, I see that "ActionFailed" looks like the semantical

      Note: According to some experiments, some UPnP 1.0
      implementations, e.g., uTorrent, simply try the same external port
      X times (usually 4 times) and then fail.  Also note that some
      applications uses GetSpecificPortMapping() to check whether a
      mapping exists.
*Behavior of uTorrent is more like following: it tries
GetSpecificPortMapping X times (usually 4 times),if it finds an external
port not being used before X times, it will call AddPortMapping

   Upon receipt of GetSpecificPortMappingEntry() from a UPnP Control
   Point, the IGD-PCP IWF MUST check first if the external port number
   is used by the requesting UPnP Control Point.  If the external port
   is already in use by the requesting UPnP Control Point, the IGD-PCP
   IWF MUST send back a positive answer.  If not, the IGD-PCP IWF MUST

*or more precisely: IWF MUST send back mapping entires specified by the
unique tuple of ExternalPort and PortMappingProtocol.

   relay to the PCP Server a MAP request, with short lifetime (e.g.,
   60s), including a PREFER_FAILURE Option.  If the requested external
   port is in use, a PCP error message will be sent by the PCP Server to
   the IGD-PCP IWF indicating CANNOT_PROVIDE_EXTERNAL as the error
   cause.  Then, the IGD-PCP IWF relays a negative message to the UPnP
   Control Point.  If the port is not in use, the mapping will be

+ if CANNOT-PROVIDE_EXTERNAL is returned from PCP server, it means the
enquired external port is being used: for example, enquired external port
is being used by another customer sharing the same external IP. Since one
of major usage of GetSpecificPortMappingEntry() is for UPnP control point
to find out if an external port is  available, how about using 718
"ConflictInMappingEntry"? which, to my eyes, provides a better semantic in
this context.

   created by the PCP Server and a positive response will be sent back
   to the IGD-PCP IWF.  Once received by the IGD-PCP IWF, it MUST relay
   a negative message to the UPnP Control Point indicating
   NoSuchEntryInArray as error code.

*Since this is a somehow complicated to be understood case, add something
like below may make it slightly clearer:

it MUST relay a negative message to the UPnP Control Point indicating
NoSuchEntryInArray as error code so that the UPnP control point knows the
enquired mapping doesn't exist.