Re: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt

Dear all,

Yes, that is the difference.

In the pcp-dslite scenario, the PCP proxy sends PCP requests within the DSlite tunnel. The receiving PCP Server/NAT can map the request to a DSlite tunnel, because it can observe from which tunnel the request comes. 

In the scenario of pcp-tunnel-id, the request comes from outside the tunnel, from a portal of the NAT operator where clients can configure their services. Here, the PCP client has to use the THIRD_PARTY option to identify the Internal Host. If the Internal Host is using private addresses, it needs further identification. This is what the TUNNEL_ID option is proposed to be used for.

Cheers,
    Juergen

> -----Original Message-----
> From: Andreas Ripke
> Sent: Freitag, 14. Februar 2014 17:09
> To: Simon Perreault; pcp@ietf.org
> Cc: Juergen Quittek; Thomas Dietz; Rolf Winter
> Subject: RE: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-
> id-option-00.txt
> 
> Hi Simon,
> 
> The use-case in draft-ietf-pcp-dslite is a different one.
> There, the PCP proxy or client is located in the customer's realm.
> What we describe is a scenario with one central PCP client located on a web
> portal serving all customers.
> Therefore, an additional identifier is needed by the PCP server to associate
> the connection to be mapped with the customer's tunnel.
> 
> Best,
> 
> Andreas
> 
> > -----Original Message-----
> > From: pcp [mailto:pcp-bounces@ietf.org] On Behalf Of Simon Perreault
> > Sent: Friday, February 14, 2014 4:09 PM
> > To: pcp@ietf.org
> > Subject: Re: [pcp] FW: New Version Notification for
> > draft-ripke-pcp-tunnel-id- option-00.txt
> >
> > Le 2014-02-14 04:07, Andreas Ripke a écrit :
> > > The below draft describes a scenario in that
> > >   (1) the subscribers behind a CGN can freely choose their internal
> > > IP
> > addresses
> > >        (which potentially leads to overlapping IP address spaces)
> > >   (2) a central PCP client is used for port mapping requests.
> > > The CGN, acting as PCP server, cannot identify the subscriber just
> > > by the
> > internal IP address provided with the THIRD_PARTY option.
> > > Therefore, an additional identifier (the subscriber’s tunnel ID) to
> > > the PCP
> > mapping request is needed.
> >
> > Eerily similar to draft-ietf-pcp-dslite...
> >
> > Why not send the PCP request inside the tunnel?
> >
> > Simon
> > --
> > DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> > NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> > STUN/TURN server               --> http://numb.viagenie.ca
> >
> > _______________________________________________
> > pcp mailing list
> > pcp@ietf.org
> > https://www.ietf.org/mailman/listinfo/pcp