[linux-support] IPv6-Anbindung via IPv4-Home-Netz

[Gaudenz Steinlin]

Hallo zusammen

Oh je, ich ignoriere meine Listenmails mal für ein paar Tage und gleich
kommt da eine interessante Diskussion... Ich versuche mal noch meine
Sicht einzubringen.

Markus Wernig <wernigm at lugbe.ch> writes:

> Hallo allerseits
>
> Ich würde gern (für manche überraschend, aber das ist eine andere
> Geschichte ;-) von mir "zu Hause" aus (d.h. aus dem IPv4-LAN hinter
> meinem NAT-Router) IPv6-Hosts bzw. -Netze erreichen können. Mein ISP
> (Cablecom) unterstützt das noch nicht nativ, daher brauche ich wohl
> einen Tunnelbroker, dem ich meine IPv6-Pakete in IPv4 enkapsuliert
> schicken kann.

Welcome on board!

>
> Hier hätte ich ein paar (recht schlecht spezifizierte) Fragen:
>
> - kann jemand einen Tunnelbroker empfehlen? - nach meinem Verständnis
> funktionieren die meisten der Tunnelling-Protokolle (6to4, 6in4, ...)
> schlecht bis gar nicht mit NAT. Falls schon jemand vor dem gleichen
> Problem stand: konntet ihr das Problem lösen? - würde jemand einen
> anderen Ansatz vorschlagen?

Wie die meisten anderen habe ich meine Tunnel Installationen mit SIXXS
gemacht. Das Kredit verfahren ist höchstens am Anfang ein Problem.
Sobald du einen Tunnel länger betreibst hast du automatisch genug
Kredits. Ich denke es ist durchaus richtig, dass man zuerst mal mit
einem Tunnel beginnt, bevor man grad ein Subnetz bekommt.

Nun noch zu den in anderen Mails aufgeworfenen Fragen:

>  Neinein, ich bin's schon ... nur weil ich die momentane Vergabepolitik
>  für IPv-Adressen haarsträubend finde (das /48-Netz, das ich bekommen
>  habe, hat 2^48 mal soviele Adressen wie der gesamte IPv4-Range, d.h.
>  das derzeitige Internet, und ich brauche noch nicht mal 20 davon ...
>  das wird sich irgendwann rächen, daran halte ich fest), heißt das ja
>  nicht, dass das nicht ausprobiert werden muss ;-)

Ich will nun nicht den Streit vom letzten Mal neu entfachen. Aber ein
neues Argument habe ich noch gefunden: Zur Zeit wird neben den Ranges
für spezielle Zwecke nur die Range 2000::/3 als "Global Unicast"
definiert. Es ist also nur ca. 1/8 des Adressraums "zur Verwendung
freigegeben". Falls sich deine Befürchtung also bewarheiten sollte,
stehen immer noch fast 7/8 für eine restriktivere Vergabepolitik zur
Verfügung. Das ist ein viel grösserer Anteil am globalen Adressraum als
für IPv4 zur Verfügung stand als die Vergabepolitik restriktiver wurde.

Folgender Link gibt einen Überblick über die vergebenen Bereiche.
Achtung nicht jede Zeile entspricht gleich vielen Adressen.
http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml

>   Sehr angenehm im IPv4 finde ich allerdings immer noch die
>   RFC1918-Bereiche, da kann ich einfach beliebig schalten und walten,
>   ohne mir Gedanken machen zu müssen, ob nicht meine Firewall das
>   vielleicht doch routet. Und ehrlich gesagt finde ich es auch
>   sinnvoller, interne Netze (Drucker, Workstations, Beamer usw.) eben
>   gerade nicht öffentlich zu adressieren. Da SOLL ja gerade niemand von
>   außen drauf kommen! Die Zeiten, wo jede Workstation z.B. in einem
>   Uni-Netz eine öffentlich routbare IP hatte und dort auch jederzeit
>   erreichbar war, empfindet meine Firewaller-Seele halt als tiefstes
>   Mittelalter. Private IP-Ranges machen das ganze sooooo viel
>   einfacher. Ich denke daher, es wird bald auch in IPv6 analoge, nicht
>   routbare Netzbereiche geben.

>   Und dass mir jetzt keiner mit fe80:: kommt! Die Hardware, die eine
>   Muliticast Domain mit derzeit mindestens 2^64 Receivers unterstützen
>   kann, muss erst gebaut werden!

Ja fe80::/64 ist etwas anderes. Das sind link-local Adressen analog zu
169.254.0.0/16. Sie werden für Dinge wie zeroconf/avahi/etc. verwendet.
Für generelles Networking sind sie nicht geeignet, da ja jedes Interface
eines Gerätes eine Adresse in diesem Netz hat, aber zwischen den Netzen
nicht geroutet werden kann.

