[Berlin-wireless] vpn03 + NPTv6

[Bastian]

Hi

Inline reply mit mobile MUA.

On Feb 29, 2016 7:26 PM, Stefan Sperling <stsp at stsp.name> wrote:
> 
> On Mon, Feb 29, 2016 at 07:10:57PM +0100, Bastian wrote:
> > Selbes gilt für einfaches end-to-end via OpenVPN/VPN03. Solange wir kein
> > Mesh-Protokoll auf vpn03 sprechen, werden unsere BGP-router das
> > Antwort-Paket immer versuchen via FTTR zuzustellen.
> >
> > Warum funktioniert das aber mit IPv4?
> > Weil wir NAT einsetzen. Unsere BGP-router kennen die VPN03 Subnetze und
> > sorgen dadurch für symmetrisches Routing. Schickst du ein Paket über
> > vpn03 ins Internet, kommt die Antwort auch über das VPN rein.
> 
> > Wuerde das auch mit IPv6 funktionieren, wenn wir NAT haetten?
> > Ich denke schon!
> 
> Könnte man nicht einen Bereich des 2001:bf7::/32 für das VPN 
> reservieren?
> Für den Fall, dass keine Verbindung per WLAN über den Backhone möglich 
> ist,
> nimmt man dann einen /64 Prefix aus diesem Bereich, und die BGP Router
> schicken Traffic für diesen Bereich über das VPN anstatt über den 
> Backbone.

Also die sauberste Lösung wär sowas wie mesh-aware prefix-delegation und 
source-specific (?) Policy-routing. Zumindest wenn gar kein oder 
möglichst wenig NAT/NPTv6 im spiel sein soll.

Aber ja, ich denke so könnte das gehen. Aber mit welchen 
Prefix-Dimensionen arbeiten wir auf beiden Seiten der Translation?

> Das löst zwar nicht das Problem mit Prefixes von anderen ISPs, aber 
> erlaubt
> es Teilnehmern die keinen echten WLAN Link zur "Wolke" haben IPv6 
> Addressen
> aus 2001:bf7::/32 via VPN zu verwenden.


Ganz so einfach ist das in einem dynamischen Mesh leider nicht. Woher 
soll denn der dritte hop in einer kleinen wolke wissen ob sein uplink 
gerade von BBB auf vpn03 gewechselt hat. Der knoten kennt ja erstmal nur 
seinen direkten nexthop. Trotz OLSR table entscheidet der netxt-hop ja 
wie es weiter geht.


FYI, wir haben schon einige nicht zusammenhängende /44 aus dem /32 in 
use