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

[Markus Stenberg <[e-mail]>]

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.