Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Apr 2011 09:18:49 +0200

This error exists just because some NATs can't create a new mapping
when it will conflict with an already existing implicit dynamic
mapping so I am sorry but I can't see how your proposal solves the
problem.

Regards

[email-masked]

PS: I propose to give up on this ticket: from the beginning it is hopeless
as the problem and any solution are out of the scope of PCP.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 11 Apr 2011 17:27:27 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Friday, April 01, 2011 12:19 AM
> To: pcp issue tracker
> Cc: [email-masked]; [email-masked]
> Subject: Re: [pcp] #45: hoping to eliminate IMPLICIT_MAPPING_EXISTS
> 

Stuart's slide 14 at http://www.ietf.org/proceedings/80/slides/pcp-8.pdf has
a reasonable suggestion, which is not rocket science to implement:

  Can be mitigated if NAT partitions its port space
  into ports for EDM use and ports for EIM use

> as the problem and any solution are out of the scope of PCP.

I believe by "out of scope", you are referring to the WG 
consensus that PCP not change NAT behavior?  The problem with
IMPLICIT_MAPPING_EXISTS is that it would force application
changes, in some cases very severe application changes (e.g.,
an application already listening on a port and accepting
connections from internal hosts would have to change its
listening port [or add an additional listening port] if
it receives the infrequent IMPLICIT_MAPPING_EXISTS error.)

I consider it more severe to require changes to millions
of potential applications versus a change to a dozen 
NAT implementations (Linux and various vendors).  It is
especially troubling to expect applications to support
IMPLICIT_MAPPING_EXISTS, because the error will be 
infrequently encountered in a lab or test bed unless
explicitly tickled.  Which means the application code
is unlikely to be adequately tested for this error 
condition.

-d

> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 13 Apr 2011 09:25:10 -0700

On 11 Apr 2011, at 17:27, Dan Wing wrote:

>> PS: I propose to give up on this ticket: from the beginning it is
>> hopeless as the problem and any solution are out of the scope of PCP.
> 

The point of my (admittedly complicated) slides at the Prague meeting was to show that I believe that it *IS* feasible for an EDM NAT to honor inbound mapping requests without just flinging its arms in the air and throwing the problem back at the clients.

Therefore what I propose is that we should not impose this unreasonable burden on clients, and state that if an EDM NAT vendor wants to support inbound mappings (using PCP or anything else), then it is the responsibility of the EDM NAT vendor to make that work.

It's not okay for an EDM NAT vendor to say, "We only handle the easy cases; for the hard cases we give up and make it the client's problem." UPnP IGD 2 suffers from this. From reading it, it gives the impression that a bunch of NAT vendors (not the client writers who will be using the protocol) got together and all wanted the spec to vindicate their different implementations, so the spec allows each NAT to do pretty much whatever it feels like, and leaves it up to the client writers (who weren't represented at the meetings) to sort out the mess. I also get the feeling that the people at the meetings generally weren't the engineers actually writing the NAT code, so they had no power to change that code. This meant that the only avenue open to them was to fight to have the spec state that whatever their current NAT code happens to do is the right thing, instead of accepting that maybe it's not the right thing in every case and maybe they should change their code. This makes IGD 2 more of a survey of what the current state of the NAT industry happens to be, rather than a specification of how it *ought* to be, moving forward.

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

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 18 Apr 2011 08:54:17 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, April 18, 2011 12:18 AM
> To: Dan Wing
>  In your previous mail you wrote:
> 
> => I can't say because I still don't understand Stuart's idea
> and the slides, in particular the slide 9, don't seem to be
> about the IMPLICIT_MAPPING_EXISTS issue which is a problem
> of collision on the *internal* port.

The NAT, in Stuart's slides, is preserving the internal port
and that NAT is so determined to preserve the internal port
that it overloads two connections on the same public port.  So,
it's violating one MUST and one SHOULD in the RFC4787 (UDP) 
and one MUST and one SHOULD in RFC5382 (TCP).

-d

>    consensus that PCP not change NAT behavior?
> 
> => yes.
> 
>    The problem with IMPLICIT_MAPPING_EXISTS is that it would force
>    application changes, in some cases very severe application changes
> 
> => anyway the presence of a NAT in the path can cause application
> changes so I don't buy your argument.
> 
>    (e.g., an application already listening on a port and accepting
>    connections from internal hosts would have to change its listening
>    port [or add an additional listening port] if it receives the
>    infrequent IMPLICIT_MAPPING_EXISTS error.)
> 
> => if the PCP server/NAT doesn't lose its explicit dynamic mapping
> state this is impossible: the existence of an explicit dynamic mapping
> prevents the creation of an implicit dynamic mapping.
>  If the PCP server/NAT loses its explicit dynamic mapping state
> then the application can get another port when it tries to renew
> and can have to change its listening port.
>  This has nothing to do with IMPLICIT_MAPPING_EXISTS...
> 
>    I consider it more severe to require changes to millions of
>    potential applications versus a change to a dozen NAT
>    implementations (Linux and various vendors).
> 
> => have we a way to change any NAT implementation? If the
> answer is no why we have this discussion?
> 
> Regards
> 
> PS: Stuart, what is the status of your slides?

---

From: "pcp issue tracker" <[email-masked]>
Date: Thu, 21 Apr 2011 00:36:06 -0000

#45: hoping to eliminate IMPLICIT_MAPPING_EXISTS

Changes (by dwing@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 fixed in -08.  The IMPLICIT_MAPPING_EXISTS error has been removed, and
 http://tools.ietf.org/html/draft-ietf-pcp-base-08#section-8.9 discusses
 what should happen:

 {{{
    For implicit dynamic mappings, some existing NAT devices have
    endpoint-independent mapping (EIM) behavior while other NAT devices
    have non-endpoint-independent mapping (non-EIM) behavior.  NATs which
    have EIM behavior do not suffer from the problem described in this
    section.  EIM behavior is strongly encouraged by both [RFC4787] and
    [RFC5382].

    In such non-EIM NAT devices, the same external port may be used by
    connections from different internal hosts.  This complicates the
    interaction with the MAP4 and MAP6 OpCodes.  With such NAT devices,
    there are two ways envisioned to implement the MAP4 and MAP6 OpCodes:

    1.  have implicit dynamic mappings (e.g., TCP SYN) use a different
        set of public ports than explicit dynamic mappings (e.g., those
        created with MAP4 or MAP6), thus avoiding the interaction problem
        between them.

    2.  on arrival of an incoming packet from the Internet, first attempt
        to process implicit dynamic mappings (as done today by existing
        port overload code), and if none of those can be processed then
        the incoming packet is for the explicit dynamic mapping.  This
        effectively 'prioritizes' implicit dynamic mappings above
        explicit dynamic mappings.
 }}}

-- 
--------------------------------------------------+-------------------------
 Reporter:  Stuart Cheshire <cheshire@…>          |        Owner:        
     Type:  defect                                |       Status:  closed
 Priority:  major                                 |    Milestone:        
Component:  base                                  |      Version:        
 Severity:  -                                     |   Resolution:  fixed 
 Keywords:                                        |  
--------------------------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/45#comment:1>
pcp <http://tools.ietf.org/pcp/>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Apr 2011 09:35:08 -0700

> Sent: Thursday, April 21, 2011 1:12 AM
> To: pcp issue tracker
> Cc: [email-masked]; [email-masked]
> The general problem is:
> "some NAT implementations don't support to have an implicit dynamic
> mapping and an explicit dynamic mapping using the same address and
> port at the same time."
> 
> base 08 section 8.9 solves only the case where the colliding port
> is the external port, not the case the colliding port is the
> internal port, so:

I do not understand what is meant by 'the case the colliding port 
is the internal port'.

Can you please walk me through an example, using port numbers and
hosts?  I don't get it.

-d

> I ask the section 8.9 to be removed as it doesn't fulfill its goal.
> 
> I ask the IMPLICIT_MAPPING_EXISTS to be defined, I offer the
> problem definition from this message.
> 
> It is my last message about this issue: anyway PROCESSING_ERROR
> can be used, it is just a shame to rely on such a generic error...
> 
> Regards
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 21 Apr 2011 18:38:39 -0700

> Sent: Thursday, April 21, 2011 10:46 AM
> To: Dan Wing
> Cc: [email-masked]
> => host address 192.168.0.1, protocol TCP, an application using
> port 12345 to connect somewhere, so has created an implicit dynamic
> mapping, and a service at the same port 12345, trying to create
> an explicit dynamic mapping. So internal address is 192.168.0.1,
> internal port is 12345.
> Do you really need me to get an address, a protocol and a port?

And you're saying this problem exists on non-EIM NATs, and is 
not solvable by the two mechanisms in
http://tools.ietf.org/html/draft-ietf-pcp-base-08#section-8.9
(the ones marked with "1." and "2.").

If so, then I expect we all need more details.

-d