Subject: [pcp] draft-wing-pcp-base-01 posted

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Oct 2010 18:09:03 -0700

I just posted http://tools.ietf.org/html/draft-wing-pcp-base-01 and
side-by-side diffs (which isn't terribly helpful due to moving sections
around) are at 
http://tools.ietf.org/rfcdiff?url2=draft-wing-pcp-base-01.txt

Significant changes:

 1. reorganization of the document, trying to put important things at
    the top (packet format, everybody loves talking bits and bytes)
    and less important things at the bottom (NAT-PMP backwards
    compatibility, UPnP IGD interworking)

 2. nested NAT:  added support for detecting a NAT between the PCP
    client and PCP server, using a STUN-like technique. Thanks to
    Mohamed for pointing out the flaw in an intermediate version.  See
    Section 7.4 and new information returned in Figure 7.

 3. cleanup: eliminated latent text from -00 that discussed S-bit,
    M-bit, and transaction-id when the text was slammed together for
    -00.  Much more of the text in -01 is now self-consistent. I
    expect astute readers will find places where it is not self-
    consistent.  Yes, some cleanup is still necessary.

 4. cleaner packet format: More clearly defined a common PCP
    request/response packet format (which contains just the version
    number, Opcode, and fields so we can return Epoch).  This will
    allows for cleaner creation of new OpCodes which won't need to
    follow the packet layout of the initially defined opcodes.
    Note, however, the on-the-wire packets are nearly identical to
    the previous version (major change to packet format was adding
    nested NAT detection).

issues:

  * The issues that have caused the most contention on the mailing
    list I have left in the document and tightened up their text.
    These are:
       -  Epoch (present in wing-pcp-base-00 and -01)
       -  Transaction-ID (not present in wing-pcp-base-00 or -01)
       -  Mandatory semantic (not present wing-pcp-base-00 or -01)

  * 17 issues are highlighted in the document itself with "Ed. Note:"
    Please review them and comment.

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Oct 2010 08:50:00 +0200

In your previous mail you wrote:

=> I'd like to get it in an IE because there are scenarios (DS-Lite
for instance) where there can't be a nested NAT.
   
   issues:

   
=> I believe we can add more, can't we?

Thanks

[email-masked]

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 08:51:36 +0200

Hi Dan, all,

I'm still not comfortable with the OpCodes defined in the document.

     PIN44 = 0 = IPv4 address to IPv4 address (NAT44 or IPv4 firewall)
     PIN46 = 1 = IPv4 address to IPv6 address (NAT46)
     PIN64 = 2 = IPv6 address to IPv4 address (NAT64)
     PIN66 = 3 = IPv6 address to IPv6 address (NAT66 or IPv6 firewall)

   For me, this supposes that the PCP Client has already determined
   "somehow" the capabilities of the PCP-controlled device prior to
   sending a request to the PCP Server.  In particular, the PCP Client
   has no means to determine the external IP address assigned by a PCP-
   controlled device without any pre-configuration or any "discovery".

   Moreover, I'm in favour of having explicit OpCodes such as the
   following:

   1.  Create PIN: to create a pinhole

   2.  Delete PIN: to delete a or a set of pinholes

   3.  Refresh PIN: to refresh a or a set of pinholes

   4.  List PIN: to list pinhole matching a filter

   5.  Get External IP Address: get the external IP address assigned by
       the PCP-controlled device. This is useful in various scenarios (in particular stateless NAT)

   6.  PING/PING:

       A.  assess the availability of the PCP Server

       B.  Retrieve the capabilities of the PCP Server

       C.  Retrieve a set of useful data such as mappings count, etc.

   7.  PCP Error

   A dedicated bit can be defined to precise whether this is a request
   or a response.

   The argument of consuming OpCode values is meaningless IMHO.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : mardi 26 octobre 2010 03:09
À : [email-masked]
Objet : [pcp] draft-wing-pcp-base-01 posted

Significant changes:

issues:

-d

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

*********************************
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: <[email-masked]>
Date: Tue, 26 Oct 2010 09:05:00 +0200

Hi Dan,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : mardi 26 octobre 2010 03:09
À : [email-masked]
Objet : [pcp] draft-wing-pcp-base-01 posted

   Med: Detecting a NAT is in the path is a useful functionality but I
   don't see a value to include it in all responses from the same PCP
   Server.  I have proposed in the past a dedicated IE to return the
   perceived IP address and perceived port number by the PCP Server
   whenever requested by the PCP Client (in particular in a dedicated PCP
   request or in the first PCP request received from a PCP Client,
   etc.).  Including systematically this information in all PCP
   Responses is not required/useful in various scenarios such as the
   control of DS-Lite CGN using a PCP Client embedded in the CP router
   and which acts as a UPnP IGD-PCP Interworking function.

   Note that other complications are to be covered for the nested NAT
   scenario such as how to determine the scope of PCP requests when PCP
   is used to control both a local NAT and the remote NAT, etc.

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 09:08:18 +0200

Hi Francis, 

Some comments inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : mardi 26 octobre 2010 08:50
À : Dan Wing
Cc : [email-masked]
Objet : Re: [pcp] draft-wing-pcp-base-01 posted

   

Med: Fully agreed.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Oct 2010 10:19:07 +0200

Even I don't agree with all the new opcodes proposed by Mohamed
IMHO we can't stay with only the create/renew/delete request
of base-01.

So +1

Regards

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 10:20:22 +0200

Hi Dan, all,

   When deployed in CGN context, specific error codes should be sent to
   the PCP Client.  As such, an Error Sub-Code is useful to
   provide more information about the encountered error.

   Below a list of error codes and associated sub-code errors.

   1.  Unsupported Version

   2.  Not Authorized.  One of the following error sub-codes must be
       indicated:

       1.  Administratively prohibited/Unknown subscriber ID

       2.  Unauthorised operation

       3.  The requested mapping does not exist

   3.  Out of resources

       1.  All available ports are in use

       2.  Unavailable bandwidth

   4.  Unsupported OpCode

   5.  Unsupported Transport Protocol

   6.  Per-subscriber resource limit exceeded

       1.  Static mapping quota exceeded

       2.  Ports quota exceeded

   7.  Parsing Error

       1.  Missing one or more mandatory IEs

       2.  Invalid mandatory IE

       3.  Invalid data field

   8.  Unknown

   It would be useful in the document to list in a table the events which trigger
   sending each of defined error code and sub-code.

   Cheers,

   Med

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 10:56:46 +0200

Re-,

   I thought the base PCP document focuses on basic functions; but I'm
   not sure IGD and NAT-PMP IWFs are part of that set.  These functions
   are to be discussed IMHO in dedicated document(s) whenever required.
   I know my position may be seen as biased because I'm author of
   https://datatracker.ietf.org/doc/draft-bpw-pcp-upnp-igd-interworking/
   which includes more information than what is in the pcp-base
   document.

   I'm not sure there is a justification for a PCP Server to send a NAT-
   PMP error message instead of returning a PCP Error message with a
   code error set to Unsupported version only for the backward
   compatibility with NAT-PMP.  What a NAT-PMP Client will do when it
   receives that error message, it will stop to send subsequent messages
   to the PCP Server?  Isn't it easier to use a distinct port number for
   PCP?

   With a distinct port number for PCP, there is not conflict between
   NAT-PMP and PCP.

   A NAT-PMP speaker which is upgraded to be PCP-speaker will
   know the PCP dedicated port.

   A NAT-PMP speaker which is not PCP-speaker won't never sent a NAT-PMP
   message to a PCP Server.

   In conclusion:

   o  I suggest IWFs are specified in dedicated documents whenever
      required.

   o  To avoid any interference with NAT-PMP, a dedicated port number to
      be assigned to PCP.

   Cheers,

   Med

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 11:26:10 +0200

Re-,

   In the draft you stated:

   "RTP and RTCP have historically run on adjacent ports, and some
   existing equipment still expects them to be on adjacent ports.  To
   accomodate that, a procedure can be used rather than adding
   complexity to the protocol or to the server implementation.

   The procedure is for the PCP client to bind to two ports on its local
   interface.  It then sends a PCP request for external port 0
   (indicating it will accept any port from the server) for one of those
   internal ports.  This request can have a short lifetime (e.g., 5
   seconds) to avoid the need to delete the pinhole.  It receives the
   PCP response indicating it now has external port N. The PCP client
   then attempts to obtain a port on either side of this external port.
   It sends two PCP requests, using the same internal port number in
   both requests, for external port N-1 and for external port N+1.  The
   adjacent external ports N-1 and N+1 are either (a) not available, (b)
   only one is available, or (c) both are available.  If (a), an
   unrelated port will be assigned and the procedure can be repeated.
   If (b) the procedure was successful.  Case (c) is also successful,
   because the PCP client cannot distinguish it from case (b), because
   the PCP server maps an specific internal IP address and internal port
   to a single external IP address and port.  "

   I don't agree this procedure is simple for the PCP Server compared to
   supporting a dedicated IE (Port Reservation Option IE).  From the NAT
   traversal perspective, supporting this IE by the PCP Server is by far
   optimal than embedding an ALG in the CGN or activating the Hosted NAT
   Traversal in the SBC.

   Furthermore, the procedure you proposed may add an extra delay for
   the establishment of RTP sessions.  This is not aligned with the
   real-time requirement to place for instance SIP calls over a CGN.
   Note that the process should be done for all media sessions (several
   audio streams can be in the same offer, video stream, etc.).  This
   means that several requests will be sent to the PCP Server; there is
   also a load impact on the PCP Server but I agree it is not easy to
   assess if we don't have an idea about the number of serviced PCP
   Clients requesting such feature.

   Below what I propose as alternative to your procedure:

   o  Define an IE called Port Reservation Option IE.  Several values
      can be included in that IE; in particular it may indicate whether
      the PCP Server has to preserve the contiguity when assigning
      external ports; Other value such us preserve parity can be defined;

   o  The requesting PCP Client indicates in its request the Port Reservation Option IE and
      (two) internal port numbers;

   o  The Server will check whether it can assign contiguous ports to
      that PCP Client and it returns the result in a response.

   When supported, this IE-based procedure

   o  Does not induce extra delay for establishing RTP sessions;

   o  PCP communication with the PCP Server is convergent and does not
      require re-sending the request;

   o  Can be justified if VoIP sessions need to cross a CGN.

   Cheers,

   Med

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Oct 2010 11:59:28 +0200

Many comments about base-01 (I suggest to not answer in one message!):

                     Pinhole Control Protocol (PCP)

=> the WG is Port Control Protocol?

   PCP Client:

         The network element that sends PCP requests to the PCP Server.
         This network element could be an application running on a host,
         embedded in the host's OS or libraries, or running on a network
         device (such as a customer premise router).

=> even if this is simple (the client is the entity which talks
directly with the server) this leaves no name for all the other
meanings of client, i.e., the terminology is incomplete.

   Mapping Types:

         There are three different ways to create mappings: dynamic
         (e.g., outgoing TCP SYN), PCP, and static configured (e.g., CLI
         or web page) .  These mappings are one and the same but their
         attributes such as lifetime or filtering might be different.

=> there is an ambiguity in the document about the term mapping
which is implicitely 'mapping managed by PCP'. IMHO it should be
better to use another term for this particular type of mappings.

         [Ed.  Note: For an IPv4 address, would the AFTR element's IPv4
         address, 192.0.0.1, be suitable as this address for DS-Lite
         deployments?

=> not if the plain mode is used (so the address is IPv6).

5.  Common Request and Response Header Format

   PCP is intended to be backwards compatible with NAT-PMP so that a
   NAT-PMP client (or server) will receive an error message when sending
   a request to a PCP server (or client).

=> request implies from client to server, i.e., the parentheses with
included texts should be removed.

   All PCP messages contain a request (or response) header, opcode-
   specific information, and (optional) informational elements.  These
   are described in the following sections.

=> here the parentheses only should be removed.

      [Ed.  Note: Do we want to allow an unsolicited IE to appear in a
      response?]

=> yes because it is the only way to carry information about an error.

5.4.  Result Codes

=> clearly the list is too short...

   Assigned external port:  requested external port for the mapping.

=> should be after the figure where it is used.

      of the requsted IP address).  Addition permission for multiple
             ^^^^^^^^

   successful, apositive response generated containing external port of
               ^^^^^^^^^

   0 and lifetime of 0.  If the deletion request was unsusccessful a
                                                     ^^^^^^^^^^^^^

      [Ed.  Note: Should we similarly return an error if attempting to
      delete mappings that were created dynamically (e.g., TCP SYN)?]

=> IMHO it is simpler (and safer) to write PCP can only delete
mappings it manages (so it created).

   When a mapping is destroyed as a result of its lifetime expiring or
   for any other reason, if the NAT gateway's internal state indicates
   that there are still active TCP connections traversing that now-
   defunct mapping, then the NAT gateway SHOULD send appropriately-
   constructed TCP RST (reset) packets both to the local client and to
   the remote peer on the Internet to terminate that TCP connection.

=> this is a specification for the NAT itself and has nothing to do
in this document (nor should be discussed by this WG, it is clearly
in the scope of BEHAVE).
I have a counter proposal: add a MAY (or SHOULD?) for the host
to close the corresponding service before the PF is deleted or expired.

   A client can request the explicit deletion of all its UDP or TCP
   mappings by sending the same deletion request to the NAT gateway with
   external port, internal port, and lifetime set to 0.

=> external port -> internal address

   mapping was manually configured by a configuration tooll, the gateway
                                                      ^^^^^

   RECOMMENDED lifetime assigned by the server is 7200 seconds (i.e.,
   two hours).

=> should be discussed (and not compatible with a further part).

   Nevertheless, a configurable feature MAY be supported by the PCP-
   controlled device, which MAY reserve (but not forward) the companion
   port so the same PCP Client can request it in the future.

=> is there still an application requiring this? If none we can get
rid of this extra complexity now.

9.  PCP Client Operation

