Subject: [pcp] Comments on draft-ietf-pcp-server-selection-01

From: Dave Thaler <[email-masked]>
Date: Mon, 5 Aug 2013 23:57:24 +0000

Comments on draft-ietf-pcp-server-selection-01 below.

Main technical comments:

1) Needs to remove mention of names and just use addresses. The DHCP
    option is being changed per WG discussion.  But even before the DHCP
    option, we had the default router list (see RFC 6887 section 8.1) which
    is a list of IP's with no name known.

2) Document assumes that
     "PCP requests to different servers are independent, the result of a
      PCP request to one server does not influence another"
We currently have no WG consensus on this.  Some (e.g., Stuart) have
argued that it's the responsibility of the server to interact with other 
redundant servers managed by the same entity.  Since no one has given
any counter argument, that should be the starting point.

 3) There needs to be a step where the selection algorithm takes a source 
address into account, if the app specified one.  Consider the case of sending
a PEER after establishing a TCP connection.  The source address of the TCP 
connection should constrain the PCP server selection mechanism so you 
don't try sending PEER messages on some other network than the one the
TCP connection is on.

4) The server selection is still missing a lot of details on how an address is selected.  E.g.:
 * Is it assumed that the addresses of the same server are already ordered
    by the configuration mechanism?  (I think there's no need for such assumption)
 * Should RFC 6724 sorting be done on them by the client? (I think so)
 * If you're trying to use PCP on an IPv4 mapping should you prefer IPv4 or not 
    for PCP server addresses?
 * Should a client do RFC 6724 to choose among servers, if point 2 is addressed
    by just using one? 
And for each of the above: Why or why not?

Full comments (including editorial ones) in context can be found at
http://research.microsoft.com/~dthaler/draft-ietf-pcp-server-selection-01.pdf
(a .docx is also available at the same location, just change .pdf to .docx)

-Dave

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, May 22, 2013 4:47 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [pcp] I-D Action: draft-ietf-pcp-server-selection-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Port Control Protocol Working Group of the
> IETF.
> 
> 	Title           : PCP Server Selection
> 	Author(s)       : Mohamed Boucadair
>                           Reinaldo Penno
>                           Dan Wing
>                           Prashanth Patil
>                           Tirumaleswar Reddy
> 	Filename        : draft-ietf-pcp-server-selection-01.txt
> 	Pages           : 10
> 	Date            : 2013-05-22
> 
> Abstract:
>    This document specifies the behavior to be followed by the PCP client
>    to contact its PCP server(s) when one or several PCP server names are
>    configured.  Multiple names may be configured to a PCP client in some
>    deployment contexts such as multi-homing.
> 
>    This document updates RFC6887.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pcp-server-selection
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-pcp-server-selection-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-pcp-server-selection-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: <[email-masked]>
Date: Tue, 6 Aug 2013 08:16:38 +0200

Hi Dave, 

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de Dave
>Thaler
>Envoyé : mardi 6 août 2013 01:57
>À : [email-masked]; [email-masked]
>Objet : [pcp] Comments on draft-ietf-pcp-server-selection-01
>

[Med] IMHO, the dhcp discussion should not impact the consensus the wg had on the definition of the name. A name can be configured using a variety of means (manually, device management protocol, etc.). The PCP server selection draft does not make any assumption on how the names are configured. Following dhc recommendations, the name is first resolved and then its results are conveyed in the dhcp option as IP addresses. 

>any counter argument, that should be the starting point.

[Med] I don't get the point here. The document makes one design assumption which is: if multiple names are configured to the pcp clients, this is a hint multiple servers are to be contacted simultaneously. If only one name is configured (which may result in one or multiple IP addresses), only one IP address will be used to contact that pcp server. The case of "redundant" server as you say, will means that multiple IP addresses are configured to the pcp client as being bound to the same PCP server. As currently defined in the document, the pcp client will never sent multiple request to multiple addresses pointing to the same pcp server. What is wrong with that rationale?

>don't try sending PEER messages on some other network than the one the

[Med] Yes, I agree. If we had a provisioning data per interface, then we can re-use what we had in the dhcp draft: 

"A host may have multiple network interfaces (e.g., 3G, WiFi, etc.); each configured differently. Each PCP server learned MUST be associated with the interface via which it was learned." 

The problem is if the pcp server address is configured manually for example, the interface to which it is bound may not be available. 

>    by the configuration mechanism?  (I think there's no need for such

[Med] There is no need for such preference. This can be explicitly indicated in the text. 

> * Should RFC 6724 sorting be done on them by the client? (I think so)

[Med] Why do you think we need more than what we have in http://tools.ietf.org/html/rfc6887#section-8.4? 

>    for PCP server addresses?

[Med] Why? Remember NAT64 is reachable using IPv6 but it assigns external IPv4 addresses. The rationale adopted in the document does not need to enter into such details: multiple names means multiple servers, one name means one pcp server (that can be reached with multiple IP addresses).

> * Should a client do RFC 6724 to choose among servers, if point 2 is

[Med] Isn't this covered in http://tools.ietf.org/html/rfc6887#section-8.4?

---

From: Dave Thaler <[email-masked]>
Date: Wed, 7 Aug 2013 20:38:00 +0000

Med wrote:
> [Med] IMHO, the dhcp discussion should not impact the consensus the wg
> had on the definition of the name. A name can be configured using a variety
> of means (manually, device management protocol, etc.). The PCP server
> selection draft does not make any assumption on how the names are
> configured. Following dhc recommendations, the name is first resolved and
> then its results are conveyed in the dhcp option as IP addresses.

The server selection document needs to not assume there are any names.
For example, it needs to be relevant in the case of the default router list
as explained in RFC 6887.   There is no need to complicate this draft with
a discussion of names.

> >argued that it's the responsibility of the server to interact with
> >other redundant servers managed by the same entity.  Since no one has
> >given any counter argument, that should be the starting point.
> 
> [Med] I don't get the point here. The document makes one design
> assumption which is: if multiple names are configured to the pcp clients, this
> is a hint multiple servers are to be contacted simultaneously. If only one
> name is configured (which may result in one or multiple IP addresses), only
> one IP address will be used to contact that pcp server. The case of
> "redundant" server as you say, will means that multiple IP addresses are
> configured to the pcp client as being bound to the same PCP server.

No, "redundant" servers here means multiple servers managed by the same
entity.

> As
> currently defined in the document, the pcp client will never sent multiple
> request to multiple addresses pointing to the same pcp server. What is
> wrong with that rationale?

The point is that we have no WG consensus to send to multiple PCP servers
managed by the same entity.   And if you only send to any one of them,
then I think you don't need to distinguish which IPs belong to which servers.
(You still have to distinguish between PCP server IPs managed by different
entities, e.g. on different networks.)

> > 3) There needs to be a step where the selection algorithm takes a
> >source address into account, if the app specified one.  Consider the
> >case of sending a PEER after establishing a TCP connection.  The source
> >address of the TCP connection should constrain the PCP server selection
> >mechanism so you don't try sending PEER messages on some other
> network
> >than the one the TCP connection is on.
> 
> "A host may have multiple network interfaces (e.g., 3G, WiFi, etc.); each
> configured differently. Each PCP server learned MUST be associated with the
> interface via which it was learned."
> 
> The problem is if the pcp server address is configured manually for example,
> the interface to which it is bound may not be available.

We can set whatever requirements we want here.  I think we should apply the
same requirement as you quote, to all cases including manually configured
servers.  That is, you have to configure a server in the context of some network.

> [Med] Why do you think we need more than what we have in
> http://tools.ietf.org/html/rfc6887#section-8.4?

Because that section is about multiple interfaces (and multiple source addresses).
My question here is about sorting destination addresses of PCP servers, even
if you have only one interface and source address.

> [Med] Why? Remember NAT64 is reachable using IPv6 but it assigns external
> IPv4 addresses. The rationale adopted in the document does not need to
> enter into such details: multiple names means multiple servers, one name
> means one pcp server (that can be reached with multiple IP addresses).

For an IPv4 mapping, RFC 6887 says the internal address is the source IP of the
PCP message, unless THIRD_PARTY is used.   So if you're trying to use PCP
on an IPv4 mapping, and you use an IPv4 address of a PCP server then
you can use the correct source IP and don't need THIRD_PARTY.
If you instead try IPv6 first, then the internal address of the mapping will be
different from the source IP of the PCP message and you'd have to use
THIRD_PARTY which may or may not be permitted.

Hence I think we need to explicitly say to prefer IPv4 PCP server addresses
when affecting IPv4 mappings.
 
> [Med] Isn't this covered in http://tools.ietf.org/html/rfc6887#section-8.4?

No, it isn't as explained above.

-Dave

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Aug 2013 20:57:53 +0000

With respect to multiple interfaces, I think it's safe to rely on whatever mechanism MIF comes up with.   Doing a one-off mechanism just for PCP is more likely to make things worse than better.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 7 Aug 2013 21:16:46 +0000

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Wednesday, August 7, 2013 1:58 PM
> To: Dave Thaler
> Cc: [email-masked]; [email-masked]; draft-ietf-pcp-server-
> [email-masked]
> Subject: Re: [pcp] Comments on draft-ietf-pcp-server-selection-01
> 
> With respect to multiple interfaces, I think it's safe to rely on whatever
> mechanism MIF comes up with.   Doing a one-off mechanism just for PCP is
> more likely to make things worse than better.

Yes, but MIF won't say how things apply to other protocols.  To steal a MIF term,
each "PVD element" (which PCP people can think of as any piece of info configured
in the context of a particular network) has to say how to handle multiple interfaces,
i.e. which category it's in as the MIF WG meeting discussed.  E.g., pick one, 
use all, or whatever else.   PCP has to specify at least what category it's in.

-Dave

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Aug 2013 02:05:06 +0000

> use all, or whatever else.   PCP has to specify at least what category it's in.

It seems pretty straightforward to me that if you are attempting to connect to a host in the context of PVD x, you use the PCP server associated with PVD x.   If there is no PCP server associated with PVD x, then you do not use PCP within that PVD.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 8 Aug 2013 02:10:15 +0000

> Sent: Wednesday, August 7, 2013 7:05 PM
> To: Dave Thaler
> > Yes, but MIF won't say how things apply to other protocols.  To steal
> > a MIF term, each "PVD element" (which PCP people can think of as any
> > piece of info configured in the context of a particular network) has
> > to say how to handle multiple interfaces, i.e. which category it's in as the
> MIF WG meeting discussed.  E.g., pick one,
> It seems pretty straightforward to me that if you are attempting to connect
> to a host in the context of PVD x, you use the PCP server associated with PVD
> x.   If there is no PCP server associated with PVD x, then you do not use PCP
> within that PVD.

Not quite.
PVD x can have zero or more PCP servers, each of which has 1 or more IP addresses.

So If you are attempting to connect to a host in the context of PVD x, you use the
PCP server IP address list associated with PVD x, and you select among them using
<whatever algorithm is defined in draft-ietf-pcp-server-selection>.

However, that only handles the PEER case.  In the MAP case, an application isn't
trying to connect, it's trying to listen.  And it might be listening within PVD x, or
it might be trying to listen within "all" PVDs (using a socket with a wildcard bind)...
and whether that works or not is still TBD.   But if it is supported, then 
draft-ietf-pcp-server-selection needs to make sure this is covered too.

-Dave

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Aug 2013 02:14:20 +0000

> PVD x can have zero or more PCP servers, each of which has 1 or more IP addresses.

Okay, so how does the client know which PCP server to use?

---

From: Dave Thaler <[email-masked]>
Date: Thu, 8 Aug 2013 02:21:30 +0000

p> -----Original Message-----
> Sent: Wednesday, August 7, 2013 7:14 PM
> To: Dave Thaler

That's what draft-ietf-pcp-server-selection is supposed to specify.

If you buy Stuart's argument that communicating with just one IP address per
PVD is sufficient (and that server is then responsible for syncing with any others
as needed), then I would expect the algorithm might be something like:

If app wants to affect an IPv4 mapping, sort IPv4 server IP's from that PVD
per RFC 6724, and try them one by one until one responds.

If app wants to affect an IPv6 mapping, sort IPv6 server IP's from that PVD
per RFC 6724, and try them one by one until one responds.

-Dave

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Aug 2013 02:40:25 +0000

> That's what draft-ietf-pcp-server-selection is supposed to specify.

Okay, but this draft is talking about multi-homing, and that would only require one PCP server per PVD.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 8 Aug 2013 13:22:57 +0000

> From: Dave Thaler [mailto:[email-masked]]
> Sent: Thursday, August 08, 2013 2:47 AM
> To: Ted Lemon
> Subject: RE: [pcp] Comments on draft-ietf-pcp-server-selection-01
> 

I think it's "use all" for certain use-cases; For example if we consider host with MIF (Wifi, 3G from different administrative domains) there will be two PVD elements, let's say each PVD is associated with one PCP server; Applications like WebRTC would communicate with both PCP servers in each PVD to find the server-reflexive candidates, advertize them in offer/answer. Based on ICE connectivity check results, one of the interfaces would be selected for media session. If it is MPRTP both the interfaces could be selected for the media session.

--Tiru.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 8 Aug 2013 13:45:40 +0000

> Sent: Thursday, August 08, 2013 7:52 AM
> To: Ted Lemon

If we consider the use-case http://tools.ietf.org/html/draft-ietf-pcp-server-selection-01#appendix-A.1 there will be one PVD and two PCP server IP addresses. If the ICE agent has ICE lite implementation, then it will have to communicate with both the PCP controlled firewalls to permit incoming ICE connectivity checks. 

--Tiru.

---

From: Dave Thaler <[email-masked]>
Date: Thu, 8 Aug 2013 14:28:25 +0000

Tiru wrote:
[...]
> If we consider the use-case http://tools.ietf.org/html/draft-ietf-pcp-server-
> selection-01#appendix-A.1 there will be one PVD and two PCP server IP
> addresses. If the ICE agent has ICE lite implementation, then it will have to
> communicate with both the PCP controlled firewalls to permit incoming ICE
> connectivity checks.

That's an interesting assertion but you didn't give any justification.

Stuart asserted that communicating with one is sufficient, and simpler for the 
client, because it's the PCP server's job to communicate with the other ones
to permit incoming ICE connectivity checks.  If you disagree with that,
please respond with a technical argument as to why having the client
communicate with both is better than having one server communicate 
with the other.

-Dave

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Aug 2013 14:41:01 +0000

> If we consider the use-case http://tools.ietf.org/html/draft-ietf-pcp-server-selection-01#appendix-A.1 there will be one PVD and two PCP server IP addresses. If the ICE agent has ICE lite implement…

I would expect this to be two provisioning domains, not one.   That's certainly the way we're currently talking about it in the MIF architecture doc.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 12 Aug 2013 03:12:55 +0000

Hi Dave,

Please see inline

> Sent: Thursday, August 08, 2013 7:58 PM
> To: Tirumaleswar Reddy (tireddy); Ted Lemon

Comparing the two approaches:

[1] PCP client will have to handle both the scenarios http://tools.ietf.org/html/draft-ietf-pcp-server-selection-01#appendix-A.1 (where both the Firewalls are managed by the same administrative domain) and http://tools.ietf.org/html/draft-patil-pcp-multihoming-00#section-5.1 (Network managed Firewall provided by each ISP). For the latter scenario PCP client would have to communicate with both the firewalls and there is no way for FW1 or FW2 to talk to each other. 

So if PCP client would already have the logic to handle multiple PCP-controlled Firewalls why make a special treatment just for http://tools.ietf.org/html/draft-ietf-pcp-server-selection-01#appendix-A.1 ?

[2] If it's compared with your suggestion then the PCP client will send all the PCP requests to only one of the routers (let's say rtr1 in appendix-A.1); rtr1 based on the source IP address of the PCP request will have to forward the request again to rtr2 causing additional delay, processing overhead.

-Tiru.

---

From: <[email-masked]>
Date: Mon, 12 Aug 2013 08:08:53 +0200

Hi Dave,

Please see inline.

Cheers,
Med

>De : Dave Thaler [mailto:[email-masked]]
>Envoyé : mercredi 7 août 2013 22:38
>À : BOUCADAIR Mohamed OLNC/OLN; [email-masked]; draft-ietf-pcp-server-
>[email-masked]
>Objet : RE: Comments on draft-ietf-pcp-server-selection-01
>
>Med wrote:

[Med] This is deployment-specific. The assumption you made in your initial comment is not so that easy to honor. I don't think it is safe to make deployment assumption on behalf of an administrative entity. Synchronization state among servers managing the same or distinct function may not so that simple. Think about configurations such as domain hosting: 

* one or multiple nat64 provisioned to IPv6-only hosts
* one or multiple nptv6 provisioned to IPv6-only and dual stack hosts
* one or multiple nat44 provisioned to IPv4-only and dual stack hosts
* one or multiple IPv4 fw 
* one or multiple IPv6 fw
* multiple flow-based access routers
* one or many port range routers
* etc.

>managed by the same entity.

[Med] BTW, I don't remember when and where this is issue was raised. This design was in the dhcp draft since January 2012 and it was inherited by the pcp-server selection draft. 

   And if you only send to any one of them,
>then I think you don't need to distinguish which IPs belong to which

[Med] Assuming that an administrative entity will need to return only one IP address is deployment-specific. I disagree with putting this constraint the administrative entities. The protocol should avoid making deployment-specific assumptions.

---

From: <[email-masked]>
Date: Mon, 12 Aug 2013 08:14:41 +0200

Hi Ted,

Multi-homing is cited in the draft as an example to illustrate a typical case where multiple servers will be provisioned. The example is not normative and does not impact the specification since we don't assume that one and only one pcp server is enabled per PVD. This is a deployment-specific assumption which, if adopted, will put a lot of complexity on the administrative entity managing the PVD. I disagree with going that path. 

Cheers,
Med

>De : Ted Lemon [mailto:[email-masked]]
>Envoyé : jeudi 8 août 2013 04:40
>À : Dave Thaler
>Cc : BOUCADAIR Mohamed OLNC/OLN; [email-masked]; draft-ietf-pcp-server-
>[email-masked]
>Objet : Re: [pcp] Comments on draft-ietf-pcp-server-selection-01
>

---

From: <[email-masked]>
Date: Mon, 12 Aug 2013 08:31:39 +0200

Re-,

Please see inline.

Cheers,
Med

>Envoyé : jeudi 8 août 2013 16:28
>À : Tirumaleswar Reddy (tireddy); Ted Lemon
>Objet : RE: [pcp] Comments on draft-ietf-pcp-server-selection-01
>
>
>Tiru wrote:
>[...]
>client,

[Med] Communicating with one pcp server is indeed simple but it has implications on the deployment options to be followed in the PVD side. BTW, this is not a technical argument since, from the pcp client perspective, the goal to be reachable from outside and to control how outgoing packets are handled by intermediary pcp-controlled device(s). This is achieved by installing state so that to be able to receive incoming packets, to retrieve the lifetime(s) of the state maintained by PCP-controlled device so that state are refreshed as appropriate, etc. To achieve that goal, connectivity can be enhanced if the client is provided with sufficient information to make appropriate decision(s): e.g., an dual stack host can:
* retrieve an external IPv6 address
* retrieve an external IPv4 address and/or port number

How would a PCP client can retrieve both an external IPv4 address and external IPv6 address with the same request? This is not doable with RFC6887.

 because it's the PCP server's job to communicate with the other
>ones
>to permit incoming ICE connectivity checks.

[Med] does this assume one pcp server will controlled every deployed PCP-controlled device in that network? How PCP servers will coordinate among themselves? How PCP servers will discover each other? How to select the set of pcp servers which need to be coordinated? Take the example of a complex configuration in which both IPv6-only, IPv4-only and dual-stack hosts are connected (e.g., only nat64, nptv6 and IPv6 fw need to be coordinated for servicing IPv6-only hosts, nat44 and nptv6 for dual-stack hosts, etc.)?   

  If you disagree with that,

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 12 Aug 2013 07:01:54 +0000

> Sent: Thursday, August 08, 2013 8:11 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Dave Thaler; [email-masked]; [email-masked]; draft-ietf-pcp-
> [email-masked]
> > If we consider the use-case http://tools.ietf.org/html/draft-ietf-pcp-
> server-selection-01#appendix-A.1 there will be one PVD and two PCP server IP
> I would expect this to be two provisioning domains, not one.   That's
> certainly the way we're currently talking about it in the MIF architecture
> doc.

In the above scenario both Firewalls are managed by the same administrative domain, I have read the draft http://tools.ietf.org/html/draft-anipko-mif-mpvd-arch-02 but could not figure why two PVD are required for this use case ?

--Tiru.

---

From: <[email-masked]>
Date: Tue, 13 Aug 2013 07:51:45 +0200

Hi Ted, all,

One additional comment: the current document does not mix multi-interface issues with multiple server case. A device with multiple interfaces may discover one single server while a mono-interfaced device may discover multiple servers. 

>From a PCP perspective, the goal is to increase the chance to get connectivity and be reachable from outside. A host in a domain which include multiple firewalls, multiple NATs4, etc. will need:

* to discover all external IP addresses/port in order to publish them to remote parties.
* to open pinholes in all FWs located in the boundary of a given domain: because a local domain may not have the control on the entry point to be selected when entering a domain (this is traditionally called inbound TE).

Cheers,
Med

>De : Ted Lemon [mailto:[email-masked]]
>Envoyé : lundi 12 août 2013 17:41
>À : Tirumaleswar Reddy
>Cc : Dave Thaler; mohamed.boucadair@; pcp@; draft-ietf-pcp-server-
>selection@
>On Aug 12, 2013, at 3:01 AM, Tirumaleswar Reddy (tireddy)
><[email-masked]> wrote:
>> In the above scenario both Firewalls are managed by the same
>administrative domain, I have read the draft
>http://tools.ietf.org/html/draft-anipko-mif-mpvd-arch-02 but could not
>figure why two PVD are required for this use case ?
>
>The motivation for treating these as separate provisioning domains is that
>we want a device that is inside a multihomed network to provide the same
>experience as a device that is at the edge of the same multihomed network.
>In order for that to be the case, the two external links need to be treated
>as separate provisioning domains.
>
>It's true that the firewalls may be managed by the same entity, but
>treating them as separate provisioning domains has several advantages.
>First, that's what you want to do anyway-you just want to do it outside the
>PVD model, with your server selection model.   Secondly, from the
>perspective of the application, the fact that the two firewalls are
>operated by the same entity is immaterial.   What matters is that they
>connect to two separate network service providers.   Doing this with
>provisioning domains groups relevant information in a way that allows the
>application to make meaningful choices about its connection to the network.
>If you separate out provisioning domains and server selection, the
>application has a _much_ harder problem to solve.

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 15 Aug 2013 19:06:41 -0700

> communicate with both is better than having one server communicate 

Dave has represented my opinion accurately, but I'll elaborate a little.

Today, a network client makes a NAT mapping (or a firewall hole) by sending an outbound TCP SYN. That is all. If there are nested NATs, the client doesn't have to know about that. If there are parallel NATs with multiple network ingress and egress points, then the client doesn't have to know about that either. The NAT that sees the outbound TCP SYN is responsible for communicating with its NAT peers to ensure that the right state is created so that inbound traffic is handled correctly.

Right now the Mac OS X and iOS PCP client handles only a single PCP server. I suspect it will only ever handle a single PCP server. I suspect that many consumer electronics products like network security cameras will also only support a single PCP server. So if you're a network router vendor that's selling a product that lets the customer load-balance across multiple ingress and egress paths, then you'd better make it look like a single PCP server to the client, or it won't work and you won't be able to sell it. If you're providing nested NAT, then you'd better make it look *exactly* like a single PCP server to the client (i.e. recursive PCP), or it won't work and you won't be able to sell it.

I had originally advocated that the PCP client sends its PCP requests to a fixed well-known anycast address, and it's up to the network to do the right thing with that. In a simple network with a single NAT, the NAT intercepts the PCP request and handles it. In a more complicated network, the network may have to do more complicated things, but that's transparent to the client.

However, I was not successful arguing for a fixed well-known any cast address, so instead the client sends its requests to its default router. I suspect Mac OS X and iOS may only ever send their PCP requests to their default router.

This means that if you want to sell some fancy network product that supports parallel and/or nested NATs and firewalls, it had better work with clients that only send requests to their default router, because that's all you're going to see in the field for quite some time.