Das analog zu den RFC1918 Bereichen sind die "Unique Local Unicast"
Adressen im fc00::/7 Bereich. Zur Zeit wird davon nur fd00::/8
verwendet. Die Idee dabei ist, dass man die 40 Bits nach fd00: für eine
zufällige Site ID verwendet. So vermeidet man die Probleme die bei
RFC1918 Adressen entstehen, wenn ursprünglich getrennte Netze
zusammengeführt werden müssen (z.B. bei einer Unternehmensfusion).
Währenddem heute Adresskolisionen in solchen Fällen sehr wahrscheinlich
sind, würden damit Adresskolisionen unwahrscheinlich. Für fc00::/8 ist
sogar vorgesehen, dass man die Site ID registrieren kann und damit eine
Adresskolission nicht mehr vorkommen sollte.

>     > Ja praktisch ist's wenn hinter dem NAT nichts erreicht werden darf.
>     > Aber das kann man mit einer default Firewall Rule lösen.
>
>     Nur dass dann die Firewall potentiell ca. 2^48 mal mehr Pakete droppen
>     muss (angenommen, sie hätte bisher das gesamte Internet geroutet und
>     gefiltert)...

Diesen Einwand verstehe ich nicht. Warum müssen mehr Pakete gedroppt
werden, weil es mehr Adressen gibt. Das hat doch mit deiner Bandbreite
bzw. mit dem globalen Netzwerkverkehr zu tun. Ich denke der entwickelt
sich unabhängig davon und ist im Moment bei IPv6 noch deutlich geringer.
Deine FW muss also wesentlich weniger Pakete droppen.

Zudem wird es mit IPv6 mehr oder weniger unmöglich ein Netzwerk zu
scannen, da es einfach zu viele Adressen gibt. Somit sollte dieser
Traffic eher abnehmen.

>     > Aber was ist mit den Geräten, Diensten, welche hinter dem NAT
>     > erreichbar sein sollen? Wenn auch nur von bestimmten IPs wie deinem
>     > SIP Provider zu deinen SIP Client? Das ist doch das Problem.
>
>     Jetzt fragt sich nur, welcher Fall häufiger ist?
>     Geräte/Systeme/Server, die wirklich von außen erreichbar sein müssen,
>     oder solche, die auf keinen Fall von außen erreichbar sein sollen. Bei
>     mir zu Hause ist das Verhältnis in etwa 1:50 ("muss erreichbar sein"
>     vs. "soll nicht erreichbar sein"). In den Kundenumgebungen, die ich
>     kenne, tendiert das eher gegen 1:1000.

NAT erstzt doch keine Firewall, oder siehst du das nicht so? Meiner
Meinung nach brauchst du die Firewall Rules trotzdem NAT hin oder her.
Somit sehe ich keinen Mehraufwand und einen grossen Vorteil für die
Geräte und Protokoll, welche von einer direkten Verbindung profitieren.
Ausserdem habe ich doch den Eindruck, dass der zentralisierte Aufbau
vieler Dienst im heutigen Netz auch damit zu tun hat, dass dezentrale
Dienste mit NAT unglaublich mühsam zu implementeiren sind (falls nicht
unmöglich).

Auch muss jeder NAT Gateway sowieso für das NAT ein State tracking jeder
Verbindung machen. Eine Stateful Firewall ohne NAT (für ausgehenden
Traffic) bedeutet auch hier keinen Mehraufwand.

> PS: Wollte nicht mal jemand einen Vortrag über IPv6 halten ... ?

Ja das würde ich immer noch anbieten. Z.B. eine kleine Einführung mit
anschliessender Disussion und Workshop.

Gruss Gaudenz

>
>
> -- Markus Wernig Präsident LugBE GPG: CA558BF7
> --------------------------------------------- Linux User Group Bern -
> http://lugbe.ch
> ---------------------------------------------
>
>
> _______________________________________________ Linux-support mailing
> list Linux-support at lugbe.ch
> http://maillists.lugbe.ch/mailman/listinfo/linux-support

-- 
Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.
~ Samuel Beckett ~
-------------- n�chster Teil --------------
Ein Dateianhang mit Bin�rdaten wurde abgetrennt...
Dateiname   : nicht verf�gbar
Dateityp    : application/pgp-signature
Dateigr��e  : 827 bytes
Beschreibung: nicht verf�gbar
URL         : <http://maillists.lugbe.ch/pipermail/linux-support/attachments/20120927/f0317b42/attachment.sig>