Re: [pcp] How can I make a ~stateless forwarding PCP proxy again?

On May 5, 2014, at 1:14 PM, Markus Stenberg <markus.stenberg@iki.fi> wrote:

> On 5.5.2014, at 21.41, Reinaldo Penno (repenno) <repenno@cisco.com> wrote:
>> we had this discussion in the past but and I, for one, backed the idea of PCP being able to support stateless proxies.  So, you are not alone there but maybe you want to write a draft about it so the WG can discuss it.
> 
> 
> Nods. Personally I like to minimize the amount of state in a system, so I’m a fan of stateless designs. My current design for a proxy has just 3 logical pieces of ‘state’ per supported remote server:
> 
> - (client) source prefix + prefix length to match
> - address of the server
> - server epoch + when was it received
> 
> And currently I’m trying to make sure it’s actually doable to do all I want with just that and few hundred lines of C. After looking at how big PCP client libraries are, last thing I want is really PCP client glued to PCP server.
> 
> Getting back to my previous question, now that I think of it, actually, the IP address of the client is in the THIRD_PARTY option. Only thing that isn’t explicitly stored somewhere is the address client contacts the proxy on (it probably has 1-N addresses per M interfaces). If proxy uses same source address for talking with server as client used to contact it (with different port, obviously), it should work fine, without per-client or per-request state. 
> 
> e.g.
> 
> C -> P [IntIP=C]
> P -> S [IntIP=P, TP=C]
> S -> P [TP=C]
> P -> C [no TP]
> 
> Beyond that, some ANNOUNCE handling is needed, but as long as you stick to multicast, that can be also stateless. (Connected clients know if they have state with the particular proxy that spams ANNOUNCEs.)
> 
> Perhaps I’ll write up about it somewhere (pcp or homenet), although it’s more of an implementation detail draft, than actual protocol change requiring one.
> 
> Cheers,
> 
> -Markus
> 
> P.S. This scheme works fine with IPv4. With IPv6, it may have issues, when C contacts P using link-local address and I don’t think there is anything preventing that.

Correct, nothing prevents it.  But C is unable to show it owns another address (so can't use THIRD_PARTY), and link-local doesn't do anything on the other side of the router (firewall), so seems fruitless for C's PCP client to use link local.  I would even think P or any PCP server should just return an error if the PCP request came from an IPv6 link local address and the proxy (or PCP server) is not doing NPTv6 or NAT66.  Link local can't go anywhere, so seems an error no matter if proxy or PCP server returns an error -- link-local won't do any good as a firewall rule because it isn't routable from the Internet.

-d

> P is probably unable to contact S using that. Oh well. I guess doing other IPv6 scopes would work, and falling back to IPv4 if client doesn’t do DHCP*/RA/something else option to learn the IPv6 GUA/ULA of the proxy on first hop.
> 
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp