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

[<[e-mail]>]

Hi Med, 

Thanks for quick reply.

> [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].

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.

> [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].

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).
>[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.

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:
>   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].

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