=> I have still a concern about the architecture of the document:
as requests are sent by clients and response by servers it makes
no sense to have client and server operations after request
and response processing.
BTW the current result is the document is very to be sound.

   In order to prevent excessive PCP chatter, it is RECOMMENDED to renew
   only 60 seconds before expiration time (to account for

=> IMHO this is a pretty bad recommendation: what happens with
a network outage?

   To delete all pinholes for all ports, the "W" (wildcard) bit is set,
   and no internal port/external port is included in the PCP request.

=> still need some editing (:-).

   To delete all pinholes for all hosts associated with this subscriber,
   an all-zero internal IP address is used.

=> oops, subscriber is a free term (i.e., please define it in terminology)

10.1.  Relationship of PCP Server and its NAT

   The PCP server receives PCP requests.  The PCP server might be
   integrated within the NAT device (as shown in Figure 8) which is
   expected to be a common deployment.

=> IMHO this was at the beginning of the document and it is its
right place.

   It is NOT RECOMMENDED that the server allow long lifetimes (exceeding
   24 hours), because they will consume ports even if the internal host
   is no longer interested in receiving the traffic or no longer
   connected to the network.

=> in fact it depends of the usage on the home side, for instance
with an IWF for a web interface someone can (and shall) argue
infinite lifetimes are needed. I do go so far but IMHO it is
something in the control of the client so a point we should discuss.

   The PCP server SHOULD be configurable for permitted minimum and
   maximum lifetime, and the RECOMMENDED values are 120 seconds for the
   minimum value and 24 hours for the maximum.

=> I have no concern at all about the minimum.
BTW it should be of the same order than the 'hold down' timer
(so 120 seconds is good).

10.3.  Pinhole deletion

   In order to prevent another subscriber from receiving unwanted
   traffic, the PCP server SHOULD NOT assign that same external port to

=> I'd like to get a MUST NOT here.

   another host for 120 seconds (MSL, [RFC0793]).

=> the term 'host' is free (i.e., it MUST be defined in terminology).

      [Ed.  Note: it should (MUST?) allow the same host to re-acquire
      the same port, though.]

=> at least a SHOULD.

      source IPv6 prefix.  No per-user polices is pre-configured in the

=> polices -> policies?

   2.  Hosts behind the B4 element include a PCP Client, and communicate
       directly with the PCP server.  No interworking function is
       required to be embedded in the B4 element.

=> this is not true in with the plain mode

   Two modes are identified to forward PCP packets to a PCP Server
   controlling the provisioned AFTR as described in the following sub-
   sections.

      [Ed.  Note: We need to decide on Encapsulation Mode or Plain IPv6
      Mode.]

=> I'll have more than a concern if the Plain IPv6 Mode is removed.

12.  Adjacent Port Procedure

   RTP and RTCP have historically run on adjacent ports, and some
   existing equipment still expects them to be on adjacent ports.

=> I reread the RFC 4787 about this point and in fact it is not true:
the real problem is the SDP option to choose RTP and RTCP ports,
RFC 3605, is optional (and not yet universally deployed some years
ago).

   To accomodate that, a procedure can be used rather than adding
   complexity to the protocol or to the server implementation.

=> it would be fine if such a procedure were reasonable.

      [Ed.  Note: Add message flow diagram showing adjacent port
      procedure]

=> just write it is not supported.

13.  Interworking with UPnP IGD

   The following diagram shows how UPnP IGD can be interworked with PCP,
   using an interworking function (IWF).

=> as you read the new specs, is it something specified in case
of host/IWF reboot? For instance, is the IWF supposed to keep
state? to announce it lost its state?

   support UPnP IGD 2.0 (which has improved behavior, see Section 13.2)

=> I am happy the 2.o was adopted (now I haven't yet read it so
perhaps I shan't remain happy :-).

13.3.  Lifetime Maintenance

   UPnP IGD does not provide a lifetime, so the UPnP IGD/PCP
   interworking function is responsible for extending the lifetime of
   mappings that are still interesting to the UPnP IGD device.

      Note: It can be an implementation advantage, where possible, for
      the UPnP IGD/PCP interworking function to request a port mapping
      lifetime only while that client is active and connected.  For
      example, creating a PCP mapping that is equal to the client's
      remaining DHCP lifetime is one useful approach.  The UPnP IGD/PCP
      interworking function is responsible for renewing the PCP lifetime
      as necessary.  As long as client renews its DHCP lease, the PCP
      lifetime should also be extended.  For clients not using DHCP,
      other mechanisms to check on the client host's liveliness can also
      be useful (e.g., ping, ARP, or WiFi association) can be used to
      discern liveliness of the UPnP IGD control point.  However, it is
      NOT RECOMMENDED to attempt to connect to the TCP or UDP port
      opened on the control point to determine if the host still wants
      to receive packets; the server could be temporarily down when
      tested, causing a false negative.

=> I am not against garbage collection (I wrote papers on it) but
I prefer to be sure it is the intended behavior in UPnP IGD.
So where is it in specs? (I can't find something in 1.0 specs
and Reinaldo didn't get the time to present the last point
in the interim meeting agenda which could help me)

14.  NAT-PMP Backwards Compatibility

      [Ed.  Note: More analysis is necessary on NAT-PMP backward
      compatibility, including checking if NAT-PMP clients are compliant
      with [I-D.cheshire-nat-pmp]] regarding error handling.

=> misplaced closing ']'.

15.  Security Considerations

   [Ed.  Note: to be completed.]

=> I am afraid we can't go further without this section and
a more complete terminology (which I expect to be heavily used
in security stuff).
So at least I suggest to put efforts on this.

   [Ed.  Note: perhaps we can use the AFTR element's IPv4 address?  But
   still need an IPv6 address assigned for PIN64 and PIN66.]

=> and plain mode.

   New information elements in the range 0-127 can be created via
   Standards Action [RFC2434], new information elements in the range
   128-192 can be created with Expert Review [RFC2434], and the range
   193-255 is for Private Use [RFC2434].

=> it should be fine to have a mandatory bit here: with a defined
value of the bit in the type, the server must recognize the IE
or return an error (with a way to specify which IE).

Appendix A.  Analysis of Techniques to Discover PCP Server

      [[Ed.  Note: This Appendix will be removed in a later version of
      this document.  It is included here for reference and discussion
      purposes.]]

=> so it is another item in the discussion list (postponed as
it is not an intrinsic part of the protocol), isn't it?

Regards

PS: I have a concern about amnesiac clients, i.e., a client which
sends a request for a PF it already has:
 - there is a simple way to recognize them from renewals:
  the requested fields are filled with the right values in renewals
 - a way to recognize the PF is needed: I propose to use the internal
  address and port, i.e., the same fields than for a delete
 - so the issue is about what to do when the requested port is not
  the same and not zero (BTW this issue is in fact independent of
  the mandatory bit stuff: even with a hint we are in trouble):
  * return an error saying 'you should have lost your state'
   (and the state recovery will fix it)
  * return the already existing PF (IMHO not good at it can be
   something different from has been wanted)
  * delete the already existing PF and create a new one
   (IMHO very bad: likely not what has been wanted)
 - there is an extra case where the already existing PF is in hold down
  (IMHO in this case it should be ignored)
BTW some UPnP IGD clients are known to exhibit this behavior.

PPS: there is nothing in the specs at the exception of the subscriber ID
but the PCP server MAY implement quotas (per subscriber where this term
makes sense). So we need another error and perhaps a way to give the
quota limit value.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Oct 2010 12:23:29 +0200

the PCP Client.

=> even draft-woodyatt-spnatpmp-appl-01.txt adds new error codes
to the original NAT-PMP...

      As such, an Error Sub-Code is useful to
      provide more information about the encountered error.
   
=> in an IE? INHO the sub-code is better to give extra information
than to refine a code.

   

=> I can't see the difference.

=> I object if the operation is a delete (a valid and authorized
delete should always succeed).

      3.  Out of resources
   
          2.  Unavailable bandwidth
   
=> I don't understand it

=> yes, this is clearly a missing one.

   
          2.  Ports quota exceeded
   
=> as I *really* prefer PCP manages only its own PFs INHO only the
code is needed.

      7.  Parsing Error

=> please define 'mandatory' here

      8.  Unknown
   
=> i.e., a wildcard code (I prefer 'illegal error', it gives no more info
but at least it is funny :-)?

=> BTW I propose a 'poor client, you should have lost your state' code too.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Oct 2010 12:30:08 +0200

I thought the base PCP document focuses on basic functions; but I'm
      not sure IGD and NAT-PMP IWFs are part of that set.

=> these sections are marked as to be reworked/deleted/moved.

      I'm not sure there is a justification for a PCP Server to send a NAT-
      PMP error message instead of returning a PCP Error message with a
      code error set to Unsupported version only for the backward
      compatibility with NAT-PMP.

=> the only extension device in NAT-PMP is the version so if we don't
use it there is no other reason to copy something from NAT-PMP...
(this includes the sharing of the port of course)

      What a NAT-PMP Client will do when it
      receives that error message, it will stop to send subsequent messages
      to the PCP Server?

=> I expect this: it is clearly a fatal error.
   
Regards

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 13:16:57 +0200

Hi Francis,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mardi 26 octobre 2010 12:23
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Dan Wing; [email-masked]
Objet : Re: [pcp] On the need of Error Codes/Sub-codes (was RE: draft-wing-pcp-base-01 posted) 

   

Med: Don't care at stage about the encoding. We need first to agree this is required and then see how to encode it. But, I agree with you comment about the sub-code.

   

Med: The first sub-code will be returned for a blacklisted subscriber or an unknown user. The second sub-code for an authorised subscriber but which does not have right to do a given operation (e.g., send a request to assess the availability of the Server, send a request to retrieve the capabilities of the PCP Server, etc.).

Med: This sub-code can be used for delete or refresh operations.

      3.  Out of resources
   
          2.  Unavailable bandwidth
   
=> I don't understand it

Med: Imagine the use of PCP in a RSVP-like fashion to pre-reserve BW for a given incoming stream (VoD crossing CGN for instance). 

   
   
          2.  Ports quota exceeded

Med: Several quotas can be defined per-subscriber: port quota which cover both dynamic and PCP-instructed one; and static port mappings as those instructed by PCP.

      7.  Parsing Error

Med: By mandatory I meant that the request fails if the IE is not met; let consider the example of DSCP marking. A request is considered successful if the DSCP marking is accepted by the PCP Server; otherwise an error is returned. I agree with you this needs further explanation.

      8.  Unknown

Med: Works for me.

Med: Isn't similar to "The requested mapping does not exist" above? Or are you referring to another use case?

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 26 Oct 2010 04:27:37 -0700

I have also echoed similar sentiment in a personal email to Dan. This is
what I said

"I am wondering if we cannot design a message to request n ports from a
PCP server.While n can be administratively controlled based on
subscriber policy rules, n is typically 2. Most NAT implementations have
this inherent capability for supporting ALGs. It is a processing
headache/pain - but if the port space is fragmented, it would take
several port = 0, messages before communication could be established and
the latency involved may not be tolerated by the application. Actually,
it is easy for the PCP/NAT to scan the ports that are contiguously free
compared to the n messages that would have to be received and processed
by PCP/NAT."

Senthil

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, October 26, 2010 5:26 AM
To: Dan Wing (dwing); [email-masked]
Subject: [pcp] Port contiguity (was RE: draft-wing-pcp-base-01 posted)

Re-,

   In the draft you stated:

   o  Define an IE called Port Reservation Option IE.  Several values
      can be included in that IE; in particular it may indicate whether
      the PCP Server has to preserve the contiguity when assigning
      external ports; Other value such us preserve parity can be
defined;

   o  The requesting PCP Client indicates in its request the Port
Reservation Option IE and
      (two) internal port numbers;

   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: <[email-masked]>
Date: Tue, 26 Oct 2010 13:37:18 +0200

Re-,

See inline.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francis Dupont
Envoyé : mardi 26 octobre 2010 11:59
À : Dan Wing
Cc : [email-masked]
Objet : Re: [pcp] draft-wing-pcp-base-01 posted

   PCP Client:

Med: What about the following definition:

"X.Y.  PCP Client

   A PCP software instance responsible for issuing PCP requests to a PCP
   Server.  One or several PCP Clients can be embedded in the same host.
   Several PCP Clients can be located in the same local network of a given subscriber.  A PCP
   Client can issue PCP request on behalf of a third party device of the
   same subscriber."
*********************************
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: <[email-masked]>
Date: Tue, 26 Oct 2010 13:53:32 +0200

Hi Senthil,

We are in full agreement.

PCP is a good candidate to ease the NAT traversal for SIP. Unlike keepalive procedure or STUN, PCP does not overload the NAT and the first service element (SBC, P-CSCF). Few PCP messages will be sufficient for establishing a session. In some deployments "a=rtcp" attribute is not supported and therefore, the ability to allocate pair of contiguous ports to requesting PCP Clients is valuable.

As for the encoding, what is needed is to allow several internal ports to be inserted in the same request (see the example below) and define the Port Reservation Option IE (see below).

     +-+-+-+
     |Index:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     : Internal Port                 | Hinted   External  Port       :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     : Internal Port                 | Hinted   External  Port       :
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"X.x. Port Reservation Option IE

   Some applications (e.g., RTP and RTCP) may require two contiguous
   port numbers.  PCP supports such feature owing to the use of the Port
   Reservation Option IE).

   The following values are supported:

   o  00: None.  This value is defined only for completeness.  When the
      Port Reservation Option value is equal to 00, the Port Reservation
      Option IE MUST NOT be included in a PCP request;

   o  01: Preserve parity;

   o  02: Preserve contiguity."

Cheers,
Med

-----Message d'origine-----
De : Senthil Sivakumar (ssenthil) [mailto:[email-masked]] 
Envoyé : mardi 26 octobre 2010 13:28
À : BOUCADAIR Mohamed NCPI/NAD/TIP; Dan Wing (dwing); [email-masked]
Objet : RE: [pcp] Port contiguity (was RE: draft-wing-pcp-base-01 posted)

Senthil

-----Original Message-----

Re-,

   In the draft you stated:

   Cheers,

   Med

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 14:19:50 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : mardi 26 octobre 2010 12:30
À : BOUCADAIR Mohamed NCPI/NAD/TIP
Cc : Dan Wing; [email-masked]
Objet : Re: [pcp] IWF & PCP Port Number (was RE: draft-wing-pcp-base-01 posted) 

Med: Are saying we don't to re-use the NAT-PMP port? 

Med: Yes, me too. This is why I think the simplest solution is to avoid a NAT-PMP client to send its request to a PCP Server. We avoid even to receive the message and send back an error.

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 15:20:31 +0200

Re-,

There is another case where care should be taken to guess there is a NAT in the path using the proposed procedure: if the IPv6 plain mode for relying PCP messages to the PCP Server is used in DS-Lite, the perceived IP address will be distinct than the one indicated in the internal IP address while there is no NAT in the path.

The PCP Proxy in B4 should remove that information or update it accordingly.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mardi 26 octobre 2010 09:05
À : Dan Wing; [email-masked]
Objet : [pcp] Detect an on-path NAT (was RE: draft-wing-pcp-base-01 posted)

Hi Dan,

Please see inline.

Cheers,
Med

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 08:04:03 -0700

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 25, 2010 11:50 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: [pcp] draft-wing-pcp-base-01 posted
> 
> 

Customer buys an 802.11N WiFi access point with a spiffy built-in
NAS (two vendors sell such a thing).  Places it behind their DS-Lite
gateway.  Boom -- customer has a NAT with DS-Lite.

We want PCP to work all the time, and to detect failures.

> => I believe we can add more, can't we?

Yes, of course.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 08:11:55 -0700

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, October 25, 2010 11:52 PM
> To: Dan Wing; [email-masked]
> Subject: OpCopdes (RE: [pcp] draft-wing-pcp-base-01 posted)
> 
> Hi Dan, all,
> 
>    sending a request to the PCP Server. 

I disagree.  Let's say I join a never-before-seen network.  I don't
know if it supports TCP (but I bet it does).  I don't know if it
supports SCTP (will it?).  I don't know if it supports PCP.  I
don't know if there is a firewall, NAT44, NAT64, NAT46, or NAT66
on the network.

I could run a procedure to ask the network its capabilities.  Or
I could send a TCP, SCTP, or PCP packet, trying to do my real
work of initiating a TCP session, SCTP session, or a PCP 
mapping.

If the network cannot do TCP, SCTP, or PCP, I will get a 
network error (ICMP maybe) or timeout.  Or, if the remote host 
can't, I'll get a host error (TCP RST, PCP error, ICMP) or
a timeout.

I don't see a problem so far.

Back to PCP, let's say the NAT in my home does what it does
today (NAPT44) and let's say it supports PCP.  I send it
a PCP request for PIN46.  It can't do IPv6 at all, so will 
return PCP error.  If I send it a PCP request for PIN44,
it can process that successfull.

That works for me.  What else is needed?

> In particular, the PCP Client

It doesn't need to.  The following exists in -01, and looking at it now 
it's in a poor location, but 

      If the PCP client doesn't know the external address,
      or doesn't have a preference, it MAY place any value into this
      field including 0.  If the Pinhole Internal IP Address equals the
      Requested External IP Address, it indicates the PCP client wants
      firewall (versus NAT) behavior.

>    3.  Refresh PIN: to refresh a or a set of pinholes

Stuart explained in an email last week the value of using the
exact same message for create and refresh.

I don't have a strong opinion on separate opcode for delete,
but I don't see how lifetime=0 is unclear, such that lifetime=0
could be confused or confusing to an implementor.

> (in particular stateless NAT)

But that forces binding state to be maintained on a stateful NAT.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 26 Oct 2010 11:23:16 -0400

I think it is interesting to deal with the case where the same NAT supports
NAT46 and NAT44. The PCP Server inside the NAT Gateway is the same but can
answer and process both types of PCP client requests that generate different
mappings.

But PCP Clients behind interface A only need NAT44 and those behind
interface B only need NAT46.  Arguably they could be behind the same
interface.

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 17:42:44 +0200

Re-,

Please see inline

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 26 octobre 2010 17:12
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: OpCopdes (RE: [pcp] draft-wing-pcp-base-01 posted)

Med: Concretely, at bootstrap of a PCP Client, what is supposed to do? Try all PINxy until it found the one supported by the PCP Server? There are also other scenarios in which with ne create mapping you need to open a pinhole in the firewall (let say IPv6 FW) and in the NAT64 which may be co-located or separated. The same example applies also for an IPv6 firewall in the CPE, an IPv4 firewall and a NAT (case of the DS-Lite). Which opcode to use? 

Med: I'm afraid to say no from my side.

Med: I'm not talking about the external IP address as a filed; but how the PCP Client can know I need to send PINxy?!

Med: the message format may be the same; but a refresh message is to be distinguished than a new request. 

Med: I don't think this has a cost for always-on subscribers (i.e., outbound traffic) and if some pinholes have been already instructed by that PCP Client. Retrieving the external IP address is useful in referral for instance.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 08:48:12 -0700

> From: Senthil Sivakumar (ssenthil) [mailto:[email-masked]]
> Sent: Tuesday, October 26, 2010 4:28 AM
> To: [email-masked]; Dan Wing (dwing);
> [email-masked]
> Subject: RE: [pcp] Port contiguity (was RE: draft-wing-pcp-base-01
> posted)
> 

Can anyone name a protocol, other than RTP/RTCP, which needs adjacent
ports?  That is, how significant a problem is this that we need to
add support in all PCP servers and the on-the-wire protocol.  

The PCP server can implement the following procedure, today, if it
desires.  This procedure provides the desired behavior and reduces
the round-trips to find adjacent ports:

On receiving a PCP request, the PCP server can choose a free port N
where N+1 is also free.  PCP server can put N+1 on the hold queue
for MMMM seconds; let's call it 5 seconds.

-d

---

From: <[email-masked]>
Date: Tue, 26 Oct 2010 17:56:42 +0200

Re-,

See inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 26 octobre 2010 17:48
À : 'Senthil Sivakumar (ssenthil)'; BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: [pcp] Port contiguity (was RE: draft-wing-pcp-base-01 posted)

ports?  

Med: The issue is not quantitative IMHO; there is a valid use case for using PCP for the NAT traversal. Having that feature supported by PCP is by far simpler than ALG and all the hooks to solve the traversal issue in the CGN.

That is, how significant a problem is this that we need to
add support in all PCP servers and the on-the-wire protocol.  

Med: Unlike STUN, if PCP allows to reserve in a simplest way a pair of ports, PCP can be of great value if VoIP flows for instance are to cross a CGN. This has an advantage of reducing the load on both the CGN and the service node (e.g., SBC) and no frequent refresh is needed. No extra delay is induced for placing the calls, its. 

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 26 Oct 2010 23:27:45 +0200

Med: The first sub-code will be returned for a blacklisted
   subscriber or an unknown user. The second sub-code for an
   authorised subscriber but which does not have right to do a given
   operation (e.g., send a request to assess the availability of the
   Server, send a request to retrieve the capabilities of the PCP
   Server, etc.).
   
=> as the only defined operations are create and delete I understand
why I couldn't see a difference.

   
   
=> there is no independent refresh so it is not possible to
get a different behavior. About delete I maintain my objection.

         3.  Out of resources
             2.  Unavailable bandwidth

   => I don't understand it
   
   Med: Imagine the use of PCP in a RSVP-like fashion to pre-reserve
   BW for a given incoming stream (VoD crossing CGN for instance).
   
=> this is not defined so there should not be an error for it yet.

   Med: Several quotas can be defined per-subscriber: port quota which
   cover both dynamic and PCP-instructed one; and static port
   mappings as those instructed by PCP.
   
=> I prefer to have a quota dedicated to objects PCP can create
and to not disturb PCP with activity it doesn't control.

   Med: By mandatory I meant that the request fails if the IE is not
   met; let consider the example of DSCP marking. A request is
   considered successful if the DSCP marking is accepted by the PCP
   Server; otherwise an error is returned. I agree with you this
   needs further explanation.
   
=> it is the mandatory bit applied to IEs.

   Med: Isn't similar to "The requested mapping does not exist" above?
   Or are you referring to another use case?

=> the amnesiac client use case (cf a preceeding message).

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 14:35:36 -0700

> Med: The issue is not quantitative IMHO;

Yes, it is. 

For RTP/RTCP, we know we need two adjacent ports.  If there is another
protocol that needs two adjacent ports, that's great.  However, if
there is another protocol that needs three (or four or five) adjacent
ports, then we would need to figure out how well / poorly it would
work.

Perhaps an IE, called something like ONE_ADJACENT_PORT, would do the
trick, allowing the PCP server to find two ports that are adjacent
to each other and put the second one on a ~5 second hold queue.

But I don't know if that would do the trick if there are other
legacy protocols floating around that need 6 or 7 adjacent ports....?

-d

> there is a valid use case for
> using PCP for the NAT traversal. Having that feature supported by PCP
> is by far simpler than ALG and all the hooks to solve the traversal
> issue in the CGN.
> 
> Med: Unlike STUN, if PCP allows to reserve in a simplest way a pair of
> ports, PCP can be of great value if VoIP flows for instance are to
> cross a CGN. This has an advantage of reducing the load on both the CGN
> and the service node (e.g., SBC) and no frequent refresh is needed. No
> extra delay is induced for placing the calls, its.
>

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 2010 00:00:47 +0200

Please note that requesting two ports at the same time is not the same
thing than requesting to contiguous ports.

PS: we should first check if we can get rid of this contiguous port
nightmare, if not it should be indicated by a dedicated and optional IE.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 2010 00:07:09 +0200

(Med)

   
=> what I said is either we use the version extension device in
NAT-PMP or we split completely NAT-PMP and PCP, and in the second
cas of course PCP should use another port.

         (Med) What a NAT-PMP Client will do when it
         receives that error message, it will stop to send subsequent messages
         to the PCP Server?

   Med: Yes, me too. This is why I think the simplest solution is to
   avoid a N AT-PMP client to send its request to a PCP Server. We
   avoid even to receive the message and send back an error.
   
=> you can ask the chairs whether PCP should be a NAT-PMP extension
or a standalone protocol. As far as I know the question was never
asked publicly...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 2010 00:29:58 +0200

> for instance) where there can't be a nested NAT.
   
=> note I got some support for the IE, including the person who
asked for nested NAT detection.

   gateway.

=> silly but this exists (I had to hack a bit the config of
new Apple AirPort Extreme to remove the NAT). Note this is a static
condition so it should be enough to check once.

   Boom -- customer has a NAT with DS-Lite.
   
=> a NAT which can be detected by the B4 but not by the PCP server
in the AFTR if Plain IPv6 Mode is used.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 2010 00:44:26 +0200

>      PIN66 = 3 = IPv6 address to IPv6 address (NAT66 or IPv6 firewall)

=> BTW these are not opcodes but IP versions: I prefer the old
IP version bits which leave a place for 'real' opcodes.

=> a place for extensions.

=> I can't see how it answers to Mohamed's question which is not
about whether the external address is needed but how to get it.

=> BTW I don't believe it is a good idea: we want for a firewall
pinhole to be able specify the external (destination in the client to
Internet way) address and ports. This consumes a whole address field
for an information which stands in one bit.
I propose to add a NAT vs firewall bit in the opcode field and
for firewalls to reuse the external address and port fields for
the 'destination', with 0 for wildcards as usual.

   
=> I can't see why? BTW this is supported by NAT-PMP which was designed
for stateless NATs.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 2010 00:54:59 +0200

=> this is even not true: RTP and RTCP don't need adjacent ports,
only broken but still conformant SDP implementations don't know
how to negociate RTP and RTCP ports (cf RFC 3605).

=> I propose to consider it as not significant until we get the
proof of the opposite.

=> could work but I know something which is called fragmentation.

Regards

PS: with other words my proposal is to ley people who want adjacent
ports to spend time to convince us it is needed, and no longer spend
our time to solve a problem without a proof it has to be solved.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 26 Oct 2010 21:40:28 -0400

Just to throw some fat in the fire, I'll remind you that SDP also allows 
a session description to specify a sequence of contiguous multicast 
addresses. How is someone going to request pinholes for that?

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 19:34:47 -0700

> From: Tom Taylor [mailto:[email-masked]]
> Sent: Tuesday, October 26, 2010 6:40 PM
> To: Francis Dupont
> Cc: Dan Wing; [email-masked]
> Subject: Re: [pcp] Port contiguity (was RE: draft-wing-pcp-base-01
> posted)
> 

Sending IGMP/MLD to join the group.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 20:02:36 -0700

>    Server. 

I struggled with how to encode this while I was writing it up.  
Originally I had a separate OpCode.  

However, some hosts and some applications cannot detect when
they move to a new network.  And the IETF has been notoriously
wrong in how and where NAT and NAPT devices will be deployed.

> I have proposed in the past a dedicated IE to return the

But if the PCP client is in the host, we need NAT discovery from
the host all the way to the PCP server.  And the user could have
installed a 802.11 wifi NAT device in their home -- we need PCP
to detect that NAT device.

>    is used to control both a local NAT and the remote NAT, etc.

Yes, that text needs to be added.

My thinking is that if the local NAT supports PCP, it takes full
responsibility for communicating upstream to the next level NAT
that runs PCP.

And if the local NAT doesn't support PCP, the host (PC or whatever)
takes responsibility for communicating with the upstream PCP
server and takes responsibility for doing one of [UPnP IGD/NAT-
PMP/screen scraping/display error] with the NAT on the LAN.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 20:08:45 -0700

Agreed we need more detailed error codes.  We should also split the errors 
into "fatal, don't retry that again" (like the 5xx response codes of SMTP or
the
'hard errors' from ICMP) and "fatal, but maybe later" (like the 4xx response

codes of SMTP or the 'soft errors' of ICMP).  This allows extending the 
error codes into more meaningful values.  Based on this, the PCP client
could give up forever, or could give up for ~10 minutes.  With our number 
space, something like 0-127 could be "fatal, don't try again" and 
128-255 could be "fatal, maybe later".

-d

> Sent: Tuesday, October 26, 2010 1:20 AM
> Subject: On the need of Error Codes/Sub-codes (was RE: [pcp] draft-
> wing-pcp-base-01 posted)
> 
> Hi Dan, all,
>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 20:13:05 -0700

> Sent: Tuesday, October 26, 2010 1:57 AM
> Subject: IWF & PCP Port Number (was RE: [pcp] draft-wing-pcp-base-01
> posted)
> 
> Re-,
> 

There is more detail necessary to describe UPnP IGD interworking,
such as how UPnP IGD's add/delete actions are mapped to PCP.  

>    receives that error message, it will stop to send subsequent

Dunno.  that's why the NAT-PMP Compatibility section (Section 14)
ends with:

     "[Ed.  Note: More analysis is necessary on NAT-PMP backward
      compatibility, including checking if NAT-PMP clients are compliant
      with [I-D.cheshire-nat-pmp]] regarding error handling."

>  Isn't it easier to use a distinct port number
>  for  PCP?

Sure, we can do that, too.  A device that supports NAT-PMP today
can continue listening on the NAT-PMP port, and PCP could get its
own new port from IANA.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 20:32:11 -0700

> Sent: Tuesday, October 26, 2010 2:26 AM
> Subject: Port contiguity (was RE: [pcp] draft-wing-pcp-base-01 posted)
> 
> Re-,
> 
>    In the draft you stated:
> 

Good point.

However, anyone truly worried about additional delay will pre-allocate 
their two adjacent ports immediately upon initialization of their 
device.

But I do share your concern that we should not make require such
pre-allocation, as it attracts scan traffic which could deplete
a battery (for example).

>       external ports; Other value such us preserve parity can be

You're right, I missed the port parity problem; legacy RTP likes being
on an even port with RTCP being RTP+1.  Thanks.

>    o  Can be justified if VoIP sessions need to cross a CGN.

How is this:

  1. define new IE, EVEN_PLUS_ONE, which has no payload.

  2. PCP request is sent, with that IE.  

  3. PCP server attempts to allocate an even port number, and 
    PCP server reserves the adjacent port number (sticks it 
    on the TIME_WAIT queue for 5 seconds, and it is only allocatable
    to the same IP address as got the even port number).

    Maybe we have PCP server return an IE EVEN_PLUS_ONE if it 
    was able to allocate the adjacent port.  That seems helpful
    for the next steps.

  4. VoIP endpoint can send its SIP/SDP message now.  Total
     delay: one round trip to PCP server.

  5. A second PCP request is sent, without the IE, requesting 
     port+1.

If PCP server cannot allocate an even port, it returns an 
odd port; afterall, the PCP client wants to communicate and
it might be able to use the odd port.  If it can't use it, 
the PCP client can Delete the port and show an error to 
the user.  The inability to provide an even port would be
an exceptional case, I expect -- a *very* busy NAT.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 20:45:23 -0700

> Sent: Tuesday, October 26, 2010 3:44 PM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]
> Subject: Re: [pcp] OpCopdes (RE: draft-wing-pcp-base-01 posted)
> 
> 

On a large-scale NAPT with a pool of IPv4 addresses, the answer
of which public IPv4 address you have will depend on when you
establish your first mapping.  Once a mapping is established,
all subsequent mappings will be on that same IPv4 address.  Once
all the mappings expire, a subsequent mapping will maybe be
to a different IPv4 address -- entirely dependent on how the
large-scale NAPT device chooses which public IPv4 address to
assign.  

So, to answer that question:  create a mapping.

