Subject: [pcp] discuss: DS-lite interaction, "Encapsulation mode" versus "Plain IPv6 Mode" (issue #13)

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Dec 2010 09:17:49 -0800

This thread is for discussion of Issue #13, "DS-lite interaction",
http://trac.tools.ietf.org/wg/pcp/trac/ticket/13

Please see the link above, and provide feedback on preferences.  

I would like to nail down one mechanism for DS-Lite unless there is a
compelling reason to allow both mechanisms.

-d

---

From: <[email-masked]>
Date: Mon, 13 Dec 2010 19:55:13 +0100

Hi Dan, all,

It seems to me the use of the encapsulated mode does not break the feature defined in the draft to detect the presence of a NAT in the path. If the plain IPv6 mode was used, a PCP Client may think it is behind a NAT while it is not (the source IP address that will be returned by the server will be IPv6 while the PCP request is issued over IPv4).

The plain IPv6 has the advantage of avoiding the de-capsulation/encap function in case the same PCP Server is used to control various functions (e.g., DS-Lite NAT44, NAT64, etc.). This may have no value if the PCP Server is embedded in the same device as the DS-Lite AFTR. 

IMHO, it is simpler to use the encapsulated mode and to abandon the plain IPv6 mode.

Cheers,
Med 

________________________________________
De : [email-masked] [[email-masked]] de la part de Dan Wing [[email-masked]]
Date d'envoi : lundi 13 décembre 2010 18:17
À : [email-masked]
Objet : [pcp] discuss: DS-lite interaction,     "Encapsulation mode" versus "Plain IPv6 Mode" (issue #13)

-d

_______________________________________________
pcp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcp

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 Dec 2010 00:25:39 +0100

If we really want only one mode it must be the "Plain IPv6 Mode" because
it is the only mode which works well with all deployments of PCP server
(cd base-00 10.1), in particular the not-embedded case.

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 Dec 2010 00:31:43 +0100

In your previous mail you wrote:

   It seems to me the use of the encapsulated mode does not break the
   feature defined in the draft to detect the presence of a NAT in the
   path. If the plain IPv6 mode was used, a PCP Client may think it
   is behind a NAT while it is not (the source IP address that will be
   returned by the server will be I Pv6 while the PCP request is
   issued over IPv4).
   
=> this only proves the current NAT detection is broken (:-).

Regards

---

From: Tina Tsou <[email-masked]>
Date: Mon, 13 Dec 2010 15:43:15 -0800

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francis Dupont
Sent: Monday, December 13, 2010 3:32 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pcp] RE : discuss: DS-lite interaction, "Encapsulation mode"
versus "Plain IPv6 Mode" (issue #13)

   

[In this sense, should we only define the unbroken one: "Encapsulation
mode"?]

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 Dec 2010 00:48:03 +0100

Please note the simplicity of the encapsulation mode is only apparent,
for instance the B4 should like to look at the requests, for instance
to check allow or disallow third party requests (and this decision is
local, i.e., should be performed by the B4 and not the server), or
pinhole its firewall (i.e., filtering of incoming connections from
the Internet).

Of course on the AFTR/PCP server side the situation is clearer:
the encapsulated request is needed so it needs a dedicated
processing (what is called on a NAT an ALG), something which is
not recommended.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 Dec 2010 00:50:26 +0100

=> no, we should:
 1- note to fix the NAT detection
 2- not use this argument for mode choice.

Regards