Subject: [pcp] Stability of external address

From: Stuart Cheshire <[email-masked]>
Date: Tue, 21 May 2013 18:59:23 -0700

In some recent discussions I had, it became clear that the text below may be a little incomplete:

   The MAP and PEER requests include a Suggested External IP Address
   field.  Some PCP-controlled devices, especially CGN but also multi-
   homed NPTv6 networks, have a pool of public-facing IP addresses.  PCP
   allows the client to indicate if it wants a mapping assigned on a
   specific address of that pool or any address of that pool.  Some
   applications will break if mappings are created on different IP
   addresses (e.g., active mode FTP), so applications should carefully
   consider the implications of using this capability.  Static mappings
   for that internal address (e.g., those created by a command-line
   interface on the PCP server or PCP-controlled device) may exist to a
   certain external address, and if the suggested external IP address is
   the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings to
   the same external address, as this can also help applications using a
   mix of both static mappings and PCP-created mappings.  If, on the
   other hand, the suggested external IP address contains a non-zero IP
   address the PCP server SHOULD create a mapping to that external
   address, even if there are other mappings from that same internal
   address to a different external address.  Once an internal address
   has no implicit dynamic mappings and no explicit dynamic mappings in
   the PCP-controlled device, a subsequent implicit or explicit mapping
   for that internal address MAY be assigned to a different External
   address.  Generally, this reassignment would occur when a CGN device
   is load balancing newly seen internal addresses to its public pool of
   external addresses.

Specifically, it says:

   Once an internal address
   has no implicit dynamic mappings and no explicit dynamic mappings in
   the PCP-controlled device, a subsequent implicit or explicit mapping
   for that internal address MAY be assigned to a different External
   address.

That implies the corollary: While an internal address has *some* mappings in the PCP-controlled device, new implicit or explicit mappings for that internal address SHOULD be assigned the *same* external address. Unfortunately, while it implies this, it does not actually state it.

To clarify this I propose submitting the following erratum:

Change:

   ... Static mappings
   for that internal address (e.g., those created by a command-line
   interface on the PCP server or PCP-controlled device) may exist to a
   certain external address,
   and if the suggested external IP address is
   the IPv4 or IPv6 all-zeros address, PCP SHOULD assign its mappings to
   the same external address, as this can also help applications using a
   mix of both static mappings and PCP-created mappings.

To:

   ... Static mappings
   for that internal address (e.g., those created by a command-line
   interface on the PCP server or PCP-controlled device) may exist to a
   certain external address.
   If the suggested external IP address is the IPv4 or IPv6 all-zeros
   address, and the internal address currently has *any* active mappings
   (implicit, explicit, or static) with an external address of the
   indicated address family, then that external address SHOULD be used
   for the new mapping.  If the existing mappings for that external
   address family do not all share a single external address, then the
   choice of which external address is assigned for the new mapping is
   implementation dependent.

Comments?

Do other agree that this correctly captures what we intended to say?

Stuart Cheshire

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 22 May 2013 04:33:47 +0000

I agree. I was pretty sure that at some point in the text we mentioned
that RFC4787 REQ-2 should be obeyed when assigning external address, but
scanning the text I could not find it. If we propose an errata maybe we
should reference REQ-2.

On 5/21/13 10:59 PM, "Stuart Cheshire" <[email-masked]> wrote:

>That implies the corollary: While an internal address has *some* mappings
>in the PCP-controlled device, new implicit or explicit mappings for that
>internal address SHOULD be assigned the *same* external address.
>Unfortunately, while it implies this, it does not actually state it.
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: Simon Perreault <[email-masked]>
Date: Wed, 22 May 2013 10:15:41 +0200

> scanning the text I could not find it. If we propose an errata maybe we

Maybe you are thinking of RFC 6888 REQ-2:

    REQ-2:  A CGN MUST have a default "IP address pooling" behavior of
       "Paired" (as defined in Section 4.1 of [RFC4787]).

Is there any meaningful difference between that and what Stuart is 
suggesting? If not, then I prefer reusing RFC4787 terminology.

Simon

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 22 May 2013 12:50:15 +0000

I thinking about REQ-2 of RFC4787.

   REQ-2:  It is RECOMMENDED that a NAT have an "IP address pooling"
      behavior of "Paired".  Note that this requirement is not
      applicable to NATs that do not support IP address pooling.

On 5/22/13 5:15 AM, "Simon Perreault" <[email-masked]> wrote:

>>> In some recent discussions I had, it became clear that the text below
>>>may
>>> be a little incomplete:
>>>

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 28 May 2013 21:41:53 -0700

On 22 May 2013, at 1:15, Simon Perreault wrote:

