Subject: [pcp] PCP-base 02: Section 7.7

From: <[email-masked]>
Date: Mon, 10 Jan 2011 10:02:37 +0100

Hi Dan,

I re-read section 7.7 of pcp-02 and especially:

"   On many common platforms (i.e., those making use of the BSD sockets
   API), using PCP for purposes of application keepalives by issuing a
   PCP request followed by a dynamic connection to the server is
   difficult to implement properly.  This is therefore NOT RECOMMENDED.
   Instead, client applications SHOULD first establish a dynamic
   connection to a server, and then issue a PCP request related to that
   connection, including the REMOTE_PEER option."
I'm not sure this reflects the opinions that have been expressed in this mailing list about this issue.

I personally expressed some concerns about the connect-then-lifetime available at: http://www.ietf.org/mail-archive/web/pcp/current/msg00483.html

I still disagree with the conclusion of this section in its current state; in particular keepalive+avoid ALGs is to be considered IMHO.

Cheers,
Med

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Jan 2011 08:45:02 -0500

> mailing list about this issue.

Note that this was discussed in the virtual interim meeting. I seem to
recall the consensus being that the advantage of easy deployment
outweighed the disadvantages. (Were the minutes of the meeting posted?)

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: <[email-masked]>
Date: Mon, 10 Jan 2011 15:47:19 +0100

Dear Simon,

I attended the interim meeting but I left before the end of the conf call.

I didn't seen any minutes posted of the interim meeting. 

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Simon Perreault
Envoyé : lundi 10 janvier 2011 14:45
À : [email-masked]
Objet : Re: [pcp] PCP-base 02: Section 7.7

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
_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

---

From: Francis Dupont <[email-masked]>
Date: Mon, 10 Jan 2011 23:48:41 +0100

In your previous mail you wrote:

   I re-read section 7.7 of pcp-02 and especially:
   ...
   I'm not sure this reflects the opinions that have been expressed in
   this mailing list about this issue.
   
=> I agree: this text was imported directly from base-01 when
it was known to be wrong.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Tue, 11 Jan 2011 00:01:53 +0100

Note that this was discussed in the virtual interim meeting. I seem to
   recall the consensus being that the advantage of easy deployment
   outweighed the disadvantages.

=> I am afraid this argument would not close the subject...
and there was no consensus, just a 'go to next point'.

  (Were the minutes of the meeting posted?)
   
=> +1!

PS: BTW the 'ease of deployment' is not a good argument as it applied
only on hosts, not on NATs, when IMHO at least 50% of the deployed
base won't support it.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Jan 2011 18:37:48 -0500

> only on hosts, not on NATs, when IMHO at least 50% of the deployed

This is the first time I hear this argument. Can you explain why 50% of 
existing NATs would not support connect-then-keepalive?

It would be very unfortunate if we had option A be unimplementable on 
hosts and option B be unimplementable on NATs...

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Jan 2011 18:38:59 -0500

> existing NATs would not support connect-then-keepalive?

I meant connect-then-lifetime...

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 10 Jan 2011 16:03:13 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Monday, January 10, 2011 3:02 PM
> To: Simon Perreault
> Cc: [email-masked]
> Subject: Re: [pcp] PCP-base 02: Section 7.7
> 
> 

For reference, this is Issue #17,
http://trac.tools.ietf.org/wg/pcp/trac/ticket/17

In the post http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html,
Simon described the host implementation difficulty.  This got agreement from
Dave Thaler, http://www.ietf.org/mail-archive/web/pcp/current/msg00475.html
and Lars Eggert,
http://www.ietf.org/mail-archive/web/pcp/current/msg00480.html.

I do not find a post that describes the NAT implementation difficulty.  

I found posts that suggest NATs want to have different port ranges for
PCP-controlled ports than for dynamically-created connections.  That's makes
some sense when the user is operating a server.  But I don't understand how
separate NAT port ranges are helpful/necessary for the application
keepalives case.  

If this does help the NAT, it seems we will need to force (MUST) the hosts
to allocate a source port in the non-ephemeral port range and follow the
other steps described in
http://www.ietf.org/mail-archive/web/pcp/current/msg00474.html.  

-d

---

From: <[email-masked]>
Date: Tue, 11 Jan 2011 07:55:26 +0100

Hi Dan,

