Subject: [pcp] draft-ietf-pcp-proxy-05 + homenet (notably multihoming)

From: Markus Stenberg <[email-masked]>
Date: Thu, 24 Apr 2014 12:26:21 +0300

I’m somewhat confused (nothing new there). Section 3.5 (manual repair) states that local mapping cache is not mandatory. However, section 3 seems to assume it, and describes the NAT-only case. I think this part use some clarification. Especially as mapping cacheless proxy would be quite different beast from just ‘logical back to back client and server’ (see below).

At the moment I’m thinking of implementing very lightweight pcp proxy for homenet style use _within home_, which doesn’t even have firewalls _or_ NATs among consenting inner routers. However, the reason proxy is needed is that:

a) there’s lots of legacy hosts there that don’t support pcp-dhcp, pcp-zones, and pcp-server selection, <solution of the day>, and

b) in case of IPv4, the CPE(s) are most likely NATting, and outbound from inner routers affects where traffic will wind up anyway.

As I don’t see any way of addressing b) even with the existing set of drafts for server selection (unless you assume you have some sort of coupling of IPv4 routing state and PCP that works beyond next-hop routing), there seems to be some sort of gap in the drafts to me. Please explain to me if there isn’t, I’d appreciate that too. [1]

To me the simple choice seems to do _very_ lightweight pcp proxy per-hop, and do server selection based on current IPv4/IPv6 routing state (=where the packets with given source(+destination if PEER) would wind up in any case). Given lack of firewalls and NATs, only state it would need to track is the set of next hops for IPv6 source prefixes, and IPv4 default route. If any of those change, epoch=0, and multicast ANNOUNCEs (and conservatively forward announces on links not heard on recently, or using some tree topology available from some other source).

With that sort of solution, there would be no cache of mappings on the lightweight proxy, but just idea of upstream connectivity (per-prefix IPv6 / default route for IPv4), and some ANNOUNCE multicast spam if that changes.

I think the design could work at least given routing is moderately stable. Comments?

Alternative design is of course to do what the current draft mainly describes - keep full mapping state, and cleverly try to repair it (in event of routing state change) and reset epoch only if you have to, and unicast ANNOUNCEs to clients if they should do something. With that design, low-power devices are spared from extra spam, which is nice, at cost of some implementation complexity and state on the routers.

Still, I can’t wrap my head around non hop-by-hop PCP unless it’s “one tube to internet” home which isn’t really interesting from my point of view. 

Cheers,

-Markus

[1] I know RFC6887 assumes single-homed network, but I’d rather see multi-homed solution work in some way too.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Apr 2014 06:42:11 -0400

> I think the design could work at least given routing is moderately stable. Comments?

That's a pretty big "if".

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 24 Apr 2014 14:02:53 +0300

On 24.4.2014, at 13.42, Ted Lemon <[email-masked]> wrote:
> That’s a pretty big "if".

In a homenet-ish IPv4 case, you have to have moderately stable routing, or you may flap between different CPEs. And bad things happen in that case given different NATs in each, even without PCP..

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Thu, 24 Apr 2014 07:12:51 -0400

> In a homenet-ish IPv4 case, you have to have moderately stable routing, or you may flap between different CPEs. And bad things happen in that case given different NATs in each, even without PCP..

Possibly so.   What you are proposing sounds brittle to me, but that is just an intuitive reaction, and it may be that if you presented a more detailed analysis I would react differently.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 24 Apr 2014 09:03:53 -0400

Le 2014-04-24 05:26, Markus Stenberg a écrit :
> Still, I can’t wrap my head around non hop-by-hop PCP

Assuming that what you mean is what I think you mean, I had the same
issue until I thought of the kind of very lightweight PCP proxy you're
implementing as a degenerate case of a not-so-lightweight PCP
server+client where the server happens to control a stateless firewall
that passes everything. This makes the server+client model apply to
everything, and still allows the implementation shortcuts you envision.
Does that model help you in any way?

Regarding ANNOUNCE relaying, the current text seems to allow both
approaches you are considering. See the last sentence in particular:

   Upon receipt of an unsolicited ANNOUNCE response from a PCP server,
   the PCP Proxy proceeds to renew the mappings and checks whether there
   are changes compared to a local cache if it is maintained by the PCP
   Proxy.  If no change is detected, no unsolicited ANNOUNCE is
   generated towards PCP clients.  If a change is detected, the PCP
   Proxy MUST generate unsolicited ANNOUNCE message(s) to appropriate
   PCP clients.  If the PCP Proxy does not maintain a local cache for
   the mappings, unsolicited multicast ANNOUNCE messages are sent to PCP
   clients.

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