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

From: <[email-masked]>
Date: Fri, 7 Sep 2012 10:27:28 +0200

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 : [email-masked] [mailto:[email-masked]] 
>Envoyé : vendredi 7 septembre 2012 09:15
>À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
>Cc : [email-masked]
>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: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext
>> [email-masked]
>> Sent: 07. syyskuuta 2012 08:26
>> To: Simon Perreault
>> Cc: [email-masked]
>> 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:[email-masked]]
>> >Envoyé : jeudi 6 septembre 2012 17:29
>> >À : BOUCADAIR Mohamed OLNC/NAD/TIP
>> >Cc : [email-masked]
>> >Objet : Re: [pcp] PREFIX64 PCP Option for NAT64:
>> >draft-boucadair-pcp-nat64-prefix64-option
>> >
>> >Le 2012-09-06 11:04, [email-masked] 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/pcp
>

---

From: <[email-masked]>
Date: Fri, 7 Sep 2012 09:57:19 +0000

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.

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

> 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

> From: ext [email-masked]
> [mailto:[email-masked]]
> Sent: 07. syyskuuta 2012 11:27
> To: Savolainen Teemu (Nokia-NRC/Tampere); [email-masked]
> Cc: [email-masked]; [email-masked]
> 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.
> 
> * 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.
> 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
> 
> >Envoyé : vendredi 7 septembre 2012 09:15 À : BOUCADAIR Mohamed
> >OLNC/NAD/TIP; [email-masked] Cc : [email-masked] Objet : RE:
> >[pcp] PREFIX64 PCP Option for NAT64:
> >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
> >> >Envoyé : jeudi 6 septembre 2012 17:29 À : BOUCADAIR Mohamed
> >> >OLNC/NAD/TIP Cc : [email-masked] Objet : Re: [pcp] PREFIX64 PCP Option
> >> >for NAT64:

---

From: <[email-masked]>
Date: Fri, 7 Sep 2012 13:40:05 +0200

Re-,

Please see inline.

Cheers,
Med

>Envoyé : vendredi 7 septembre 2012 11:57
>Cc : [email-masked]; [email-masked]
>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? 

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

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

>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
>
>> * An application/host needs to retrieve the exact PREFIX64 
>used for the
>> NAT64 to be involved in the data path.

---

From: <[email-masked]>
Date: Fri, 7 Sep 2012 13:17:12 +0000

Hi,

Inline:

> >From a host standpoint there are no guarantees to have PCP always
> >available when a NAT64 is present.
> 

I hope the cellular (and other) operators actually follow the guidance once that draft becomes RFC. 
 
> 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?

I think the heuristic draft is best to be kept as a standalone tool and I think that it definitely should not speculate on what other tools there might be available in the future (there have been other proposals as well at the individual I-D level).

If the PREFIX64 option is adopted by the PCP WG, I think it could describe how it will coexist with heuristic-option, e.g. saying that if a client supports PCP, it SHOULD/MUST try with PREFIX64 option before performing heuristic procedures.

Btw how do you get the IPv4 subnet->Pref64::/n mapping list with this option? I quickly looked the draft and it also seemed to deliver just one Pref64::/n?

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

Good, and I definitely support deployment of PCP.

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

Well, ok, I agree and changed my mind on this:) The PCP Server definitely has an interface to NAT64 (unlike DHCPv6 Server), and hence it could ask the Pref64::/n from it (or provision it to NAT64, whatever you guys plan to do).

> is: PCP-enabled networks.

Thanks, in PCP-enabled networks it is definitely ok to skip heuristics in favor for explicit configuration. 

If you do go forward with explicit option, you could look if you can resolve the "mapping of IPv4 address ranges to IPv6 prefixes" problem. Something better perhaps than asking from PCP Server what is the Pref64::/n for a given IPv4 address..

Best regards

	Teemu

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 7 Sep 2012 13:01:40 -0700

> I hope the cellular (and other) operators actually follow the guidance once that draft becomes RFC.

Cellular operator here.

No plans to support PCP on NAT64, LSN, or clients, .... just as a data point.

> I think the heuristic draft is best to be kept as a standalone tool and I think that it definitely should not speculate on what other tools there might be available in the future (there have been o…

+1 for standalone.

Heuristic just like NAT64 does not require anything special on the
client side aside from supporting IPv6 and a simple script to derive
the Pref64.  I have that today.

PCP option would not be  heuristic, it would be explicit (like a DHCP
option) support assuming a capable client and NAT64.

CB
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 7 Sep 2012 16:35:04 -0700

...
> battery etc, but it is not something that can be assumed to happen

The MAP Opcode allows those incoming connections, which is separate
from the PEER Opcode to optimize keepalives.  It would be annoying
to implementers, but I could imagine some network operators deploying
a PCP server with PEER enabled but with MAP disabled.  I would
imagine the network operators that, today, find excuses to rotate
their subscriber's IP addresses every day would be among those 
operators that will not allow MAP but might allow PEER.

-d

---

From: <[email-masked]>
Date: Tue, 11 Sep 2012 11:50:03 +0200

Hi Teemu,

Please see inline. 

Cheers,
Med 

>Envoyé : vendredi 7 septembre 2012 15:17

[...]
>
>> Med: I didn't asked for that. Sorry I was not clear: the 
>scope of this discussion
>> is: PCP-enabled networks.
>
>Thanks, in PCP-enabled networks it is definitely ok to skip 
>heuristics in favor for explicit configuration. 
>
>If you do go forward with explicit option, you could look if 
>you can resolve the "mapping of IPv4 address ranges to IPv6 
>prefixes" problem. Something better perhaps than asking from 
>PCP Server what is the Pref64::/n for a given IPv4 address..

Med: Thanks. I have just submited a new version which takes into account this comment. An OpCode is now supported to convey a list of  {IPv4 subnet, Prefix64::/n}. The new version is available at: http://tools.ietf.org/html/draft-boucadair-pcp-nat64-prefix64-option-01