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

[<[e-mail]>]

Hi Markus,

It seems that your design is close to what is documented in http://tools.ietf.org/html/draft-ietf-pcp-proxy-04#section-8, no?

FWIW, the heaviness of the b2b model was raised in slide 6 of http://tools.ietf.org/agenda/89/slides/slides-89-pcp-4.pdf but I don't know what was the outcome of that discussion.

Cheers,
Med

>-----Message d'origine-----
>De : pcp [mailto:[e-mail]] De la part de Markus Stenberg
>Envoyé : lundi 5 mai 2014 22:15
>À : Reinaldo Penno (repenno)
>Cc : [e-mail]
>Objet : Re: [pcp] How can I make a ~stateless forwarding PCP proxy again?
>
>On 5.5.2014, at 21.41, Reinaldo Penno (repenno) <[e-mail]> 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. 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/pcp