Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS

From: <[email-masked]>
Date: Sat, 2 Apr 2011 14:17:29 +0800

|> My argument is that I don't think PCP client has the right to remove 
|> NAT filter on behalf of another app.
|
|My argument is that it does not matter.  The first application 
|(which is a pure UDP or TCP client) sent a packet to the 
|Internet, and has _no reasonable expectation_ that the network 
|does any filtering.  
|You're saying that, on your network, it gets some filtering.  
|That's great.  That's fine.  
|
|The next application, listening on the same port, wants to 
|receive incoming packets.
|
|So, the filtering gets removed from that first application.
|
|I don't see a problem, because that first application had (and 
|has) no reasonable expectation of the network doing filtering 
|on its behalf.

A nice point. I agree with you on this point.

However, when it comes to PCP UPnP IWF, there is another
issue according to our PCP UPnP IWF tests.

It is likely that after an UPnP 1.0 client has established a
dynamic session on an internal port, it will then requests the same
internal port/external port to be forwarded, which will fail even if
"promote" the conflict implicit mapping to the explicit mapping, 
because the external port ( a random port ) is unlikely to be the 
same as the internal port for implicit mappings but UPnP 1.0 asks for
a specific port (internal port) as the external port. 

Yet, it should not fail if you assume explicit mappings should prior 
to implicit mappings.

BR,
Xiaohong
opensource A+P: http://opensourceaplusp.weebly.com/

|
|-d
|

|

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 02 Apr 2011 02:16:20 -0700

> a specific port (internal port) as the external port. 

As you point out, UPnP IGD 1.0 is fundamentally flawed. The semantics it demands are fundamentally impossible to achieve in any shared NAT. If it weren't fundamentally flawed we wouldn't have needed NAT-PMP, or PCP (or UPnP IGD v2). Constraining PCP to achieve IGD's unachievable semantics ("give me the external port I demand") results in a protocol that doesn't work. There's no way for a shared NAT to provide the semantics demanded by UPnP IGD 1.0, regardless of whether it uses PCP or any other protocol.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: <[email-masked]>
Date: Sat, 2 Apr 2011 19:39:21 +0800

|As you point out, UPnP IGD 1.0 is fundamentally flawed. The 
|semantics it demands are fundamentally impossible to achieve 
|in any shared NAT. If it weren't fundamentally flawed we 
|wouldn't have needed NAT-PMP, or PCP (or UPnP IGD v2). 
|Constraining PCP to achieve IGD's unachievable semantics 
|("give me the external port I demand") results in a protocol 
|that doesn't work. There's no way for a shared NAT to provide 
|the semantics demanded by UPnP IGD 1.0, regardless of whether 
|it uses PCP or any other protocol.
 
Yes, UPnP IGD 1.0 is flawed, but we still want to make 
as many UPnP 1.0 (AddPortMapping) requests work as possible, 
because most of exist applications are using UPnP 1.0, right?

Note that the case we've talked here is internal port conflict, so
UPnP 1.0 is still likely to obtain demanded external port. If we assume
 explicit mappings are more important than implicit mappings, there is
still a way to make UPnP 1.0 work; such as delete the (internal port ) 
conflict implicit mapping when the demanded external port is available.

Besides, If we don't try to make it work and eliminate 
IMPLICIT_MAPPING_EXISTS,  in this case which error code
 should be returned to IWF? 

BR,
Xiaohong

|
|Stuart Cheshire <[email-masked]>
|* Wizard Without Portfolio, Apple Inc.
|* www.stuartcheshire.org
|
|

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 12 Apr 2011 16:04:02 -0700

> -----Original Message-----
> From: [email-masked] [mailto:xiaohong.deng@orange-
> ftgroup.com]
> Sent: Friday, April 01, 2011 11:17 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS
> 
> 

