Subject: [pcp] [PCP] Should we allow PCP to control mapping for remote peers

From: GangChen <[email-masked]>
Date: Wed, 9 Mar 2011 00:09:35 +0800

Hi,

As stated in interim meeting, the failure situation is elaborated as following.

When a PCP host operating a client send PCP request to build a pinhole
on NAT/FW, PCP server will hold mapping for required lifetime after
successful processing.  Let't assume the lifetime is T1.  Afterwards,
the host will initiate TCP communication with a remote peer.  The
remote peer will reply TCP SYN/ACK message to the internal host for
TCP handshake.  Meanwhile, NAT generates implicit dynamic mapping for
the remote peer.  Let't assume the lifetime is T2.  Normally, T1 and
T2 is not identical.

Let's assume there is long-lived TCP connection between the interanl
host and remote peer.  For reducing keepalive signaling, T1 is likely
longer than T2. After TCP session is established, such remote peer NAT
mapping will be expired when there is no traffic occurring in interval
of T2.  In this case, TCP session will be broken even if the mapping
for internal host is still alive.

Gang

---

From: GangChen <[email-masked]>
Date: Wed, 9 Mar 2011 20:23:06 +0800

Hello all,

I have proposed a new draft to address this issue.
Please kindly to review.

http://tools.ietf.org/html/draft-chen-pcp-bidirection-mapping-00

Filename:	 draft-chen-pcp-bidirection-mapping
Revision:	 00
Title:		 Bidirectional Port Control for PCP
Creation_date:	 2011-03-07
WG ID:		 Independent Submission
Number_of_pages: 7

Abstract:
The memo has proposed a bi-directional option, along with which PCP
could not only control PCP client pinhole, but also could manage port
mapping status for communicating remote peers.  The bi-directional
port control mode will eliminate risks of connections interruption
caused by remote peer pinhole timeout.

BRs

Gang

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Mar 2011 11:40:23 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> GangChen
> Sent: Tuesday, March 08, 2011 8:10 AM
> To: [email-masked]
> Subject: [pcp] [PCP] Should we allow PCP to control mapping for remote
> peers
> 
> Hi,
> 
> the host will initiate TCP communication with a remote peer. 

Using the same source port?

If so, that is "Operating a Symmetric Client/Server", described 
in http://tools.ietf.org/html/draft-ietf-pcp-base-06#section-7.3

> The

Depending on the NAT's implementation, T2 may not have created any
additional state in the NAT whatsoever.  For example, a NAT 
that is has both endpoint independent mapping and endpoint independent
filtering would not create any additional state because of that
outgoing TCP connection.

> longer than T2. After TCP session is established, such remote peer NAT
.........................................................^^^^^^^^^^^^^^^

> for internal host is still alive.

I am confused by the use of "remote peer NAT".  Here is what I
interpret you to mean:

   TCP client----[NAT]======<Internet>====[NAT]---TCP server
                                          ^^^^^   ^^^^^^^^^^^
                                          ^^^^^   ^^^^^^^^^^^
                                          ^^^^^   this is the "remote peer"
                                          ^^^^^
                                          ^^^^^
                                    this is the "remote peer NAT"

Is that what you mean?  If you mean something else, please provide
a diagram of what you mean by "remote peer NAT".

-d

---

From: GangChen <[email-masked]>
Date: Fri, 11 Mar 2011 00:15:59 +0800

> in http://tools.ietf.org/html/draft-ietf-pcp-base-06#section-7.3

That's right.
My intention here is "Operating a client". So, I correct this
statement like "After a host operating a client connects to its
server, it issues a PCP request with the PEER opCode for reducing NAT
keepalive message. PCP server will hold mapping for required lifetime
after successful processing. Let's assume the lifetime is T1.
Meanwhile, NAT also holds implicit dynamic mapping for the remote
peer. Let's assume the lifetime is T2. ..."

BTW, this failure also occurs when that is "Operating a Symmetric
Client/Server".

> filtering would not create any additional state because of that

I'm not sure. Let me draw a digram to make clear.

+------------------------+                   +------------------------+
|  IPv4 network          |                   |  IPv6 network          |
|   1.1.1.1:200          |                   |     [2001::1]:200      |
|   +-----------+        |    +-------+      |   +-----------+        |
|   |Client(PCP)|--------|----| NAT46 |------|---|Server     |--------|
|   +-----------+        |    +-------+      |   +-----------+        |
+------------------------+   PCP Server      +------------------------+

