Subject: [pcp] discuss: PCP server discovery

From: "Dan Wing" <[email-masked]>
Date: Tue, 7 Dec 2010 11:18:44 -0800

This is one of the PCP discussion points.

We have not discussed PCP server discovery on the mailing list nor at
face-to-face meetings.  

Currently, the PCP specification says
(http://tools.ietf.org/html/draft-ietf-pcp-base-00#section-4):

   4. PCP Server Discovery

   There are several possible methods to discover a PCP Service:

   o  sending the PCP message to the default router.  This requires the
      default router to support PCP.

   o  a fixed IPv4 and a fixed IPv6 address, to be assigned by IANA.
      This follows the same routing path as other Internet-bound
      traffic.

         [Ed.  Note: For an IPv4 address, would the AFTR element's IPv4
         address, 192.0.0.1 [I-D.ietf-softwire-dual-stack-lite], be
         suitable as this address for DS-Lite deployments?  Would that
         same address be suitable for all PCP deployment scenarios?]

   o  New DHCP option.  This requires the local network's DHCP server
      support the new option.

      [Ed.  Note: more discussion around these methods is necessary to
      reach consensus on the best approach(es)s for PCP.]

The first method, sending the PCP message to the default router, requires
that the default router support PCP.  This would not work well in a NAT444
deployment if there are routers between the subscriber's CPE and the ISP's
PCP server -- those routers would all need to support forwarding PCP
messages upstream to each other.  In other deployments, such as DS-Lite, it
would work okay but would fail if the subscriber's home was not routed (that
is, was only L2).

The second method, sending the PCP message to an IANA-allocated IP address,
means the PCP packets follow the same path as an outgoing connection attempt
to the Internet (the same path a TCP SYN would follow).  This has a lot of
appeal, because the PCP server will either exist (and be on the path) or
won't exist.  This doesn't require any special support on routers along the
path.

The third method requires a DHCP option.  This would take years to deploy
and require CPE to support this new DHCP option, and require ISPs to add
this option to their DHCP servers, and require the underlying OS to support
the ability for the PCP applications to query the new DHCP option.  To me,
this has significant barriers to deployment.  

Any comments on the analysis above?

Does anyone have other ideas for PCP server discovery, and can you also
provide Pro/Con for your idea? 

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 7 Dec 2010 14:37:35 -0500

Comments inline...

> would work okay but would fail if the subscriber's home was not routed (that

Agreed.

> won't exist.  This doesn't require any special support on routers along the

If this is a public address and everybody will have the same it might cause
routing issues. If it is private, wouldn't that indirectly dictate the
numbering of the internal network to a degree?

This might not be an issue for DS-Lite (or even NAT64) due to
tunneling/concatenation respectively but it might impact NAT444.

> this has significant barriers to deployment.

Yes, like other DHCP options (6rd, DS-Lite, etc) it might take time to roll
out but in the long term might be a better solution. The DHCP option in
certain deployments might only need to be understood by the CPE (UPnP-PCP
interworking). In other words, maybe we should keep DHCP on the radar. But I
do not feel strongly about it.

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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 7 Dec 2010 11:50:54 -0800

> -----Original Message-----
> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Tuesday, December 07, 2010 11:38 AM
> To: Dan Wing; [email-masked]
> Subject: Re: [pcp] discuss: PCP server discovery
> 
> Comments inline...
> 
> 
> If this is a public address and everybody will have the same it might
> cause routing issues.

Can you elaborate on 'routing issues'?  (Also see below.)

> If it is private, wouldn't that indirectly dictate the

Let's pretend, for the sake of discussion, that PCP uses 192.0.0.1
as the PCP server's address, hardcoded into PCP clients.  (Yes,
I know that 192.0.0.1 comes from DS-Lite.)

There are two cases that I see:

  1. the ISP operates a PCP server, and routes 192.0.0.1 to
     their PCP server.
  2. the ISP is not operating a PCP server, and does nothing
     at all with 192.0.0.1.

In the case of (1), this works exactly like any other IP address
for any other server.  If the PCP server is integrated into
the NAT, there is actually nothing interesting or special the
ISP does with routing 192.0.0.1 -- the packets will simply
follow their default route (towards the Internet) and be
intercepted by the PCP server looking for destination 
address=192.0.0.1.  If the PCP server is *not* integrated into
the NAT, the ISP will need to somehow attract traffic to 
the correct PCP server.  Where "correct PCP server" is
the same PCP server that would handle the traffic following
the default route.

In the case of (2), the packets sent to 192.0.0.1 will be
forwarded upstream and dropped because nobody is advertising
192.0.0/24 on the Internet.  (Much as nobody advertises
RFC1918 addresses on the Internet).

> interworking). In other words, maybe we should keep DHCP on the radar.
> But I do not feel strongly about it.

However, a problem with using DHCP is that the PCP server configured
in DHCP might not be on the natural default route routing path.  This
can cause the *wrong* PCP server to be contacted, and the PCP-
created mapping to be completely worthless.

This problem happens, today, if two UPnP IGD devices are accidentally
visible to the same host -- a mapping can be created on one, and
when a TCP SYN arrives (from the Internet), the SYN ACK response
follows the default route and goes out a different path, and
incoming connections don't work.

-d

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Dec 2010 21:03:49 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan
> Wing
> Sent: Tuesday, December 07, 2010 11:19 AM
> To: [email-masked]
> Subject: [pcp] discuss: PCP server discovery
> 
> We have not discussed PCP server discovery on the mailing list nor at face-to-
> face meetings.
> 
> The first method, sending the PCP message to the default router, requires that
> the default router support PCP.  This would not work well in a NAT444
> deployment if there are routers between the subscriber's CPE and the ISP's PCP
> server -- those routers would all need to support forwarding PCP messages
> upstream to each other.  In other deployments, such as DS-Lite, it would work
> okay but would fail if the subscriber's home was not routed (that is, was only
> L2).

This is a simple method that's useful as a last resort when all discovery mechanisms fail.

> appeal, because the PCP server will either exist (and be on the path) or won't
> exist.  This doesn't require any special support on routers along the path.

This has a number of problems.   
1) Unlike all other methods suggested so far, this one can only discover one at a time.
2) It requires an IANA-allocated IP address which might(?) be difficult to get.
3) It doesn't do anything that can't be done with DHCP.

> 
> The third method requires a DHCP option.  This would take years to deploy and
> require CPE to support this new DHCP option, and require ISPs to add this option
> to their DHCP servers, and require the underlying OS to support the ability for
> the PCP applications to query the new DHCP option.  To me, this has significant
> barriers to deployment.

Requiring a PCP-speaking CPE to support it is easy since we're already requiring 
them to change to support PCP.

Adding an option to DHCP servers is already doable today.

Requiring a PCP-speaking OS to support it is straightforward if they have to change
to support PCP anyway (and Windows already has the ability for applications to
query new DHCP options).

So I don't see this as a big deal at all.

> provide Pro/Con for your idea?

My strawman suggestion would be:
* If a PCP server list is manually configured, use it.  Else,
* If DHCP provides a list, use it.  Else,
* Use the default router list.

-Dave

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 7 Dec 2010 16:22:33 -0800

> From: Dave Thaler [mailto:[email-masked]]
> Sent: Tuesday, December 07, 2010 1:04 PM
> Subject: RE: [pcp] discuss: PCP server discovery
> 
> face-to-

True.  Which has two side effects:

  1. it creates a restriction for nested NATs, specifically that
     if the NAT closest to the subscriber implements a PCP server
     and processes, we must necessarily also require that PCP 
     server to function as a client to communicate with the next
     upstream PCP server.  Something like this:

     PC------[NAT w/PCP]----[NAT w/PCP]----[NAT w/PCP]----[... ...]
      |         ^    |         ^    |         ^     |        ^
      V         |    V         |    V         |     V        |
      +->-PCP->-+    +->-PCP->-+    +->-PCP->-+     +->-PCP->+

     This is not necessarily a bad thing.  But I thought I would
     point out this happens as a side-effect.
 
  2. it only finds one PCP server, as you point out.  This means
     it would only work successfully in a single-homed networks.

     I suggest, though, that we are well within the 80%/20% rule
     by only worrying about single-homed networks.

     Multi-homed networks could use, or could require, a DHCP
     option so that multiple PCP servers could be configured.

> 2) It requires an IANA-allocated IP address which might(?) be difficult

DS-Lite was able to get an IANA-allocated IP address from the 192.0.0.0/24
range, RFC5736.  PCP, like DS-Lite, is a protocol necessary for successful
transition to IPv6.

> Requiring a PCP-speaking CPE to support it is easy since we're already
> requiring them to change to support PCP.
> 
> Requiring a PCP-speaking OS to support it is straightforward if they
> have to change to support PCP anyway (and Windows already has the 
> ability for applications to query new DHCP options).
> 

What about Linux, OSX, Android, and so on.  Or is that a good questin
for the DHC working group?

> * Use the default router list.

Alright.

-d

---

From: <[email-masked]>
Date: Wed, 8 Dec 2010 08:22:45 +0100

Dear all,

I agree with Dave analysis.

Below some more comments.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dave Thaler
Envoyé : mardi 7 décembre 2010 22:04
À : Dan Wing; [email-masked]
Objet : Re: [pcp] discuss: PCP server discovery

Med: (1) This method does not work for NAT64 scenarios. (2) if the plain IPv6 mode is used for ds-lite, the first router may not be the one which embeds the PCP server.

Med: this solution works for ds-lite if the encap scheme is used to send PCP messages, but it may not work in some scenarios such as NAT64 because the PCP messages may be handled by a PCP Server embedded in a NAT which does not handle IP packets issued from that host.

Med: +1.

*********************************
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: Shane Amante <[email-masked]>
Date: Wed, 8 Dec 2010 07:31:24 -0700

Hi Dan,

> this has significant barriers to deployment.

What about a fourth method, which is the PCP server(s) announce itself/themself using multicast?  Specifically, couldn't one use either:
a)  Organization-Local or Site-Local Scope Multicast Address; or,
http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml#multicast-addresses-12
http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml#ipv6-multicast-addresses-3

b)  newly allocated reserved Multicast Address

-shane

---

From: <[email-masked]>
Date: Wed, 8 Dec 2010 15:47:03 +0100

Dear Shane,

This method may not work for networks where multicast is not deployed. Note also that PCP-controlled devices such as CGNs are not in the same LAN where the PCP Client is located.

Another issue I see with multicast is how to select the appropriate PCP Server when several ones are received by a PCP Client. The selected PCP Server must control the NAT/firewall that will be crossed by issued traffic. This would require to advertise further information when announcing the PCP Server; this can be for instance implemented using a SLP template. To my knowledge, SLP is not widely deployed.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Shane Amante
Envoyé : mercredi 8 décembre 2010 15:31
À : Dan Wing
Cc : [email-masked]
Objet : Re: [pcp] discuss: PCP server discovery

Hi Dan,

-shane

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Dec 2010 07:17:53 -0800

...
> Med: this solution works for ds-lite if the encap scheme is used to
> send PCP messages, but it may not work in some scenarios such as NAT64
> because the PCP messages may be handled by a PCP Server embedded in a
> NAT which does not handle IP packets issued from that host.

A host route can easily steer that traffic to the PCP server.

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 18:07:25 +0100

In fact I believe the solution should depend on the scenario,
and what is the targeted PCP server in the multiple NAT case:
 - for AFTR we already have DHCPv6 so it is not a problem to add
  a PCP server option
 - it is less clear for the NAT444 CGN but other options don't work well
  and DHCP is something well understood by operators so I'd like to
  get DHCP too for this case
 - for a home gateway the default router idea is not silly so I am
  for trying it first

Now about methods:
 - the default router method is simple so IMHO it is a good idea to
  try it first in cases it likely works
 - the fixed address doesn't work at all with multiple NATs or with
  PCP relays so IMHO it is the worst proposed method
 - DHCP will work well as soon as there is a managed infrastructure
  so it should be used as soon as a light-weight method is not required.

Three remarks:
 - what we need is in fact a NAT detection protocol. Unfortunately if
  it is easy to detect the presence of at least one NAT on a path,
  it is far harder to get the position of the NAT.
 - the '(and be on the path)' in the second method description is not
  always true: it makes the assumption the PCP server and the NAT/firewall
  are co-located.
 - the router alert option is today considered as a bad idea, we should
  not try to copy this idea...

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 18:35:36 +0100

=> a router can't send a packet to another node when it believes
it owns the destination address.

=> this is a generic problem: if there are two NATs in the home network
no proposed method can recover from an asymetrical routing.

BTW DHCP puts thing in the hands of a manager: it has a clear cons,
one needs a manager, but a clear pros too: the manager has the tools
to solve problems including with complex topologies.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 19:09:35 +0100

=> I vote for this!

PS: I prefer 'the default router' than 'the default router list'
in this case (as if there are more than one default router bad things
can (so will) happen :-).

---

From: Dave Thaler <[email-masked]>
Date: Wed, 8 Dec 2010 18:36:22 +0000

Francis Dupont wrote:
[...]
> in this case (as if there are more than one default router bad things can (so will)
> happen :-).

Can you elaborate?   I think we want to make sure you can have more than
one default router without bad things happening.

-Dave

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 23:15:39 +0100

What about a fourth method, which is the PCP server(s) announce
   itself/themself using multicast?  Specifically, couldn't one use
   either:
   a)  Organization-Local or Site-Local Scope Multicast Address; or,
   http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml#multicast-addresses-12
   http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml#ipv6-multicast-addresses-3

=> I am afraid it is not better than the default router (applicable in
the same environment which the same kind of constraints)...

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2010 00:13:57 +0100

=> there is already a message in this list about bad things which
can happen with 2 UPnP IGD devices so I am afraid we have not to go
far to find an example.

Regards

---

From: <[email-masked]>
Date: Thu, 9 Dec 2010 07:59:39 +0100

Hi Dan,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 8 décembre 2010 16:18
À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Dave Thaler'; [email-masked]
Objet : RE: [pcp] discuss: PCP server discovery

...

Med: Can you please explain how this can be done to force PCP packet to reach the PCP Server which control the appropriate NATxy when several ones are deployed (e.g., several NAT64 with distinct Pref64s)?

---

From: Tina Tsou <[email-masked]>
Date: Thu, 09 Dec 2010 11:39:13 -0800

I agree with Dave proposed discovery steps.
   * If a PCP server list is manually configured, use it.  Else,
   * If DHCP provides a list, use it.  Else,
   * Use the default router list. (But this has problem for the two default route case).

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, December 08, 2010 11:00 PM
To: Dan Wing; 'Dave Thaler'; [email-masked]
Subject: Re: [pcp] discuss: PCP server discovery

Hi Dan,

Please see inline.

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mercredi 8 décembre 2010 16:18
À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Dave Thaler'; [email-masked]
Objet : RE: [pcp] discuss: PCP server discovery

...

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Dec 2010 16:40:25 -0800

> Med: Can you please explain how this can be done to force PCP packet to
> reach the PCP Server which control the appropriate NATxy when several
> ones are deployed (e.g., several NAT64 with distinct Pref64s)?

Insert the host route immediately in front of the NAT64, such as
one router hop away from the NAT64.

-d

---

From: <[email-masked]>
Date: Tue, 14 Dec 2010 07:14:01 +0100

Hi Dan,

Even if I admit I don't see exactly how this will work (one IP address to reach any PCP Server in case two NAT64-enabled devices with two Pref64 are deployed for instance), but is this a generic configuration valid for any NAT64 deployment scheme? 

The PCP server discovery should be deterministic and should avoid having pre-requisites on the underlying topology and configuration. 

Cheers,
Med

-----Message d'origine-----
De : Dan Wing [mailto:[email-masked]] 
Envoyé : mardi 14 décembre 2010 01:40
À : BOUCADAIR Mohamed NCPI/NAD/TIP; 'Dave Thaler'; [email-masked]
Objet : RE: [pcp] discuss: PCP server discovery

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 14 Dec 2010 08:00:59 -0800

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Monday, December 13, 2010 10:14 PM
> Even if I admit I don't see exactly how this will work (one IP address
> to reach any PCP Server in case two NAT64-enabled devices with two
> Pref64 are deployed for instance), but is this a generic configuration
> valid for any NAT64 deployment scheme?
> 
> The PCP server discovery should be deterministic and should avoid
> having pre-requisites on the underlying topology and configuration.

Let's say you're right.  Then, after port forwarding is configured
to run a server on two different NAT64s with different prefixes,
an TCP SYN arrives at the host.  It needs to respond with a TCP
SYNACK.  It will respond using the same interface the SYN packet
arrived from which will -- by necessity -- go out the same NAT64
the packet arrived from (or the TCP connection setup fails).  
Thus, a TCP connection has to take a certain path, which is 
dictated by the network topology.

PCP can use that same path.

-d