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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Thursday, October 28, 2010 8:34 AM
> To: Reinaldo Penno; [e-mail]
> Subject: Re: [pcp] OpCopdes (RE: draft-wing-pcp-base-01 posted)
> 
> 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.

A dual stack host has not purpose or need to send a PIN64 or PIN46.  It
has only a reason to send PIN66 or PIN44.  I explained that earlier, 
and you must have disagreed because you keep talking about 4 messages.

For an IPv4-only host, without a discovery function it might send
two PCP messages (PIN46, PIN44).  Adding a discovery function doesn't
reduce the number of messages -- it would send a discovery message
message (1 message) and then a PIN46 (2 messages) and/or PIN44 message
(3 messages).  It could, in fact, add a message.

For an IPv6-only host, it's the same analysis as an IPv6-only host.

For a dual-stack host, without a discovery function it might send two
PCP messages (PIN44, PIN66).  It has no reason to use its IPv4
interface to get an IPv6 address (PIN46), nor any reason to use
its IPv6 interface to get an IPv4 address (PIN64).  Adding a 
discovery function doesn't reduce the number of messages --
same as analysis for IPv4-only host.

-d


> 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.
> ********************************
> 
> _______________________________________________
> pcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pcp