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

["Reinaldo Penno (repenno)" <[e-mail]>]

Thanks for the review Iljitsch.

I think you have a good point on the separation of what can be done with
the discovery of Pref64 alone versus coupled with other mechanisms. The
bitorrent use-case is certainly a good representation of that.

Load-blancing is also something was discussed but never got into the
draft. There were other initiatives around that, specially in BEHAVE WG
and med was involved in that. This might be something that could be
incorporated into the draft.

Regards,

Reinaldo

On 5/17/13 9:57 AM, "Iljitsch van Beijnum" <[e-mail]> wrote:

>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