It's easy to write documents telling PCP clients what they should be doing, but I'd like to see some vendors stepping up and volunteering for that commitment. Do we have a vendor of some $49 network security camera volunteering to support multiple PCP servers? How would that even work? If it requires *any* user configuration, it's a non-starter. Once you accept manual user configuration, it's easier to just make some port mappings by hand. The win of PCP is that it allows plug-and-play zero configuration operation. The moment the user has to configure the device with the address of its PCP server, it's easier to configure the NAT gateway with a manual port mapping. And if you suppose a DHCP option to do this configuration, the home gateway has to be updated to support that DHCP option, and if you have to update the home gateway then it's easier to put recursive PCP support into the gateway (works today with all PCP clients) than it is to add support for the PCP DHCP option (doesn't work until clients are updated to understand the new option).

Stuart Cheshire

---

From: Dan Wing <[email-masked]>
Date: Thu, 15 Aug 2013 19:48:58 -0700

> However, I was not successful arguing for a fixed well-known any cast address, so instead the client sends its requests to its default router. I suspect Mac OS X and iOS may only ever send their PC…

We have encountered use cases where such a well-known anycast address would be very useful, most notably with draft-wing-pcp-flowdata where an existing non-PCP-aware router or NAT is in the local network and the ISP is operating a PCP-speaking and draft-wing-pcp-flowdata-aware router, and we want to use draft-wing-pcp-flowdata to ask the ISP to provide differentiated service for a certain flow (e.g., make Skype or Netflix work better than BitTorrent in the downstream direction).  Reinaldo wrote up draft-kiesel-pcp-ip-based-srv-disc, but as it wasn't on PCP's agenda I have not researched how Reinaldo's proposal differs from draft-cheshire-pcp-anycast.

-d

> It's easy to write documents telling PCP clients what they should be doing, but I'd like to see some vendors stepping up and volunteering for that commitment. Do we have a vendor of some $49 network security camera volunteering to support multiple PCP servers? How would that even work? If it requires *any* user configuration, it's a non-starter. Once you accept manual user configuration, it's easier to just make some port mappings by hand. The win of PCP is that it allows plug-and-play zero configuration operation. The moment the user has to configure the device with the address of its PCP server, it's easier to configure the NAT gateway with a manual port mapping. And if you suppose a DHCP option to do this configuration, the home gateway has to be updated to support that DHCP option, and if you have to update the home gateway then it's easier to put recursive PCP support into the gateway (works today with all PCP clients) than it is to add support for the PCP DHCP option (d
> oesn't work until clients are updated to understand the new option).
> 
> Stuart Cheshire
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 16 Aug 2013 03:25:45 +0000

On Aug 15, 2013, at 10:40 PM, Dan Wing <[email-masked]> wrote:
> Only one of them would get a TCP SYN that the host sends off the local network.  Same logic -- whatever that logic -- would determine which default router is used by PCP.

Hm, well, right.  So there's only one PCP server in this situation.   You think you configured two, but only one will ever be used, until we have support for multiple provisioning domains.

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Fri, 16 Aug 2013 09:58:49 +0000

We discussed it during the meeting and offline a few times. There is
basically a lot of overlap between the two proposals. The difference is
what should be done when there are two PCP Servers in the network. The
classical case is asymmetric routing where PCP Servers are firewalls.
Other cases are associated with FLOW data such as getting info from
network as to what is the most appropriate link to use, etc.

Some folks believe firewalls should synch state amongst themselves. Others
believe PCP client should discover and talk to both PCP Servers. The crux
of the issue is where do you want to put the burden. A PCP Server vendor
for enterprises, ISPs might want the client to carry its weight and a
client vendor probably wants the server to do all work.

-Reinaldo

On 8/15/13 11:48 PM, "Dan Wing" <[email-masked]> wrote:

>> Today, a network client makes a NAT mapping (or a firewall hole) by
>>sending an outbound TCP SYN. That is all. If there are nested NATs, the
>>client doesn't have to know about that. If there are parallel NATs with
>>multiple network ingress and egress points, then the client doesn't have
>>to know about that either. The NAT that sees the outbound TCP SYN is
>>responsible for communicating with its NAT peers to ensure that the
>>right state is created so that inbound traffic is handled correctly.
>> 
>> Right now the Mac OS X and iOS PCP client handles only a single PCP
>>server. I suspect it will only ever handle a single PCP server. I
>>suspect that many consumer electronics products like network security
>>cameras will also only support a single PCP server. So if you're a
>>network router vendor that's selling a product that lets the customer
>>load-balance across multiple ingress and egress paths, then you'd better
>>make it look like a single PCP server to the client, or it won't work
>>and you won't be able to sell it. If you're providing nested NAT, then
>>you'd better make it look *exactly* like a single PCP server to the
>>client (i.e. recursive PCP), or it won't work and you won't be able to
>>sell it.
>> 
>> I had originally advocated that the PCP client sends its PCP requests
>>to a fixed well-known anycast address, and it's up to the network to do
>>the right thing with that. In a simple network with a single NAT, the
>>NAT intercepts the PCP request and handles it. In a more complicated
>>network, the network may have to do more complicated things, but that's
>>transparent to the client.
>> 
>> However, I was not successful arguing for a fixed well-known any cast
>>address, so instead the client sends its requests to its default router.
>>I suspect Mac OS X and iOS may only ever send their PCP requests to
>>their default router.
>
>We have encountered use cases where such a well-known anycast address
>would be very useful, most notably with draft-wing-pcp-flowdata where an
>existing non-PCP-aware router or NAT is in the local network and the ISP
>is operating a PCP-speaking and draft-wing-pcp-flowdata-aware router, and
>we want to use draft-wing-pcp-flowdata to ask the ISP to provide
>differentiated service for a certain flow (e.g., make Skype or Netflix
>work better than BitTorrent in the downstream direction).  Reinaldo wrote
>up draft-kiesel-pcp-ip-based-srv-disc, but as it wasn't on PCP's agenda I
>have not researched how Reinaldo's proposal differs from
>draft-cheshire-pcp-anycast.
>
>-d
>
>
>> This means that if you want to sell some fancy network product that
>>supports parallel and/or nested NATs and firewalls, it had better work
>>with clients that only send requests to their default router, because
>>that's all you're going to see in the field for quite some time.
>> 
>> It's easy to write documents telling PCP clients what they should be
>>doing, but I'd like to see some vendors stepping up and volunteering for
>>that commitment. Do we have a vendor of some $49 network security camera
>>volunteering to support multiple PCP servers? How would that even work?
>>If it requires *any* user configuration, it's a non-starter. Once you
>>accept manual user configuration, it's easier to just make some port
>>mappings by hand. The win of PCP is that it allows plug-and-play zero
>>configuration operation. The moment the user has to configure the device
>>with the address of its PCP server, it's easier to configure the NAT
>>gateway with a manual port mapping. And if you suppose a DHCP option to
>>do this configuration, the home gateway has to be updated to support
>>that DHCP option, and if you have to update the home gateway then it's
>>easier to put recursive PCP support into the gateway (works today with
>>all PCP clients) than it is to add support for the PCP DHCP option
> (d

---

From: Dan Wing <[email-masked]>
Date: Fri, 16 Aug 2013 07:30:53 -0700

> client vendor probably wants the server to do all work.

Yes, that was discussed at the meeting.

But if there is one, and only one, IANA-assigned PCP server address (anycast address), the design questions around firewall synchronization and communicating to multiple PCP servers fall out, because there is only one IANA-assigned PCP server address and thus only one PCP server.  If the host has multiple interfaces, there can be one PCP server on each interface, but that does not create the problems you describe above.

-d

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 17 Aug 2013 01:01:13 -0700

In general, i am a big fan of anycast, but i am not sure i feel comfortable understanding
all the challenges using it with PCP target deployment cases.

To elaborate a bit more on a case that i am worried about:

Anycast will make people (ok: me) think that we can get PCP to work even if the
maybe best onpath devices do not support it. So if i assume that the home-gateway 
and access-node (both the best onpath devices) can for some reasons not support
PCP and i start putting PCP onto some nearby devices, eg: The main media-center in the 
home and some "server" in the PCP. Great. Beng able to do this was one benefit
of not using a strict onpath signaling method with PCP. But how do i do this with
ONE anycast address. Assume the PCP server in the home uses that anycast address.
It will have a real tough time sending packets to the same anycast address to reach
the server in the POP.

That's why i suggested we may want at least to ask for a few anycast addresses,
and then figure out how to use them. For example, clients would always only have
to know adress1, PCP server in the home binds to adress1, but sends (as proxy) to address2,
which would reach then the PCP server in the POP. The server in the POP could of
corse listen to both adress1 and address2, so that the PCP server in the POP
could listen to eg: address1, address2, so it will work whether or not there is a PCP
server in the home.

Cheers
    Toerless

---

From: <[email-masked]>
Date: Mon, 19 Aug 2013 11:48:59 +0200

Stuart,

What you described is really deployment-specific with a focus on the CPE deployment model.

There are other deployment cases where PCP can be used to interact with multiple servers and not one, e.g.,:

* non-NAT devices in order to allow for incoming packets to be forwarded appropriated to an internal host: a typical example is a multi-homed site which cannot force the entry point to be used by incoming packets. If you have a firewall in each Border Router, you will need typically to open pinholes in those FW.

* NAT devices which assigns addresses of distinct address families. A typical example is two devices: the first one is a NAT64 while the second one is NPTv6. The discovery of the external IPv4 address assigned by the NAT64 and the external IPv6 address assigned by the NPTv6 is need to help establishing communications with remote IPvx hosts.

* multi-interfaces device which interfaces with multiple flow-aware access router.

* Etc.

Because this is deployment-specific, draft-ietf-pcp-server-selection does not assume how many servers will be enabled. It does specify the behavior to accommodate any deployment model:

* having one server to contact (with one or multiple IP addresses)
* contact multiple servers in parallel.

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]] De la part de
>Stuart Cheshire
>Envoyé : vendredi 16 août 2013 04:07
>À : [email-masked]
>Cc : [email-masked]
>Today, a network client makes a NAT mapping (or a firewall hole) by sending
>an outbound TCP SYN. That is all. If there are nested NATs, the client
>doesn't have to know about that. If there are parallel NATs with multiple
>network ingress and egress points, then the client doesn't have to know
>about that either. The NAT that sees the outbound TCP SYN is responsible
>for communicating with its NAT peers to ensure that the right state is
>created so that inbound traffic is handled correctly.
>
>Right now the Mac OS X and iOS PCP client handles only a single PCP server.
>I suspect it will only ever handle a single PCP server. I suspect that many
>consumer electronics products like network security cameras will also only
>support a single PCP server. So if you're a network router vendor that's
>selling a product that lets the customer load-balance across multiple
>ingress and egress paths, then you'd better make it look like a single PCP
>server to the client, or it won't work and you won't be able to sell it. If
>you're providing nested NAT, then you'd better make it look *exactly* like
>a single PCP server to the client (i.e. recursive PCP), or it won't work
>and you won't be able to sell it.
>
>I had originally advocated that the PCP client sends its PCP requests to a
>fixed well-known anycast address, and it's up to the network to do the
>right thing with that. In a simple network with a single NAT, the NAT
>intercepts the PCP request and handles it. In a more complicated network,
>the network may have to do more complicated things, but that's transparent
>to the client.
>
>address, so instead the client sends its requests to its default router. I
>suspect Mac OS X and iOS may only ever send their PCP requests to their
>default router.
>
>supports parallel and/or nested NATs and firewalls, it had better work with
>clients that only send requests to their default router, because that's all
>you're going to see in the field for quite some time.
>
>It's easy to write documents telling PCP clients what they should be doing,
>but I'd like to see some vendors stepping up and volunteering for that
>commitment. Do we have a vendor of some $49 network security camera
>volunteering to support multiple PCP servers? How would that even work? If
>it requires *any* user configuration, it's a non-starter. Once you accept
>manual user configuration, it's easier to just make some port mappings by
>hand. The win of PCP is that it allows plug-and-play zero configuration
>operation. The moment the user has to configure the device with the address
>of its PCP server, it's easier to configure the NAT gateway with a manual
>port mapping. And if you suppose a DHCP option to do this configuration,
>the home gateway has to be updated to support that DHCP option, and if you
>have to update the home gateway then it's easier to put recursive PCP
>support into the gateway (works today with all PCP clients) than it is to
>add support for the PCP DHCP option (d

---

From: <[email-masked]>
Date: Mon, 19 Aug 2013 11:50:56 +0200

Hi Dan,

That's does not work for incoming packets in some specific cases. Imagine two default routers with PCP-controlled firewall function. 

Cheers,
Med

>De : Dan Wing [mailto:[email-masked]]
>Envoyé : vendredi 16 août 2013 04:40
>À : Ted Lemon
>Cc : Stuart Cheshire; pcp@; [email-masked]
>On Aug 15, 2013, at 7:21 PM, Ted Lemon <[email-masked]> wrote:
>
>> On Aug 15, 2013, at 10:06 PM, Stuart Cheshire <[email-masked]> wrote:
>> Wait, what?   What happens if there are two default routers?
>
>Only one of them would get a TCP SYN that the host sends off the local
>network.  Same logic -- whatever that logic -- would determine which
>default router is used by PCP.
>
>-d

---

From: <[email-masked]>
Date: Mon, 19 Aug 2013 13:20:40 +0200

Dan,

For the typical use case you mentioned (i.e., PCP service operated by an operator), having an explicit provisioning means to enabled/disable PCP service is more likely for various reasons such as:

* Avoid overloading the network with useless traffic (e.g., limit the usage of radio resources for the mobile network). 
* Flow-based access control policies may not be managed by an on-path device (e.g., separate PCP server and PCP-controlled device model)
* Multiple flow-based policies may be enforced at multiple entry points. Having a means to interact with all of them in // is likely to be required.
* The node which enforces the flow-based policies may not be able to relay the request to another upstream PCP-controlled device (e.g., not explicitly configured to do so)
* The anycast-based model will require Epoch values are appropriately configured in multiple servers listening on the same address; if not the client won't be able to detect state loss when a failure occurs.
* The anycast-based model cannot work in the proxy model if non-explicit server(s) is configured to the proxy: this is a simple forwarding issue (the proxy should listen on anycast address and use that same address to reach the upstream server).  

Cheers,
Med

>De : [email-masked] [mailto:[email-masked]] De la part de Dan
>Wing
>Envoyé : vendredi 16 août 2013 04:49
>À : Stuart Cheshire
>Cc : [email-masked]; [email-masked]
>Objet : [pcp] well-known address for PCP [was Re: Comments on draft-ietf-
>pcp-server-selection-01]
>
>
>multiple network ingress and egress points, then the client doesn't have to
>know about that either. The NAT that sees the outbound TCP SYN is
>responsible for communicating with its NAT peers to ensure that the right
>state is created so that inbound traffic is handled correctly.
>>
>server. I suspect it will only ever handle a single PCP server. I suspect
>that many consumer electronics products like network security cameras will
>also only support a single PCP server. So if you're a network router vendor
>that's selling a product that lets the customer load-balance across
>multiple ingress and egress paths, then you'd better make it look like a
>single PCP server to the client, or it won't work and you won't be able to
>sell it. If you're providing nested NAT, then you'd better make it look
>*exactly* like a single PCP server to the client (i.e. recursive PCP), or
>it won't work and you won't be able to sell it.
>>
>> I had originally advocated that the PCP client sends its PCP requests to
>a fixed well-known anycast address, and it's up to the network to do the
>We have encountered use cases where such a well-known anycast address would
>be very useful, most notably with draft-wing-pcp-flowdata where an existing
>non-PCP-aware router or NAT is in the local network and the ISP is
>operating a PCP-speaking and draft-wing-pcp-flowdata-aware router, and we
>want to use draft-wing-pcp-flowdata to ask the ISP to provide
>differentiated service for a certain flow (e.g., make Skype or Netflix work
>better than BitTorrent in the downstream direction).  Reinaldo wrote up
>draft-kiesel-pcp-ip-based-srv-disc, but as it wasn't on PCP's agenda I have
>not researched how Reinaldo's proposal differs from draft-cheshire-pcp-
>anycast.
>
>-d
>
>

---

From: Dan Wing <[email-masked]>
Date: Mon, 19 Aug 2013 09:40:36 -0700

> That's does not work for incoming packets in some specific cases. Imagine two default routers with PCP-controlled firewall function. 

You're describing a situation where we use MAP to 'listen', and accept connections on both of those different networks.  Yes, that works differently than sending a TCP SYN.  For that to work with an anycast address, the two PCP-controlled firewalls would have to synchronize state amongst themselves, or don't use anycast in such a network topology and leave the PCP client to communicate with the several PCP servers itself.

-d