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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

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

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