> Is there any meaningful difference between that and what Stuart is suggesting? If not, then I prefer reusing RFC4787 terminology.
> 
> Simon

I'm happy for you to suggest specific wording for the erratum.

I'd like us to clarify this, because it affects the assumptions clients can make.

If a client has to assume it may get different external addresses for different ports, then it significantly complicates things like dynamic DNS updates, because the client can't assume a single hostname for all its mapped ports.

Stuart Cheshire

---

From: Simon Perreault <[email-masked]>
Date: Wed, 29 May 2013 10:05:19 +0200

Le 2013-05-29 06:41, Stuart Cheshire a écrit :
> If a client has to assume it may get different external addresses for
> different ports, then it significantly complicates things like
> dynamic DNS updates, because the client can't assume a single
> hostname for all its mapped ports.

The thing is that PCP cannot require much more from NATs than what is 
already in RFC 4787s and 6888.

RFC 4787 requires of all NATs:

       behavior of "Paired".

RFC 6888 makes this requirement stronger for CGNs in particular:

       "Paired"

Assume we say: PCP-controlled NATs MUST have an "IP address pooling" 
behavior of "Paired".

Even then a PCP client or, more generally, a host behind a NAT cannot 
rely on its external address being always the same for a host of reasons:

- If all ports on an external address get allocated, new mappings will 
have to either be rejected or move to a new external address. The latter 
is what's usually preferred and implemented.

- Local policy. Dumb example: VoIP goes to provider A, bulk goes to B.

- etc. etc. etc.

IMHO it's good advice to recommend a particular behaviour for NATs, but 
it's also bad advice to recommend that clients rely on it.

If an app depends on this NAT behaviour, then it should use the 
PREFER_FAILURE option. I can see that working for DNS updates too. Once 
the client gets an external address, it requests that external address 
for all future mappings. But since ANNOUNCE is not reliable, it would 
need some heuristics to gracefully handle external address changes.

Simon

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 29 May 2013 09:34:24 +0000

>need some heuristics to gracefully handle external address changes.

ANNOUNCE? 

PREFER_FAILURE works for PCP enabled flows, but regular outgoing flows can
not get feedback if their external mapping broke APP or not. Unless we
create an notification from server to client to let it know about APP
breakage through PCP.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 29 May 2013 11:50:07 +0200

>> need some heuristics to gracefully handle external address changes.

I was assuming that the DNS update app would create a dummy mapping in 
order to get and lock the external address. Then the PCP server would 
send it ANNOUNCEs when things change, would it not?

Simon

---

From: "Reinaldo Penno (repenno)" <[email-masked]>
Date: Wed, 29 May 2013 09:55:06 +0000

>send it ANNOUNCEs when things change, would it not?

If just the mapping changes it will send an unsolicited response. If an
event happens that affects all PCP Clients such as a NAT reboot, it will
send an ANNOUNCE.

I'm still not clear how it will detect regular flows breaking APP if app
relies on those flows also having the same external IP. Should they also
create dummy (PEER) mappings?

---

From: Simon Perreault <[email-masked]>
Date: Wed, 29 May 2013 13:19:27 +0200

> event happens that affects all PCP Clients such as a NAT reboot, it will

Right, right. That's what I meant. There's a mechanism that will keep 
the DNS updater informed.

> create dummy (PEER) mappings?

If an app cares about those things, it will not only have to create 
dummy PEER mappings, but real PEER mappings that it will create with the 
same suggested external address and the PREFER_FAILURE option. That's 
the only way to be sure.

Simon

---

From: Dan Wing <[email-masked]>
Date: Wed, 29 May 2013 10:23:24 -0700

>   implementation dependent.

Looks reasonable to me.  Based on the rest of this thread, it would be additionally helpful to cite REQ-2 of RFC4787 (which is SHOULD level) and REQ-2 of RFC6888 (which is MUST level), so your new second sentence ends like:

  ... then that external address SHOULD be used for the new mapping, so that PCP behavior follows NAT requirements of REQ-2 of [RFC4787] and REQ-2 of [RFC6888].

-d

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 30 May 2013 09:34:14 -0700

On 29 May 2013, at 2:50, Simon Perreault wrote:

> I was assuming that the DNS update app would create a dummy mapping in order to get and lock the external address. Then the PCP server would send it ANNOUNCEs when things change, would it not?

I was not proposing dummy mappings. The internal host creates *real* mappings for its services, and creates SRV records giving the external ports. The question is whether those SRV records can share a single target hostname, which points to a single target address (which is what Mac OS X currently does).

Requiring the code to potentially generate multiple different target hostnames pointing to different target addresses would add significant complexity (which is why we haven't done that). With NAT-PMP this was not an issue because there was only a single external address.

Stuart Cheshire