If the question is "how do I tell if I'm behind a NAPT or
a stateless NAT" -- do we need to do that?  The only
advantage I see is reducing PCP messages.  That is, if a 
host discovers or determines it is on a network with 
a stateless NAT (what I mean is a NAT where UDP and TCP 
ports aren't rewritten, but IP addresses are rewritten),
it would know its UDP/TCP ports won't be changed and thus
doesn't need to send PCP mapping requests to the PCP
server.

If that is the reason, I vote we punt and don't solve
it now.  It's an optimization.  The protocol works without
that optimization.

If there is a different reason, let's hear it.

> the 'destination', with 0 for wildcards as usual.

Ok, that's one way to do it.  I would lay that out differently
in the I-D, but it will lay out the same in a struct and
on the wire.

>    >        the PCP-controlled device. This is useful in various
> scenarios
>    > (in particular stateless NAT)
> 

Yes, that's true.  The difference is the NATs used by NAT-PMP 
don't have a pool of public IPv4 addresses; rather, they had just
one public IPv4 address (because they are residential NATs).  

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 20:50:59 -0700

> how to negociate RTP and RTCP ports (cf RFC 3605).

Yes, and there is also RTP/RTCP muxing (RFC5761), which is even 
better than RFC3605 to ease NAT traversal.

But my H.323 experts tell me that still-shipping H.323 
implementations (by Cisco and other vendors) have not done 
something like RFC3605 and still expect even/odd.

If those H.323 endpoints are updated to do PCP -- which let's 
assume is possible -- those H.323 endpoints won't know if the 
remote endpoint they are calling still needs even/odd ports
or if it could handle some new H.323 RFC3605-like thing or
could do RFC5761.

> => could work but I know something which is called fragmentation.

Filled in 5.0001 seconds by the next outgoing UDP packet for 
some UDP-based protocol (DNS, NTP, yadda yadda).

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Oct 2010 21:07:14 -0700

> There is another case where care should be taken to guess there is a
> NAT in the path using the proposed procedure: if the IPv6 plain mode
> for relying PCP messages to the PCP Server is used in DS-Lite, the
> perceived IP address will be distinct than the one indicated in the
> internal IP address while there is no NAT in the path.
> 

The DS-Lite text in Section 11 of draft-wing-pcp-base-01 came
from draft-softwire-wing-port-control-protocol-02, and I think
was written by you.

Plain IPv6 Mode requires a PCP proxy function in the B4 element.  I
agree the B4 element, being a proxy, has to Do The Right Thing.

But I don't know the advantage of Plain IPv6 Mode, and the text
doesn't say.  What is the advantage?

There is an "Ed. Note" that says:

I copied the text into this email for everyone else's benefit.

-d

-----

http://tools.ietf.org/html/draft-wing-pcp-base-01#section-11.1.2

11.1.2. Encapsulation Mode

   In this mode, B4 element does no processing at all of the PCP
   messages, and forwards them as any other UDP traffic.  With DS-Lite,
   this means that IPv4 PCP messages issued by internal PCP Clients are
   encapsulated into the IPv6 tunnel sent to the AFTR as for any other
   IPv4 packets.  The AFTR decapsulates the IPv4 packets and processes
   the PCP requests (because the destination IPv4 address points to the
   PCP Server embedded in the AFTR).

11.1.3. Plain IPv6 Mode

   Another alternative for deployment of PCP in a DS-Lite context is to
   rely on a PCP Proxy in the B4 element.  Protocol exchanges between
   the PCP Proxy and the PCP Server are conveyed using plain IPv6 (no
   tunnelling is used).  Nevertheless, the IPv6 address used as source
   address by the PCP Proxy MUST be the same as the one used by the B4
   element.

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 07:27:51 +0200

Hi Reinaldo,

The question of having several functions controlled by the same PCP Server is a little bit more complicated. For instance a PCP Client asking for opening incoming pinholes on the PCP-controlled device, does it require to send a bunch of request to control all the embedded functions or it has just to send a request to the PCP Server and it is up to him to configure appropriately policies and pinholes for each function? To be concrete: let consider a DS-Lite CP with an embedded IPv6 firewall, IPv4 firewall and a remote PCP Server embedded in the CGN. The configuration of a single pinhole will require to control various function: IPv6 firewall for the B4 tunnel (this is not required for each operation), IPv4 firewall and the remote NAT.  

Note that can be useful for a PCP Client to retrieve the capabilities of the PCP-controlled device and therefore target the functionality(ies) it invokes.  

Cheers,
Med

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 07:53:52 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 05:03
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: Detect an on-path NAT (was RE: [pcp] draft-wing-pcp-base-01 posted)

Med: An option would be as follows:

* Initialisation of the PCP Client
* Discovery of the PCP Server (or pre-configuration)
* Issues PING request to the discovered servr(s) to retrieve the capabilities of the server (and also to assess the availability of the PCP service)
* Upon receipt of the PING request the server returns back its capabilities, the perceived IP/port, and other information.
* For the remaining, PCP operations remain the same.

Or 
* When issuing its first request to the PCP Server, the PCP Client includes an IE to request the server to answer back with the perceived IP/port.

Med: There is a value to detect the path; but there is no need to do it in all messages.

Med: Note that in some scenarios the function controlled locally is not the same as the one embedded in another upstream device: local IPv6 firewall and remote  NAT64 for instance. We need to see those cases also.

-d

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 08:01:45 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 06:07
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : PCP DS-Lite Encapsulation Mode [was RE: [pcp] Detect an on-path NAT (was RE: draft-wing-pcp-base-01 posted)]

Med: The main advantage I saw in the plain mode is there is no need for an encap/decap function in the PCP Server side. The encap/decap in the CPE is also avoided in case a PCP Client is embedded in the CPE itself.

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 08:16:03 +0200

Re-,

See inline.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 26 octobre 2010 23:36
À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Senthil Sivakumar (ssenthil)'; [email-masked]
Objet : RE: [pcp] Port contiguity (was RE: draft-wing-pcp-base-01 posted)

Yes, it is. 

Med: I'm not aware of any protocol requesting for more than 2 contiguous ports. Of course, there are cases where PCP can be used to offer A+P to bypass the NAT  and a range of ports (contiguous or not) can be delegated to the requested; but this is not the case I'm discussing in this thread. Defining an IE to ask for a pair of ports is pragmatic because it solves a real problem: NAT traversal for RTP/RTCP and no more than that.

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 08:18:29 +0200

Re-,

What I'm asking for as the ability to retrieve in one single request a pair of ports.

The range of port is limited to two in the case we are discussing.

Of course it is not mandatory that any PCP Server supports this IE.

Cheers,
Med

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 08:32:40 +0200

Re-,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 05:32
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: Port contiguity (was RE: [pcp] draft-wing-pcp-base-01 posted)

Good point.

Med: This can be an option, but you don't known in advance all the sessions that you will establish: several audio sessions, several video sessions, etc.

How is this:

Med: I still we can avoid some extra exchanges with the server (for instance in your bullet 5, you will need to do it for all the media you are negotiating including audio, video, etc.). Having an explicit indication from the PCP Client (preserve parity and request for pair) in one single request seems to me simpler. 

Med: At least for the CGN case, the implementations we tested support the ability to allocate pairs of ports for a new binding. Returning the pair of port by PCP may not be so that complicated IMHO.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 2010 09:43:54 +0200

BTW there is a problem with this NAT detection: it detects the presence
of at least a NAT on the path but doesn't say where it is or if
there is more than one NAT. In deep NAT hierarchy it can be fooled
by accident too (i.e., the composition of many translations can be
the identity).

So I prefer we put the case of multiple NATs out of scope until
it is explicitely added to the charter. BTW I don't know how
the correctly handle NAT444, in particular if I reuse your Wifi
NAT-router case.

I am still in favor of an optional (so in an IE) NAT detection
as Mohamed initially proposed.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 00:57:38 -0700

...
> * Issues PING request to the discovered servr(s) to retrieve the
> capabilities of the server (and also to assess the availability of the
> PCP service)
> * Upon receipt of the PING request the server returns back its
> capabilities, the perceived IP/port, and other information.
> * When issuing its first request to the PCP Server, the PCP Client
> includes an IE to request the server to answer back with the perceived
> IP/port.

That may work.  I'll think about this some more for -02.

...
> Med: Note that in some scenarios the function controlled locally is not
> the same as the one embedded in another upstream device: local IPv6
> firewall and remote  NAT64 for instance. We need to see those cases
> also.

Good point.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 00:59:45 -0700

...
> Med: The main advantage I saw in the plain mode is there is no need for
> an encap/decap function in the PCP Server side. The encap/decap in the
> CPE is also avoided in case a PCP Client is embedded in the CPE itself.

The AFTR element is doing encap/decap for hundreds of thousands of
packets per second (traffic destined to the IPv4 Internet), and the
B4 element is doing encap/decap for all of the subscriber's IPv4 
traffic (perhaps 100 packets per second or whatever).   So avoiding
the encap/decap of PCP chatter can't be a performance savings.  Is
there some other value?

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Oct 2010 10:01:06 +0200

=> yes but this has some advantages too (to be able to detect a
spurious NAT in the home network for instance :-).

=> the Plain IPv6 Mode is the natural way to go when the PCP server
is implemented in the control plane (Figure 9 in 10.1 of base-01)
(think about routers where the forwarding plane is implemented
in ASICs). The Encapsulation Mode requires an ALG.

I have no concern about the Encapsulation Mode but I'll have
a strong one if the Plain IPv6 Mode is removed.

Regards

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 10:06:04 +0200

Re-, 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 10:00
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: PCP DS-Lite Encapsulation Mode [was RE: [pcp] Detect an on-path NAT (was RE: draft-wing-pcp-base-01 posted)]

...

Med: If you have the same PCP Server which controls both an DS-Lite CGN and NAT64 (outsourced case), there might be a value but I'm not sure if the gain is significant or not.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 01:08:59 -0700

...
> Med: I still we can avoid some extra exchanges with the server (for
> instance in your bullet 5, you will need to do it for all the media you
> are negotiating including audio, video, etc.).

If the endpoint needs to do audio and video, it will send two PCP
requests, at the same time, in step 2.  This will result in two 
PCP responses in step 4.

As soon as the audio+video session is established, there will be
at least 50 packets per second of video and ~20-50 packets per
second of video.

> Having an explicit
> indication from the PCP Client (preserve parity and request for pair)
> in one single request seems to me simpler.

You're wanting an explicit message for not just one even/odd port
pair (RTP/RTCP), but for 2 even/odd pairs (RTP/RTCP, RTP/RTCP)?

Above you wrote "audio, video, etc.".  What is the "etc."?  More
RTP sessions?  Or some more reasonable protocol??

> Med: At least for the CGN case, the implementations we tested support
> the ability to allocate pairs of ports for a new binding. Returning the
> pair of port by PCP may not be so that complicated IMHO.

My paragraph wasn't about implementation difficulty; rather, it
was about what occurs if there are *no* 'even' ports available but
only 'odd' ports available.  

As splendid as that implementation might have been, it ain't going
to cough up even ports if they're all allocated and in use.  :-)

-d

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 10:14:39 +0200

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 10:09
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: Port contiguity (was RE: [pcp] draft-wing-pcp-base-01 posted)

Med: the indication is for one pair at the time. 

Med: I don't know what is meant by "reasonable protocol" ;-)

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 27 Oct 2010 04:13:10 -0400

On 10/26/10 10:27 PM, "[email-masked]"
<[email-masked]> wrote:

> Hi Reinaldo,
> 
> The question of having several functions controlled by the same PCP Server is
> a little bit more complicated. For instance a PCP Client asking for opening
> incoming pinholes on the PCP-controlled device, does it require to send a
> bunch of request to control all the embedded functions or it has just to send
> a request to the PCP Server and it is up to him to configure appropriately
> policies and pinholes for each function?

Well, both types of behavior could be standardized. I believe we need some
text around them.

I think in general if we have a single PCP server on each device there are
two cases that can co-exist:

1 - different functions (NAT44, NAT64, DS-Lite) in different devices.
2 - different functions (NAT44, NAT64, DS-Lite) in a single device

For 1 we discussed in the list the first in the chain taking care of the
rest (similar to recursive queries). Another possibility is similar to
iterative.

For 2, in the absence of any discovery the PCP Client would possibility need
to request mappings for all 'opcodes' (NAT types - the name is confusing).
But the problem is that different ports or addresses could be returned by
the PCP Server. 

> To be concrete: let consider a
> DS-Lite CP with an embedded IPv6 firewall, IPv4 firewall and a remote PCP
> Server embedded in the CGN. The configuration of a single pinhole will require
> to control various function: IPv6 firewall for the B4 tunnel (this is not
> required for each operation), IPv4 firewall and the remote NAT.
> 
> Note that can be useful for a PCP Client to retrieve the capabilities of the
> PCP-controlled device and therefore target the functionality(ies) it invokes.
> 
> Cheers,
> Med
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 01:25:32 -0700

> there is more than one NAT.

Yes, it only reports what the PCP server sees, which is the 
outer-most NAT closest to the PCP server.

> In deep NAT hierarchy it can be fooled
> the identity). So I prefer we put the case of multiple NATs out of scope
until
> it is explicitely added to the charter.

You want to discard nested NATs because of a convoluted case
where two (or more) NATs have reverted the ephemeral IP address
and port back to their original values, performing a transitive
(lossless) translation?

If those NATs did that job so well with the PCP message, they
will probably handle TCP and UDP and everything else as well --
thus they don't need to be detected by PCP.

> BTW I don't know how the correctly handle NAT444,

Double NAT is in PCP's charter.

> in particular if I reuse your Wifi NAT-router case.

If I add a NAT to a network that doesn't support PCP and 
doesn't support UPnP IGD and doesn't support NAT-PMP, we are
pretty hosed.  Best that can be done is _maybe_ screen
scraping to help the user, but that's a nightmare.  Some
products do that.

In that situation, I would be happy if PCP said "oh, I'm
sorry -- there is a NAT on your network that doesn't speak
PCP.  So I know this mapping won't work."  That is better
than UPnP IGD or NAT-PMP do today (both will happily gets 
your WAN mapping, unaware that it's behind a CGN).

With the right information in the protocol, smart PCP
clients can talk to close (or far) NATs in order to
poke the necessary pinholes in them.

> as Mohamed initially proposed.

I am leaning towards either a separate opcode or a 
mandatory-to-implement-IE.  Mandatory because detecting
an on-path NAT is vital to successful operation of PCP.
Otherwise applications will proceed, thinking they have
mappings, when they really don't.

Ideally, I would like to detect on-path firewalls, but
that's impossible.  And, with today's residential networks,
they are not typically a problem.  NATs are.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 01:38:16 -0700

> in ASICs). The Encapsulation Mode requires an ALG.

Requires an ALG to listen on a socket?  We have been making routers
that receive traffic sent to their IP address for awhile, and 
packets sent to the router's IP address get punted out of 
the forwarding plane (which incurs delay) and to the main 
CPU where it's just normal BSD-like socket code.  No ALG.

But I'm not here to argue about implementation.  I understand
it brings some value to some implementation, that's enough for
me.  Some text on that for the document would be appreciated,
because justifying 2, 3, 4 ways to do something always comes
up during reviews and it's useful to short-cut those things.

-d

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 10:45:41 +0200

Re-,

See inline.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 10:26
À : [email-masked]
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: [pcp] Detect an on-path NAT (was RE: draft-wing-pcp-base-01 posted) 

Med: Agree that it is difficult to detect all FWs but at least fw-controlled by PCP can be detected owing to a PCP capability retrieval procedure (see another e-mail I sent on a proposed solution). Note the presence of a firewall may be an issue in various contexts: e.g.,  (1) symmetric RTP is not used the firewall will block incoming packets if no explicit action is done; (2) unidirectional streams (e.g., VoD) will be blocked by the FW if no action is undertaken, etc. The detection can also be done by a dedicated UPnP service, etc.

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 27 Oct 2010 04:52:16 -0400

I believe we should solve nested NATs. If anything, NAT444 as the low
hanging fruit.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 02:01:44 -0700

> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Wednesday, October 27, 2010 1:13 AM
> To: [email-masked]; Dan Wing; [email-masked]

No, they can't. 

Here are the scenarios:

1. internal host is IPv4 only
2. internal host is IPv6 only
3. internal host is dual stack

For (1), that host can only do PIN44 (to get a public IPv4 address)
or PIN46 (to get a public IPv6 address).

For (2), that host can only do PIN66 (to get a public IPv6 address;
mostly this is for IPv6 firewall.  Yes, this needs more fleshing
out.  Yes, there is an "Ed. Note" to that effect in the document.
Yes, I am aware of that) or PIN64 (to get a public IPv4 address).

For (3), that host can use any of the four opcodes (PIN44, PIN46,
PIN64, PIN66).  If it is being reasonable, it won't do PIN46
or PIN64, because it could just keep the IP address family the
same instead because it is dual stack.  But we cannot detect
a dual-stack node and there isn't a reason to block it.  So,
yes, I suppose a dual-stack host could attempt all four of
the OpCodes.  But it would more reasonably do PIN44 to get
a public IPv4 presence and PIN66 to get a public IPv6 presence.
Besides, on a network with a dual-stack host, that network
is unlikely (not not prohibited) to operate a NAT64, and
also unlikely (but not prohibited) to operate a NAT46.  This
seems to warrant some text around "dual-stack hosts SHOULD
NOT use PIN46 or PIN64 OpCodes".

So, a host will reasonably only send two OpCodes to discover
if it can get a public IPv4 or IPv6 presence.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 02:05:49 -0700

> Med: Agree that it is difficult to detect all FWs but at least fw-
> controlled by PCP can be detected owing to a PCP capability retrieval
> procedure (see another e-mail I sent on a proposed solution). Note the
> presence of a firewall may be an issue in various contexts: e.g.,  (1)
> symmetric RTP is not used the firewall will block incoming packets if
> no explicit action is done; (2) unidirectional streams (e.g., VoD) will
> be blocked by the FW if no action is undertaken, etc. The detection can
> also be done by a dedicated UPnP service, etc.

An idea:  as part non-PCP-controlled firewall discovery, PCP client 
opens a firewall pinhole (to itself) using PCP and asks PCP server to 
send a message into the pinhole.  If the message is received, PCP client 
knows no firewall is on that path.  Obviously this doesn't check for 
firewalls not on that path (such as between the PCP server and the 
Internet), but might be useful for the case within a network.  This 
idea feels less useful for NAT detection due to the vagaries around 
NAT filtering/mapping behavior (and it is those non-PCP-controlled 
NATs, which might have that vague behavior, which we want to detect).

-d

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 11:14:21 +0200

Re-,

See inline.

Cheers,

Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 11:06
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : firewall detection RE: [pcp] Detect an on-path NAT (was RE: draft-wing-pcp-base-01 posted) 

An idea:  as part non-PCP-controlled firewall discovery, PCP client 
opens a firewall pinhole (to itself) using PCP and asks PCP server to 
send a message into the pinhole.

Med: I guess, you mean the PCP server will send a message to the internal IP address/port indicated in the pinhole request.

  If the message is received, PCP client 
knows no firewall is on that path.  

Med: This does not mean there is no firewall in the path, but at best communications from PCP Server are allowed to an internal host. No? 

Obviously this doesn't check for 

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 27 Oct 2010 05:22:35 -0400

Why do you say they can't when by definition they are different address
families and will return different IP addresses? The issue as a described
is:

* Both can succeed
* One can fail and another succeed. Not clear which one the client really
needs
* Both can succeed but different ports (not really interesting unless the
mandatory bit comes into play).

No, they can't. 

....

So, a host will reasonably only send two OpCodes to discover if it can get a
public IPv4 or IPv6 presence.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 02:26:52 -0700

> Med: I guess, you mean the PCP server will send a message to the
> internal IP address/port indicated in the pinhole request.

Might be a separate OpCode.  I dunno yet.  The idea just popped
into my head.  Not fully fleshed out.

> Med: This does not mean there is no firewall in the path, but at best
> communications from PCP Server are allowed to an internal host. No?

If there is fear of a firewall exception for the PCP server's IP address,
then how about if that special message causes some *other* IP address
to send the firewall test message?  

