I think.... *righ*... eg: The only clean way with IPinIP is that every proxies
subnet can be distinguished on a registrar by the encapsulation header of IPinIP
and that only has source and destination ACP ULA addresses, yada yada: we need
either more ULA on the proxy and/or the registrar. 

I guess we do not want any on-demand actions on the proxy because that would be
a dynamic state establishment that we try to avoid, so the proxy would need
to set up all the state needed upfront which means it needs one IPinIP tunnel
per subinterface, just at the off-chance that some pledges have the same 
address.

So then we look at the total address waste and obviously we may have 1000 
pledges
but 1 or few registrars, so it definitely would make most sense to get these 
addresses
on the registrar, announce via GRASP and let pleges build tunnels with them.

And the registrars would dynamically build these tunnels based on (Src,Dst) 
encap headers
received, and hopefully somebody comes up with a better way for linux to do 
this than
loosing the first packet which seems to be what Michael is running into.

And given how the tunnels ultimately are built only on a (per-proxy,interface)
basis there is also not a direct attack vector against dynamic creation based
on nasty pledges.

So, i am warming up more to this ;-)

Cheers
    Toerless

On Mon, Jul 17, 2017 at 10:55:40AM +0200, Michael Richardson wrote:
> 
> Eliot Lear <l...@cisco.com> wrote:
>     > On the other hand, maybe it's fundamental, but is relying on LL in this
>     > architecture to go beyond LL boundaries the right thing to do?
> 
> We've already established a way around the concern that made me think
> that we needed multiple LL for the proxy, and also that we needed multiple
> Ar for the proxy connection.
> 
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



-- 
---
t...@cs.fau.de

_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

Reply via email to