Re: [pcp] Detect an on-path NAT (was RE: draft-wing-pcp-base-01 posted)

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med 

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


>  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.
> 
> 
>    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 struggled with how to encode this while I was writing it up.  
Originally I had a separate OpCode.  

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.

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
>    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.

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.

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

>    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.

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.

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.

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



*********************************
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.
********************************