Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-option

From: <[email-masked]>
Date: Fri, 4 Jan 2013 07:01:16 +0000

Hi,

If the PCP server readily has information about Pref64::/n, then why not tell that to PCP client indeed. But if it has not, then I would ask what is the benefit of defining PCP option instead of DHCPv6 option?

In the Behave WG we have been working on analysis of different Pref64::/n discovery tools, currently in RFC Editor:  http://tools.ietf.org/html/draft-ietf-behave-nat64-learn-analysis-03

The Behave's work resulted in heuristic approach being selected, which is currently in AD evaluation: http://tools.ietf.org/html/draft-ietf-behave-nat64-discovery-heuristic-13

Should this document formally update learn-analysis and have a section with similar analysis, stating pros and cons and then concluding why it is useful to have this solution for PCP deployment scenarios?

In this document I would like to see text talking about relation to said analysis document and heuristic approach. For example, if a host does Pref64::/n discovery with heuristic approach for its generic use (such as local AAAA record synthesis), is there utility for SIP client to perform separate discovery also with PCP client?

Nit: the IPv4-only SIP UA can be IPv4-only, but terminology about IPv6-only SIP UE is not that accurate IMHO: the draft's SIP UA in IPv6-only *access* seems to be quite capable of understanding IPv4-world (adding IPv4 addresses to SDP offer), hence maybe better say SIP UA in IPv6-only access, instead of IPv6-only SIP UA?

Best regards,

	Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Reinaldo Penno (repenno)
> Sent: 03. tammikuuta 2013 01:30
> To: [email-masked]
> Subject: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-
> option
> 
> Hello,
> 
> First of all, Happy new Year!
> 
> Based on the discussions at IETF Atlanta Meeting we would like to start call of
> adoption on a few drafts, with the first one below.
> 
> This email starts a 2-week consensus call on adopting
> 
>      Title           : Learn NAT64 PREFIX64s using PCP
>      Author(s)       : M. Boucadair
>      Filename        : draft-boucadair-pcp-nat64-prefix64-option-02.txt
>      URL             :
> http://tools.ietf.org/id/draft-boucadair-pcp-nat64-prefix64-option-02.txt
> 
> Please read the current revision and state you opinion either for or against
> adoption (and with reasoning why) in the mailing list. The call for adoption
> ends 16th January 2013.
> 
> 
> Thanks,
> 
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Dave Thaler <[email-masked]>
Date: Sun, 27 Jan 2013 02:26:20 +0000

I have read the draft and the list discussion.

I think there is need for a mechanism to explicitly learn the PREFIX64, and indeed
in the document shepherd writeup I did for http://tools.ietf.org/html/draft-ietf-
behave-nat64-learn-analysis-03 I referred to this draft:
> The document specifies a heuristic that is not perfect and so some
> points were rough, but the constraint for this document was to operate
> without changes to code (only configuration) in existing networks.
> Given that constraint, there was strong consensus.  Relaxing the
> constraint would allow one to do better, and that is the focus of a
> draft recently submitted to the PCP WG.

So I do not think this draft should update or obsolete that one, as the 
constraints are quite different.   That is, use an explicit mechanism if supported,
else use the heuristic.

I believe draft-boucadair-pcp-nat64-prefix64-option needs work but is
a decent starting point (for instance it should not keep both the Opcode and the
Option, and in my view the Option is better) should the PCP WG take on this
work.   The biggest open question that would affect adoption however is the 
one Teemu raised in the email below:
" what is the benefit of defining PCP option instead of DHCPv6 option?"
After all, we're defining a DHCP option to learn the PCP server(s), so why
wouldn't the client be able to learn the PREFIX64(s) in the same DHCP exchange?

I haven't seen an answer to this question yet, and would like to see consensus
on the answer before confirming adoption.

-Dave

