Subject: [BEHAVE] draft-ietf-behave-nat64-discovery-heuristic in PCP-enabled networks?

From: <[email-masked]>
Date: Fri, 7 Sep 2012 08:43:11 +0200

Dear all,

I bring this discussion point to behave ML as draft-ietf-behave-nat64-discovery-heuristic was cited by Simon and Reddy in PCP ML.

Context: There are plans to use PCP to control an upstream NAT64. For such contexts, using PCP to retrieve the PREFI64 is straightforward.

Discussion: Should draft-ietf-behave-nat64-discovery-heuristic say something about the applicability scope? Is it justified to implement this heuristic to retrieve an information which is available via PCP?

Cheers,
Med

---

From: <[email-masked]>
Date: Fri, 7 Sep 2012 07:11:50 +0000

Hi Med, All,

It is justified, because the heuristic approach was specifically developed to allow discovery of Pref64::/n when the network does not explicitly provide the information (by any means that are generally available). Even if PCP would provide this information, there is no telling what kind of deployment PCP will see and especially will there always be PCP when there is NAT64.

Furthermore, will the PCP *always* tell the Pref64::/n, or is that also PCP deployment specific detail?

IMHO PCP proposal for Pref64::/n falls to similar category as DHCPv6 in the draft-ietf-behave-nat64-learn-analysis-03.txt. I.e. it may not be deployed alongside NAT64, it requires PCP client implementation on a node, and so forth.

Best regards,

                Teemu

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: 07. syyskuuta 2012 09:43
To: [email-masked]
Subject: [BEHAVE] draft-ietf-behave-nat64-discovery-heuristic in PCP-enabled networks?

Dear all,

Cheers,

Med

---

From: Simon Perreault <[email-masked]>
Date: Fri, 07 Sep 2012 08:45:56 -0400

On 09/07/2012 03:11 AM, [email-masked] wrote:
> IMHO PCP proposal for Pref64::/n falls to similar category as DHCPv6 in
> the draft-ietf-behave-nat64-learn-analysis-03.txt. I.e. it may not be
> deployed alongside NAT64, it requires PCP client implementation on a
> node, and so forth.

Yes they are similar, but there are differences:

>    The PROs of the proposal are listed below:
>
>    +  Can be used to solve Issue #1, Issue #2, Issue #3 and Issue #4 via
>       DHCPv6 information lifetime.

Same for PCP.

>    +  Does not involve DNS system.  Therefore, applications that would
>       not normally initiate any DNS queries can still learn the NAT64
>       prefix.

Same for PCP.

>    +  DHCPv6 is designed to provide various kinds of configuration
>       information in a centrally managed fashion.

Not really the same, but this is fuzzy...

>    The CONs of the proposal are listed below:
>
>    -  Change of NSP requires change to DHCPv6 configuration.

Here PCP is different: since the PCP server presumably has direct access 
to CGN configuration, there is no need to change the PCP server 
configuration.

>    -  Requires at least Stateless DHCPv6 client on hosts.

PCP requires a PCP client on hosts.

>    -  Requires support on DHCPv6 clients, which is not trivial in all
>       operating systems.

PCP requires support on PCP clients.

>    -  The DHCPv6-based solution involves changes and management on
>       network side nodes that are not really part of the NAT64/DNS64
>       deployment (or issues caused by their existence).

This does not apply to PCP.

>    -  A new DHCPv6 option is required and the corresponding changes to
>       both DHCPv6 clients and servers.

And a new PCP option/opcode is required.

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