Subject: [pcp] My review of draft-ietf-pcp-nat64-prefix64-02

From: <[email-masked]>
Date: Thu, 30 May 2013 10:39:25 +0000

Hi,

I read through most of the draft. I am not that expert in PCP so my focus is on discovery in general.

The Introduction has a justification text:"This extension is required to help establishing communications  between IPv6-only hosts and remote IPv4-only hosts.", which is not exactly correct, as we already have one solution for that problem: draft-ietf-behave-nat64-discovery-heuristic.

The IESG approval email for heuristic-draft had text:
-
Working Group Summary

    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.
-
Furthermore, draft-ietf-behave-nat64-learn-analysis-03.txt (RFC Editor's queue, now cleared due resolution of MISSREF) analyses various solutions that we had on the table at March 2012. In particular the learn-analysis talks about application layer protocols (such as STUN) in section 5.8, but also lists Issues (from #1 to #5). I think this PCP solution solves the issues, BUT with additional box on the network (PCP).

All in all, I think this document should reference to heuristic as existing solution and learn-analysis as discussion paper of the problem, and say that PCP solution solves the Issues (please double check that it does), but also adds the benefits that come with explicit provisioning tool - but with a cost of requiring said provisioning tool (PCP).

Actually, the reference to analysis document could be at section 3.1 that lists the Issues listed in learn-analysis this PCP solution solves (and what more is solved). The "stale Pref64::/n" is the same as Issue #4 in learn analysis?

The 3.2 could reference to learn-analysis section 4 as well, as I think there is overlap?

Now that you have explicit tool for provisioning Pref64::/n, why do you not provision also the suffix introduced in RFC6052? Wouldn't that make this more future proof? The format shown in 4.1 could have variable length suffix field. In fact, having suffix included would allow *fixed length* 128 bit field-length, which might be optimized to be 96 bit field (128-32, with first bits for prefix and remaining for suffix - dropping bits for IPv4).

It seems this solution does not solve the destination-dependent Pref64::/n "problem" discussed in heuristic-discovery section "5.1.  Mapping of IPv4 Address Ranges to IPv6 Prefixes" ? If so, it should be mentioned that this is not solved/supported.

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Thu, 30 May 2013 14:53:47 +0200

Hi Teemu,

Thank you for the review.

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>[email-masked]
>Envoyé : jeudi 30 mai 2013 12:39
>À : [email-masked]
>Objet : [pcp] My review of draft-ietf-pcp-nat64-prefix64-02
>
>Hi,
>
>The Introduction has a justification text:"This extension is required to
>help establishing communications  between IPv6-only hosts and remote IPv4-
>only hosts.", which is not exactly correct, as we already have one solution
>for that problem: draft-ietf-behave-nat64-discovery-heuristic.
>
>Furthermore, draft-ietf-behave-nat64-learn-analysis-03.txt (RFC Editor's
>queue, now cleared due resolution of MISSREF) analyses various solutions
>that we had on the table at March 2012. In particular the learn-analysis
>talks about application layer protocols (such as STUN) in section 5.8, but
>also lists Issues (from #1 to #5). I think this PCP solution solves the
>issues, BUT with additional box on the network (PCP).
>
>All in all, I think this document should reference to heuristic as existing
>solution and learn-analysis as discussion paper of the problem, and say
>that PCP solution solves the Issues (please double check that it does), but
>also adds the benefits that come with explicit provisioning tool - but with
>a cost of requiring said provisioning tool (PCP).
[Med] I added this text: 

   A more elaborated discussion can be found at
   [I-D.ietf-behave-nat64-learn-analysis].  A solution which solves some
   of these issues is specified in
   [I-D.ietf-behave-nat64-discovery-heuristic].

>
>Actually, the reference to analysis document could be at section 3.1 that
>lists the Issues listed in learn-analysis this PCP solution solves (and
>what more is solved). The "stale Pref64::/n" is the same as Issue #4 in
>learn analysis?
[Med] Yes.

>The 3.2 could reference to learn-analysis section 4 as well, as I think
[Med] I added this text to Section 3.2:

   This section provides some use cases to illustrate the problem space.
   More details can be found at Section 4 of
   [I-D.ietf-behave-nat64-learn-analysis].

>
>Now that you have explicit tool for provisioning Pref64::/n, why do you not
>provision also the suffix introduced in RFC6052? Wouldn't that make this
>more future proof? The format shown in 4.1 could have variable length
>suffix field. In fact, having suffix included would allow *fixed length*
>128 bit field-length, which might be optimized to be 96 bit field (128-32,
>with first bits for prefix and remaining for suffix - dropping bits for
>IPv4).
[Med] I'm not sure there is a value to configure the suffix. The implementation I'm aware does not allow to configure other suffixes. My personal opinion is we should not include it in the option format.

>
>It seems this solution does not solve the destination-dependent Pref64::/n
>"problem" discussed in heuristic-discovery section "5.1.  Mapping of IPv4
>Address Ranges to IPv6 Prefixes" ? If so, it should be mentioned that this
>is not solved/supported.
[Med] I guess you are referring to what we had in http://tools.ietf.org/html/draft-boucadair-pcp-nat64-prefix64-option-02#page-6. The support of this case will complicates the design option for a corner case. I added this sentence:

   This option does not solve the destination-dependent Pref64::/n
   discovery problem discussed in Section 5.1 of
   [I-D.ietf-behave-nat64-discovery-heuristic].

>
>Best regards,
>
>	Teemu
>
>
>
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: <[email-masked]>
Date: Fri, 31 May 2013 12:56:15 +0000

Hi Med, 

Thanks for quick reply.

>   [I-D.ietf-behave-nat64-discovery-heuristic].

I guess that is enough. Some discussion around might be nice (e.g. comparison, additional thoughts for why PCP option was standardized and why heuristic was not enough), but I'm not sure it is actually required.

 >  [I-D.ietf-behave-nat64-learn-analysis].

Ok.

>>Now that you have explicit tool for provisioning Pref64::/n, why do you 
>>not provision also the suffix introduced in RFC6052? Wouldn't that make 
>>this more future proof? The format shown in 4.1 could have variable 
>>length suffix field. In fact, having suffix included would allow *fixed 
>>length*
>>128 bit field-length, which might be optimized to be 96 bit field 
>>(128-32, with first bits for prefix and remaining for suffix - dropping 
>>bits for IPv4).

AFAIK the suffix is defined in RFC6052 for some possible future uses (there's some discuss in RFC6052 section 4.1). If the PCP option would support delivery of the suffix information (esp. if suffix were to be a static value per deliver Pref64::/n and not e.g. facility for providing checksum neutrality), it might be more future proof if some use for suffix is actually taken into use some day.

However, if the decision is not to deliver suffix, it could be worthwhile to have couple of word saying that in the generation of synthetic IPv6 addresses, suffix of zero MUST be used and that if in the future the suffix is taken into use in protocol translation system, and the host can be involved in setting the suffix in sensible manner, a new PCP option may be needed.

> [Med] I guess you are referring to what we had in http://tools.ietf.org/html/draft-boucadair-pcp-nat64-prefix64-option-02#page-6. The support of this >case will complicates the design option for a corner case. I added this sentence:

Oh I had missed that draft revision text:) Sure, it would complicate. However, this consideration was really wanted to be included in the heuristic-draft, and hence I think it should be included in this document as well. 

Best regards,

	Teemu

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 31 May 2013 18:30:16 +0000

Overall, this is a well-written draft and is ready for progressing.
The only comment I have is this document doesn¹t address the multiple
prefixes that could be present on a NAT64 device.
Any guidelines on which prefix should be reported would be useful.

Thanks
Senthil