[pcp] #64: Teemu's comments on draft-ietf-pcp-nat64-prefix64-02

["pcp issue tracker" <[e-mail]>]

#64: Teemu's comments on draft-ietf-pcp-nat64-prefix64-02

 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.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-pcp-
  [e-mail]         |  [e-mail]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  nat64-prefix64           |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/pcp/trac/ticket/64>
pcp <http://tools.ietf.org/pcp/>