Subject: [pcp] discuss: PCP lifetime expiration

From: "Dan Wing" <[email-masked]>
Date: Tue, 7 Dec 2010 11:18:37 -0800

This is one of the PCP discussion points.

A PCP-allocated port has a lifetime associated with it.  When that lifetime
expires, do we want to simply delete the mapping or do we want active
inside->outside traffic (using that mapping) to keep the connection alive?  

The difference requires the NAT (and/or PCP server) to remember which
mappings have been created with PCP (which should be deleted strictly on
their expiration time) versus which mappings have been created by dynamic
outbound connections (e.g., TCP SYN) (which should have their mapping
lifetimes extended when active inside->outside traffic is seen).

Thoughts?

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 7 Dec 2010 14:43:42 -0500

> lifetimes extended when active inside->outside traffic is seen).

Don't we need to remember the distinction always? I do not get this part.
Even if inside->outside is sufficient to keep the mapping alive, an
application might still choose to use the lifetime extension message to keep
the mapping alive in case there is no traffic, just because the standard
allows it, or because it is a third-party scenario and the PCP client has no
idea if packets are sent or not. Therefore we need to remember those
mappings are 'PCP' created.

So, whether sending traffic keeps the mapping alive seems orthogonal to the
issue of remembering the distinction between mappings, right? Or not?

> 
> Thoughts?
> 
> -d
> 
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Simon Perreault <[email-masked]>
Date: Tue, 07 Dec 2010 14:53:10 -0500

> mappings are 'PCP' created.

Why shouldn't it be possible to use PCP to change the lifetime of a
mapping created by e.g. a TCP SYN?

I'm a big fan of Stuart Cheshire's "unified theory of NAT mappings".
Whether a mapping is created by PCP or otherwise should never matter.

There should be no need for a "PCP bit" in the NAT's state table.

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: Reinaldo Penno <[email-masked]>
Date: Tue, 7 Dec 2010 15:03:42 -0500

> mapping created by e.g. a TCP SYN?

Theoretically yes, not sure about the implications. But aren't we talking
about the reverse case (see below).

> There should be no need for a "PCP bit" in the NAT's state table.

The question is if the mapping started its life as a PCP requested mapping.
Do we need to remember the distinction due to which operations are allowed:
delete, modifications, etc? Are there any security issues?

>From an operational stand point not having a distinction might face some
barriers. Wouldn't you want to know how many messages were processed
successfully, how many mappings due to PCP were installed/deleted, etc. What
about High Availability? Would you checkpoint all mappings as opposed to
only PCP mappings (this last point requested by several ISPs)?

---

From: Simon Perreault <[email-masked]>
Date: Tue, 07 Dec 2010 15:18:51 -0500

On 2010-12-07 15:03, Reinaldo Penno wrote:
> successfully, how many mappings due to PCP were installed/deleted, etc.

I don't see how this requires adding a "PCP bit" in the NAT's state
table. Couldn't this just be accomplished with counters on PCP requests?

> What

This use case needs a "checkpoint bit" in the NAT state table, not a
"PCP bit". PCP would only be one method among others to create mappings
with the checkpoint bit set. For example, mappings created with a
management interface could also have the checkpoint bit.

The PCP protocol itself does not require the existence of this bit. In
your use case, the existence of this bit is required by operational
constraints that do not apply to all contexts where PCP could be used.

Simon

---

From: Dave Thaler <[email-masked]>
Date: Tue, 7 Dec 2010 20:43:54 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Perreault
> Sent: Tuesday, December 07, 2010 12:19 PM
> To: Reinaldo Penno
> Cc: [email-masked]
> Subject: Re: [pcp] discuss: PCP lifetime expiration
> 
> > From an operational stand point not having a distinction might face
> > some barriers. Wouldn't you want to know how many messages were
> > processed successfully, how many mappings due to PCP were
> installed/deleted, etc.
> 
> I don't see how this requires adding a "PCP bit" in the NAT's state table. Couldn't
> this just be accomplished with counters on PCP requests?
> 
> > What
> > about High Availability? Would you checkpoint all mappings as opposed
> > to only PCP mappings (this last point requested by several ISPs)?
> 
> This use case needs a "checkpoint bit" in the NAT state table, not a "PCP bit".
> PCP would only be one method among others to create mappings with the
> checkpoint bit set. For example, mappings created with a management interface
> could also have the checkpoint bit.
> 
> The PCP protocol itself does not require the existence of this bit. In your use
> case, the existence of this bit is required by operational constraints that do not
> apply to all contexts where PCP could be used.

Personal opinion (no hats): I agree with Stuart and Simon that no distinction
is needed between PCP-created mappings and mappings created by 
outgoing data packets.   Keep it simple.

-Dave

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 7 Dec 2010 15:46:25 -0500

> table. Couldn't this just be accomplished with counters on PCP requests?

Maybe yes/no. Just an example, today we have a quite comprehensive set of
operational commands for different type of NAT mappings including
show/clear/statistics/etc. We could have had a similar discussion about
different types of NAT mappings (EIM, APD, AD) and whether they need
differentiation a few years back.

The question is if ISPs will require a 'clear pcp mappings' or 'clear PCP
mappings from host a.b.c.d' or 'show PCP mappings in the last 2 days'?

> "PCP bit". 
> PCP would only be one method among others to create mappings

Agreed. From my perspective is whether ISPs that use
NAT44(4)/DS-Lite/NAT64/etc will require such operational commands,
high-availability model, etc.

---

From: Alain Durand <[email-masked]>
Date: Tue, 7 Dec 2010 18:12:09 -0800

> only PCP mappings (this last point requested by several ISPs)?

I agree with Reinaldo. From an outside perspective, a PCP-signaled connection and a TCP-SYN signaled connection look the same.
However, a NAT may decide to treat PCP-signaled connection differently and do different internal processing, like selective HA.
Which port to allocate should remain a decision that is local to the NAT. If that one decides to have a special pool for PCP, that should be fine.

So far, we have been talking about PCP to pre-signal connection, mostly in the incoming case. Now that we are talking about the outgoing case
as well, we can either stick to the pre-signaling model or go to a mode where existing connection could become PCP controlled
with post-signaling. I personally believe we should stay with pre-signaling. To Reinaldo's point, we need to understand better if post-signaling has any security implications.

  - Alain.

---

From: <[email-masked]>
Date: Wed, 8 Dec 2010 08:33:33 +0100

Dear all,

>From an operational perspective, we need to have an indication whether the mapping has been statically created (we are requesting some interfaces to do that in the CGN), automatic (e.g., using PCP) or dynamic (using an outgoing packet). Otherwise, we don't have any means to select the states to be synced/backup. Please don't forget High Availability needs. 

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dave Thaler
Envoyé : mardi 7 décembre 2010 21:44
À : Simon Perreault; Reinaldo Penno
Cc : [email-masked]
Objet : Re: [pcp] discuss: PCP lifetime expiration

-Dave

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Lars Eggert <[email-masked]>
Date: Wed, 8 Dec 2010 12:17:00 +0200

> inside->outside traffic (using that mapping) to keep the connection alive?  

Under normal conditions, there shouldn't be any harm in keeping the binding alive if it is seeing use.

If the NAT is overloaded (= running out of binding table entries), then you might want to delete it; but in those conditions you may even need to delete bindings *before* their lifetime ends.

Lars

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 17:13:42 +0100

=> simply delete (if the entry was deleted or not renewed it is expected
the entry is no longer active).

BTW a PCP-entry lifetime is a control plane object, a dynamic entry
lifetime belongs to the data plane, so even they can be implemented
by the same value they are conceptually different.

Regards

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Dec 2010 08:42:01 -0800

> From: Lars Eggert [mailto:[email-masked]]
> Sent: Wednesday, December 08, 2010 2:17 AM
> To: Dan Wing
> Cc: [email-masked]

Ok.

> If the NAT is overloaded (= running out of binding table entries), then
> you might want to delete it; but in those conditions you may even need
> to delete bindings *before* their lifetime ends.

In exceptional cases, exceptional things happen.  Crashes, for example.

But running tight on ports is not a good excuse for the NAT (or PCP server)
to break its previous commitment to a lifetime.  Imagine if, for example,
a DHCP decided to withdraw IPv4 addresses when the free pool of IP addresses
was nearing exhaustion!

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 18:45:55 +0100

In your previous mail you wrote:

=> this makes the assumption all mappings are EIM/EIF, something
which is not universally true.

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 8 Dec 2010 13:02:24 -0500

In the post-signaling scenario where a PCP client can 'take over' a regular
mapping, how would the PCP Client know that the regular mapping is there in
the first place?

Is there a clear use case for this? It would be interesting to know.

