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

From: <[email-masked]>
Date: Thu, 6 Sep 2012 09:59:24 +0200

Dear all,

FYI, a new I-D describing the problem of referrals in NAT64 is described. 

Comments and suggestions are welcome.

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : jeudi 6 septembre 2012 09:48
À : [email-masked]
Objet : I-D Action: draft-boucadair-pcp-nat64-prefix64-option-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : PREFIX64 PCP Option for NAT64
	Author(s)       : Mohamed Boucadair
	Filename        : draft-boucadair-pcp-nat64-prefix64-option-00.txt
	Pages           : 8
	Date            : 2012-09-06

Abstract:
   This document defines a new PCP option to learn the Prefix64 used by
   a PCP-controlled NAT64 device to build IPv4-embedded IPv6 addresses.
   This option is needed for successful communications when IPv4
   addresses are used in referrals (e.g., SIP).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-boucadair-pcp-nat64-prefix64-option

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-boucadair-pcp-nat64-prefix64-option-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Sep 2012 08:36:13 -0400

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?

If a), how is PREFIX64 of any use to the client?

If b), why include it in a MAP response? Why not DHCP or something else? 
What happens if the client receives two MAP responses with conflicting 
PREFIX64 options? Does it have to check that?

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

---

From: <[email-masked]>
Date: Thu, 6 Sep 2012 15:20:09 +0200

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

>De : [email-masked] [mailto:[email-masked]] De la 
>part de Simon Perreault
>Envoyé : jeudi 6 septembre 2012 14:36
>À : [email-masked]
>Objet : Re: [pcp] PREFIX64 PCP Option for NAT64: 
>draft-boucadair-pcp-nat64-prefix64-option
>

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 

Med: You can include it in DHCP but for mobile terminal not supporting DHCPv6 this may not help.

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

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

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Sep 2012 10:00:03 -0400

Mohamed,

Thanks for the very detailed answer! The background story is much 
clearer to me now.

Le 2012-09-06 09:20, [email-masked] a écrit :
>> 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.

I still have a problem with this. The problem is that the PREFIX64 data 
should not be associated with a MAP request because it is global to the 
server. Returning it as part of a MAP response makes no sense to me.

Suggestion: why not create a new opcode for querying server-global 
parameters? The PCP client would use this opcode once, get the PREFIX64 
data in the response, then would do MAP requests separately as usual. I 
think this would result in clearer semantics and implementations.

Simon

---

From: <[email-masked]>
Date: Thu, 6 Sep 2012 17:04:15 +0200

Re-,

Please see inline.

Cheers,
Med 

>De : Simon Perreault [mailto:[email-masked]] 
>Envoyé : jeudi 6 septembre 2012 16:00
>À : BOUCADAIR Mohamed OLNC/NAD/TIP
>Cc : [email-masked]

Med: I see it from a distinct perspective: return it in the MAP says to the PCP Client this is the prefix the NAT64 will use when translating received IPv4 packets matching the instantiated entry. The question whether we can extrapolate it to all mapping is a valid one. 

>think this would result in clearer semantics and implementations.

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.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Sep 2012 11:28:39 -0400

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

---

From: <[email-masked]>
Date: Fri, 7 Sep 2012 07:25:58 +0200

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 

>Envoyé : jeudi 6 septembre 2012 17:29

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 7 Sep 2012 06:14:17 +0000

Hi Med -

You may want to look into draft  http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-11 which already addresses this problem and also refers to cases where multiple Pref64::/n exist.

--Tiru.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, September 06, 2012 6:50 PM
> To: Simon Perreault; [email-masked]
> 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
> 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:
> 
> 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.
> 
> >
> 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.
> 
> >
> 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
> >--

---

From: <[email-masked]>
Date: Fri, 7 Sep 2012 08:22:42 +0200

Dear Reddy,

Thanks for the pointer. I'm already aware about that document.

Are you arguing the heuristic should be used instead of retrieving directly the information from the PCP server?

Cheers,
Med 

>De : Tirumaleswar Reddy (tireddy) [mailto:[email-masked]] 
>Envoyé : vendredi 7 septembre 2012 08:14
>À : BOUCADAIR Mohamed OLNC/NAD/TIP; Simon Perreault; [email-masked]
>Objet : RE: [pcp] PREFIX64 PCP Option for NAT64: 
>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.
>
>> Med: You can include it in DHCP but for mobile terminal not 
>supporting DHCPv6
>> this may not help.
>>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 7 Sep 2012 06:45:58 +0000

> Sent: Friday, September 07, 2012 11:53 AM
> To: Tirumaleswar Reddy (tireddy); Simon Perreault; [email-masked]
> Subject: RE: [pcp] PREFIX64 PCP Option for NAT64: draft-boucadair-pcp-nat64-
> prefix64-option
> 
> Dear Reddy,
> 

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.

---

From: <[email-masked]>
Date: Fri, 7 Sep 2012 07:14:58 +0000

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

> 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,
>
> >Looking at the list of pros and cons for DHCPv6, PCP would be
> >different, and better in some aspects.
> >

---

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

Re-,

Please see inline.

Cheers,
Med 

>Envoyé : vendredi 7 septembre 2012 08:46
>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.

---

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

>De : [email-masked] [mailto:[email-masked]] 
>Envoyé : vendredi 7 septembre 2012 09:15
>À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
>Cc : [email-masked]
>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
>

---

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

---

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

Hi Simon,

I updated the draft with a new OpCode to retrieve the list of PREFIX64. The new version is available at: 
 http://tools.ietf.org/html/draft-boucadair-pcp-nat64-prefix64-option-01 

The new version includes also some comments from Reddy.

Please feel free to comment the new version of the draft. 

Cheers,
Med

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Sep 2012 10:08:00 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sent: Tuesday, September 11, 2012 2:53 AM
> To: Simon Perreault
> Cc: [email-masked]

Thanks for the draft showing both choices.

The message flow for the new PCP Opcode implies there is always
an additional round trip.  There is only an additional round-trip
if MAP (or PEER) is used.  If, on the other hand, the host only
needed to learn the NAT64 prefix (and then it set up a TCP 
connection), the number of messages on the network is exactly
the same for the MAP option or the new Opcode, assuming the PCP
client simply leaves the dangling MAP-created mapping until its
Lifetime expires.

-d

---

From: Simon Perreault <[email-masked]>
Date: Tue, 11 Sep 2012 13:12:37 -0400

> client simply leaves the dangling MAP-created mapping until its

Can't the two opcodes be sent simultaneously? No need to wait for one 
request to finish before starting another one...

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 11 Sep 2012 10:26:30 -0700

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Tuesday, September 11, 2012 10:13 AM
> To: Dan Wing
> Cc: [email-masked]; [email-masked]

Good point.  Learning the PREFIX64 can actually be deferred, as 
knowing the PREFIX64 is not time critical to sending the SIP INVITE.

-d

---

From: <[email-masked]>
Date: Wed, 12 Sep 2012 07:17:32 +0200

Hi Dan, 

Please see inline. 

Cheers,
Med 

>De : Dan Wing [mailto:[email-masked]] 
>Envoyé : mardi 11 septembre 2012 19:08
>À : BOUCADAIR Mohamed OLNC/NAD/TIP; 'Simon Perreault'
>Cc : [email-masked]
>> I updated the draft with a new OpCode to retrieve the list 
>of PREFIX64.
>> The new version is available at:
>>  
>an additional round trip.

Med: This is only an example for this particular case. I added a new flow example when no MAP is needed.

  There is only an additional round-trip
>client simply leaves the dangling MAP-created mapping until its

Med: Fully agree. Note another order may be followed to send the requests in the examples of the draft. The purpose is to show how it works not to compare the opcode vs option at this stage.

---

From: <[email-masked]>
Date: Wed, 12 Sep 2012 07:20:49 +0200

Hi Simon,

You are right. There is no need to wait. Another order to issue the requests can be used in the flow examples. 

I added a note to the draft.

Cheers,
Med

>Envoyé : mardi 11 septembre 2012 19:13
>À : Dan Wing
>Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]

---

From: <[email-masked]>
Date: Wed, 12 Sep 2012 09:28:04 +0200

Re-,

I updated the draft with these changes:

* Add new flow example showing a TCP session
* clarify the requests can be sent using another order.

FWIW, the diff is available at: http://www.ietf.org/rfcdiff?url2=draft-boucadair-pcp-nat64-prefix64-option-02.

If the WG accepts to work on this draft, I plan to remove all the flow examples from the draft and focus on the specification part.

Cheers
Med 

>Envoyé : mardi 11 septembre 2012 19:27
>À : 'Simon Perreault'