> [email-masked]
> Sent: Thursday, January 3, 2013 11:01 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [pcp] WG Call for Adoption: draft-boucadair-pcp-nat64-prefix64-
> option
> 
> Hi,
> 
> If the PCP server readily has information about Pref64::/n, then why not tell
> that to PCP client indeed. But if it has not, then I would ask what is the
> benefit of defining PCP option instead of DHCPv6 option?
> 
> In the Behave WG we have been working on analysis of different Pref64::/n
> discovery tools, currently in RFC Editor:  http://tools.ietf.org/html/draft-ietf-
> behave-nat64-learn-analysis-03
> 
> The Behave's work resulted in heuristic approach being selected, which is
> currently in AD evaluation: http://tools.ietf.org/html/draft-ietf-behave-
> nat64-discovery-heuristic-13
> 
> Should this document formally update learn-analysis and have a section with
> similar analysis, stating pros and cons and then concluding why it is useful to
> have this solution for PCP deployment scenarios?
> 
> In this document I would like to see text talking about relation to said analysis
> document and heuristic approach. For example, if a host does Pref64::/n
> discovery with heuristic approach for its generic use (such as local AAAA
> record synthesis), is there utility for SIP client to perform separate discovery
> also with PCP client?
> 
> Nit: the IPv4-only SIP UA can be IPv4-only, but terminology about IPv6-only
> SIP UE is not that accurate IMHO: the draft's SIP UA in IPv6-only *access*
> seems to be quite capable of understanding IPv4-world (adding IPv4
> addresses to SDP offer), hence maybe better say SIP UA in IPv6-only access,
> instead of IPv6-only SIP UA?
> 
> Best regards,
> 
> 	Teemu
> 
> 
> 
> > Based on the discussions at IETF Atlanta Meeting we would like to
> > start call of adoption on a few drafts, with the first one below.
> >
> > Please read the current revision and state you opinion either for or
> > against adoption (and with reasoning why) in the mailing list. The
> > call for adoption ends 16th January 2013.
> >
> >
> > Thanks,
> >
> >

---

From: <[email-masked]>
Date: Mon, 28 Jan 2013 11:03:10 +0100

Dear Dave,

For your question about DHCP, I have already answered to this question here: http://www.ietf.org/mail-archive/web/pcp/current/msg02258.html.

Additional items in which PCP is superior to DHCP are:

* Retrieving the information directly from the discovered PCP Server(s) is more flexible from an operational perspective: think about changing the PREFIX64 configured to a NAT64, for planned maintenance operations the traffic may be redirected to another NAT64 (can be achieved by using a distinct PREFIX64 for that backup NAT64), deployment of several NAT64 with distinct PREFIX64s, etc. 

* For organizations which adopt a two-level indirection (centralized DHCP server for generic configuration) and a regional team to operate regional portions of the network, the information about the PREFIX64 used in each regional area may not be available at the DHCP level. 

* Unlike DHCP, applications may embed a PCP Client (see for instance http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-4.2)

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la 
>part de Dave Thaler
>Envoyé : dimanche 27 janvier 2013 03:26
>À : [email-masked]
>Objet : Re: [pcp] WG Call for Adoption: 
>draft-boucadair-pcp-nat64-prefix64-option
>
>> currently in AD evaluation: 
>http://tools.ietf.org/html/draft-ietf-behave-
>> >      Filename        : 
>draft-boucadair-pcp-nat64-prefix64-option-02.txt
>> >      URL             :
>> >

---

From: <[email-masked]>
Date: Mon, 28 Jan 2013 14:26:04 +0000

Med,

Thank you for the pointer and extra justifications. Consider my concern cleared and hence I'm also positive for adoption.

Best regards,

        Teemu

> ext [email-masked]
> Sent: 28. tammikuuta 2013 12:03
> To: Dave Thaler; [email-masked]
> For your question about DHCP, I have already answered to this question
> here: http://www.ietf.org/mail-archive/web/pcp/current/msg02258.html.
>
> * Retrieving the information directly from the discovered PCP Server(s) is
> more flexible from an operational perspective: think about changing the
> PREFIX64 configured to a NAT64, for planned maintenance operations the
> traffic may be redirected to another NAT64 (can be achieved by using a
> distinct PREFIX64 for that backup NAT64), deployment of several NAT64 with
> distinct PREFIX64s, etc.
>
> * For organizations which adopt a two-level indirection (centralized DHCP
> server for generic configuration) and a regional team to operate regional
> portions of the network, the information about the PREFIX64 used in each
> regional area may not be available at the DHCP level.
>
> * Unlike DHCP, applications may embed a PCP Client (see for instance
> http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-
> 00#section-4.2)
>
> Cheers,
> Med
>
> >De : [email-masked] [mailto:[email-masked]] De la part de
> >Dave Thaler Envoyé : dimanche 27 janvier 2013 03:26 À : [email-masked]
> >I think there is need for a mechanism to explicitly learn the PREFIX64,
> >and indeed in the document shepherd writeup I did for
> >http://tools.ietf.org/html/draft-ietf-
> >I believe draft-boucadair-pcp-nat64-prefix64-option needs work but is a
> >decent starting point (for instance it should not keep both the Opcode
> >and the Option, and in my view the Option is better) should the PCP WG
> >take on this
> >After all, we're defining a DHCP option to learn the PCP server(s), so
> >why wouldn't the client be able to learn the PREFIX64(s) in the same
> >DHCP exchange?
> >
> >I haven't seen an answer to this question yet, and would like to see
> >consensus on the answer before confirming adoption.
> >
> >-Dave
> >