Re: [pcp] Official reviewers Request for Learn NAT64 PREFIX64s using PCP

[Iljitsch van Beijnum <[e-mail]>]

On 16 mei 2013, at 13:19, Reinaldo Penno (repenno) <[e-mail]> wrote:

>> Title  : Learn NAT64 PREFIX64s using PCP
>> URL    : http://tools.ietf.org/html/draft-ietf-pcp-nat64-prefix64-00
>> Authors: M. Boucadair

Ok, here is a brief review. Brief in the sense that I didn't re-familiarize myself with the related RFCs.

This is clearly useful.

I found 3.2, and especially 3.2.2 very sparse, I was looking to learn more about how this mechanism is useful in practice here. Some more applications/protocols could be listed. However, a lot of information is provided in 3.3. Unfortunately, there are two issues with this:

1. SIP is a very complex protocol that not everyone may be familiar with

2. Unless I misunderstood, a lot of what happens here is pure NAT64, and unrelated to the knowledge of the Pref64:

"the PCP Client issues a PCP MAP request with
   PORT_RESERVATION_OPTION to reserve a pair of ports preserving parity
   and contiguity [I-D.boucadair-pcp-rtp-rtcp].  A pair of ports and an
   external IPv4 address are then returned by the PCP server to the
   requesting PCP Client."

It would be more useful to concentrate on the functionality that is only possible when the Pref64 is known at this point. For instance, in the case of BitTorrent, IPv4 addresses of prospective peers may be learned from a tracker. In order for the client to connect to those peers, it needs to synthesize IPv6 representations for those IPv4 addresses by combining them with the Pref64.

It would be useful to spell out that the ability to reserve ports and learn the external IPv4 address used by the NAT64 (or any NAT) allows for receiving incoming sessions. For this, the Pref64 is not needed. The Pref64, on the other hand, allows for setting up outgoing connections to systems for which only a literal IPv4 address (and not a fully qualified domain name) is known. But for this, no other PCP functionality is required. (Although in practice it gets more complex when ports are used in both directions simultaneously.)

The abstract starts with "This document defines a new PCP extension to learn the IPv6 prefix(es) used by a PCP-controlled NAT64 device" but the PREFIX64 option only allows for one Pref64 and the option may only appear once, so the (es) part shouldn't be there. (Would the ability to learn multiple Pref64s be useful?? I guess load balancing across NAT64s with each a Pref64 of their own is possible.)

In 4.1 a reference to section 7.3 of RFC 6887 would be useful.

Although I was unhappy with the SIP example earlier, I think it's appropriate in section 5 as it shows the full complexity of a real-world system now that we've learned all the details of the mechanism. I think the section title should have "SIP" in it, though.

In the security considerations, I would expect a discussion about what happens when a malicious third party impersonates a PCP server and provides a fake Pref64.

Iljitsch