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

[<[e-mail]>]

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