Subject: [pcp] suggested external address

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Oct 2011 11:13:45 +0200

I have two questions about the suggested external address
(for MAP but they are the same for PEER):

in 9.1 it is defined as:

   Suggested External IP Address:  Suggested external IPv4 or IPv6
      address.  This is useful for refreshing a mapping, especially
      after the PCP server loses state.  If the PCP client does not know
      the external address, or does not have a preference, it MUST use
      the address-family-specific all-zeroes address (see Section 5).

About the last statement, does it mean if an IPv4-IPv4 NAT receives
a MAP request with :: (NOT ::ffff:0.0.0.0) as the suggested external
address it replies with a malformed request error?
This is how I interpret the MUST but it requires the client to do the
right thing (and to know the address family to use), including
in the sections 7.[123].
(BTW I am in favor of this behavior because it helps the client
to understand what types of CGNs PCP servers control).

The second question is about the new "external address or port"
mismatch returns a CANNOT_PROVIDE_EXTERNAL_PORT. I like this
but the error definition is still about port even the cause can
be the address, so:
 - should a CANNOT_PROVIDE_EXTERNAL_ADDR be defined?
 - what is the exact behavior of PREFER_FAILURE (including implicit)
  with an external address != 0 but port == 0? (what I believe? is a
  clarification needed?)
BTW the PREFER_FAILURE section 11.2 obviously needs to be updated.

Regards

[email-masked]

PS: section 6.4:

   11 CANNOT_PROVIDE_EXTERNAL_PORT: the requested external port cannot
      be provided.  This error MUST only be returned for PEER requests,
      for MAP requests that included the PREFER_FAILURE Option (because
      otherwise a new external port could have been assigned), or PEER
                                                                      ^ ,
      or MAP requests for the SCTP protcool.  See Section 11.2 for
      processing details.  The error lifetime depends on the reason for
      the failure.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 20 Oct 2011 08:32:16 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Thursday, October 20, 2011 2:14 AM
> To: [email-masked]
> Subject: [pcp] suggested external address
> 

The text quoted above doesn't say anything about what the PCP server
would do when it receives the IPv6 all-zeros address.

The text that is closest to describing this case is in 9.3,
"Processing a MAP Request",

   If
   the PCP server or PCP-controlled device does not support the Protocol
   or cannot create a mapping for the Protocol (e.g., because the
   request is for a NAT mapping instead of a firewall mapping and the
   PCP-controlled device is not a NAT or does not support NATting that
   specific Protocol), it MUST generate an UNSUPP_PROTOCOL error.

> right thing (and to know the address family to use), including

This encoding of IPV4 all-zeros and IPv6 all-zeros is how we managed
to collapse the MAP4 and MAP6 Opcodes into the MAP Opcode, and 
collapse the PEER4 and PEER6 Opcodes into the PEER Opcode.  The
functionality is the same as the separate MAP4/MAP6/PEER4/PEER6
Opcodes.

>  - should a CANNOT_PROVIDE_EXTERNAL_ADDR be defined?

Renaming the error, as you suggested in another email, seems
suitable.

>   with an external address != 0 but port == 0? (what I believe? is a

Section 9.3 says this, which I believe covers the Internal Port=0
case, which prohibits using Internal Port=0 for protocols with port
numbers.  

   If
   the Protocol is supported and the Internal Port is zero but the
   protocol uses a 16 bit port number (e.g., TCP, SCTP), it generates a
   MALFORMED_REQUEST error.  

We may want to revisit the text above considering this addition 
in -15 to map all protocols:

   If the Protocol and Internal
   Port are both 0 (zero), all protocols and all ports, without any
   exception, are mapped; if this request cannot be fulfilled, the error
   UNSUPP_PROTOCOL MUST be returned.

Feedback from the WG is welcome on this point.

>                                                                       ^
> ,

Fixed, thanks.

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Oct 2011 23:49:33 +0200

=> the "MUST" strongly suggest the PCP server should raise an error
if it is not happy with the suggested external address as I explained later.

      If

   
=> so it seems the PCP server should raise an error on address family
mismatch. I suppose it is the MALFORMED_REQUEST one.

   
=> thanks.

=> the question is about the external port.

      If

   
   
=> I explain my idea: as the PREFER_FAILURE covers now both the external
address and the external port, we have 4 cases:
 - suggested external address != 0, suggested external port != 0:
  get a mapping with these two values or fail

 - suggested external address == 0, suggested external port != 0:
  get a mapping with the port and a suitable external address, or fail

 - suggested external address == 0, suggested external port == 0:
  fail with MALFORMED_OPTION

 - suggested external address != 0, suggested external port == 0:
   (new case) get a mapping with the address and an external port,
   or fail

So the last/new case is the way to force the use of the suggested external
address.

   > BTW the PREFER_FAILURE section 11.2 obviously needs to be updated.

=> still applies

Regards

---

From: james woodyatt <[email-masked]>
Date: Thu, 20 Oct 2011 14:55:58 -0700

On Oct 20, 2011, at 2:49 PM, Francis Dupont wrote:
> 
> - suggested external address == 0, suggested external port == 0: fail with MALFORMED_OPTION

This shouldn't fail wth MALFORMED_OPTION.  If the PCP server is prepared to map all of the protocol's port numbers to the private address for a suitable external address, then it should succeed.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Oct 2011 12:39:27 +0200

=> please remember this is when an explicit PREFER_FAILURE option is
present, so it is a syntax issue.

   This shouldn't fail wth MALFORMED_OPTION.  If the PCP server is
   prepared to map all of the protocol's port numbers to the private
   address for a suitable external address, then it should succeed.
   
=> my answer is if the client wants this it MUST NOT add a
PREFER_FAILURE option. And BTW it is already specified as it:

   If an Option with value less than 128 exists (i.e., mandatory to
   process) but that Option does not make sense (e.g., the
   PREFER_FAILURE Option is included in a request with lifetime=0), the
   request is invalid and generates a MALFORMED_OPTION error.

so PREFER_FAILURE makes sense only when the request can fail because
of the suggested external address and port, for instance it doesn't
make sense if both are not specified, in a MAP delete, in a PEER, etc.

Regards