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

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med
  

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] 
>Envoyé : vendredi 7 septembre 2012 11:57
>À : BOUCADAIR Mohamed OLNC/NAD/TIP; [e-mail]
>Cc : [e-mail]; [e-mail]
>Objet : RE: [pcp] PREFIX64 PCP Option for NAT64: 
>draft-boucadair-pcp-nat64-prefix64-option
>
>Hi Med,
>
>From a host standpoint there are no guarantees to have PCP 
>always available when a NAT64 is present. 

Med: Yes, this is deployment-specific. Note the LSN requirements draft mandates to have a way to open mappings.

Hence heuristic is 
>needed anyway, but as an optimization/improvement it is 
>possible to avoid heuristic in cases where PCP happens to be available.

Med: This is what I wanted to hear. The intent was not to say PCP is better. My initial discussion point was focusing on PCP-enabled networks and only that case. Concretely, would it be possible to add a sentence in the sense of your statement above? 

>
>To respond to your detailed points:
>
>> * PCP is needed for NAT64 to accept incoming connections/hosting
>> servers/reduce keepalive messages/etc.
>
>Only if an operator chooses to provide these goodies to hosts; 
>I have no evidence that says all operators who deploy NAT64 
>are ok to allow incoming connections/hosting services/helping 
>hosts to reduce keepalive signaling. I do hope PCP finds its 
>place in networks and helps save battery etc, but it is not 
>something that can be assumed to happen (always).

Med: That's fair. Again, I'm exclusively positioning this discussion in context where PCP is deployed.

>
>> * A solution to learn the PREFIX64 is needed (e.g., IPv4 in 
>referrals) so that
>> local address synthesis can be done by the host.
>
>Agree:)
>
>> * Several NAT64 can be deployed and load balancing enabled 
>to distribute
>> connected hosts: this can be done by assigning distinct PREFIX64s.
>
>Yes, but do you need to make an individual host use multitude 
>of Pref64::/n? In a large deployment wouldn't the load 
>balancing purposes be achieved by some hosts using one 
>Pref64::/n and others using another?
>
>> * An application/host needs to retrieve the exact PREFIX64 
>used for the
>> NAT64 to be involved in the data path.
>
>You plan to utilize different Pref64::/n for different IPv4 
>destinations? That is definitely something heuristic does not 
>support (finding out random mappings for different IPv4 
>addresses would require plenty of queries :-D

Med: This can happen if each NAT64 is servicing a portion of the IPv4 network/internet.

>
>If this is really a hard requirement (i.e. not possible / too 
>costly) to route all IPv4 traffic using a single Pref64::/n, 
>then I agree you need to have a provisioning tool in place. 
>This tool perhaps could be PCP - if this WG thinks it is ok to 
>extent PCP for this kind of provisioning purposes - for me 
>this sounds a bit like loading PCP with something that might 
>fit better to DHCPv6.

Med: I disagree: PCP is there to help NAT traversal, returning the PREFIX64 is part of that problem. 

>
>All that I'm saying is that PCP cannot replace the need for 
>heuristic in a general case due availability reasons, and that 
>I don't think it is ok to mandate hosts to implement PCP just 
>for Pref64::/n discovery purposes.

Med: I didn't asked for that. Sorry I was not clear: the scope of this discussion is: PCP-enabled networks.

>
>> * An exist strategy is still to be found for the heuristic method.
>
>True (but hosts would also someday need to stop asking for 
>Pref64::/n with PCP).
>
>> * The heuristic method requires some tweaking in DNS.
>
>It requires hosting of a well-known IPv4-only name, such as 
>"ipv4only.arpa". But no tweaking to DNS protocols or server 
>softwares. That is much less tweaking that implementing PCP 
>client to hosts/applications, hosting PCP server on all NAT64 
>enabled networks, and supporting some PCP server discovery 
>mechanism (e.g. via DHCPv6 options).
>
>Best regards,
>
>	Teemu
>
>> -----Original Message-----
>> From: ext [e-mail]
>> [mailto:[e-mail]]
>> Sent: 07. syyskuuta 2012 11:27
>> To: Savolainen Teemu (Nokia-NRC/Tampere); [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: RE: [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 : [e-mail] [mailto:[e-mail]]
>> >Envoyé : vendredi 7 septembre 2012 09:15 À : BOUCADAIR Mohamed
>> >OLNC/NAD/TIP; [e-mail] Cc : [e-mail] 
>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: [e-mail] [mailto:[e-mail]] On
>> >Behalf Of ext
>> >> [e-mail]
>> >> Sent: 07. syyskuuta 2012 08:26
>> >> To: Simon Perreault
>> >> Cc: [e-mail]
>> >> 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:[e-mail]]
>> >> >Envoyé : jeudi 6 septembre 2012 17:29 À : BOUCADAIR Mohamed
>> >> >OLNC/NAD/TIP Cc : [e-mail] Objet : Re: [pcp] 
>PREFIX64 PCP Option
>> >> >for NAT64:
>> >> >draft-boucadair-pcp-nat64-prefix64-option
>> >> >
>> >> >Le 2012-09-06 11:04, [e-mail] 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
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/pcp
>> >
>