NAT will hold a pair of address mapping

+-----------+-------------------+------------+-------------+
|IPv4       |IPv6               |Lifetime    |mapping type |
+-----------+-------------------+------------+-------------+
|1.1.1.1:200|[2001::1.1.1.1]:200|T1          |explicit     | mapping
of internal host
+-----------+-------------------+------------+-------------+
|1.1.1.3:300| [2001::1]:200     |T2          |implicit     | mapping
of remote peer
+-----------+-------------------+------------+-------------+

The state of IPv6 remote peer need to be created no matter what kind
of implementation.

>    TCP client----[NAT]======<Internet>====[NAT]---TCP server
Sorry for the confusion.
"remote peer NAT" means "the mapping of remote peer on NAT". Please
refer to above table.

Many thanks

Gang

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 Mar 2011 09:06:22 -0800

> From: GangChen [mailto:[email-masked]]
> Sent: Thursday, March 10, 2011 8:16 AM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] [PCP] Should we allow PCP to control mapping for
> remote peers
> 

Text in -06 currently says:

   On receiving the PEER4 or PEER6 OpCode, the PCP server examines the
   mapping table.  If a mapping does not exist, the NONEXIST_PEER error
   is returned.

 % If the PCP-controlled device can extend the lifetime of a mapping,
 % the PCP server uses the smaller of its configured maximum lifetime
 % value and the requested lifetime from the PEER request, and sets the
 % lifetime to that value.

   The PEER4 or PEER6 OpCodes MUST NOT reduce the lifetime of an
   existing mapping.  If the mapping is terminated by the TCP client or
   server (e.g., TCP FIN or TCP RST), the mapping will eventually be
   destroyed normally; the earlier use of PEER does not extend the
   lifetime in that case.

   If all of the proceeding operations were successful (did not generate
   an error response), then a SUCCESS response is generated, with the
   assigned-lifetime containing the lifetime of the mapping.

      Note: it is implementation-specific if the PCP-controlled device
      destroys the mapping when the lifetime expires, or if
      inside->outside traffic keeps the mapping alive.

for the scenario you have, the PCP-controlled device can extend
the lifetime of the mapping, which means the paragraph I marked with
"%" applies.  This means that the requested lifetime (T1) is processed
successfully by the PCP server, and thus T1 = T2.

If the PCP-controlled device cannot extend the lifetime (due to
how it is implemented), it merely reports the current lifetime
(T2).  In that case, the PCP PEER message only reports the
lifetime -- it does not change (extend) the lifetime.

I don't see a failure with this.

> BTW, this failure also occurs when that is "Operating a Symmetric

Which I think is what you're describing below.

> I'm not sure. Let me draw a digram to make clear.

So, those are two separate connections -- the IPv4 addresses and
IPv6 addresses are different.  First is 1.1.1.1 and second is
1.1.1.3.  

That isn't at all a Symmetric Client/Server, which is summarized in 
Section 7.3 as:

   A host operating a client and server on the same port (e.g.,
   Symmetric RTP [RFC4961] or SIP Symmetric Response Routing (rport)
   [RFC3581]) first establishes a local listener, (usually) sends the
   local and public IP addresses and ports to a rendezvous service
   (which is out of scope of this document), and (usually) initiates
   outbound connections from that same source address.  To accomplish
...^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   this, the application uses the procedure described in this section.

> The state of IPv6 remote peer need to be created no matter what kind

I don't follow.

-d

---

From: GangChen <[email-masked]>
Date: Fri, 11 Mar 2011 15:32:03 +0800

I need to clarify the failure scenario further. Let's focus on host
operating a client
I list step-by-step analysis.

|   |Client(PCP)|--------|----| NAT46 |------|---|Server     |        |

Step 1: To use PCP for this function, the applications first connects
to its server, as normal.
A TCP connection is established between the client and server.
The NAT needs to hold two separate mappings for one TCP connection.

For inside->outside traffic, the address mapping of internal host
should be created
+-----------+-------------------+------------+-------------+
|IPv4       |IPv6               |Lifetime    |mapping type |
+-----------+-------------------+------------+-------------+
|1.1.1.1:200|[2001::1.1.1.1]:200|T1          |explicit     |
+-----------+-------------------+------------+-------------+

For outside->inside traffic, the address mapping of remote server
should be created
+-------------+------------+------------+-------------+
|IPv6         |IPv4        |Lifetime    |mapping type |
+-------------+------------+------------+-------------+
|[2001::1]:200|1.1.1.3:300 |T2          |implicit     |
+----------- -+------------+------------+-------------+
Note: 1.1.1.3 belongs to IPv4 pool maintained in NAT46

Step2: PCP client issues a PCP request with the PEER6 OpCode.
Afterwards, PCP-controlled device can extend the lifetime T1 of the
mapping of internal host(that is for inside->outside). But it can't
extend the lifetime T2 of the mapping of remote server(that is for
outside->inside).
T1 is likely longer than T2.

If above statement is true, failure might happen when long-lived TCP
connection exists between client and server.
PCP could extend lifetime T1 to 1 hour or 1 day. But lifetime T2 still
remains to 30 minutes, which is normal NAT configuration for TCP
session.
When there is no traffic occurring for more than 30 minutes, the
mapping of internal host is alive. But the mapping of remote server is
expired.
As a result, the TCP connection will be broken.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Mar 2011 10:07:11 -0800

> Sent: Thursday, March 10, 2011 11:32 PM
> To: Dan Wing
> Cc: [email-masked]

Two?  When did two mappings get created?

> For inside->outside traffic, the address mapping of internal host

How did that explicit mapping get created?  It must have been with
PCP, I guess??  But you didn't list any PCP activity occurring above.
The first PCP message is in Step 2, below.

> For outside->inside traffic, the address mapping of remote server

It would use the PEER4 OpCode.  The client is IPv4-only (which
is why it's going through a NAT46) and does not need to know 
(and might not even be able to learn) the IPv6 address of the 
remote IPv6 peer.

-d

> >> >> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of
> >> >> GangChen
> >> >                                           ^^^^^   this is the
> "remote
> >> peer"

---

From: GangChen <[email-masked]>
Date: Mon, 14 Mar 2011 00:54:17 +0800

> Two?  When did two mappings get created?

Say the IPv4 Node A wants to communicate with the IPv6 Node B.  Node A
creates a packet with:
Source Address, SA=1.1.1.1 , source TCP port = 200 and Destination
Address, DA = 1.1.1.3, destination TCP port = 300.
Therein, DA and TCP port belongs to IPv4 pool maintained in NAT46.
This means IPv6->IPv4 mapping for Node B is created in advance by
DNS-ALG or somehow another means. That is first mapping in my
understanding.

When the packet reaches the NAT46 box, NAT46 would assign IPv6 address
and port to translate the tuple of (Source Address, Source TCP port)
as follows:
SA=2001::1.1.1.1, source TCP port = 200  and  DA=2001::1, destination
TCP port =200.
This IPv4->IPv6 mapping is second mapping for this TCP connection.

> The first PCP message is in Step 2, below.

I refer to http://tools.ietf.org/html/draft-ietf-pcp-base-06#section-7.2.
My understanding is PEER opcode only take effect on explicit mapping.

> (and might not even be able to learn) the IPv6 address of the

Yes. It should be PEER4 OpCode. I think PEER4 opCode could control
IPv4->IPv6 mapping, but nothing to do with IPv6->IPv4 mapping. Am I
right?

Many thanks

Gang

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 17:22:37 -0700

> Sent: Sunday, March 13, 2011 9:54 AM
> To: Dan Wing
> Cc: [email-masked]

I read the above twice, on different days.  I'm sorry.  I still
don't understand how there are two mappings for one TCP connection.

> My understanding is PEER opcode only take effect on explicit mapping.

No, PEER works with implicit dynamic mappings.  Implicit dynamic mappings
are those that are created by the host initiating a new flow -- such as
by sending a TCP SYN, or by sending a UDP packet.

> IPv4->IPv6 mapping, but nothing to do with IPv6->IPv4 mapping. Am I

Yes, PEER4 would be used with IPv4->IPv6 mapping (and IPv4->IPv4),
and PEER6 would be used with IPv6->IPv4 mapping (and IPv6->IPv6).

-d