Of course, nothing will definitively say there isn't a firewall;
a firewall might allow a TCP 3-way handshake but then refuse, say,
a TLS exchange (because the firewall wants to inspect traffic and
deny encrypted traffic, I don't know).  But, anyway, as a procedure
we describe and some additional PCP elements -- this might provide
the protocol elements to allow for a simple-minded check for
a firewall on the path.

Better, though, is probably none of that nonsense -- the 
application should just try testing itself with a loopback call,
or doing a wget to its public IP address through a proxy
somewhere -- that would be a real test.  We can't simulate
it well enough within PCP itself.

... So, I think trying to find a firewall isn't something
we should worry about, and withdraw my idea.

-d

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 11:38:51 +0200

Re-,

See inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 11:27
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: firewall detection RE: [pcp] Detect an on-path NAT (was RE: draft-wing-pcp-base-01 posted) 

Med: Yes. 

Med: Yes, a special IP address can be reserved for this usage. This is better IMHO  than illegitimate use of IP addresses as source address.

Med: Fully agree.

Med: The test will be efficient of there is no outbound message prior to receiving the test message.

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 12:55:21 +0200

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 05:13
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: IWF & PCP Port Number (was RE: [pcp] draft-wing-pcp-base-01 posted)

Med: That's would be great.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 08:46:31 -0700

...
> to receiving the test message.

Yes, it's more efficient.  But it's effort to design and code it and
it still won't solve an engineering problem.  What I'm saying is that
such a 'firewall test' doesn't need to be an inherent part of PCP.  
We have nested NATs in real residential networks today.  We do not 
have unexpected firewalls in real residential networks today.  
'Firewall test' could be its own I-D with new opcodes and I agree
could be useful.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 09:06:11 -0700

> Sent: Wednesday, October 27, 2010 2:23 AM
> To: Dan Wing; [email-masked]; [email-masked]
> families and will return different IP addresses?  The issue as a
> described is:
> 
> * Both can succeed
> * One can fail and another succeed. Not clear which one the client
> really needs
> * Both can succeed but different ports (not really interesting unless
> the mandatory bit comes into play).

Can you walk me through the scenario, perhaps by backing up to 
describing three hosts, one IPv4-only, one IPv6-only, one dual-stack,
and what OpCodes they would send, and where the problem happens?

-d

> > But the problem is that different ports or addresses could be
> returned
> > by
> > the PCP Server.
> 
> No, they can't.
> 
> ....
>

---

From: <[email-masked]>
Date: Wed, 27 Oct 2010 18:28:28 +0200

Hi Dan,

Agree detecting the presence of the FW is not urgent and this can be specified in a separate document.

Nevertheless, the base PCP specification should mention something like "In some scenarios communications may fail if intermediary (non PCP-controlled) firewalls are not appropriately configured to accept incoming traffic. Detecting the presence of firewall(s) in the path and configuring it is out of scope of this document".

Cheers,
Med  

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 17:47
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: firewall detection RE: [pcp] Detect an on-path NAT (was RE: draft-wing-pcp-base-01 posted) 

...

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 27 Oct 2010 13:24:39 -0400

Leveraging your previous email. Let's take the case of an IPv6 only host
(analogous to IPv4 only case). It wants an external mapping. It does really
know what kind of NAT is behind, so it sends two requests, one for NAPT64
and one for NAT66.

Let's say both succeed. If every IPv6 only host does that you will get twice
as many mappings in the CGN/CPE which has an impact on scalability and
storage.

Let's say the NAT66 mapping succeeds and the NAT66 fails. Should the host
try again until both succeed? If the solution is too say every host asks for
all possible opcodes that apply to them we have a scalability impact.

Thanks,

Reinaldo

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 10:40:02 -0700

> Sent: Wednesday, October 27, 2010 10:25 AM
> Leveraging your previous email. Let's take the case of an IPv6 only
> host (analogous to IPv4 only case). It wants an external mapping. 
> It does really know what kind of NAT is behind, so it sends two 
.........^
        not?
> requests, one for NAPT64 and one for NAT66.

Pointing to the same internal-port?

> Let's say both succeed. If every IPv6 only host does that you will get
> twice as many mappings in the CGN/CPE which has an impact on 
> scalability and storage.

I don't see the problem.  The host sent those two requests because it
needs to communicate with both IPv4 hosts and IPv6 hosts.  The PIN64 
request gives the host an IPv4 address (to communicate with IPv4 
hosts), and the PIN66 request opens the IPv6 firewall pinhole (to 
communicate with IPv6 hosts).

> Let's say the NAT66 mapping succeeds and the NAT66 fails.

So, a PCP response is sent back to the IPv6 host, and then (later) 
the NAT66 device fails (crashes)?

> Should the host try again until both succeed? If the solution is too 
> say every host asks for all possible opcodes that apply to them 
> we have a scalability impact.

I showed already that a host would only send two OpCode requests --
one opcode if it wants IPv4 communications, and another opcode if
it wants IPv6 communications.  This seems quite reasonable to my
mind.

-d

> >> So, a host will reasonably only send two OpCodes to discover if it
> can
> >> get a

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 27 Oct 2010 13:59:02 -0400

On 10/27/10 10:40 AM, "Dan Wing" <[email-masked]> wrote:

> it wants IPv6 communications.

Can you elaborate on how an IPv6 only host will determine 'if it wants IPv4
communication' or 'IPv6 communication'? The NAT Gateway implements both
NAT66 and NAT64. The host is in a network that goes through the NAT64 but
not NAT66 (or a IPv6 firewall).

> This seems quite reasonable to my
> mind.

Yes, if it actually needs it, that is not the case. Two is one too many when
a million hosts will do the same. It will impact permanent storage and
restoration of mappings.

Thanks,

Reinaldo

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 11:17:00 -0700

> Can you elaborate on how an IPv6 only host will determine 'if it wants
> IPv4 communication' or 'IPv6 communication'? 

The IPv4-only host (or IPv6-only host) would perform the same decision
process that a dual-stack host makes today.  Today, a dual-stack host 
might have an application that binds to an IPv6 interface, an IPv4 
interface, or both.  Examples include Apache, Postfix and BIND, which 
are all dual-stack applications and which are configured (by the 
administrator) to listen for incoming connections on IPv4 or IPv6.
If those are running on an IPvX-only host, and there is a desire
to accept IPvY connections (where X is different from Y), then
a NAT46 or NAT64 is needed, and thus a PIN46 (or PIN64) would
be requested by the host.

> The NAT Gateway implements both

If my explanation above doesn't do it, let's have a phone call.  I'm
not following.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 27 Oct 2010 14:26:10 -0400

Dan,

Your premise is that a host somehow knows these things. My question is on
the 'somehow'. Why (and how) an IPv6-only host will determine that it needs
and request NAT64 mapping? An IPv6-only host as far as it is concerned only
sends or receives IPv6 packets - it has no idea of IPv4 or NAT64.

I think a discovery procedure is needed so that a host can find out what
type of NAT is behind when it actually sends or receives packets (as opposed
to all NAT types on the Gateway).

Thanks,

Reinaldo

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 27 Oct 2010 14:47:27 -0700

> Your premise is that a host somehow knows these things. My question is
> on the 'somehow'. Why (and how) an IPv6-only host will determine that 
> it needs and request NAT64 mapping?

It wants to receive packets from an IPv4 host.

> An IPv6-only host as far as it is 
> concerned only sends or receives IPv6 packets - it has no idea of 
> IPv4 or NAT64.

Then such a host would not want to receive packets from an IPv4
host.

> I think a discovery procedure is needed so that a host can find out
> what type of NAT is behind when it actually sends or receives 
> packets (as opposed to all NAT types on the Gateway).

I don't see what that accomplishes.  If the host is only concerned
with sending and receiving IPv6 packets (and not concerned with
sending or receiving packets with an IPv4 host), it will not care
if the network supports the PIN64 OpCode.

We are going around in circles, not coming to a mutual understanding
of what each other is saying.  I'll call you this afternoon.

-d

---

From: <[email-masked]>
Date: Thu, 28 Oct 2010 07:27:44 +0200

Dan,

Please see inline.

Cheers
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 05:45
À : [email-masked]
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : RE: [pcp] OpCopdes (RE: draft-wing-pcp-base-01 posted) 

Med: 

   There is a case where the PCP Server will be overloaded because of
   the 4 PINxy OpCodes: at the initialisation of the PCP Client it
   proceeds to removing stale mappings installed by the former owner of
   the internal IP address.  The PCP Client, depending on AF of its
   assigned IP address, will send up to 4 requests (or at least 2) to
   the PCP Server.  This is not optimal during avalanche restart for
   instance, since the overall load will be multiplied by 2 or 4.

   You don't think it is better to have one single OpCode to create
   entries and a dedicated field (called for example EAF for External
   Address Family) to indicate the type of the external IP address?  If
   this single OpCode + EAF is used: only one single request will be
   sent with an EAF set to ANY during the initialisation of a PCP
   Client.  If ANY is not allowed, 2 messages may be required but still
   the amount of messages is divided by 2 compared to the initial PINxy
   proposal.  See below for more discussion.

   For the firewall case, there is no need to indicate its type (44 or
   66) in the request since the requested external IP address will be
   set to the same value is the one enclosed in the Internal IP Address.

   If we assume a given PCP Server controls one and only one function
   (e.g., NATxy).  It is trivial there is no need to indicate the type
   of the external IP Address type in the request; therefore the OpCodes
   you proposed are meaningless.  The PCP Client has only to send its
   PIN CREATE REQUEST to the PCP Server; no overload will be
   experienced.

   Now consider the case where we want to allow the same PCP Server
   controls several functions (NAT44, NAT46, NAT66, NAT64).

   o  There is no value to repeat the AF of the internal IP address in
      the OpCode (x of PINxy is not required) since the Internal IP
      Address itself is conveyed in the message.

   o  This means that the 4 OpCodes you proposed will be reduced to 2.
      I.e., only the AF of the requested external IP Address(es) (i.e.,
      EAF) is to be indicated in the request (OpCodes list are reduced
      to PINy).

   o  If we assume that a hinted external IP address MUST be included,
      there is no need to differentiate PINy OpCodes (since the AF is
      conveyed in the hinted external IP Address).  Only one PIN CREATE
      OpCode will be sufficient; and therefore one request will be
      issued by the PCP Client.

         But the question is how the PCP Client knows the AF of the
         external IP Address to be assigned by the PCP-controlled
         device?

   o  In addition how to avoid unwanted mappings to be instantiated in
      all the controlled functions (NAT46; NAT44) or (NAT66, NAT64)
      while this is not needed by the PCP Client?

   A procedure to retrieve the capabilities of the PCP-controlled
   devices is IMHO required such as:

   1.  Add a Capability information to the PCP reachability information
       received in DHCP or any other discovery means;

   2.  In the same manner we can detect the presence of the NAT in the
       path, PING/PING can be used to return back the Capability IE to
       the requesting PCP Client.  A cache can be stored in the PCP
       Client to maintain a PCP Server and its capabilities.  This cache
       can be TTLed of course.

   3.  etc.

   Having one single OpCode to create mapping solves the issue of sending
   several messages; retrieving the capability of the PCP Server allows to avoid installing unwanted
   entries.

   BTW, for easing parsing the messages, I'm wondering it is not useful to have bits which indicate the AF of internal and External
   IP addresses included in the request. These bits are not part of the OpCode bits of course.

   Cheers,

   Med

---

From: <[email-masked]>
Date: Thu, 28 Oct 2010 08:15:13 +0200

Hi Reinaldo, all,

FWIW, an example of how the capabilities of the PCP-controlled device is retrieved can be found at: 

http://tools.ietf.org/html/draft-bpw-softwire-pcp-flow-examples-00#section-6.2

Cheers,
Med 

-----Message d'origine-----
De : Reinaldo Penno [mailto:[email-masked]] 
Envoyé : mercredi 27 octobre 2010 20:26
À : Dan Wing; BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : Re: [pcp] OpCopdes (RE: draft-wing-pcp-base-01 posted)

Dan,

Thanks,

Reinaldo

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2010 09:37:56 +0200

In your previous mail you wrote:

   > The Encapsulation Mode requires an ALG.

=> routers are different because packets to the control plane are
intercepted before being forwarded. In the Encapsulation Mode
if a PCP packet goes through decap and NAT, and after is given
to the PCP server many interesting infos are lost so the right
way is to intercept it as soon as possible: such a processing
is exactly what is called an ALG.

=> IMHO figures 8 and 9 are already good justifications, i.e.,
the two modes are a direct consequence of the two architectures
for the service.

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 28 Oct 2010 06:18:01 -0400

Hi,

I talked to Dan today and I believe we came to an agreement on the 'problem
statement'. Unfortunately what you/we propose below also does not solve the
problem.

It is a very practical problem and already described in detail:
http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-01
(specifically in section 7.1) and
https://tools.ietf.org/html/draft-kuarsingh-lsn-deployment-00. But imagine
both combined, more NAT modes and other CPE/Hosts being served.

These features and deployments are the norm in actual ISPs and PCP will
hopefully play along along and prove useful.

As a *simple example* let's say an IPv6-only host and a ING (Integrated NAT
Gateway) that does NAT66, NAT64 and FW66. Let's suppose the host traffic
will _never_ traverse the NAT64 or NAT66. If the PCP Client asks for the
capability, it would get NAT64/NAT66/FW66 in the list and consequently
requests 3 mappings. This brings some interesting questions that I tried
articulating earlier:

* How can a client determine that 2 out of 3 mappings are not really needed?
It is a function of actual traffic and not all the NAT modes in the ING.
Scalability (permanent storage), performance (lookups) will be adversely
impacted.

* Should the client keep trying until it gets the same port from all three
different NAT types? Referral of objects (in this case ports) plays a role
here. The Application needs to decide which external port to advertise to
another host.

* If the Application Server can be reached through FW66 and NAT64 but their
semantics are different, say: anybody coming through FW66 can reach me in
port X, but if you are coming through the NAT64 I need an EIF (Endpoint
Independent Filter) attached to the mapping and the external port will be
different. Much like 'zones' (or a similar concept) in ING today.

Thanks,

Reinaldo

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2010 16:17:00 +0200

=> BTW I thought again about this and I believe it is better to put
the source addresss and port in the request for at least 2 reasons:
 - the PCP server detects directly the presence of an unexpected NAT
  in the path so can raise an error, in place of leave the client
  detecting the problem in a so useless response.
 - when a PF is created in a NAT for PCP itself, PCP mapping is static
  and known so the PCP client can put the right source address and
  port in requests to the 'next' PCP server.

=> it was just an example showing 'traditional' NAT detection is not
what we need. But I can't see a solution to the PCP problem, for
instance how we can get the address of the next NAT.
I am afraid we have to rely on the PCP service discovery and only
check if there is no unexpected NAT in the path.

=> you assume no filtering for connection initiated from the Internet.

   
=> in fact it seems only NAT444 is clearly in the charter.
I changed my idea: I believe the multiple NAT issue is hard enough
to be the object of at least a dedicated discussion.

   pretty hosed.

=> you can add in the list of reasons to be broken 'no support for
the bridge mode'.

   Best that can be done is _maybe_ screen
   scraping to help the user, but that's a nightmare.  Some
   products do that.
   
   In that situation, I would be happy if PCP said "oh, I'm
   sorry -- there is a NAT on your network that doesn't speak PCP.

=> fortunately it should be 'a pcp'.

   So I know this mapping won't work."  That is better
   than UPnP IGD or NAT-PMP do today (both will happily gets 
   your WAN mapping, unaware that it's behind a CGN).
   
Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2010 16:29:12 +0200

We have nested NATs in real residential networks today.

=> two comments about this:
 - some NATs detect they are nested ('double NAT' red text in status),
  I believe they just check if the 'WAN' address they got by DHCP is
  private, but I have not the code so it is just a simple idea about
  how to do this. BTW this gives another reason to get the external
  address without creating a mapping in PCP.

 - a residential nested NAT should be put in the bridged mode (when
  it can be configured or when it is enough to connect the upstream
  Ethernet on a 'LAN' port): this removes the NAT (and routing)
  function which doesn't make sense.

Regards

PS: Of course it will be easier if the box code is clever enough to
combine both but it seems I am talking about the properties of
an element of the empty set (:-).

---

From: <[email-masked]>
Date: Thu, 28 Oct 2010 17:34:16 +0200

Hi Reinaldo,

In fact, there are several dimensions to this problem of determining the external IP Address. 
 
Retrieving the capabilities helps to avoid overloading the PCP Server in some scenarios: e.g., there is no reason for a PCP Client embedded in a dual stack host to issue 4 requests to a PCP Server which controls only a NAT44 function.

Cheers,
Med 

-----Message d'origine-----
De : Reinaldo Penno [mailto:[email-masked]] 
Envoyé : jeudi 28 octobre 2010 12:18
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : Re: [pcp] OpCopdes (RE: draft-wing-pcp-base-01 posted)

Hi,

Thanks,

Reinaldo

---

From: <[email-masked]>
Date: Thu, 28 Oct 2010 17:52:57 +0200

Hi Francis, 

Please see inline.

Cheers;
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] 
Envoyé : jeudi 28 octobre 2010 16:17
À : Dan Wing
Cc : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Objet : Re: [pcp] Detect an on-path NAT (was RE: draft-wing-pcp-base-01 posted) 

   

Med: This does not work: think about an application which opens a pinhole in a NAT (using any technique PCP, UPnP, static config) and gets the information from a NAT; once retrieved it uses that information to build its PCP Request to the remote PCP Server. With the source IP Address and Port included in the request, the PCP Server will detect a NAT is in the path, but this does not mean the pinhole will be broken! There is no value for the PCP Server to compare the source IP Address and Port with the perceived one. What will be then? Send a notification that a NAT is in path to the PCP Client? In that case, it is simpler to enclose the perceived IP Address and Port in a response and let the decision to the PCP Client.

Med: Could you please explain this point further; I failed to get it.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 28 Oct 2010 12:33:07 -0400

Certainly. We also discussed that error codes should be set appropriately
even in the case the PCP Server gets 4 requests in your scenario. The
current "Unsupported Opcode" should be fine if it is a "fatal, never try it
again" type of error. Each client would try once and be done.

We need some other error that says

"Unsupported opcode in this domain"

Meaning the PCP server understands the opcode but can not fulfill such
requests when coming through this interface(s), zone, others. This is also a
"fatal, never try it again" type of error.

Thanks,

Reinaldo

On 10/28/10 8:34 AM, "[email-masked]"
<[email-masked]> wrote:

> Retrieving the capabilities helps to avoid overloading the PCP Server in some
> scenarios: e.g., there is no reason for a PCP Client embedded in a dual stack
> host to issue 4 requests to a PCP Server which controls only a NAT44 function.
> 
> Cheers,
> Med 
> 
http://tools.ietf.org/html/draft-bpw-softwire-pcp-flow-examples-00#section-6.>>
2

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 28 Oct 2010 11:52:44 -0700

...
>       Address itself is conveyed in the message.

It's needed to open a pinhole on behalf of another host (e.g., 
a PC running PCP that wants to open a pinhole on behalf of a 
webcam).  

It's needed for UPnP IGD interworking, which does a similar thing
(allows opening a pinhole on behalf of another host -- although I
understand that IGD functionality is not used very often / not 
used at all).

It seems needed in the DS-Lite case, where the PCP message arrives
at the PCP server with the B4's IPv6 address, but describes a 
pinhole for an IPv4 host in the subscriber's home.

-d

>    BTW, for easing parsing the messages, I'm wondering it is not useful
> to have bits which indicate the AF of internal and External

---

From: Francis Dupont <[email-masked]>
Date: Thu, 28 Oct 2010 21:38:00 +0200

Med: This does not work: think about an application which opens a
   pinhole in a NAT (using any technique PCP, UPnP, static config) and
   gets the information from a NAT; once retrieved it uses that
   information to build its PCP Request to the remote PCP Server.

=> can you provide a schema? I believe you are trying to describe
the second reason (and as it was not understood...).

req-app --- NAT1 --- ??? --- NAT2 --- Internet

   With the source IP Address and Port included in the request, the PCP
   Server will detect a NAT is in the path, but this does not mean the
   pinhole will be broken!

=> IMHO unexpected NAT == broken

   There is no value for the PCP Server to compare the source IP
   Address and Port with the perceived one. What will be then? Send a
   notification that a NAT is in path to the PCP Client?

=> exactly and it is better than to create a broken PF.

   
=> in the schema a pcp (PCP or NAT-PMP or UPnP-IGD or anything else)
is used to create a PF for req-app - NAT2-PCP-server PCP packets.
Requests to NAT2-PCP-server contain the address and port which are
used at the Internet side of NAT1 so NAT2-PCP-server can detect
an unexpected NAT presence between NAT1 and NAT2.

Regards

PS: assumptions (with you == requesting application):
 - you can know your (source) address and port (it is in all APIs)
 - you can set your (source) address and port (a bit harder but it
  is in all APIs too, BTW it is a good idea to fix your address.
 - if traffic goes through a NAT then the NAT must be programmed/configured
  for all PFs for this traffic

---

From: <[email-masked]>
Date: Thu, 28 Oct 2010 22:34:34 +0200

Hi Dan,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : jeudi 28 octobre 2010 20:53
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : RE: [pcp] OpCopdes (RE: draft-wing-pcp-base-01 posted) 

...

Med: Don't get your point here. In the case you mention, the internal IP Address of the request will carry the IP address of the webcam.   

Med: Idem as above.

Med: Same as above. It seems there is a confusion. I said "There is no value to repeat the AF of the internal IP address in the OpCode (x of PINxy is not required) since the Internal IP Address itself is conveyed in the message." and not to have the internal IP address. Did I missed something?

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 28 Oct 2010 14:29:20 -0700

> Med: Don't get your point here. In the case you mention, the internal
> IP Address of the request will carry the IP address of the webcam.

Then I don't understand your proposal.  Please sketch out a packet
diagram or whatever might be useful to describe what you're proposing
in a different way.  To my mind, *something* in the PCP request 
needs to indicate the address family of the internal IP address. 
Currently, I'm using different OpCodes to do that.  I don't see how
to avoid conveying the address family of the internal IP address.

> Med: Same as above. It seems there is a confusion. I said "There is no
> value to repeat the AF of the internal IP address in the OpCode (x of
> PINxy is not required) since the Internal IP Address itself is conveyed
> in the message."

Yes, there was no packet corruption and that is exactly what I read.

Perhaps you can explain it differently, instead of repeating.

-d

> and not to have the internal IP address. Did I missed
> something?
> 
> -d
> 
> >    several messages; retrieving the capability of the PCP Server
> allows
> > to avoid installing unwanted
> >    entries.
> >
> >    IP addresses included in the request. These bits are not part of
> the
> > OpCode bits of course.
> >
> >    Cheers,
> >
> >    Med

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 28 Oct 2010 16:10:22 -0700

> Sent: Thursday, October 28, 2010 8:34 AM
> To: Reinaldo Penno; [email-masked]
> Retrieving the capabilities helps to avoid overloading the PCP Server
> in some scenarios: e.g., there is no reason for a PCP Client embedded
> in a dual stack host to issue 4 requests to a PCP Server which controls
> only a NAT44 function.

A dual stack host has not purpose or need to send a PIN64 or PIN46.  It
has only a reason to send PIN66 or PIN44.  I explained that earlier, 
and you must have disagreed because you keep talking about 4 messages.

For an IPv4-only host, without a discovery function it might send
two PCP messages (PIN46, PIN44).  Adding a discovery function doesn't
reduce the number of messages -- it would send a discovery message
message (1 message) and then a PIN46 (2 messages) and/or PIN44 message
(3 messages).  It could, in fact, add a message.

For an IPv6-only host, it's the same analysis as an IPv6-only host.

For a dual-stack host, without a discovery function it might send two
PCP messages (PIN44, PIN66).  It has no reason to use its IPv4
interface to get an IPv6 address (PIN46), nor any reason to use
its IPv6 interface to get an IPv4 address (PIN64).  Adding a 
discovery function doesn't reduce the number of messages --
same as analysis for IPv4-only host.

-d

> > FWIW, an example of how the capabilities of the PCP-controlled device
> is
> > retrieved can be found at:
> >
> what
> changed
> > or falsified.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 28 Oct 2010 19:29:59 -0400

Putting discovery aside which is contentious, don't you think the The IPv4
address on the host might be private, for example, connected to a VPN? In
this case it needs the NAT64 mapping since that's how Internet connects to
it, not the private address.

At least that's what used to happen with my VPN client. Internet traffic
would be sent/received through the public IPv4 interface and VPN traffic
through the VPN interface.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 28 Oct 2010 16:45:07 -0700

> Putting discovery aside which is contentious, don't you think the The
> IPv4 address on the host might be private, for example, connected to 
> a VPN?  In this case it needs the NAT64 mapping since that's how 
> Internet connects to it, not the private address.
> 
> At least that's what used to happen with my VPN client. Internet
> traffic would be sent/received through the public IPv4 interface 
> and VPN traffic through the VPN interface.

Changed the subject line, because we are really talking about
multihoming in this thread.  

How would/could the host determine which address is to/from the
Internet, and which isn't?  

I think the only way is "I want to accept connections from the 
Internet" and "I want to accept connections from <the incoming
path my packets would go if I was going to send a packet to
foo.example.com>"  (where host foo is inside the company 
Example and accessible only via VPN).  That would cause the
mapping to be created for the VPN'd traffic.

(I would rather talk about how to get PCP working in the simple 
case before piling on multihoming.)

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 28 Oct 2010 22:10:35 -0400

> mapping to be created for the VPN'd traffic.

Yes, as we discussed.

> case before piling on multihoming.)

I'm fine as long as when we understand the requirements so when we get to
multihoming we do not have to create 10 different IEs to patch the base
protocol that will create a interoperability barrier.