As a reminder, I have enumerated a set of advantages of implementing what was called option 2 (http://www.ietf.org/mail-archive/web/pcp/current/msg00483.html).

In http://www.ietf.org/mail-archive/web/pcp/current/msg00487.html, I tried to explain that implementing option 1 may not reduce keepalives in some contexts since the refresh interval is forced by the server and not by the client (see SIP example for instance).

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 11 janvier 2011 01:03
À : 'Francis Dupont'; 'Simon Perreault'; BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : [email-masked]
Objet : RE: [pcp] PCP-base 02: Section 7.7

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Jan 2011 09:35:02 -0800

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, January 10, 2011 10:55 PM
> To: Dan Wing; 'Francis Dupont'; 'Simon Perreault'
> Cc: [email-masked]
> Subject: RE: [pcp] PCP-base 02: Section 7.7
> 
> Hi Dan,
> 
> As a reminder, I have enumerated a set of advantages of implementing
> what was called option 2 (http://www.ietf.org/mail-
> archive/web/pcp/current/msg00483.html).
> 
> In http://www.ietf.org/mail-archive/web/pcp/current/msg00487.html, I
> tried to explain that implementing option 1 may not reduce keepalives
> in some contexts since the refresh interval is forced by the server and
> not by the client (see SIP example for instance).

Thanks for the pointers.

The first URL says:

    > I don't know how we can forbid applications to use option 2
    > which is the obvious one to avoid overloading service
    > elements with keepalive messages!
    >
    > As a concrete example: In the current VoIP deployments SBC
    > or P-CSCF forces the SIP User Agent to send frequent
    > REGISTER messages (setting a small value of expire timer);
    > these messages are not forwarded to the core service
    > elements. The main purpose is to maintain the NAT binding
    > in case a NAT is traversed alive. Both the NAT and SBC are
    > overloaded with these keepalive messages. For the NAT side
    > this may not be an issue when the NAT is embedded in the
    > CPE but this may be become sensitive for the CGN case.
    >
    > If PCP is used to instruct a mapping before issuing the
    > REGISTER message: (1) the CGN is not overloaded, (2)
    > service contact point is not overloaded, (3) the client can
    > use the external IP address/port to build its application
    > messages (e.g., SIP) and thus no need to implement extra
    > function in the service side (e.g., SBC) or in the CGN
    > (e.g., SIP ALG), (4) the service elements can detect the
    > present of non-transparent NAT by comparing the content of
    > the message with the source IP/port information, (5) the
    > client is aware of the lifetime of the mapping in the CGN
    > which important to avoid sending aggressive keeplines
    > (e.g., 20s for Ipsec clients), etc.

and the second URL reinforces that connect-then-lifetime does not
have property (3).

Here is how I see property (3) implemented when doing connect-then-lifetime,
following the REGISTER
procedure described at
http://tools.ietf.org/html/draft-ietf-sipping-nat-scenarios-13#page-16

  SIP UA                          PCP server    SIP proxy
    |                                 |             |
    |--SIP REGISTER, rport------------------------->|
    |<-Ok, port=12345-------------------------------|
    |                                 |             |
    |-PIN44, REMOTE_PEER=<sip proxy>->|             |
    |<--lifetime=3600, ext-port=12345-|             |
    |                                 |             |

What is the disadvantage of reducing SIP keepalives that way?

For RTP, message flow would be like this, again doing connect-then-lifetime.
The difference is we don't get anything like an "rport=NNN" from the remote
peer.  But, we don't need it anyway except to detect a rogue NAT on the path
between the PCP-controlled NAT and the RTP peer.  If the SIP UA wanted to
detect such a rogue NAT, it would need to send ICE (STUN) messages to the
RTP peer.

  SIP UA                          PCP server     RTP peer
    |                                 |             |
    |--RTP message--------------------------------->|
    |--RTP message--------------------------------->|
    |--... more RTP messages ...------------------->|
    |--RTP message--------------------------------->|
    |                                 |             |
    |-PIN44, REMOTE_PEER=<rtp peer>=->|             |
    |<--lifetime=3600, ext-port=12345-|             |
    |                                 |             |

As with SIP, the SIP UA does not need to be in a hurry to communicate with
the PCP server.

-d

> >    Note that this was discussed in the virtual interim meeting. I
> seem
> > to

---

From: <[email-masked]>
Date: Wed, 12 Jan 2011 07:55:23 +0100

Hi Dan,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 11 janvier 2011 18:35
À : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Francis Dupont'; 'Simon Perreault'
Cc : [email-masked]
Objet : RE: [pcp] PCP-base 02: Section 7.7

Thanks for the pointers.

Med: The use of "rport" allows the SIP Proxy to answer to the source port number and not to the one indicated in the via header but it does not help the SIP proxy server to detect the lifetime of the nat binding in the path; therefore a lower expire timers (e.g., 30 or 60s) will be returned by the SIP Proxy to the SIP UA to maintain such binding. The SIP UA has to refresh its registration before the expiry of the returned expiry timer. The PCP request does not help in such case. In some deployments "rport" is not used but SBCs "emulate" a similar functionality but this does not prevent frequent re-registration messages (not forwarded to the core service elements btw). Keepalive messages have a SEVERE impact on the performance of the SBC (60% degradation). This is why I prefer to present a SIP message to the SIP proxy without rport but with the external IP/port assigned by the nat in the path. This would be a hint for the proxy server to return an expire timer with greater value.

Med: Why not doing it simple, use the even_plus_one option to get the ports; use those ports to build the offer/answer and issue the request. We don't need ICE/STUN/etc. 

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Jan 2011 09:19:49 -0800

...
> Med: The use of "rport" allows the SIP Proxy to answer to the source
> port number and not to the one indicated in the via header but it does
> not help the SIP proxy server to detect the lifetime of the nat binding
> in the path;

Agreed.  But it is not the SIP proxy's job to keep the NAT
binding alive.  It is the SIP UA's job to do that, and the SIP UA
sends those keepalives.

> therefore a lower expire timers (e.g., 30 or 60s) will be
> returned by the SIP Proxy to the SIP UA to maintain such binding. The
> SIP UA has to refresh its registration before the expiry of the
> returned expiry timer. The PCP request does not help in such case. In
> some deployments "rport" is not used but SBCs "emulate" a similar
> functionality but this does not prevent frequent re-registration
> messages (not forwarded to the core service elements btw). Keepalive
> messages have a SEVERE impact on the performance of the SBC (60%
> degradation).

In both the cases you describe above, it is the SIP UA that is
generating the keepalive messages.  It is the SIP UA that can
reduce the frequency of those messages when it (a) determines it
has only PCP-controlled NATs on the path and (b) knows the lifetime
of the mappings in those NATs.

This new knowledge in the SIP UA may require changes to SIP's signaling.

> This is why I prefer to present a SIP message to the SIP
> proxy without rport but with the external IP/port assigned by the nat
> in the path. This would be a hint for the proxy server to return an
> expire timer with greater value.

"rport" could be removed, but only if we have the SIP UA open its 
port differently from how it does it today.  See below.

> Med: Why not doing it simple, use the even_plus_one option to get the
> ports; use those ports to build the offer/answer and issue the request.
> We don't need ICE/STUN/etc.

I did not suggest or propose using ICE/STUN to open pinholes.  Rather, I 
suggested using ICE (STUN) to detect a rogue NAT.  By 'rogue', I mean a 
NAT that is not running PCP but is on the media path.

But please see below.

> As with SIP, the SIP UA does not need to be in a hurry to communicate

I stepped back from the problem and came to a different way to view
this, which I have added to my work-in-progress copy of -03.  This
new text reads:

  "7.1.  Use Cases for PIN OpCodes

   There are three uses for these PIN OpCodes:

   1.  a host operating a server (e.g., a web server).  For this, the
       application needs to (a) create a pinhole from a public IP
       address and port to itself and (b) publish that public IP address
       and port to some sort of rendezvous server (e.g., DNS, a SIP
       message, a proprietary protocol).  To accomplish this, the
       application follows the procedures described in Section 7.1.1.
[7.1.1 is a new section titled "Using PCP to Operate a Server",
which says you need to bind to an non-ephemeral port for your
application's exclusive use.]

   2.  a host operating a client (e.g., XMPP client, SIP client).  For
       this, the application wants to ensure its connection is not
       terminated prematurely (due to inactivity) by an on-path NAT or
       firewall.  To accomplish this, the application uses the
       procedures described in Section 7.1.2.
[7.1.2 is -02's Section 7.7 "Using PCP to Eliminate 
Application Keepalive Messages"]

   3.  a host operating a client and server on the same port (e.g.,
       Symmetric RTP [RFC4961] or SIP Symmetric Response Routing (rport) 
       [RFC3581]).  For this, the application desires properties of 
       both (1) and (2), and uses the procedures described in Section 
       7.1.3.
[7.1.3 is a new section titled "Using PCP to Operate a 
Symmetric Client/Server", which combines aspects of (1)
and (2).]"

I believe this is much more clear about how the PCP-enabled application 
should utilize PCP to meet its needs.

Related, I created a new ticket, Issue #35, which is something Simon 
and I had discussed offline, but I don't think we achieved clarity on 
the problem.  I now think the problem is clearer.  Included in -03
will be the following (which is the same as in Issue #35),

          [Ed.  Note: A host operating a pure client (2) seldom knows or
          cares about the address family of the server; a host 
          operating a symmetric client/server (3) sometimes also does
          not know or care.  Thus, the PCP client could mistakenly use
          the PIN44 OpCode when it should have used PIN46.  This is
          unfortunately not fully handled by REMOTE_PEER's inclusion of
          address family from the PCP client's perspective.  Do we want
          to resolve this?  If so, how -- perhaps adjust all of the PIN
          opcodes to effectively incorporate the REMOTE_PEER semantic?
          This is tracked as PCP Issue #35]

http://trac.tools.ietf.org/wg/pcp/trac/ticket/35

Thoughts / comments on Issue #35?

-d

> > Simon described the host implementation difficulty.  This got
> agreement
> > from
> > PCP-controlled ports than for dynamically-created connections.
> That's
> > makes
> > some sense when the user is operating a server.  But I don't
> understand
> > how
> > If you are not the intended addressee of this message, please cancel
> it
> > immediately and inform the sender.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Jan 2011 22:50:58 +0100

=> on a Linux: man iptables
To summary connect-then-keepalive assumes dynamic and PCP mappings are the same
and it is at least fully false on the most common NAT code, in particular
on small boxes.

=> this is why to design something without taking care of the existing
is IMHO not the best (:-).

Regards

PS: in fact Linux NAT is not EIM/EIF: it is either (== on choice)
EIM/APDF or APDM.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Jan 2011 22:58:35 +0100

=> you can find many posts saying than the hypothesis "dynamic mapping ==
PCP mapping" is not always true.
(cf ticket #9)

=> with separate NAT port ranges either the PCP request will fail or it returns
another external port. In both cases it won't do what is expected, i.e.,
the request won't change the lifetime of the dynamic mapping.

=> the issue is with the external port so the choice of the internal port
by the host won't help.

Regards

PS: note it is possible to fall back on the lifetime-than-connect strategy
but it introduces delay and complexity.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Jan 2011 17:41:38 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, January 13, 2011 1:59 PM
> To: Dan Wing
> Cc: 'Simon Perreault'; [email-masked];
> [email-masked]
> That's makes
> understand how

I have an idea, which I am writing into -03, which takes a different
approach to solve the problem.  I believe it works.

However, I do not understand the purpose of the PCP server using
different pools for PCP-controlled mappings and for dynamic
mappings.  That is, I do not see the advantage to to _preventing_
an application from learning the lifetime of its dynamic mapping.
You and Med have said there is some advantage to forcing the 
application to first send a PCP message.  I have not understood
what advantage that brings to the NAT's implementation or to
the NAT's operation.  Can you please elaborate the advantage.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Jan 2011 18:00:17 -0800

> Sent: Thursday, January 13, 2011 1:51 PM
> To: Simon Perreault
> Cc: [email-masked]
>    Le 10/01/2011 6:01 PM, Francis Dupont a icrit :
> and it is at least fully false on the most common NAT code, in
> particular on small boxes.

You're saying PCP cannot dip into the NAT state table for an
existing connection, examine (or increase) the lifetime of the mapping, 
and return that value?

-d

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Jan 2011 10:53:06 +0100

=> I say we can't require all NAT implementations to perform
operations you cite for dynamic mappings. And BTW this is out of
the charter which is for NATs only about port forwarding.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Jan 2011 03:38:41 -0800

> Sent: Friday, January 14, 2011 1:53 AM
> To: Dan Wing
> Cc: 'Simon Perreault'; [email-masked]
> operations you cite for dynamic mappings.

And several people have said we can't require all applications 
developers to do complicated socket allocations in order to 
bring up a simple TCP client and optimize its keepalives.

> And BTW this is out of

I see.

-d

---

From: Simon Perreault <[email-masked]>
Date: Fri, 14 Jan 2011 08:52:18 -0500

> => on a Linux: man iptables

Please. I think I know iptables well enough...

> and it is at least fully false on the most common NAT code, in particular

Why wouldn't dynamic and PCP mappings be the same? Why couldn't a Linux
PCP server just edit Netfilter's conntrack table directly? Why would it
need to go through iptables?

Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 14 Jan 2011 09:00:32 -0500

> existing connection, examine (or increase) the lifetime of the mapping, 

As least on Linux it is possible using e.g. libnetfilter_conntrack.

Simon

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Jan 2011 17:33:59 +0100

=> so you know iptables don't provide a way to patch dynamic mappings.

   > and it is at least fully false on the most common NAT code, in particular
   
   Why wouldn't dynamic and PCP mappings be the same?

=> they can (!= 'they must' and != 'they must not').

   Why couldn't a Linux PCP server just edit Netfilter's conntrack
   table directly? Why would it need to go through iptables?
   
=> because conntrack is at least one order bigger to manage than
iptables, and we are taking about small boxes (big boxes don't run Linux,
BTW this doesn't mean they don't share the issue).

And again this is not in the charter so if the NAT supports this why not,
and no more.

Regards

---

From: Simon Perreault <[email-masked]>
Date: Fri, 14 Jan 2011 11:39:18 -0500

> => so you know iptables don't provide a way to patch dynamic mappings.

Of course.

> BTW this doesn't mean they don't share the issue).

iptables uses conntrack in the kernel to implement its NAT. You cannot
run a NAT on Linux with iptables without using conntrack implicitly. Big
or small, every Linux NAT runs conntrack.

Using libnetfilter_conntrack to inspect and modify the NAT state table
from user-space is very simple. One might even argue that it is simpler
than iptables because it provides a real API.

Simon

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Jan 2011 17:50:40 +0100

mappings.

=> first it is a fact so to discuss about advantages is useless,
second it is just an example of a classical way to manage share
resources: as dynamic and PCP mappings are at least different
for lifetime it can be simpler to use different pools.
And don't forget the pretty different security constraints can become
a strong argument too.

   That is, I do not see the advantage to to _preventing_
   
=> I shan't because it is about NAT behavior and it is not
the right mailing-list.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Jan 2011 19:13:48 +0100

> BTW this doesn't mean they don't share the issue).
   
=> I believe it was obvious but I refered to the user mode
conntrack tools.

=> I know: it is pretty hard to disable conntrack when you don't need it
(of course, to remove all iptables' chains has not this effect :-).

=> we can argue about the libipt API but the conntrack table is
for some orders larger than an iptables chain. This is why I don't expect
to get it on a typical small box.

Regards

PS: about other "Unix" NAT implementations (or future Linux):
you have the equivalent of conntrack tools as soon as you have
NAT state duplication (obviously to duplicate the state you
have to read, transfer and re-install it).
For instance OpenBSD PF (used on some other BSDs) provides pfsync.
BTW it makes clear again the PF state and the PF rulesets
(aka dynamic and static mapping tables) pretty different.

PPS: when PCP gives access to both dynamic and not dynamic mappings,
one can ask for a way to recognize not dynamic mappings.
IMHO the lifetime is a good criterion and a not dynamic mapping
which will expire soon looks the same than a dynamic mapping
with all other properties the same. But this is an operational
point of view: for security they could be considered as critically
different...

---

From: Jacni Qin <[email-masked]>
Date: Mon, 17 Jan 2011 09:14:09 +0800

Re-,

> Thoughts / comments on Issue #35?

Or simply return an error to identify this status, which then trigger the
client to try another server in its list?

Cheers,
Jacni

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 18 Jan 2011 14:06:14 -0800

> Or simply return an error to identify this status, which then trigger
> the client to try another server in its list?

But the client doesn't have another server on its list.  Looking at
an XMPP we all know and love as a concrete example:

  # host jabber.ietf.org
  jabber.ietf.org has address 64.170.98.32
  jabber.ietf.org has IPv6 address 2001:1890:1112:1::20
  jabber.ietf.org mail is handled by 0 mail.ietf.org.

-d

---

From: Jacni Qin <[email-masked]>
Date: Wed, 19 Jan 2011 09:19:30 +0800

Re-,

On Wed, Jan 19, 2011 at 6:06 AM, Dan Wing <[email-masked]> wrote:

> But the client doesn't have another server on its list.

Jacni>: Sorry, I'm confused. What I mean is to try another PCP Server.
The PCP Client, also the client of an application should know the stack of
its remote peer of that application. The problem is which PIN opcode it
should use. Assume that the Client is of IPvX and its remote peer is of
IPvY, then it should use PINXY. If the PCP server is not a right one (e.g.,
doesn't support Y), maybe try another one.

While I got another question, in one of the use case NAT64, if the PCP
Client is IPv6-only (i.e., a host with only IPv6 stack), how could it know
IPv4 and use PIN64?
Maybe the other type of IPv6-only host, with both IPv4 and IPv6 stack but
only with IPv6 connectivity is ok. Did I miss something?

Cheers,
Jacni

>  Looking at

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 18 Jan 2011 17:53:55 -0800

> From: Jacni Qin [mailto:[email-masked]]
> Sent: Tuesday, January 18, 2011 5:20 PM
> To: Dan Wing
> Cc: [email-masked]; Francis Dupont; Simon
> Perreault; [email-masked]
> Subject: Re: [pcp] client/server/symmetric [was RE: PCP-base 02:
> Section 7.7]
> 
> Re-,
> 
> 
> 	>       Related, I created a new ticket, Issue #35, which is
> something
> 	> Simon
> 	>       and I had discussed offline, but I don't think we
> achieved
> 	> clarity on
> 	>       the problem.  I now think the problem is clearer.
> Included in -
> 	> 03
> 	>                [Ed.  Note: A host operating a pure client (2)
> seldom
> 	> knows or
> 	>                operating a symmetric client/server (3)
> sometimes also
> 	> does
> 	>                not know or care.  Thus, the PCP client could
> mistakenly
> 	> use
> 	>                the PIN44 OpCode when it should have used PIN46.
> This
> 	> is
> 	>                address family from the PCP client's
> perspective.  Do we
> 	> want
> 	>                to resolve this?  If so, how -- perhaps adjust
> all of
> 	> the PIN
> 	>                opcodes to effectively incorporate the
> REMOTE_PEER
> 	> semantic?
> The PCP Client, also the client of an application should know the stack
> of its remote peer of that application. The problem is which PIN opcode
> it should use. Assume that the Client is of IPvX and its remote peer is
> of IPvY, then it should use PINXY. If the PCP server is not a right one
> (e.g., doesn't support Y), maybe try another one.

The problem isn't what the PCP server supports.  I mean, let's assume
(for the moment) that the PCP server supports all of the PIN* codes --
in that case, the PCP client doesn't know which PIN* code to send.

I have resolved this with a new OpCode in -03.  I expect to publish
-03 shortly (this evening or tomorrow).

> Client is IPv6-only (i.e., a host with only IPv6 stack), how could it
> know IPv4 and use PIN64?

In -03, new text explains there are three cases:

  1. operating a server.  If a host wants to operate a server, it
     knows if it wants an IPv6 listener, IPv4 listener, or both --
     just like today it knows if it wants to listen on an IPv6 
     socket or an IPv4 socket or both.
  2. client connecting to a server, such as an IMAP server, 
     XMPP server, SIP server, etc.  In such a case, it wants to
     reduce application-level keepalives that it would otherwise
     send to keep the NAT mapping alive
  3. symmetric client and server on the same port, such as done
     by SIP signaling and by RTP media, where the same port is
     used to send packets and to receive incoming packets.

With this new clarity in -03, you are referring to case (1) and
case (3).  In those cases, the client knows it wants an IPv4
listener (PINx4), IPv6 listener (PINx6), or both (PINx4 and PINx6).  
It knows if it has an IPv4 interface on itself (PIN4y) or an IPv6 
interface on itself (PIN4y).  Taking the union of its own knowledge
of what it wants publicly and its own interfaces, it sends a
request for PIN44, PIN64, PIN46, or PIN66.

> Maybe the other type of IPv6-only host, with both IPv4 and IPv6 stack
> but only with IPv6 connectivity is ok. Did I miss something?

-d

---

From: <[email-masked]>
Date: Wed, 19 Jan 2011 13:55:10 +0100

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : jeudi 13 janvier 2011 18:20
À : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Francis Dupont'; 'Simon Perreault'
Cc : [email-masked]
Objet : client/server/symmetric [was RE: [pcp] PCP-base 02: Section 7.7]

...

Med: In theory yes; but in practice (let's say some of the deployment I know) the binding is updated by re-issuing frequent REGISTER messages. The re-registration rhythm is forced by the server side and not the SIP UA side. I'm sure you know that.

Med: Agree if the keepalive message is not the REGISTER message; otherwise see my answer above.

But please see below.

Med: I need to read the content of Sections 7.1.x ...

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Jan 2011 09:38:47 -0800

> Sent: Wednesday, January 19, 2011 4:55 AM
> Subject: RE: client/server/symmetric [was RE: [pcp] PCP-base 02:
> Section 7.7]
> 
> 
> Re-,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> Med: In theory yes; but in practice (let's say some of the deployment I
> know) the binding is updated by re-issuing frequent REGISTER messages.
> The re-registration rhythm is forced by the server side and not the SIP
> UA side. I'm sure you know that.

What happened to the SIP ideas of sending CRLF.CRLF, or to sending a
STUN message?  Those are both lighter weight than REGISTER.

In any event, the SIP specification needs a small change to add a phrase 
something like:  

    "Unless the SIP UA has reason to believe a less frequent 
     keepalive frequency is necessary to keep its NAT mapping alive 
     (e.g., [I-D.ietf-pcp-base]),"

immediately prior to its text that says the SIP proxy decides the
frequency of the NAT keepalive messages.

I see absolutely nothing PCP (the protocol itself) can here; this is
a problem entirely with one application (SIP) which will need to
take into account that PCP exists.

-d

---

From: <[email-masked]>
Date: Thu, 20 Jan 2011 08:20:40 +0100

Re-,

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 19 janvier 2011 18:39
À : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Francis Dupont'; 'Simon Perreault'
Cc : [email-masked]
Objet : RE: client/server/symmetric [was RE: [pcp] PCP-base 02: Section 7.7]

Med: I'm aware of non-SIP keepalive mechanisms. My point was when a SIP-based keepalive mechanism is used as what is described http://tools.ietf.org/html/rfc5853#section-3.4.

Med: But how the proxy is aware about this???

Med: I summarise again my position because I'm not sure I follow you here:

* PCP is another mechanism that can be used to ease the NAT traversal for SIP-based application, to avoid SIP-ALG or any procedure in the proxy side to assist establishing session when there is an NAT in the path, etc.

* the proxy server is not aware of the mechanism used to control the binding in the NAT; therefore some keepalive messages are required: these KA can be SIP-based or non-SIP-based. 

* if SIP-based KA are used, creating the mapping and then use the external IP/port in the SIP message is a hint for the proxy server to not force frequent registration.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 Jan 2011 08:28:12 -0800

...
> Med: I'm aware of non-SIP keepalive mechanisms. My point was when a
> SIP-based keepalive mechanism is used as what is described
> http://tools.ietf.org/html/rfc5853#section-3.4.

*Shrug*.  If there is a desire by the SIP UA and/or the SIP proxy
to reduce those keepalives to something that causes less pain
(less bandwidth, less processing power, whatever) -- those
implementations can do that already.  "CRLF.CRLF" is lighter 
weight, as is sending a STUN message on the same UDP ports.

> Med: But how the proxy is aware about this???

I don't know.  Ask on a SIP mailing list.

> * PCP is another mechanism that can be used to ease the NAT traversal
> for SIP-based application, to avoid SIP-ALG or any procedure in the
> proxy side to assist establishing session when there is an NAT in the
> path, etc.
> 
> * the proxy server is not aware of the mechanism used to control the
> binding in the NAT;

Agreed.

> therefore some keepalive messages are required:
> these KA can be SIP-based or non-SIP-based.

I do not agree with the "therefore some keepalive message are required".
That need is of the SIP proxy itself, and is not related WHATSOEVER
to PCP.

> * if SIP-based KA are used, creating the mapping and then use the
> external IP/port in the SIP message is a hint for the proxy server to
> not force frequent registration.

The SIP folks will have to take that up.

-d