Subject: [pcp] WG last call on draft-ietf-pcp-upnp-igd-interworking-01

From: Dave Thaler <[email-masked]>
Date: Fri, 13 Jul 2012 20:07:37 +0000

>From the IETF 83 minutes:
> 1330-1340 UPnP-IGD Interworking Function             (Mohamed Boucadair, 10)
>           Document: draft-ietf-pcp-upnp-igd-interworking-01
>           Slides: http://www.ietf.org/proceedings/83/slides/slides-83-pcp-1.pdf
> 
> Any objections to starting a WG Last Call on this?
> Francis objected that the issue of an IGD client that asks for a lifetime 
>     longer than the PCP server is willing to grant can never be solved, 
>     and therefore the entire work item is futile.
> Dave: This is an issue, but not an open issue.
> Dave: will confer with Alain about whether to start WG Last Call.

The chairs have agreed to start a WG last call.   We've seen no additional
discussion on this draft since last IETF, so this email initiates a last call on
draft-ietf-pcp-upnp-igd-interworking-01.   This call will conclude in two
weeks (Friday July 27th), just prior to IETF.   Hopefully that will allow
for discussion of WGLC comments in Vancouver.

We need at least 5 reviewers.  Please send comments to the list.

Thanks,
-Dave

---

From: Dave Thaler <[email-masked]>
Date: Sat, 28 Jul 2012 00:31:36 +0000

A marked up version with my full comments is available at:
http://research.microsoft.com/~dthaler/draft-ietf-pcp-upnp-igd-interworking-01.pdf

A summary of the main non-editorial issues follows:

1) The UPnP IGD state variables and methods fall into two categories: those
relevant to port mapping, and those not relevant to port mapping.   Currently
some the latter are listed as "not applicable", some are omitted from the document,
and of those not omitted, I think some of the statements aren't correct.   Instead,
I think this doc should be scoped to only discussion of the first category and say
the rest are covered in [IGD2], without enumerating them.   And I think we should
also say that an IGD with the IWF MUST be compliant to [IGD2].   I believe that
will maximize the chance of interoperability with UPnP-IGD clients.

2) The doc currently assumes that there's only one ExternalIPAddress.   I don't
think that's as scalable, and it's certainly not required by the PCP protocol.
Instead, I think we should explicitly state that the ExternalIPAddress should be stored
on a per control-point basis, so that different control points could see different 
values.   Each value comes from the PCP responses for mappings for that control point.
This means that just because there's a collision in external port for some other
control point doesn't mean that adding a mapping will fail.   It would only fail
if that other control point used the same ExternalIPAddress as the requesting one.
If the requesting control point hadn't yet been assigned an ExternalIPAddress, then
the request should be relayed to the PCP server(s).    [See also my comment #10
on the pcp-dhcp draft.]    Section 11.3 of the pcp-base spec already has logic where
the server will accept a port MAP request even when one IP already has a mapping,
as long as it has another available external IP that can service the request.

3) It would be good to add a paragraph, say in the discussion of Figure 4 
(Cascaded NAT scenario), explaining that without the PCP IWF, the control point
would see an "ExternalIPAddress" and port of the WAN link between the IGD
and NAT2, not the public address/port on the Internet.   With the PCP IWF,
the control point will instead see the public address/port on the Internet.
It will no longer see the intermediate address/port between the IGD and
NAT2, even though it would be useful for communication with another
host  behind the same NAT2 but not behind the IGD.   Such learning is not
supported, and so it would be good to point that out.   This helps the reader
understand the point of the rest of the logic.

4) Renewals are mentioned in passing under the "PortMappingLeaseDuration"
state variable.   However the behavior is never specified.   This should be added
as a new section 5.10.

5) The assumption in UPnP-IGD is that GetSpecificPortMappingEntry() can not
return something that wouldn't be returned by GetGenericPortMappingEntry()
and GetListOfPortMappings().   Section 5.8 breaks that, without giving any justification.
That is, it says GetListOfPortMappings and GetGenericPortMappingEntry are
served locally, never relayed, but that GetSpecificPortMappingEntry can be
relayed when no mapping is found.   This is inconsistent.  I think it should be
handled locally as well, to retain consistency.   Yes that means you can't use
it to look up third party information about other IGDs.   And that's a good thing.

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave
> Thaler
> Sent: Friday, July 13, 2012 1:08 PM
> To: [email-masked]
> Subject: [pcp] WG last call on draft-ietf-pcp-upnp-igd-interworking-01
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: <[email-masked]>
Date: Mon, 30 Jul 2012 16:36:02 +0200

Dear Dave,

Thank you for the detailed review. 

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Dave Thaler
>Envoyé : samedi 28 juillet 2012 02:32
>À : [email-masked]
>Objet : Re: [pcp] WG last call on 
>draft-ietf-pcp-upnp-igd-interworking-01
>
>the rest are covered in [IGD2], without enumerating them.   

Med: I removed non-applicable variables from the document.

>And I think we should

Med: Added to Section 4.1 this sentence: 
"The UPnP IGD-PCP Interworking Function MUST support IGD:2 behavior."

>2) The doc currently assumes that there's only one 
>ExternalIPAddress.

Med: Yes, it assumes one external IP address is assigned per CPE not per UPnP CP. This is aligned with REQ#2 of http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-08.

   I don't
>as long as it has another available external IP that can 

Med: I don't have a problem to relax this constraint to be on a per CP basis rather than per CPE. If there is no objection from the WG, I will implement the change you are requesting for.  

>understand the point of the rest of the logic.

Med: I added this new text:

   Without the involvement of the IGD-PCP Interworking Function, the UPnP
   CP would retrieve an external IP address and port number having a
   limited scope and which can not be used to communicate with hosts
   located beyond NAT2 (i.e., assigned by the IGD and not the ones
   assigned by NAT2 in Figure 4).

>state variable.   However the behavior is never specified.   

Med: I added this new section:

5.10.  Renewal

   Because of the incompatibility of mapping lifetimes between UPnP IGD
   and PCP, the IGD-PCP Interworking Function MUST simulate long and
   even infinite lifetimes.  Indeed, for requests having a requested
   PortMappingLeaseDuration longer than 65535 or infinite, the IGD-PCP
   Interworking Function MUST set the requested PCP Lifetime of the
   corresponding PCP request to 65535.  Furthermore, the IGD-PCP
   Interworking Function MUST maintain an additional timer set to the
   initial requested PortMappingLeaseDuration.  Upon receipt of a
   positive answer from the PCP server, the IGD-PCP Interworking
   Function relays the corresponding UPnP IGD response to the requesting
   UPnP CP with PortMappingLeaseDuration set to the same value as the
   one of the initial request.  Then, the IGD-PCP Interworking Function
   MUST renew the instructed PCP mapping until the expiry of
   PortMappingLeaseDuration.  Responses received when renewing the
   mapping MUST NOT be relayed to the UPnP CP.

   In case an error is encountered during mapping renewal, the IGD-PCP
   Interworking Function has no means to inform the UPnP CP.

>it to look up third party information about other IGDs.   And 

Med: The motivation for this is as mentioned in the draft: 

"some
      applications uses GetSpecificPortMapping() to check whether a
      mapping exists."

These applications check whether a specific mapping is instantiated, if not these applications sent a request to install that mapping. 
If GetSpecificPortMappingEntry() is served locally, this will lead to application error. It is efficient to relay GetSpecificPortMappingEntry() rather than serving it locally.

>> >           Slides: 
>http://www.ietf.org/proceedings/83/slides/slides-83-pcp-1.pdf
>> >