Subject: [pcp] Get external IP address

From: <[email-masked]>
Date: Thu, 3 Mar 2011 10:50:56 +0100

Hi Dan, all,

We have discussed in the past the need for a method to retrieve the external IP address but without achieving any conclusion.

It is obvious this method is needed for stateless NAT for instance. For the stateful case, we have an issue with the IGD-PCP IWF since some applications (e.g., PSP) send first a GetExternalIP and then issue a request to create a port mapping. Some applications will be broken if we don't honor the GetExternalIP request.

What is the behaviour for the IWF when a IGD:GetExternalIP request is received?

* Should the IWF handle the request locally (i.e., without relaying it to the PCP Server)? This can be doable if the IWF checks its local mappings table and if it assumes that the same IP address will be assigned by the PCP Server. When there is no mapping in the local table, a solution should be found.

* The IWF can generate a "fake" MAP request to the PCP Server to retrieve the external IP address. This may increase the port conflicts in case of IGD:1 since it may consume a port which may be requested by an internal host.

* Define a new method to retrieve an external IP address. IMHO, this solution is clean: (1) it does not consume port and (2) the behaviour of IWF is simple. Of course, for the stateful case, the PCP Server need to maintain a state (user, external IP address) when there is no dynamic mappings or instantiated PCP mappings.

Thoughts?

Cheers,
Med

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

---

From: Simon Perreault <[email-masked]>
Date: Thu, 03 Mar 2011 09:24:53 -0500

On 2011-03-03 04:50, [email-masked] wrote:
> * Should the IWF handle the request locally (i.e., without relaying it
> to the PCP Server)? This can be doable if the IWF checks its local
> mappings table and if it assumes that the same IP address will be
> assigned by the PCP Server. When there is no mapping in the local
> table, a solution should be found. 
>  
> * The IWF can generate a "fake" MAP request to the PCP Server to
> retrieve the external IP address. This may increase the port conflicts
> in case of IGD:1 since it may consume a port which may be requested by
> an internal host.

I'm fine with either of these two. The latter one seems cleaner to me.
Also setting lifetime=1 reduces possible conflicts.

> * Define a new method to retrieve an external IP address. IMHO, this
> solution is clean: (1) it does not consume port and (2) the behaviour of
> IWF is simple. Of course, for the stateful case, the PCP Server need to
> maintain a state (user, external IP address) when there is no dynamic
> mappings or instantiated PCP mappings.

I would really like to avoid adding this in PCP just for the purpose of
interworking with UPnP. It's not PCP's fault that UPnP has this request
(which can be considered harmful). So in my mind it would be "fair" to
let the IWF figure out how to deal with it on its own. PCP itself should
not be burdened with such a harmful request.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 3 Mar 2011 07:13:55 -0800

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, March 03, 2011 1:51 AM
> To: [email-masked]; Dan Wing
> Subject: Get external IP address
> 
> Hi Dan, all,
> 
> We have discussed in the past the need for a method to retrieve the
> external IP address but without achieving any conclusion.
> 
> It is obvious this method is needed for stateless NAT for instance. For
> the stateful case, we have an issue with the IGD-PCP IWF since some
> applications (e.g., PSP) send first a GetExternalIP and then issue a
> request to create a port mapping. Some applications will be broken if
> we don't honor the GetExternalIP request.
>

That UPnP IGD method, like several other UPnP IGD methods, is simply
incompatible with a CGN.  There isn't a way to get it working well.
That is because a CGN typically has a large pool of dozens or hundreds
of IPv4 addresses.  To tell a client its public IP address, the CGN
needs to maintain state for an amount of time.

Let UPnP IGD die.

> retrieve the external IP address.

That's what I would recommend.

> This may increase the port conflicts

Some other subscriber might grab that port number, too; I don't see how
we can realistically worry about that with a CGN.

If that is a worry, request with lifetime=1.   Which means a subsequent 
mapping request from the client could get assigned to a different public 
address, if the PCP-controlled device is a CGN with a large pool of public 
addresses and there aren't any other mappings across the CGN.

> solution is clean: (1) it does not consume port and (2) the behaviour
> of IWF is simple. Of course, for the stateful case, the PCP Server need
> to maintain a state (user, external IP address) when there is no
> dynamic mappings or instantiated PCP mappings.

If there is a pool of public IP addresses -- such as on a PCP-controlled
CGN -- doing that requires the CGN (or PCP server) to maintain state, 
so that a subsequent mapping request from that client returns the 
same address.  If you want it to maintain state, just do a real 
mapping.

-d

> IMPORTANT.Les informations contenues dans ce message electronique y
> compris les fichiers attaches sont strictement confidentielles
> Si vous avez recu ce message par erreur ou s il ne vous est pas
> destine, veuillez immediatement le signaler  a l expediteur et effacer
> ce message
> A ce titre, le Groupe France Telecom decline toute responsabilite
> notamment s il a ete altere, deforme ou falsifie.
> IMPORTANT.This e-mail message and any attachments are strictly
> confidential and may be protected by law. This message is
> If you have received this message in error, or are not the named
> recipient(s), please immediately notify the sender and delete this e-
> mail message.
> Since e-mail messages may not be reliable, France Telecom Group shall
> not be liable for any message if modified, changed or falsified.