On 12/7/10 6:12 PM, "Alain Durand" <[email-masked]> wrote:

> I agree with Reinaldo. From an outside perspective, a PCP-signaled connection
> and a TCP-SYN signaled connection look the same.
> However, a NAT may decide to treat PCP-signaled connection differently and do
> different internal processing, like selective HA.
> Which port to allocate should remain a decision that is local to the NAT. If
> that one decides to have a special pool for PCP, that should be fine.
> 
> So far, we have been talking about PCP to pre-signal connection, mostly in the
> incoming case. Now that we are talking about the outgoing case
> as well, we can either stick to the pre-signaling model or go to a mode where
> existing connection could become PCP controlled
> with post-signaling. I personally believe we should stay with pre-signaling.
> To Reinaldo's point, we need to understand better if post-signaling has any
> security implications.
> 
>   - Alain.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 19:21:34 +0100

I agree with Reinaldo. From an outside perspective, a PCP-signaled
   connection and a TCP-SYN signaled connection look the same.

=> it looks the same *only* with EIM/EIF (a PCP-signaled connection
has no end-point so is by construction End-point Independent)

Regards

---

From: Simon Perreault <[email-masked]>
Date: Wed, 08 Dec 2010 13:26:52 -0500

> has no end-point so is by construction End-point Independent)

This is an implementation detail. PCP itself does not require that there
be different kinds of mappings. If your NAT only does EIM/EIF mappings
then there will be no difference. The difference comes from the fact
that your NAT does different kinds of mappings. It is specific to your
implementation, not to PCP.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Dec 2010 12:40:00 -0800

> Reinaldo Penno
> Sent: Wednesday, December 08, 2010 10:02 AM
> To: Alain Durand; Simon Perreault; [email-masked]; Dave Thaler
> Subject: Re: [pcp] pre-signaling vs post-signaling (was Re: discuss:
> PCP lifetime expiration)
> 
> mapping, how would the PCP Client know that the regular mapping is
> there in the first place?

For an existing socket, the PCP client knows the internal IP address 
and knows the internal port number.  That's all it needs to know.  It 
can send a PCP request to the PCP server with a requested-lifetime.  
The response will contain the public mapping (external IP address 
and assigned-external-port) and assigned lifetime.

> Is there a clear use case for this? It would be interesting to know.

For an application that wants to use PCP to reduce its application
keepalives, the application's UDP or TCP traffic is useful and
necessary.  The PCP message, to request a long lifetime and to
know the lifetime of the mapping, is an optimization -- and the
PCP message can be deferred until later.  With any sort of 
NAT, you know the mapping will be alive for at least 29 seconds
so the PCP message can be deferred at least a few seconds for
more important things to occur -- such as getting the call 
set up, retrieving the calling user's picture to display on the
screen, and so on.  During time when fewer time-critical things
are happening the PCP message can be sent.

-d

> some
> connection

---

From: Simon Perreault <[email-masked]>
Date: Wed, 08 Dec 2010 15:51:52 -0500

> and assigned-external-port) and assigned lifetime.

In another email (it's getting hard to keep track of all the parallel
threads...) I mentioned that there may be multiple TCP sessions with the
same internal address+port number. To fully describe a TCP session you
need to full 4-tuple. If you only include the internal address in the
PCP request for an existing session, there may be a conflict.

Simon

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Dec 2010 13:37:32 -0800

> From: Simon Perreault [mailto:[email-masked]]
> Sent: Wednesday, December 08, 2010 12:52 PM
> To: Dan Wing
> Cc: 'Reinaldo Penno'; 'Alain Durand'; [email-masked]; 'Dave Thaler'

I don't see a conflict.

The interesting information in the PCP response is the external-port 
and external-ip-address, and assigned lifetime.  Those are all the
same no matter if the PCP client has 0, 1, or hundreds of existing
TCP connections on the PCP's client same inside-ip-address.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 8 Dec 2010 15:46:46 -0500

> and assigned-external-port) and assigned lifetime.

Just clarification. I was thinking more about the scenario where PCP Client
is in the CPE in the UPnP/PCP IWF such as DS-lite. In this case, what is
your suggestion to get all mappings?

> are happening the PCP message can be sent.

So, this is the case where PCP Client and application are on the same host,
right?

---

From: Dave Thaler <[email-masked]>
Date: Wed, 8 Dec 2010 22:37:28 +0000

> From: Dan Wing [mailto:[email-masked]]
> Sent: Wednesday, December 08, 2010 1:38 PM
> To: 'Simon Perreault'
> Cc: 'Reinaldo Penno'; 'Alain Durand'; [email-masked]; Dave Thaler
> Subject: RE: [pcp] pre-signaling vs post-signaling (was Re: discuss: PCP lifetime
> expiration)
> 
> > > and knows the internal port number.  That's all it needs to know.
> > > It can send a PCP request to the PCP server with a requested-lifetime.
> > threads...) I mentioned that there may be multiple TCP sessions with
> > the same internal address+port number. To fully describe a TCP session
> > you need to full 4-tuple. If you only include the internal address in
> > the PCP request for an existing session, there may be a conflict.
> 
> I don't see a conflict.
> 
> The interesting information in the PCP response is the external-port and
> external-ip-address, and assigned lifetime.  Those are all the same no matter if
> the PCP client has 0, 1, or hundreds of existing TCP connections on the PCP's
> client same inside-ip-address.

If the PCP server uses endpoint-independent mapping but address-and-port
dependent filtering, then you are right about the assigned lifetime of the
mapping.  However, it's different from the assigned lifetime of the filtering
portion, for which you need the 5-tuple if you want to optimize the keepalive
time for the session.

-Dave

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2010 00:05:03 +0100

=> I don't speak about my implementation (which does what the guy
who gives the money wants) but about real world implementations:
EIM/EIF is simply not common so any reasoning based on ubiquitous
EIM/EIF is just plainly wrong, sorry.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Dec 2010 15:43:02 -0800

> > and
> If the PCP server uses endpoint-independent mapping but address-and-
> port dependent filtering, then you are right about the assigned 
> lifetime of the mapping.  However, it's different from the assigned 
> lifetime of the filtering portion, for which you need the 5-tuple 
> if you want to optimize the keepalive time for the session.

I don't know if we would want to allow such flexibility with PCP.  Is
there a need to allow separate lifetimes for packet filtering 
versus the mapping itself?  (This gets us into firewall discussions,
which might be a good thing.  Or a rathole!)

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2010 00:49:01 +0100

=> note it is not possible to bind a socket to an already used
local address and port without a REUSEADDR. So this is in fact in
favor of the pre-signaling (aka 2 aka Lifetime-Then-Connect) where
the port is fully under the control of the application.

Regards

PS for chairs: item #19 in the tracker has a wrong title
(obviously a cut & paste error from #9).

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Dec 2010 16:02:45 -0800

> Just clarification. I was thinking more about the scenario where PCP
> Client is in the CPE in the UPnP/PCP IWF such as DS-lite. In this 
> case, what is your suggestion to get all mappings?

Walk me through that scenario slowly.  If I understand correctly,
you're describing a scenario where:

  * the PC (in the home) runs as a UPnP IGD control point
  * the B4 element supports UPnP IGD -> PCP interworking
  * the PC (in the home) sends a TCP SYN to a server and 
    the TCP three-way handshake completes.

Then I get confused.  Is the next step:

  * The PC (in the home) then issues a UPnP IGD message
    mapping its TCP port to a public port on the in-home
    NAT?    

> So, this is the case where PCP Client and application are on the same
> host, right?

Yes; this thread was about PCP lifetime expiration, and if the 
application should do PCP before or after communicating to the
server.  I don't see how to do that with the PCP client and the
application running on different devices (e.g., PC and B4 element).

-d

> >>> Which port to allocate should remain a decision that is local to
> the
> >> NAT. If

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2010 01:08:43 +0100

If the PCP server uses endpoint-independent mapping but
   address-and-port dependent filtering, then you are right about the
   assigned lifetime of the mapping.  However, it's different from the
   assigned lifetime of the filtering portion, for which you need the
   5-tuple if you want to optimize the keepalive time for the session.
   
=> it is not new: the filtering part shares firewall constraints
so it likely to take benefit of the peer address and port.
BTW if you look at an UPnP IGD/NET-PMP implementation like miniupnpd
you can find the action is split into a NAT and a firewall parts.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Dec 2010 16:14:16 -0800

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, December 08, 2010 3:49 PM
> To: Simon Perreault
> Cc: Dan Wing; [email-masked]

The PCP application doesn't need to bind to the socket to send
the PCP message.  It just needs to know the port number.

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 8 Dec 2010 19:19:47 -0500

>     mapping its TCP port to a public port on the in-home

The next would be the PC in the home wanting to extend the lifetime through
UPnP or PCP Client doing that on behalf of the PC. It seems we are in
agreement this is not a feasible scenario? I'm trying to understand the
scoping of the pre/pos scenarios.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 8 Dec 2010 16:28:02 -0800

> scoping of the pre/pos scenarios.

It seems an infeasible scenario.

-d

---

From: Simon Perreault <[email-masked]>
Date: Wed, 08 Dec 2010 19:34:25 -0500

>> PCP request for an existing session, there may be a conflict.

It seems that nobody understood me. I think it is an important point so 
let me try again.

 From the same host:
1. TCP session A is established to address X, port x.
2. TCP session B is established to address Y, port y.

By chance, these two sessions were assigned the same source address and 
port (let's call them address Z and port z) by the host's kernel. There 
is no NAT in the picture yet. We have the following two TCP sessions, 
identified by their 4-tuple:

Session A: Z:z <-> X:x
Session B: Z:z <-> Y:y

There is no need to use SO_REUSEADDR for this to happen. This is a 
normal situation that happens all the time in everyday life with the 
normal socket()-then-connect() sequence.

Now, step 3:

3. Application B wants to increase the lifetime of its pre-existing TCP 
session. It sends a PCP request with Z:z as its internal address and 0:0 
as its external address.

CONFLICT!

There is not enough information in the PCP request to know which of 
session A or B is the object of the request.

Conclusion: with the current specification of PCP, Connect-Then-Lifetime 
is impossible.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 08 Dec 2010 19:48:33 -0500

> the port is fully under the control of the application.

The sockets are not bound. They're just created with the regular 
socket()-then-connect() sequence. It just happens that they were 
assigned the same source address by the kernel. You don't need 
SO_REUSEADDR for this to happen.

(But see my other email with much more detail.)

Simon

---

From: Alain Durand <[email-masked]>
Date: Thu, 9 Dec 2010 06:57:51 -0800

> Conclusion: with the current specification of PCP, Connect-Then-Lifetime 

Thank you Simon.
Your comment made me think about another issue. Do we really want to enable application X on a host to freely signal something with PCP for a session run by application Y?
This is not just about extending mapping lifetime, but anything else that could be signaled by PCP.

   - Alain.

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 9 Dec 2010 10:05:19 -0500

Wouldn't that be an acute problem in DS-Lite where IPv4 addresses can be
overlapping across homes? The lifetime extension message needs more info in
order to be able to work in such scenarios. Or the scenario needs to be
constrained more.

---

From: Tina Tsou <[email-masked]>
Date: Thu, 09 Dec 2010 11:23:29 -0800

May I propose the following?
Divide the NAT entries refreshing mechanism into two kinds.
1) PCP refreshing mechanism
2) Legacy NAT refreshing mechanism, which is defined in RFCs from BEHAVE SG.

One NAT entries only adopt one kind of refreshing mechanism, no hybrid, to
reduce the refreshing mechanism's complexity.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Reinaldo Penno
Sent: Thursday, December 09, 2010 7:05 AM
To: Simon Perreault; Dan Wing
Cc: [email-masked]; [email-masked]
Subject: Re: [pcp] pre-signaling vs post-signaling (was Re: discuss: PCP
lifetime expiration)

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Dec 2010 11:26:53 -0800

> From: Reinaldo Penno [mailto:[email-masked]]
> Cc: Alain Durand; [email-masked]; 'Dave Thaler'
> overlapping across homes?

Each home is identified by its IPv6 address (of the DS-Lite tunnel);
that is true of all incoming traffic from each home (TCP, UDP, etc.)
as well as the incoming PCP traffic from each home.

-d

> The lifetime extension message needs more
> info in

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 9 Dec 2010 11:30:21 -0800

> From: Alain Durand [mailto:[email-masked]]
> Sent: Thursday, December 09, 2010 6:58 AM
> To: Simon Perreault
> Cc: Dan Wing; Reinaldo Penno; [email-masked]; Dave Thaler
> Your comment made me think about another issue. Do we really want to
> enable application X on a host to freely signal something with PCP for
> a session run by application Y?

No, but I don't see any way to prevent that.

-d

>    - Alain.=

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 9 Dec 2010 14:58:59 -0500

Of course, but the question remains. How to demux a lifetime extension
message on the AFTR? Use IPv6 as a DHCP-82 like option? Have more data on
the message? etc

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2010 22:40:41 +0100

=> both.

Regards

PS: with EIM in fact the NAT doesn't make a difference between A and B,
i.e., they are mapped to the same external address and port, and
they share of course the timeout.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 09 Dec 2010 16:59:52 -0500

> they share of course the timeout.

This is true for the mapping table.

The session table, which is used for implementing filtering (which MAY
not be endpoing-independent according to BEHAVE's documents), would have
separate entries with separate timeouts.

And realistically, PCP needs to be applicable to NATs that are not
endpoint-independent. There are just way too many of those out there for
us to ignore them.

Simon

---

From: Alain Durand <[email-masked]>
Date: Thu, 9 Dec 2010 15:04:52 -0800

Sent from my iPad

> No, but I don't see any way to prevent that.

Alain==> if we do pre-signaling, at least we can guaranty to no other non-pcp session will be hijacked. There is value to this.

Alain.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 10 Dec 2010 10:48:36 -0800

> Sent: Thursday, December 09, 2010 11:59 AM
> To: Dan Wing; 'Simon Perreault'
> message on the AFTR? Use IPv6 as a DHCP-82 like option? Have more data
> on the message? etc

That is Issue #13, "DS-lite interaction",
http://trac.tools.ietf.org/wg/pcp/trac/ticket/13

The WG needs more input on pros/cons of "Encapsulation Mode" versus
"Plain IPv6 Mode" (see ticket 13).

-d

> >> Wouldn't that be an acute problem in DS-Lite where IPv4 addresses
> can
> >> be
> >>> session. It sends a PCP request with Z:z as its internal address
> and
> >> 0:0
> >>> as its external address.
> >>>
> >>> CONFLICT!
> >>>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 10 Dec 2010 19:43:44 +0000

> Sent: Thursday, December 09, 2010 2:00 PM
> To: Francis Dupont
> Cc: [email-masked]
> Subject: Re: [pcp] pre-signaling vs post-signaling (was Re: discuss: PCP lifetime
> expiration)
> 
> > PS: with EIM in fact the NAT doesn't make a difference between A and
> > B, i.e., they are mapped to the same external address and port, and
> The session table, which is used for implementing filtering (which MAY not be
> endpoing-independent according to BEHAVE's documents), would have separate
> entries with separate timeouts.
> 
> And realistically, PCP needs to be applicable to NATs that are not endpoint-
> independent. There are just way too many of those out there for us to ignore
> them.

I disagree.    A NAT implementation has to be updated to support the PCP protocol.
Since it's not a "legacy" NAT, then we should require them to conform to the
NAT requirements.  Specifically, RFC 5382 for TCP:

> REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" behavior
> for TCP.

And RFC 4787 for UDP:
> REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" behavior.

-Dave

---

From: Simon Perreault <[email-masked]>
Date: Fri, 10 Dec 2010 14:51:46 -0500

On 2010-12-10 14:43, Dave Thaler wrote:
> NAT requirements.

I would tend to agree.

However, I'm a bit worried about the scaling properties of an EIM NAT.

Would it not be OK for an otherwise EIM NAT to make "exceptions" for
known-safe protocols? e.g. endpoint-dependent mapping for UDP port 53
and TCP port 80, EIM otherwise. This was discussed briefly in BEHAVE
about a year ago, and there seems to be agreement that this was fine.

Simon

---

From: Francis Dupont <[email-masked]>
Date: Sat, 11 Dec 2010 14:17:58 +0100

=> I fully agree for the first part of the argument but I don't share
the conclusion. i.e., if PCP must be applicable to NATs which are not
EIM there is no strong reason to add specific features for no-EIM.

Now the firewall case a pretty different because it requires destination
description.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 11 Dec 2010 15:01:47 +0100

I disagree.  A NAT implementation has to be updated to support the
   PCP protocol.

=> in fact it is not true: only the control plane has to be updated
(and the remaining of the message is about the data plane).

   Since it's not a "legacy" NAT, then we should require them to
   conform to the NAT requirements.  Specifically, RFC 5382 for TCP:
   
=> this is simply very unrealistic and BTW unnecessary too.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 13 Dec 2010 16:50:32 -0800

> they share of course the timeout.

But for "Address-Dependent Mapping" (RFC4787) NATs, they would map
the connections to different external ports.

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 14 Dec 2010 09:30:05 +0100

=> so 1 aka Connect-Then-Lifetime should not be used...   
   
Regards