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

From: Andreas Ripke <[email-masked]>
Date: Fri, 14 Feb 2014 09:07:11 +0000

Hi,

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.

If you have any comments on this draft please let us know. Thanks.

Best,

Andreas

NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB | Registered in England 2832014

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, February 13, 2014 4:51 PM
> To: Andreas Ripke; Rafael Lopez da Silva; Rafael Lopez da Silva; Thomas Dietz;
> Juergen Quittek; Juergen Quittek; Thomas Dietz; Andreas Ripke
> Subject: New Version Notification for draft-ripke-pcp-tunnel-id-option-00.txt
> 
> 
> A new version of I-D, draft-ripke-pcp-tunnel-id-option-00.txt
> has been successfully submitted by Andreas Ripke and posted to the IETF
> repository.
> 
> Name:		draft-ripke-pcp-tunnel-id-option
> Revision:	00
> Title:		PCP Tunnel-ID Option
> Document date:	2014-02-13
> Group:		Individual Submission
> Pages:		8
> URL:            http://www.ietf.org/internet-drafts/draft-ripke-pcp-tunnel-id-
> option-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-ripke-pcp-tunnel-id-option/
> Htmlized:       http://tools.ietf.org/html/draft-ripke-pcp-tunnel-id-option-00
> 
> 
> Abstract:
>    This document describes a new Port Control Protocol (PCP) option
>    called TUNNEL_ID.  It serves for identifying a Third Party in
>    addition to the means that PCP's THIRD_PARTY option already provides
>    for that purpose.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat

---

From: Simon Perreault <[email-masked]>
Date: Fri, 14 Feb 2014 10:08:30 -0500

> 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

---

From: Andreas Ripke <[email-masked]>
Date: Fri, 14 Feb 2014 16:09:11 +0000

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

> From: pcp [mailto:[email-masked]] On Behalf Of Simon Perreault
> Sent: Friday, February 14, 2014 4:09 PM
> To: [email-masked]
> Subject: Re: [pcp] FW: New Version Notification for draft-ripke-pcp-tunnel-id-
> option-00.txt
> 
> > The CGN, acting as PCP server, cannot identify the subscriber just by the
> internal IP address provided with the THIRD_PARTY option.
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Juergen Quittek <[email-masked]>
Date: Sat, 15 Feb 2014 18:46:37 +0000

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
 
> From: Andreas Ripke
> Sent: Freitag, 14. Februar 2014 17:09
> To: Simon Perreault; [email-masked]
> 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,
> 
> Therefore, an additional identifier is needed by the PCP server to associate
> the connection to be mapped with the customer's tunnel.
> 
> Best,
> 
> Andreas
> 
> > Subject: Re: [pcp] FW: New Version Notification for
> > draft-ripke-pcp-tunnel-id- option-00.txt
> >
> > >   (1) the subscribers behind a CGN can freely choose their internal
> > > IP
> > addresses
> > > Therefore, an additional identifier (the subscriber’s tunnel ID) to
> > > the PCP
> > mapping request is needed.
> >