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

[Reinaldo Penno <[e-mail]>]

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