Subject: [pcp] Multiple issues with PEER external address

From: Simon Perreault <[email-masked]>
Date: Tue, 26 Apr 2011 10:57:42 -0400

Issue 1:

For the request, we have:

   Suggested External IP Address:  always 128 reserved bits.  If an IPv4
      address, it is placed into the first 32 bits and the other 96 bits
      MUST be 0.  Note that the External_AF field is not present in the
      request; this is by design so that 128 bits are unambiguously
      present in this field, no matter if an IPv4 or IPv6 address is
      present.

The issue here is how to determine if this is supposed to be an IPv4
address or an IPv6 address. There is no External_AF field so we cannot
use that as we would for the response. And the length is fixed to 128
bits so we cannot use that either. And there is no guarantee that it
will be IPv4 for PEER4 and IPv6 for PEER6, because it would not hold for
a mixed-family NAT (e.g. NAT64).

Suggestion: Add External_AF to the request. Make the suggested external
address length depend on it (32 bits for IPv4, 128 bits for IPv6). Make
the response copy the External_AF value, so that the length of
corresponding request and response is identical. This implies that error
responses would no longer set External_AF to IPv4.

(This suggestion overrides my previous one about fixing the response
length to 128 bits.)

Issue 2:

For the response we have:

   External IP Address:  For success responses, this contains the
      external IP address, assigned by the NAT (or firewall) to this
      mapping.  This field allows the PCP client and its remote peer to
      determine if there is another NAT between the PCP-controlled NAT
      and remote peer.  If the PCP-controlled device is a firewall, this
      will match the internal IP address.  This field is 128 bits long
      if External_AF indicates IPv6, or 32 bits long if External_AF
      indicates IPv4.  For error responses, this MUST be 0 (and is 32
      bits long, because External_AF is IPv4 for error responses).

The problem is with the last sentence. Since we now have a suggested
external address in the request, we could do as we now do for MAP and
simply copy the request's value in the response. It would have the same
benefits as it has for MAP.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 26 Apr 2011 11:36:12 -0700

Thanks.  These will be corrected in -10.  (I don't recall why I was
reluctant to include External_AF in the PEER request.  I'll blame
it on the mushrooms.)

-d

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Perreault
> Sent: Tuesday, April 26, 2011 7:58 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [pcp] Multiple issues with PEER external address
> 
> Issue 1:
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp