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

[Reinaldo Penno <[e-mail]>]

Certainly. We also discussed that error codes should be set appropriately
even in the case the PCP Server gets 4 requests in your scenario. The
current "Unsupported Opcode" should be fine if it is a "fatal, never try it
again" type of error. Each client would try once and be done.

We need some other error that says

"Unsupported opcode in this domain"

Meaning the PCP server understands the opcode but can not fulfill such
requests when coming through this interface(s), zone, others. This is also a
"fatal, never try it again" type of error.

Thanks,

Reinaldo


On 10/28/10 8:34 AM, "[e-mail]"
<[e-mail]> wrote:

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