Hi Mark,
Am Mittwoch, 18. Dezember 2002 22:34 schrieb Mark Doll:
> Das JOIN richtet ja /112-Netze auf den Tunneln ein mit ::1 auf ihrer und
> ::2 auf der anderen Seite. Problematisch finde ich, dass dann ein Paket
> an eine der 65534 anderen, nicht existierenden Adressen (z. B. ::3)
> immer zwischen den Routern hin- und herwandert, bis es schlie�lich beim
> Erreichen des Hoplimits verworfen wird.
Das ist richtig und ein bekanntes Problem bei Point-to-Point-Links.
Gerade im globalen Routingbereich (auf nativen Links) ist es aber immer
notwendig das Interface des Partners ueber ein IGP sehen zu koennen.
Uebliche Praxis ist hierbei meist sogar ein /64. Wir benutzen da aus
historischen Gruenden und aufgrund der Lesbarkeit ein /112.
> W�re es nicht sinnvoller statt eines /112er eine dedizierte Host-Route
> auf das Gegen�ber plus eine /112er Unreachable-Route zu setzen?
Wir haben uns entschlossen fuer jeden unserer Kunden ein /112-Subnetz
zu definieren und zu reservieren. Wir haben dies zur Vereinheitlichung
fuer jeden Kunden gemacht, _manchmal_ benoetigt man das zwingend (IBGP).
Ausserdem habe wir die /48-Routen bei uns auf diese Interfaceadresse und
nicht auf das Tunnelinterface gelegt. Dies ist ebenfalls zur
Vereinheitlichung, bei nativen PtP-Verbindungen ist dies notwendig.
Weiterer Vorteil ist, das der Kunde 'gezwungen' ist, die von uns gewuenschte
Adresse auf das Verbindungsinterface zu legen, und wir so zuverlaessig und
einheitlich die Verbindung ueberwachen koennen.
> Als Beispiel unter Linux hier unser 6WiN-Uplink:
>
> Anstatt also wie bisher
>
> ip tunnel add 6win mode sit remote 193.174.75.249 local 141.3.70.6 ttl 64
> ip link set 6win up
> ip addr add 2001:638:0:300::204:2/112 dev 6win
> [...]
>
> zu setzen, nicht lieber so:
>
> ip tunnel add 6win mode sit remote 193.174.75.249 local 141.3.70.6 ttl 64
> ip link set 6win up
> ip addr add 2001:638:0:300::204:2 dev 6win
> ip route add 2001:638:0:300::204:1 dev 6win
> ip route add unreachable 2001:638:0:300::204:0/112
Der entscheidende Punkt hier ist, das es sich um ein Tunnel-Interface
handelt. Bei einer nativen Verbindung waere dies so nicht moeglich.
Von unserer Seite aus behandeln wir aber alle Kundenverbindungen gleich,
also wie eine native Verbindung.
Tatsaechlich koennte man das so auf einem Tunnelinterface machen. Generell
besteht bei einem Tunnel keine Notwendigkeit fuer die /112 Route (von
Kundenseite aus). Ich hab mich neulich schon mal mit jemandem darueber
gestritten, auch bei BSD ginge das aehnlich, dort kann man offenbar 'ueber'
den V4-Tunnel einfach einen V6-Tunnel (mit den beiden /128-Adressen, die
dann auch Routingeintrage bekommen) legen.
Ich hab mir aber an dieser Stelle noch keine Gedanken ueber die Konsequenzen
gemacht, wenn von JOIN ein /112 auf dem Tunnel liegt, und von Kundenseite aus
nicht. Wir empfehlen daher allen Kunden, den Tunnel - so wie wir - wie eine
native Verbindung zu konfigurieren.
Gruss,
Christian
--
JOIN - IP Version 6 in the WiN Christian Schild
A DFN project Westfaelische Wilhelms-Universitaet Muenster
http://www.join.uni-muenster.de Zentrum fuer Informationsverarbeitung
Team: [EMAIL PROTECTED] Roentgenstrasse 9-13
Priv: [EMAIL PROTECTED] D-48149 Muenster / Germany
GPG-/PGP-Key-ID: 6EBFA081 Fon: +49 251 83 31638, fax: +49 251 83 31653
_______________________________________________
ipv6 mailing list
[EMAIL PROTECTED]
http://listserv.uni-muenster.de/mailman/listinfo/ipv6
