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 : Tirumaleswar Reddy (tireddy) [mailto:[e-mail]] 
>Envoyé : vendredi 7 septembre 2012 08:46
>À : BOUCADAIR Mohamed OLNC/NAD/TIP; Simon Perreault; [e-mail]
>Objet : RE: [pcp] PREFIX64 PCP Option for NAT64: 
>draft-boucadair-pcp-nat64-prefix64-option
>
>> -----Original Message-----
>> From: [e-mail] 
>[mailto:[e-mail]]
>> Sent: Friday, September 07, 2012 11:53 AM
>> To: Tirumaleswar Reddy (tireddy); Simon Perreault; [e-mail]
>> Subject: RE: [pcp] PREFIX64 PCP Option for NAT64: 
>draft-boucadair-pcp-nat64-
>> prefix64-option
>> 
>> Dear Reddy,
>> 
>> Thanks for the pointer. I'm already aware about that document.
>
>ok.
>
>> 
>> Are you arguing the heuristic should be used instead of 
>retrieving directly
>> the information from the PCP server ?
>
>No. This draft already deals with providing multiple 
>Prefix64::/n. you will have to solve the problem.

Med: I can see a justification to maintain several PREFIX64, but only one prefix64 per PCP Server. 


>I am just trying to understand scenarios where PCP server can 
>give a correct answer than heuristics, which needs to be 
>highlighted, so that implementers do prefer this option in 
>future.

Med: OK. A point which can be highlighted is: when load-balancing is used to distributed connected IPv6-only hosts among available stateful NAT64, distinct PREFIX64 can be used to distribute the load. PCP will return the appropriate PREFIX64 for the assigned PCP-controlled NAT64. PCP can return a prefix64 used for reaching a dedicated NAT64 used during planned maintenance operation or when the primary NAT64 fails. The change of the NAT64 (and potentially the PREFIX64) can be dynamically triggered by PCP while this requires extra effort for the heuristic.


 For e.g. using PCP Prefix64::/n lifetime of the prefix 
>can be provided which is not possible with heuristics, so that 
>PCP client can learn the new Prefix64 again before expiry.
>

Med: Good point. Providing the lifetime associated with prefix is encouraged as per http://tools.ietf.org/html/rfc6250#section-3.2.1. 

>--Tiru.
>
>> 
>> Cheers,
>> Med
>> 
>> >-----Message d'origine-----
>> >De : Tirumaleswar Reddy (tireddy) [mailto:[e-mail]]
>> >Envoyé : vendredi 7 septembre 2012 08:14
>> >À : BOUCADAIR Mohamed OLNC/NAD/TIP; Simon Perreault; [e-mail]
>> >Objet : RE: [pcp] PREFIX64 PCP Option for NAT64:
>> >draft-boucadair-pcp-nat64-prefix64-option
>> >
>> >Hi Med -
>> >
>> >You may want to look into draft
>> >http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-he
>> >uristic-11 which already addresses this problem and also
>> >refers to cases where multiple Pref64::/n exist.
>> >
>> >--Tiru.
>> >
>> >> -----Original Message-----
>> >> From: [e-mail]
>> >[mailto:[e-mail]]
>> >> Sent: Thursday, September 06, 2012 6:50 PM
>> >> To: Simon Perreault; [e-mail]
>> >> Subject: Re: [pcp] PREFIX64 PCP Option for NAT64:
>> >draft-boucadair-pcp-nat64-
>> >> prefix64-option
>> >>
>> >> Hi Simon,
>> >>
>> >> Before answering your questions, I would like to say some
>> >words about the
>> >> context of this work: In fact we have ported a SIP UA
>> >implementation to be
>> >> PCP-aware and tested it IPv6-only environment + NAT64 in
>> >using both Wifi and
>> >> 3G connectivity. The challenge was
>> >>
>> >> (1) to place successful communications between IPvx/IPvy UAs
>> >without requiring
>> >> any particular mechanism in the SIP Proxy Server and ALG 
>in the NAT64
>> >> (2) use PCP to control the NAT64
>> >>
>> >> IPv6-only UA needs to be provisioned with the PREFIX64 used
>> >by the PCP-
>> >> controlled NAT64 for local synthesis of IPv4-embedded 
>IPv6 addresses.
>> >>
>> >> Retrieving the PREFIX64 used by the PCP-controlled NAT64
>> >using PCP was a
>> >> natural approach rather than mandating to support a
>> >dedicated DHCP option;
>> >> mainly for the following reasons:
>> >>
>> >> * DHCPv6 is not supported by some mobile UEs
>> >> * We need to correlate a PREFIX64 and a NAT64 device
>> >>
>> >> Below some answers.
>> >>
>> >> Cheers,
>> >> Med
>> >>
>> >>
>> >> >-----Message d'origine-----
>> >> >De : [e-mail] [mailto:[e-mail]] De la
>> >> >part de Simon Perreault
>> >> >Envoyé : jeudi 6 septembre 2012 14:36
>> >> >À : [e-mail]
>> >> >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64:
>> >> >draft-boucadair-pcp-nat64-prefix64-option
>> >> >
>> >> >Interesting... I have a question:
>> >> >
>> >> >Consider a PCP client that receives a MAP response containing
>> >> >a PREFIX64
>> >> >option. Does the option apply a) only to the mapping
>> >contained in the
>> >> >MAP response, or b) to all future mappings as well?
>> >>
>> >> Med: I'm tempted to say the prefix will be used for all
>> >mappings associated
>> >> with the same PCP server. A record to associate a PCP server
>> >and a PREFIX64
>> >> should be maintained by the client. We need to check if
>> >there are scenarios
>> >> where the same PCP Server controls NAT64s configured with
>> >distinct PREFIX64
>> >> servicing the same IPv6-only host.
>> >>
>> >> >
>> >> >If a), how is PREFIX64 of any use to the client?
>> >>
>> >> Med: I'm not sure I get your question; but PREFIX64 will be
>> >used whenever
>> >> needed to construct IPv4-embedded IPv6 addresses. This is
>> >needed particularly
>> >> for services which does not involve DNS64.
>> >>
>> >> >
>> >> >If b), why include it in a MAP response? Why not DHCP or
>> >> >something else?
>> >>
>> >> Med: You can include it in DHCP but for mobile terminal not
>> >supporting DHCPv6
>> >> this may not help.
>> >>
>> >> >What happens if the client receives two MAP responses with
>> >conflicting
>> >> >PREFIX64 options? Does it have to check that?
>> >>
>> >> Med:  If we assume a PCP Server controls only one
>> >NAT64/PREFIX64, then it is
>> >> safe the client to check whether only one PREFIX64 is
>> >learned for each PCP
>> >> Server.
>> >>
>> >> >
>> >> >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
>> >> >
>> >
>