Re: [BEHAVE] [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. Hence heuristic is needed anyway, but as an optimization/improvement it is possible to avoid heuristic in cases where PCP happens to be available.

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

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

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.

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.

> * 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 mohamed.boucadair@orange.com
> [mailto:mohamed.boucadair@orange.com]
> Sent: 07. syyskuuta 2012 11:27
> To: Savolainen Teemu (Nokia-NRC/Tampere); simon.perreault@viagenie.ca
> Cc: pcp@ietf.org; behave@ietf.org
> 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 : 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
> >