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

[<[e-mail]>]

Hi Teemu,

Thank you for the review.

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De la part de
>[e-mail]
>Envoyé : jeudi 30 mai 2013 12:39
>À : [e-mail]
>Objet : [pcp] My review of draft-ietf-pcp-nat64-prefix64-02
>
>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).
[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
>there is overlap?
[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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcp