Subject: [pcp] PCP proxying / relaying

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Mar 2011 12:18:25 -0800

A subscriber might have multiple IP addresses, from the same ISP.  There are

several ways this could occur:

  * IPv6 subscriber with a /64 (e.g., native IPv6, with a CPE implementing 
    Simple CPE Security [RFC6092]).  This is unrelated to IPv4, and might
    be an IPv6-only subscriber, a Dual-Stack Lite subscriber, 6rd
subscriber,
    dual-stack subscriber, and so on.

  * Dual-Stack Lite subscriber, with an IPv6 /64 and multiple IPv4 addresses

  * IPv4-only subscriber with multiple IPv4 addresses (e.g., "business
service"),
    behind a CGN.

(There are probably others, which don't yet exist on anyone's radar, such as
an ISP offering filtering (firewalling) for an IPv4 subscriber, in order to
block incoming IPv4 address sweeps, pings, etc., prior to consuming access
link bandwidth.)

For all of these cases, consensus seems to be that we do not want any
arbitrary host to create, modify, or delete mappings for any other arbitrary
host.  Rather, we want only the subscriber's CPE to do that.  The subscriber
would need to log into the CPE to do that, using the CPE's administrative
interface (e.g., HTTP with the administrative username/password).

If PCP is implemented in end hosts (e.g., PCs), this is complicated by PCP
clients which send PCP requests to their default gateway.  Several network
topologies could exist.  For example, with DS-Lite or other dual-stack
technologies with an ISP-operated PCP-aware CGN, two scenarios would be in
operation at the same time, one scenario for each address family.

Whenever there are multiple IPv4 addresses at the subscriber's premise,
either because of DS-Lite or because of a "business class" service, the
scneario looks like this:
   [IPv4 host]--[PCP-aware CPE router]--------[PCP server and CGN at
ISP]--<Internet>

For IPv6, the PCP-aware router in the CPE implements Simple CPE Security
[RFC6092] and the scenario looks like this:
   [IPv6 host]--[PCP-aware CPE router]--<Internet>

There are two ways that PCP can be handled in the CPE router:

  1.  CPE router passes packet using internal node's IPv4 address.  This
      is simple routing.
  2.  CPE router passes packet using the CPE router's own IPv4 
      external address (e.g., for DS-Lite would be 192.0.0.2).  This
      requires doing "PCP proxying" or "PCP Relaying" (see below).
  3.  CPE router passes packet using the CPE router's external 
      IPv6 address.  This requires doing "PCP proxying" or "PCP 
      Relaying".

PCP proxying:  described in draft-bpw-pcp-proxy-00.txt.  Implements
a PCP server in the CPE router which understands most of the protocol.

PCP relaying:  this is more akin to how DHCP Relay works today.  In
DHCP relay, a DHCP-aware router on the local LAN picks up the 
broadcasted message, populates the GIADDR field (so that the router
does not need to maintain state) and forwards the DHCP message to
the DHCP server's IP address.  The packet's source address is
re-written to the router's IP address, so the DHCP server's response
goes back to the router, which uses the GIADDR to send the message
back to its original interface.  

Critical distinction between PCP Proxy and PCP relay is this:  the
relay understands very, very little of the protocol.

A concern I have, which others have raised usually in conjunction
with the term "ALG", is that PCP proxying might prevent the PCP
protocol from being extended.  For example, introducing a new 
OpCode requires updating the PCP Client and PCP server (which is 
normal, necessary, and expected) but if it requires also updating
the PCP Proxy, we will have harmed ourselves.  As we all know,
software in CPE routers is seldom, if ever, upgraded by users.
Most don't know their CPE routers even run software that can be
upgraded, don't know how to do it, or are afraid of bricking it.

My question to the group, and to Francis:  how close to a "relay"
can we get, so that the PCP-aware software in the CPE router 
does the least amount of work?

-d

---

From: Alain Durand <[email-masked]>
Date: Fri, 11 Mar 2011 15:11:43 -0800

Dan:

It seems to me that our 'old' idea of using the AFTR IANA assigned address (192.0.0.1)
as the default address of the PCP server (instead of sending to the default router) would
actually solve this problem more elegantly...

What do you think?

   - Alain.

On Mar 11, 2011, at 3:18 PM, Dan Wing wrote:

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

---

From: Francis Dupont <[email-masked]>
Date: Sat, 12 Mar 2011 00:58:27 +0100

In your previous mail you wrote:

=> I tried to catch this idea this simple Proxy and smart Proxy
(unfortunately only the simple Proxy was edited in the version 00).

The simple Proxy is explicitely designed to be as simple as possible
(perhaps not as possible as I'd like because of the THIRD_PARTY option
and CPE embedded NAT/firewall mess, but I really try).
   
The smart Proxy is based on the simple Proxy as it basically
provides the same function but offers optional extra services
like multiple PCP servers, request/response caching, etc,
and IMHO fits better in a 'swiss knife' IWF.

Note I can change the terms but there are not really different
beasts, just the minimal point and extensions from this minimal point.

Thanks

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 Mar 2011 16:38:52 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, March 11, 2011 3:58 PM
> To: Dan Wing
> Cc: [email-masked]
> Subject: Re: PCP proxying / relaying
> 
> 

I agree the THIRD_PARTY option makes PCP-to-PCP proxying more 
complicated, and requires the proxy be aware of future OpCodes
that would need a THIRD_PARTY option added when they are proxied.

But Alain brought up an interesting point:  re-consider the 
IANA-assigned address, which would allow avoiding proxying
altogether.  I've diagramming this on paper and I still like 
that idea.

Another approach, if we want to stick with proxying / relaying
of some sort, is to collapse the THIRD_PARTY back into the
OpCodes.  

(Not that you brought this up, but for others reading this
thread:  None of this matters in the (so-called) NAT444 case, 
because the in-home NAT44 needs to do PCP-to-PCP proxying, 
because it needs to understand the PCP request from the 
internal host, it needs to create its own mapping, and it 
needs to send a PCP request to the ISP's PCP server.)

What is the value/purpose/benefit of PCP-to-PCP proxying?

> beasts, just the minimal point and extensions from this minimal point.

Yes, same ideas.

-d

---

From: Francis Dupont <[email-masked]>
Date: Sat, 12 Mar 2011 15:05:35 +0100

It seems to me that our 'old' idea of using the AFTR IANA assigned
   address (192.0.0.1) as the default address of the PCP server
   (instead of sending to the default router) would actually solve
   this problem more elegantly...
   
   What do you think?
   
=> This is not an address assigned to the B4 so it doesn't work
with a PCP Proxy implemented in user mode. The B4 address in
the same network is not standardized and is assigned on the wrong
(i.e., Internet facing) interface.

And BTW I can't see how this solves Dan's concern (which was
already handled in the proxy I-D but not in a visible way).

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Sat, 12 Mar 2011 15:59:27 +0100

=> the THIRD_PARTY option has another side effect on proxies: proxies
are used too to implement security controls (typically ACLs on target
addresses/internal ports) but these security controls include the
third party operation authorization so with the current security
considerations in the base I-D a proxy enforcing security controls on
all host-server paths is needed.

=> I already got this idea with the associated 'magic packet' one.
I still deeply dislike it and IMHO all router vendors too, i.e., don't
reinvent the router alert.

=> you mean to hear my arguments against the THIRD_PARTY option?

=> yes, I wrote the 'embedded NAT in the CP router' case for
a PCP proxy and it was really not fun!

=> security controls, including for third party operations.
A lot of things which are already needed by IWFs, transparent
multiple PCP servers, as previously mentioned embedded NAT,
less complex by requiring something the embedded firewall,
etc.
BTW I don't believe one wants to put this complexity into
clients, so I am in favor of PCP proxies, and not only
because I work on DS-Lite in plain mode (:-).

   Yes, same ideas.
   
=> fine!

Thanks

---

From: Stuart Cheshire <[email-masked]>
Date: Sat, 12 Mar 2011 22:21:08 -0800

> actually solve this problem more elegantly...

I'm still a big fan of this approach. In some cases it may be a little more work to implement on the server side, but once done, it provides wonderful zero-configuration operation for the clients. The client just has one address to send to, and either it works or it doesn't, and if it doesn't then that's a server-side configuration error that needs to be fixed (by one knowledgable server operator), not a client-side configuration error (to be fixed by countless end-users who have no idea what this means).

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org

---

From: Francis Dupont <[email-masked]>
Date: Sun, 13 Mar 2011 10:29:29 +0100

it may be a little more work

=> we just have a big difference about the appreciation
of the 'more work'...

Regards

PS: I leave this to router people...

---

From: Stuart Cheshire <[email-masked]>
Date: Sun, 13 Mar 2011 04:36:01 -0700

On 13 Mar 2011, at 1:29, Francis Dupont wrote:

> => we just have a big difference about the appreciation of the 'more work'...
> 
> Regards
> 

No, we just disagree about how much training end-users should have to go through to learn to use and troubleshoot our products.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 09:58:32 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Sunday, March 13, 2011 1:29 AM
> To: Stuart Cheshire
> Cc: [email-masked]
> Subject: Re: [pcp] PCP proxying / relaying
> 
> 

Using the IANA-assigned address would mean the PCP proxy in a B4 element is
_very_ lightweight -- it could even be non-existent.  The only thing it
might need to do is change the encapsulation, depending on whatever we
choose as the DS-Lite encapsulation.

Seems less work than the PCP proxying we are considering otherwise.

-d

---

From: Francis Dupont <[email-masked]>
Date: Mon, 14 Mar 2011 19:22:44 +0100

=> you make the hidden and false assumption the B4 will never need
the content of PCP messages.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 14:12:21 -0700

> Sent: Monday, March 14, 2011 11:23 AM
> To: Dan Wing
> Cc: 'Stuart Cheshire'; [email-masked]

Which message does it need to process.

-d

---

From: Francis Dupont <[email-masked]>
Date: Mon, 14 Mar 2011 23:11:22 +0100

=> MAP requests for sure, PEER requests because it is useless
to extend an implicit dynamic mapping lifetime if the corresponding
entry in the firewall got a shorter one. So a priori all requests.
   
Regards

PS: we should be careful: PCP is being designed to be used with ISP CGNs
so its default security requirements are higher than NAT-PMP and
UPnP IGD, including version 2.0.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 15:25:12 -0700

> Sent: Monday, March 14, 2011 3:11 PM
> To: Dan Wing

I am thinking of a B4 element, and it doesn't need to do that for
PCP messages sent by hosts over IPv4.  Are you thinking of something
else, or am I wrong, or what?

> UPnP IGD, including version 2.0.

A fair statement.  But with that in mind, what should be written 
into the document?

-d

---

From: Francis Dupont <[email-masked]>
Date: Mon, 14 Mar 2011 23:46:04 +0100

=> when the B4 is just a standard Home Gateway upgraded to implement
DS-Lite there is no reason for the embedded firewall to be disabled
(and IMHO most customers could want it will be kept).
So out of a lab the B4 must look at the content of all PCP requests.

   > PS: we should be careful: PCP is being designed to be used with
   > ISP CGNs so its default security requirements are higher than
   > NAT-PMP and UPnP IGD, including version 2.0.

=> I have nothing specific in mind now.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 16:04:27 -0700

> Sent: Monday, March 14, 2011 3:46 PM
> To: Dan Wing

Yes, an IPv6 firewall is required according to RFC6092 (Simple 
CPE Security).

Considering DS-Lite:

For PCP sent over IPv6, I agree that the B4 element would want to 
examine PCP messages, in order to perform the functions of the 
protocol alluded to in RFC6092 (Simple CPE Security).  It 
certainly needs to receive and process PCP messages in that
case, because it is going to create or destroy state within
its own firewall.

For PCP sent over IPv4, I don't see the B4 needing to process or 
parse the PCP messages -- afterall, the B4 is not going to create 
or destroy any state within itself because of those messages.  

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Mar 2011 00:32:30 +0100

=> and there is no good reason to remove the existing IPv4 firewall,
this means a B4 should get a PCP Proxy for AFTR control and a PCP
Server for the IPv6 firewall (but the entry for DS-Lite in the
IPv6 firewall should be static, so not controlled by PCP).

   Considering DS-Lite:

=> we agree this is *only* about the PCP control of the embedded IPv6
firewall, don't we?

=> you forget the embedded IPv4 firewall, and the ACL on MAPs, etc.
None is mandatory but you can't require none exists.
   
Regards

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 16:52:11 -0700

I think you are saying:  if the B4 element needs to process
the PCP message, it needs to process the PCP message.

I agree.

What I am saying is that if the B4 element is not processing
the PCP message, it should do the least amount of processing
as possible.  As an example, the DHCP protocol is relayed with
that same philosophy.

I believe you are saying is that there is no case where a
B4 element would not process PCP messages.

Which means, it always needs to be a (relatively) 'heavy'
proxy.

If so, how can we future proof it?  That was the main worry
in my previous email, where I wrote:

    A concern I have, which others have raised usually in
    conjunction with the term "ALG", is that PCP proxying might
    prevent the PCP protocol from being extended.  For example,
    introducing a new OpCode requires updating the PCP Client and
    PCP server (which is normal, necessary, and expected) but if
    it requires also updating the PCP Proxy, we will have harmed
    ourselves.  As we all know, software in CPE routers is
    seldom, if ever, upgraded by users. Most don't know their CPE
    routers even run software that can be upgraded, don't know
    how to do it, or are afraid of bricking it.

I know the PCP Proxying document says "unrecognized opcodes
should just be forwarded upstream" (or words to that effect).
Is that sufficient?  Do we need fields, in known places, 
where the PCP proxy could do the *functional*equivalent*
of the GIADDR field of a DHCP proxy -- for example, a way
for the PCP proxy to easily insert or add the internal IP
address / port of the original PCP request for any and all
OpCodes?  

-d

> Sent: Monday, March 14, 2011 4:33 PM
> To: Dan Wing

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Mar 2011 01:35:56 +0100

as possible.

=> what I've read is the default case should be the B4 doesn't
process the PCP message. I raised two concerns: it is far from
obvious it will be the default case, and to try to optimize this
case makes the other case (processing) far more hairy to implement.

   As an example, the DHCP protocol is relayed with that same
   philosophy.
   
=> a DHCP relay doesn't route DHCP message: it does a small
but not null processing.

=> we have no discussed about the key point: where/when/how the
PCP Proxy function is required. BTW the I-D doesn't address this,
it just describes what is the PCP Proxy function with a lot of
options and corner cases.

=> it depends on the user wants as security features on the B4.
The only case where it will be unconditionally heavy is for
NAT444 (you can shout we should use DS-Lite instead :-).

=> ALG is inside the NAT, a proxy is a better alternative.
IMHO the case we should *not* fall into is to enforce an ALG in order
to avoid a proxy.

       it requires also updating the PCP Proxy

=> I didn't answer to this point but what to do with unknown OpCode
and Option is in the new proxy I-D, including the case they don't
matter and can be just forwarded.
Note the unknown Option case is better as the worst case for an
unknown optional-to-process Option is to have to remove it from
requests.

       or are afraid of bricking it.

=> not an impossible event (:-).
   
   of the GIADDR field of a DHCP proxy

=> if you'd like to copy DHCP please copy DHCPv6, not DHCPv4!

   for example, a way
   
=> DHCP provides relay options (BTW needed in DHCPv6 for a
correct operation in common scenarios), I don't believe PCP
needs the same: why to make the protocol more complex without
a clear need?

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 17:41:09 -0700

> Sent: Monday, March 14, 2011 5:36 PM
> To: Dan Wing

I would like to discuss that key point.  That is why I initiated
this thread.

-d

---

From: Francis Dupont <[email-masked]>
Date: Tue, 15 Mar 2011 01:58:49 +0100

=> it becomes too late for me but I have some arguments about
security controls in a message I sent to Reinaldo I can share
later...

Regards

PS: can you open a dedicated thread?

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 16:57:27 -0700

> Sent: Saturday, March 12, 2011 6:06 AM
> To: Alain Durand
> Cc: Dan Wing; [email-masked]
> with a PCP Proxy implemented in user mode. 

If the B4 wants to process the packets, can it bring up a pseudointerface
with that address on its LAN interface?

-d

> The B4 address in

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Mar 2011 17:03:33 -0700

> Sent: Saturday, March 12, 2011 6:59 AM
> To: Dan Wing
> Cc: [email-masked]

The presence of the internal-ip-address, anywhere in the packet 
causes that problem.  Doesn't matter if the bits are in the
MAP OpCode, PEER OpCode, or a separate option.

> => security controls, including for third party operations.

But if we disallow end hosts from using THIRD_PARTY (which
is what PCP-06 and -07 say), it would only be the B4
element itself using THIRD_PARTY.  

So, what is the 'security control' that the B4 needs to
enforce??

-d

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 14:59:05 +0100

=> If you do that you'll be in trouble to send packets to this address.
(BTW if you are really interested I can explain how you can implement
it but it is hairy: a good example of things you'd like to avoid :-).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 15:15:54 +0100

=> I note you use 'needs' and not 'requires' so the answer
can't be very accurate.
The B4 needs to enforce the security controls the user wants.
As I don't know a priori what (s)he could want, I give the
example for the MiniUPnP daemon (it is the tool you can find
on Linux-based home gateways, including OpenWrt-based,
and it includes NAT-PMP support despite of the name):

 - secure_mode (allows clients to add mappings only
  to their IP, you should recognize this one :-)

 - permission rules (from miniupnpd.conf sample:
 (allow|deny) (external port range) ip/mask (internal port range)
 it is advised to only allow redirection of port above 1024
 and to finish the rule set with "deny 0-65535 0.0.0.0/0 0-65535"

BTW as user I would want the second: my printer has no
good reason to open a hole in the home gateway.

Thanks

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Mar 2011 09:29:26 -0700

> Sent: Wednesday, March 16, 2011 6:59 AM
> To: Dan Wing
> Cc: 'Alain Durand'; [email-masked]

If we were to standardize on 1.1.1.1, it should be a single command
during startup:

#ifconfig eth0:1 1.1.1.1/24
#ifconfig eth0:1
eth0:1    Link encap:Ethernet  HWaddr 5c:ff:35:02:7a:e1  
          inet addr:1.1.1.1  Bcast:1.1.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1430  Metric:1
          Memory:f2400000-f2420000

which the daemon would then listen on.

This ain't hairy.  Or is the concern other daemons, listening
on all interfaces, would choose this one??

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Mar 2011 09:32:52 -0700

Thanks.  Good points.

-d

> Sent: Wednesday, March 16, 2011 7:16 AM
> To: Dan Wing
> Cc: [email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 16 Mar 2011 17:49:41 +0100

=> this is not the problem: if you use *one* address you can't at
the same time assign this address at one of your interfaces *and*
be able to forward packets further to the *same* address.

=> but the daemon won't be able to send request to the *next*
PCP server at 1.1.1.1.

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 16 Mar 2011 11:55:15 -0700

> Sent: Wednesday, March 16, 2011 9:50 AM
> To: Dan Wing

This seems quite similar to how today's ALGs function.  Can this be modeled
in the CPE router like an ALG?

A difference from a normal ALG is that sometimes a PCP response needs to be
generated by the CPE router itself (rather than forwarding the request to
the upstream PCP server).  But perhaps that is why the earlier PCP Proxy
paper (draft-bpw-pcp-proxy-00) mentioned 'faking' a response.

-d

---

From: Francis Dupont <[email-masked]>
Date: Thu, 17 Mar 2011 15:55:10 +0100

=> if you extend the ALG notion for NATs to routers it would be an ALG.

=> normal ALG? an ALG can do anything: it is supposed to have access
to all functions (in a traditional OS it is at least in part in the kernel (*)).

=> yes, the word 'fake' meant the response is built directly by the proxy
(which at the difference of an ALG is a standard application: its only
complexity is that it is multiplexed on two sides: the internal where it
acts as a server, the external where it acts as a client. But if you don't
require it to be able to handle a zillion of messages per second it is
still a low complexity).
   
Regards

PS (*): there are two standard ways to implement such an ALG:
 - fully in the kernel (not the best: kernel programming is hairy,
  a nightmare to debug and bugs are named panics :-)
 - use a hook to intercept "interesting" packets and a second one
  to reinject processed packets (BTW NATs/firewalls often provides
  such hooks which are still available in the "router mode").

PPS: in case it is not clear I think ALGs are BAD!

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Mar 2011 11:50:12 -0700

> Sent: Thursday, March 17, 2011 7:55 AM
> To: Dan Wing

Agreed ALGs are bad.  But your argument against the IANA-assigned
address is that it's hard to implement.  My point is that ALGs,
which demonstrably exist on NATs and (before that) firewalls,
do the same thing as PCP would need if we use an IANA-assigned
address.

Does that remove your objection to consider an IANA-assigned
address?

-d

---

From: Francis Dupont <[email-masked]>
Date: Fri, 18 Mar 2011 01:10:16 +0100

=> that does not remove my objection (and I can't see why the use
of an ALG could be in favor of IANA-assigned address?).

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Mar 2011 08:45:51 -0700

> Sent: Thursday, March 17, 2011 5:10 PM
> To: Dan Wing
> => that does not remove my objection

Your objection, as I recall, was "it is difficult to implement" (couldn't be
done in user mode).  Yet ALGs are implemented, today, and do a nearly
identical function as would be necessary for an IANA-assigned PCP address.
So this shows a path to easy implementation of an IANA-assigned address.

> (and I can't see why the use

In that parenthetical statement, are you re-asserting your observation in
http://www.ietf.org/mail-archive/web/pcp/current/msg01101.html, where you
wrote:

#   The B4 needs to enforce the security controls the user wants.
#   As I don't know a priori what (s)he could want, I give the
#   example for the MiniUPnP daemon (it is the tool you can find
#   on Linux-based home gateways, including OpenWrt-based,
#   and it includes NAT-PMP support despite of the name):
#
#    - secure_mode (allows clients to add mappings only
#     to their IP, you should recognize this one :-)
#
#    - permission rules (from miniupnpd.conf sample:
#    (allow|deny) (external port range) ip/mask (internal port range)
#    it is advised to only allow redirection of port above 1024
#    and to finish the rule set with "deny 0-65535 0.0.0.0/0 0-65535"
#
#   BTW as user I would want the second: my printer has no
#   good reason to open a hole in the home gateway.

which was the only argument that I saw for requiring hop-by-hop PCP
processing (that is, using the default gateway or DHCP-assigned address),
and against an IANA-assigned address.

-d

---

From: Francis Dupont <[email-masked]>
Date: Mon, 21 Mar 2011 17:16:22 +0100

done in user mode).

=> yes, it requires an ALG.

   Yet ALGs are implemented

=> the fact ALGs are implemented doesn't remove the other fact
we seemed to agree about which is that ALGs are BAD.

   processing

=> no, it was not hop-by-top processing nor requiring, it was just
a PCP proxy will be very likely requested by users (and why).

=> this is right: the argument is against the IANA-assigned address
(but it is far to be the only argument against the IANA-assigned
address, BTW I believed we had a consensus and this consensus
doesn't include the IANA-assigned address?)
   
Regards

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Mar 2011 11:53:01 -0700

> Sent: Monday, March 21, 2011 9:16 AM
> To: Dan Wing
> Cc: 'Alain Durand'; [email-masked]; 'Stuart Cheshire'

The consensus was established before we analyzed the difficulty
of building a future-proof PCP Proxy.

A re-evaluation in that light seems prudent.

-d

---

From: Francis Dupont <[email-masked]>
Date: Mon, 21 Mar 2011 23:20:29 +0100

=> I don't understand this argument: all the difficulties come
from things which requires a PCP Proxy so where is the advantage
to make a PCP proxy harder to implement?

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Mar 2011 16:20:48 -0700

> Sent: Monday, March 21, 2011 3:20 PM
> To: Dan Wing

I already showed that it's no more difficult to implement the
IANA-registered address than using the default route address.

The IANA-registered address has the distinct advantage
that it does _not_ require hop-by-hop support/awareness of PCP.

Your argument, if I understand it correctly, is that was 
_always_ want PCP awareness at every layer 3 hop.

-d

---

From: <[email-masked]>
Date: Tue, 22 Mar 2011 14:40:06 +0800

|On 11 Mar 2011, at 15:11, Alain Durand wrote:
|
|> Dan:
|> 
|> It seems to me that our 'old' idea of using the AFTR IANA assigned 
|> address (192.0.0.1) as the default address of the PCP server 
|(instead 
|> of sending to the default router) would actually solve this 
|problem more elegantly...
|> 
|> What do you think?
|> 
|>   - Alain.
|
|I'm still a big fan of this approach. In some cases it may be 
|a little more work to implement on the server side, but once 
|done, it provides wonderful zero-configuration operation for 
|the clients. The client just has one address to send to, and 
|either it works or it doesn't, and if it doesn't then that's a 
|server-side configuration error that needs to be fixed (by one 

what if the failure is not due to configuration, instead  it's due 
to server failure, in which case some sort of PCP server 
discovery mechanism may help PCP Client finding an available server;
while fixing default address denies PCP Client opportunities finding a
new server.

Thanks,
Xiaohong
opensource A+P: http://opensourceaplusp.weebly.com/

|knowledgable server operator), not a client-side configuration 
|error (to be fixed by countless end-users who have no idea 
|what this means).
|
|Stuart Cheshire <[email-masked]>
|* Wizard Without Portfolio, Apple Inc.
|* www.stuartcheshire.org
|
|
|

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Mar 2011 11:24:31 +0100

=> it is a common issue to all simple discovery methods (i.e.,
the default router method shares it): there is no possibility
of backup, capability negociation, etc. This is why the first method
in base documents is the DHCP & co configuration.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Mar 2011 12:37:52 +0100

=> IMHO you have already showed the exact opposite, so can you
detail your logic here?

=> it has the distinct disadvantage to work very badly when
PCP awareness is needed somewhere on the path.

=> you don't understand correctly: my argument is
very likely want PCP awareness somewhere on the path.
(always -> very likely and out of our control,
 every/hop-by-hop -> somewhere (IMHO it should be the CP router))

Regards

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 22 Mar 2011 11:13:45 -0700

> Sent: Tuesday, March 22, 2011 4:38 AM
> To: Dan Wing

An IANA-registered address works well if PCP awareness is needed --
the on-path device processes the PCP messages, same as with using
the default gateway.

The advantage is that if the default gateway doesn't need to
process PCP messages, PCP will still work.  

If a user needs PCP processing at a router, because that
router is also doing filtering (e.g., implementing IPv6 
Simple CPE Security), then it processes the PCP messages
on the IANA-assigned address.  If the router does _not_
implement IPv6 Simple CPE Security, the PCP message goes
upstream to the next router that might want to process
the message.  In a wireless network, it would be typical
for the service provider to provide filtering to protect
both the service provider's access network and the 
subscriber's battery-operated device.  

Such as a routed network in the home, which is necessary as
we move beyond just WiFi in the home to things like sensor
networks, smartgrid, and other in-home network technologies 
which are appearing on the horizon.  Several of those network
technologies have different MTU than Ethernet, and cannot
be bridged.

In short:  an IANA-assigned address works in all 
circumstances, including if each router wants to process
PCP messages and including if each router does not want
(or care) to process PCP messages.  In contrast, using the 
default gateway creates a constraint:  PCP has to be processed
by every router along the path.

-d

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 22 Mar 2011 12:43:46 -0700

> while fixing default address denies PCP Client opportunities finding a

When requesting a NAT mapping, there is only *ONE* NAT gateway that it makes sense to make your mappings in: the one that your traffic is going through. If that NAT gateway is defective in some way, making mappings in some other NAT gateway (that your traffic's not going through) doesn't help.

Over the last six years since we shipped NAT-PMP and IGD support in Mac OS 10.4, we get this bug report with some regularity. The story usually goes something like this:

Customer: Mac OS X won't make port mappings in my UPnP gateway. My Xbox/PS3/PC works fine, and has done for years.

Apple: What do you mean "works fine"?

Customer: It says on the screen that it's working.

Apple: Have you tested it?

Customer: What?

Apple: Can your Xbox/PS3/PC receive connections or packets from outside your network?

Customer: Yes, of course. Oh, wait, it doesn't work. Let me get back to you on this...

Customer: You'll never guess what! My home gateway has UPnP turned off! But I have an old Linksys still connected to the network that I'm not using as my home gateway any more, and it has UPnP turned on, and all my devices were talking to that instead! Isn't that amazing! I turned on UPnP on my actual home gateway and now the Mac is working fine.

Apple: Thank you for your bug report.

What we learn from this is that making mappings in the wrong device doesn't help. What the customer reported as "My Mac has a problem" was actually "*ONLY* my Mac is correctly telling me that my network has a problem."

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Mar 2011 22:38:08 +0100

> => IMHO you have already showed the exact opposite, so can you

=> I note you didn't provide an answer...

=> no, it doesn't work well because it requires in this case an ALG.

=> no, the case of a default gateway is different because
PCP requests are sent to the default gateway, not to an address
which is reachable through the default gateway.

=> advantage for which?

   If a user needs PCP processing at a router, because that
   router is also doing filtering (e.g., implementing IPv6 
   Simple CPE Security), then it processes the PCP messages
   on the IANA-assigned address.

=> a router which also does filtering is a L3 firewall,
and what you describe is the equivalent for a firewall
of an ALG for a NAT. Not exactly a "work well" case.

   If the router does _not_
   implement IPv6 Simple CPE Security,

=> you take the negation of an example... I assume
it is just a wording issue.

   the PCP message goes

=> I saw a lot of technologies which have different MTU than
Ethernet but are still bridged with Ethernet...
If the argument is it is better to perform L3 operation on
a L3 device, not a L2 one, of course I agree.

   circumstances,

=> anything is feasible in this domain: this doesn't mean
anything is the right thing. And in this case I strongly disagree
if you add "well" after "works".

   including if each router wants to process
   PCP messages and including if each router does not want
   (or care) to process PCP messages.

=> but this is very far to be neutral: an IANA-assigned address
works well *only* when no router wants to process PCP messages.

   In contrast, using the default gateway creates a constraint:

=> I don't believe the default gateway method is great: IMHO
it matches only one case: a client on an internal host attached
to a LAN directly connected to the home gateway. BTW it is
also the NAT-PMP use case.

   PCP has to be processed by every router along the path.

=> no, it has to be processed by every router following
a node which uses this method.

BTW the default gateway method is only the method of last resort
so what we are discussing about?
   
Regards

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 22 Mar 2011 15:08:12 -0700

> Sent: Tuesday, March 22, 2011 2:38 PM
> To: Dan Wing

It can be implemented like an ALG is implemented, and process 
traffic sent to a specific port and specific (IANA-assigned) IP 
address.

This is different from a typical ALG, which processes traffic 
sent to a specific port and any destination IP address.  Such
ALGs have been implemented in NATs, as we all know well.

> => no, it doesn't work well because it requires in this case an ALG.

A user-mode implementation would be *modeled similar to* an ALG, yes.

> of an ALG for a NAT. Not exactly a "work well" case.

Not all routers do filtering.

> it is just a wording issue.

Routers which don't do filtering are not doing IPv6 Simple CPE Security.

> so what we are discussing about?

We're discussing how to get PCP successfully deployed, quickly,
so it will work in the most variety of network topologies.

The "first resort" is manual configuration via a configuration
file (a non-starter for success), and via DHCP.  DHCP 
requires support in the network's DHCP server, which means
in the DS-Lite case the B4 element and in the NAT444 case
the already-deployed CPE in my house.  I don't see that
working too well, until there is a refresh of equipment
or better support, across all sorts of OSs, for DHCP 
INFORM.

-d

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 22 Mar 2011 15:26:32 -0700

>   process PCP messages, PCP will still work.  

Advantage for the users.

This is how it works:

1. Install a PCP-capable NAT.
2. Run PCP-enabled app (no OS-level support required).
3. App sends PCP request to IANA-assigned well-known ("anycast") address and NAT gateway makes the requested mapping.

With this scheme, a PCP-enabled client and a PCP-enabled NAT gateway can talk to each other with no other dependencies -- no changes to DHCP clients, DHCP servers, or any other network infrastructure.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 22 Mar 2011 23:43:21 +0100

> => I note you didn't provide an answer...
   
   It can be implemented like an ALG is implemented,

=> so your argument is an ALG is no more difficult to implement
than a regular user-mode proxy? If it is the case please note
I strongly disagree.

   
=> a 100% user-mode implementation is not possible so it is not
only 'modeled similar to'.

   
=> yes, no all routers are firewalls but a router which is
PCP aware must implement a function you can find only in NATs
and firewalls which are based on NAT software.

   
=> but if I just read your text as it is written it means
the only reason to be PCP aware is to do IPv6 Simple CPE Security.

   
=> IMHO this means the IANA-address is disqualified because
of its ALG requirement on PCP aware routers.

=> I can't see how this is more complex than current DNS server
discovery, and inside a simple home network you can still use
the default router method.

BTW I believed the IANA-address method was to solve the whole
PCP server discovery problem, not only the problem inside the
home network. Perhaps the proposal was changed to an IANA-address
for the CPE, something which makes IMHO more sense?
   
Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 23 Mar 2011 00:09:33 +0100

Advantage for the users.
   
   This is how it works:

=> I disagree: OS-level support is required because
it is the adopted way to avoid multiple client interference
on the same host.

   3. App sends PCP request to IANA-assigned well-known ("anycast")
  address and NAT gateway makes the requested mapping.
   
=> there is an ambiguity here about what is the IANA-assigned
address for, in particular is it for a PCP server or for the CPE?

   NAT gateway

=> I don't know what is a NAT gateway but it is a minor point.
Multiple NATs in the home network too but I don't expect this case
to work anyway too.

Regards

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 22 Mar 2011 16:30:05 -0700

> it is the adopted way to avoid multiple client interference

What are you talking about?

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 14:32:29 +0800

|On 21 Mar 2011, at 23:40, [email-masked] wrote:
|
|> what if the failure is not due to configuration, instead  
|it's due to 
|> server failure, in which case some sort of PCP server discovery 
|> mechanism may help PCP Client finding an available server; while 
|> fixing default address denies PCP Client opportunities finding a new 
|> server.
|
|When requesting a NAT mapping, there is only *ONE* NAT gateway 
|that it makes sense to make your mappings in: the one that 
|your traffic is going through. If that NAT gateway is 
|defective in some way, making mappings in some other NAT 
|gateway (that your traffic's not going through) doesn't help.

Agreed. Making mappings in some other NAT doesn't help at all.
The PCP server failure that I was thinking is actually a AFTR failure,
as
PCP server usually embedded with AFTR, in which case finding an
available
AFTR offers a new PCP server at the same time. In addition, only
authenticated
customer is able to  make mappings in the AFTR, which help avoiding make
mappings in wrong AFTR.

|
|Over the last six years since we shipped NAT-PMP and IGD 
|support in Mac OS 10.4, we get this bug report with some 
|regularity. The story usually goes something like this:
|
|Customer: Mac OS X won't make port mappings in my UPnP 
|gateway. My Xbox/PS3/PC works fine, and has done for years.
|
|Apple: What do you mean "works fine"?
|
|Customer: It says on the screen that it's working.
|
|Apple: Have you tested it?
|
|Customer: What?
|
|Apple: Can your Xbox/PS3/PC receive connections or packets 
|from outside your network?
|
|Customer: Yes, of course. Oh, wait, it doesn't work. Let me 
|get back to you on this...
|
|Customer: You'll never guess what! My home gateway has UPnP 
|turned off! But I have an old Linksys still connected to the 
|network that I'm not using as my home gateway any more, and it 
|has UPnP turned on, and all my devices were talking to that 
|instead! Isn't that amazing! I turned on UPnP on my actual 
|home gateway and now the Mac is working fine.
|
|Apple: Thank you for your bug report.
|
|
|What we learn from this is that making mappings in the wrong 
|device doesn't help. What the customer reported as "My Mac has 
|a problem" was actually "*ONLY* my Mac is correctly telling me 
|that my network has a problem."

Thanks for sharing this inspiring story.  What's more could we learn
from this ? 
Make sure PCP server controls right NAT? or make sure PCP server
discovery 
is associated with NAT discovery?

Thanks,
Xiaohong

|

---

From: <[email-masked]>
Date: Wed, 23 Mar 2011 14:45:25 +0800

| In your previous mail you wrote:
|
|   what if the failure is not due to configuration, instead  it's due
|   to server failure, in which case some sort of PCP server
|   discovery mechanism may help PCP Client finding an available server;
|   while fixing default address denies PCP Client 
|opportunities finding a
|   new server.
|   
|=> it is a common issue to all simple discovery methods (i.e., 
|the default router method shares it): there is no possibility 
|of backup, capability negociation, etc. This is why the first 
|method in base documents is the DHCP & co configuration.

One thing I'd like to share on this point is that during our UPnP
IWF test, we note that discovery process may help tracking problems.
With the SSDP ,we can at least tell if the failure is due to the IGD
discovery
or the IGD discovery process succeed and something else causes the
problem.

Thanks,
Xiaohong

|
|Regards
|
[email-masked]
|

---

From: Francis Dupont <[email-masked]>
Date: Wed, 23 Mar 2011 13:07:40 +0100

=> ticket #32

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 23 Mar 2011 10:36:59 -0700

>   What are you talking about?

Ticket 32 muddles up unrelated issues. OS-level support is not required.

The existence of user-level libraries like MiniUPnP (which implements NAT-PMP) shows that OS-level support is not required.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 25 Mar 2011 14:03:51 +0100

> => ticket #32
   
   Ticket 32 muddles up unrelated issues.

=> the issue 'How to prevent PCP Client_1 deletes the mappings of
PCP Client_2?" is still in it so IMHO this is no longer
confusing things in the ticket.   

   OS-level support is not required.
   
=> your answer was to use OS-level support so
now you propose something else?

   The existence of user-level libraries like MiniUPnP (which
   implements NAT-PMP) shows that OS-level support is not required.
   
=> IMHO it shows just the issue is real...

Regards