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

From: "pcp issue tracker" <[email-masked]>
Date: Thu, 31 Mar 2011 19:58:34 -0000

#45: hoping to eliminate IMPLICIT_MAPPING_EXISTS

 During Stuart Cheshire's review, he pointed out a potential issue with the
 IMPLICIT_MAPPING_EXISTS error result code.

 As a reminder, the IMPLICIT_MAPPING_EXISTS is returned if a MAP request is
 received by the PCP server, and there is already an implicit dynamic
 mapping from that same port, and the NAT cannot create a new mapping.

 The problem he pointed out (which is what is discussed in pcp-base
 already) is that this could be caused also by the previous owner of that
 IP address having a (lingering) dynamic mapping in the NAT, or because of
 a dynamic mapping from this same client -- forcing the the server to be
 moved from its perfectly-legitimate port (e.g., TCP/22, TCP/80) to some
 other port.  This is really awkward, to say the least.

 I certainly agree with him on that.  I don't like the
 IMPLICIT_MAPPING_EXISTS error at all.

 I mean, consider if you have a server listening on port "Y", and it is
 running just fine for a week while you're troubleshooting and getting it
 working fine.  And then, when you want listening on the Internet, you have
 to move it to port "F" because PCP said port "Y" is being used by an
 ephemeral connection across the NAT.  That's really awkward.

 Thinking of ways to avoid this error, he came up with an idea:

   Instead of returning this error, the NAT simply create a
   new mapping.

 To do this, I believe this requires the NAT acquire some aspects of
 endpoint-dependent mapping.  Specifically, the NAT would need to continue
 to

 use the existing external port for outgoing packets that are using the
 existing implicit dynamic mapping, and would need to use the new external
 port for other packets.  I believe this wouldn't be possible
 with a lot of NATs.    The way I model this on paper is that a TCP
 SYN arrives from the Internet, hits the NAT and then hits the server,
 which generates a SYNACK, and that SYNACK needs to be NATted using the
 same mapping as used by the inbound SYN.

 More importantly than a thread of "that won't work", I am hoping this will
 kindle some other ideas.

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

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