We should be able to make that work with PCP, as well, even with 
a (so-called) "endpoint-dependent mapping" NAT.  (I say "so-called"
because the issue isn't really EDM, but rather the issue is "port
overloading" or "port reuse").

> Yet, it should not fail if you assume explicit mappings should prior

I'll work on some text for that.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 12 Apr 2011 16:04:40 -0700

> From: Stuart Cheshire [mailto:[email-masked]]
> Sent: Saturday, April 02, 2011 2:16 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> As you point out, UPnP IGD 1.0 is fundamentally flawed. The semantics
> it demands are fundamentally impossible to achieve in any shared NAT.
> If it weren't fundamentally flawed we wouldn't have needed NAT-PMP, or
> PCP (or UPnP IGD v2). Constraining PCP to achieve IGD's unachievable
> semantics ("give me the external port I demand") results in a protocol
> that doesn't work. There's no way for a shared NAT to provide the
> semantics demanded by UPnP IGD 1.0, regardless of whether it uses PCP
> or any other protocol.

I think I can craft text, and implementation, to get this working.  Stay
tuned for some proposed text on this in the next day or so.

-d

---

From: <[email-masked]>
Date: Wed, 27 Apr 2011 18:01:53 +0800

|> However, when it comes to PCP UPnP IWF, there is another issue 
|> according to our PCP UPnP IWF tests.
|> 
|> It is likely that after an UPnP 1.0 client has established a dynamic 
|> session on an internal port, it will then requests the same internal 
|> port/external port to be forwarded, which will fail even if 
|"promote" 
|> the conflict implicit mapping to the explicit mapping, because the 
|> external port ( a random port ) is unlikely to be the same as the 
|> internal port for implicit mappings but UPnP 1.0 asks for a specific 
|> port (internal port) as the external port.
|
|We should be able to make that work with PCP, as well, even 
|with a (so-called) "endpoint-dependent mapping" NAT.  (I say 
|"so-called"
|because the issue isn't really EDM, but rather the issue is 
|"port overloading" or "port reuse").

How does PCP server act when an IWF issues a request with 
PREFER_FAILURE Option indicating the same Internal ip and 
internal port as an implicit mapping? 

In the current version (-09), section 11.1." Implementing MAP with
non-EIM
 NATs" will make it work, and assumes an EIM NAT doesn't suffer this
problem.

However EIM NAT is highly likely to fail this request, because it  is
unlikely to
make the PCP request reuse the same mapping/external port as the
implicit
mapping, since the requested external port is unlikely to be the same as
the 
one that implicit mapping is using.

|
|> Yet, it should not fail if you assume explicit mappings should prior 
|> to implicit mappings.
|
|I'll work on some text for that.
|
|-d

BR,
Xiaohong

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Apr 2011 08:09:17 -0700

> Sent: Wednesday, April 27, 2011 3:02 AM
> Subject: RE:[pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS
> 

PREFER_FAILURE just says "if the PCP server cannot provide the Requested
External Port, return an error".  It doesn't control anything related
to EDM or non-EDM NATs, and doesn't control or influence re-use of
an implicit dynamic mapping.

-d

---

From: <[email-masked]>
Date: Thu, 28 Apr 2011 12:50:26 +0800

|> How does PCP server act when an IWF issues a request with 
|> PREFER_FAILURE Option indicating the same Internal ip and internal 
|> port as an implicit mapping?
|> 
|> In the current version (-09), section 11.1." Implementing MAP with 
|> non-EIM  NATs" will make it work, and assumes an EIM NAT doesn't 
|> suffer this problem.
|> 
|> However EIM NAT is highly likely to fail this request, 
|because it  is 
|> unlikely to make the PCP request reuse the same 
|mapping/external port 
|> as the implicit mapping, since the requested external port 
|is unlikely 
|> to be the same as the one that implicit mapping is using.
|
|PREFER_FAILURE just says "if the PCP server cannot provide the 
|Requested External Port, return an error".  It doesn't control 
|anything related to EDM or non-EDM NATs, and doesn't control 
|or influence re-use of an implicit dynamic mapping.

Are you suggesting PREFER_FAILURE should fail even if it's due to 
internal port confilict (with an exist implicit mapping) instead of
external port unavailable?

BR,
Xiaohong

|
|-d
|
|
|> |
|> |> Yet, it should not fail if you assume explicit mappings should 
|> |> prior to implicit mappings.
|> |
|> |I'll work on some text for that.
|> |
|> |-d
|>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Apr 2011 23:36:23 -0700

> Sent: Wednesday, April 27, 2011 9:50 PM
> Subject: RE: [pcp] hoping to eliminate IMPLICIT_MAPPING_EXISTS
> 
> 

No, the text for PREFER_FAILURE only talks about failing (returning
an error) if the Requested External Port cannot be provided.

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Apr 2011 08:37:06 +0200

In your previous mail you wrote:

=> IMHO it must fail with the correct error (i.e.,
IMPLICIT_MAPPING_EXISTS as the recovery is not the same than
for CANNOT_PROVIDE_EXTERNAL_PORT).

Regards

[email-masked]

---

From: <[email-masked]>
Date: Thu, 28 Apr 2011 15:33:41 +0800

|> |PREFER_FAILURE just says "if the PCP server cannot provide the 
|> |Requested External Port, return an error".  It doesn't control 
|> |anything related to EDM or non-EDM NATs, and doesn't control or 
|> |influence re-use of an implicit dynamic mapping.
|> 
|> Are you suggesting PREFER_FAILURE should fail even if it's due to 
|> internal port confilict (with an exist implicit mapping) instead of 
|> external port unavailable?
|
|No, the text for PREFER_FAILURE only talks about failing 
|(returning an error) if the Requested External Port cannot be provided.

Are you going to add some text talking about PREFER_FAILURE
failure when internal port is unavailable?

|
|-d
|
|
|> BR,
|> Xiaohong
|> opensource A+P: http://opensourceaplusp.weebly.com/
|> 
|> |
|> |-d
|> |
|> |
|> |> |
|> |> |> Yet, it should not fail if you assume explicit mappings should 
|> |> |> prior to implicit mappings.
|> |> |
|> |> |I'll work on some text for that.
|> |> |
|> |> |-d
|> |>
|
|

---

From: <[email-masked]>
Date: Thu, 28 Apr 2011 15:35:26 +0800

| In your previous mail you wrote:
|
|   Are you suggesting PREFER_FAILURE should fail even if it's due to 
|   internal port confilict (with an exist implicit mapping) instead of
|   external port unavailable?
|   
|=> IMHO it must fail with the correct error (i.e., 
|IMPLICIT_MAPPING_EXISTS as the recovery is not the same than 
|for CANNOT_PROVIDE_EXTERNAL_PORT).

Right, that's the question: which error code should be returned in this
case?

|
|Regards
|
[email-masked]
|

---

From: Simon Perreault <[email-masked]>
Date: Thu, 28 Apr 2011 08:34:07 -0400

> failure when internal port is unavailable?

IMHO, it's not that the internal port is unavailable. It's that the only
external port available is the one that's currently assigned to that
internal port. So I see this as just another instance of the
CANNOT_PROVIDE_EXTERNAL_PORT error case.

We currently have:

   This option indicates that if the PCP server is unable to MAP the
   suggested port, then instead of returning an available port that it
   *can* allocate, the PCP server should instead allocate no port and
   return result code CANNOT_PROVIDE_EXTERNAL_PORT.

This seems to cover this error case perfectly.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 28 Apr 2011 08:54:53 -0700

> Sent: Thursday, April 28, 2011 12:34 AM

I wasn't planning on it.  What is your suggested text?  

I slightly changed the wording of " Implementing MAP with non-EIM NATs", 
http://tools.ietf.org/html/draft-ietf-pcp-base-09#section-11.1,
to cover both connections from separate hosts (using the
same source port) and connections from the same host (using
the same source port) -- a change which I think causes the
text to include an issue Francis raised in private email.

But I don't know if you're describing a similar, related problem
with PREFER_FAILURE or what.  Because, frankly, I don't understand
the issue and need some hand-holding to understand the problem.
With that understanding, I could have a chance to write text.  But
as I do not understand the problem, I cannot successfully write any
text..

So:  can you suggest text, please?

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Apr 2011 19:15:24 +0200

> failure when internal port is unavailable?
   
   IMHO, it's not that the internal port is unavailable.

=> Simon, it is possible to get both errors, IMPLICIT_MAPPING_EXISTS
from a collision on the internal port, and CANNOT_PROVIDE_EXTERNAL_PORT
from an unavailable external port. In this case of both errors
IMHO the server must return IMPLICIT_MAPPING_EXISTS.

   We currently have:

   
=> I agree: implicitely it means there is no other errors.

Regards