Re: [BEHAVE] [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-prefix64-option

Hi Teemu,

(behave ML cced)

The point is: for PCP-enabled networks the heuristic seems to be more "complex" compared to returning this information using PCP.

>From an operational standpoint, the situation is as follows:

* PCP is needed for NAT64 to accept incoming connections/hosting servers/reduce keepalive messages/etc. 
* A solution to learn the PREFIX64 is needed (e.g., IPv4 in referrals) so that local address synthesis can be done by the host.
* Several NAT64 can be deployed and load balancing enabled to distribute connected hosts: this can be done by assigning distinct PREFIX64s.
* An application/host needs to retrieve the exact PREFIX64 used for the NAT64 to be involved in the data path.
* An exist strategy is still to be found for the heuristic method.
* The heuristic method requires some tweaking in DNS.

Given what listed above, wouldn't be safe to provide some guidelines to help selecting which option to use in PCP-based networks or the one to prefer when both are available? 

Cheers,
Med

>-----Message d'origine-----
>De : teemu.savolainen@nokia.com [mailto:teemu.savolainen@nokia.com] 
>Envoyé : vendredi 7 septembre 2012 09:15
>À : BOUCADAIR Mohamed OLNC/NAD/TIP; simon.perreault@viagenie.ca
>Cc : pcp@ietf.org
>Objet : RE: [pcp] PREFIX64 PCP Option for NAT64: 
>draft-boucadair-pcp-nat64-prefix64-option
>
>Just quick comment also for PCP mailing (I sent separate email 
>also to behave) - maybe we need to cross post if this 
>discussion extends.
>
>The PCP may be fine way to learn Pref64::/n, but I doubt it is 
>possible to generalize PCP to be always present *and* telling 
>Pref64::/n when there is NAT64. I.e. PCP would be similar as 
>DHCPv6 in its pros/cons (as listed in 
>draft-ietf-behave-nat64-learn-analysis) - am I right?
>
>I.e. we need the heuristic to have a general way to find out 
>Pref64::/n, as we cannot count PCP to be always deployed with NAT64.
>
>Best regards,
>
>        Teemu
>
>> -----Original Message-----
>> From: pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] On 
>Behalf Of ext
>> mohamed.boucadair@orange.com
>> Sent: 07. syyskuuta 2012 08:26
>> To: Simon Perreault
>> Cc: pcp@ietf.org
>> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64: 
>draft-boucadair-pcp-
>> nat64-prefix64-option
>>
>> Hi Simon,
>>
>> Perhaps it is too late to ask for including it in the analysis draft.
>> I see another place where we can ask for including it is: 
>464xlat v6op draft.
>>
>> Cheers,
>> Med
>>
>> >-----Message d'origine-----
>> >De : Simon Perreault [mailto:simon.perreault@viagenie.ca]
>> >Envoyé : jeudi 6 septembre 2012 17:29
>> >À : BOUCADAIR Mohamed OLNC/NAD/TIP
>> >Cc : pcp@ietf.org
>> >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64:
>> >draft-boucadair-pcp-nat64-prefix64-option
>> >
>> >Le 2012-09-06 11:04, mohamed.boucadair@orange.com a écrit :
>> >> Med: I'm open to evaluate which approach is better: new opcode vs.
>> >> new option. We need first to agree this is valid problem to solve.
>> >
>> >There is clearly a need to discover the NAT64 prefix:
>> >draft-ietf-behave-nat64-learn-analysis
>> >draft-ietf-behave-nat64-discovery-heuristic
>> >
>> >Note that the analysis draft does not consider PCP. Maybe it should.
>> >Looking at the list of pros and cons for DHCPv6, PCP would be
>> >different, and better in some aspects.
>> >
>> >Personally I would much prefer using PCP than the heuristic 
>when PCP is
>> >available.
>> >
>> >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
>