Re: [pcp] OpCopdes (RE: draft-wing-pcp-base-01 posted)

[<[e-mail]>]

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:[e-mail]] 
Envoyé : jeudi 28 octobre 2010 12:18
À : BOUCADAIR Mohamed NCPI/NAD/TIP; [e-mail]
Objet : Re: [pcp] OpCopdes (RE: draft-wing-pcp-base-01 posted)

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









On 10/27/10 11:15 PM, "[e-mail]"
<[e-mail]> wrote:

> 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:[e-mail]]
> Envoyé : mercredi 27 octobre 2010 20:26
> À : Dan Wing; BOUCADAIR Mohamed NCPI/NAD/TIP; [e-mail]
> Objet : Re: [pcp] OpCopdes (RE: draft-wing-pcp-base-01 posted)
> 
> 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
> 
> 
> 
> On 10/27/10 11:17 AM, "Dan Wing" <[e-mail]> wrote:
> 
>> 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.
> 
> 
> *********************************
> 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.
> ********************************
> 


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