Analyse des Problems von Cisco Bug ID CSCsd13298 Oder Warum funktioniert IPv6 ueber meine PPPoE Verbindung nicht mehr seit ich an einer Cisco C10k angebunden bin? Bjoern A. Zeeb, bzeeb+cscsd13298@zabbadoz.net, 2007-01-17 $Id: article.txt,v 1.1 2009-02-12 20:05:15 bz Exp $ Ausgangssituation: ======================================== Die Deutsche Telekom AG (auch bekannt als DTAG oder AS3320)/T-Com.de/... betreibt ein fast flaechendeckendes deutschlandweites Netz fuer den Breitband DSL Zugang. Zwischen dem Kunden und dem Breitband-Zugangsrouter (BBRAS) auf Seite der Telekom wird das PPP over Ethernet (PPPoE) Protokoll[1] eingesetzt. Klassischerweise wurden dort, soweit oeffentlich bekannt, Geraete vom Hersteller Juniper eingesetzt. In den letzten Monaten wurden diese angeblich vermehrt durch Cisco 10000 Geraete ersetzt. Kunden nutzten die Breitbandzugaenge unter anderem um Zugriff auf das Internet oder ein privates Netzwerk zu erhalten. Dazu koennen die PPP Verbindungen durch das L2TP Protokoll auch zu anderen Providern weitergeleitet werden. PPP ermoeglicht nun nicht nur den Transport von IPv4[2] Daten, sondern auch anderen Protokollen. Mehrere Provider bieten ueber per L2TP getunnelte Zugaenge auch Verbindung zum Internet ueber das Internet Protokoll in der Version 6 (IPv6)[3]. Problembeschreibung: ======================================== In letzter Zeit gab es vereinzelte Beschwerden, dass Zugaenge, die nicht IPv4 nutzen, nicht mehr funktionieren. Allen gemeinsam war, dass diese Zugaenge laut Hinweisen im AC-Name Feld des PPPoE Protokolls bzw. der MAC-Addressen, ab mindestens diesem Zeitpunkt an einer Cisco 10000 terminiert wurden. Oeffentlich bekannt wurde das Problem durch ein Posting im Usenet[4], nachdem es zuvor u.a. im IRC diskutiert wurde. Erste Erkenntnisse zeigen eine konstant falsche Angabe im Laengenfeld des PPPoE Protokolls: 0x0002. Ein weiteres Posting auf der IPv6 Operators Mailingliste[5] bringt sehr schnell genauere Aufklaerung. Es handelt sich in der Tat um einen schon laenger bekannten Fehler in der Implementation fuer die Cisco 10000. Zum damaligen Zeitpunkt gab es bereits seit einigen Monaten eine korrigierte Software, in der das Problem mit der falschen Laengenangaben des Bugs CSCsd13298 behoben sein sollte. Zusammenfassung bisher: Wird IPv6 innerhalb einer PPPoE Verbindung eingesetzt, so setzt eine Cisco 10000, die mit der fehlerbehafteten Software betrieben wird, einen falschen Wert im Laengenfeld. Konsequenz: Das Paket wird beim Endkunden, wegen der viel zu kurzen Laengenangabe von 2 verworfen und damit funktioniert die IPv6 Verbindung nicht. Dies war der Stand im August 2006. Was seither geschah? ======================================== Auch zum Jahreswechsel 2006/2007 bestand das Problem weiterhin. Arnold Nipper, der das Problem urspruenglich bemerkte und anfing es zu analysieren, stellte an seinem Zugang, an dem das Problem auftrat, entsprechende Hardware und seine Zeit zu Verfuegung und es wurde ein speziell veraendertes FreeBSD als neuer IPv6 Router installiert. Nach der Installation stellte sich sehr schnell heraus, dass trotz des praeparierten FreeBSD Systems nicht von ueberall her IPv6-Verbindungen zu diesem aufgebaut werden konnten. Weitere Analysen zeigten, dass zusaetzlich zu den viel zu kurzen PPPoE Laengenangaben auch viel zu hohe, deutlich hoeher als die MTU, vorkommen konnten. Speziell moderne FreeBSD 6 oder FreeBSD 7 Systeme als entfernte Kommunikationspartner zeigten dieses Problem. Das FreeBSD Router System wurde entsprechend angepasst und kann seither trotz des Cisco 10000 Problems auf Seiten der DTAG ohne Probleme per IPv6 kommunizieren. Auch auf Seiten Ciscos hat es Aenderungen gegeben. Wie in den "Cisco IOS Release Notes zu 12.2SB"[6] nachzulesen ist, hatte sich bei der Korrektur von CSCsd13298 ein weiteres Problem eingeschlichen: CSCsf15121. Daraus geht hervor, dass Cisco das urspruengliche Problem dadurch behoben hat, indem die Laenge des Ethernet Frames herangezogen wurde. Dabei wurde nicht beruecksichtigt, dass ggf. eine kuenstliche Frameverlaengerung (Padding) auf Ethernetebene noetig ist. Als Konsequenz kann die Angabe im PPPoE Laengenfeld nun zu hoch ausfallen. Wie sich herausstellen wird, hat dies nichts mit dem Problem der zu langen Angaben bei Kommunikation mit modernen FreeBSD Systemen zu tun. Was ist nun wirklich kaputt? ======================================== Um genauere Aussagen zu dem Problem treffen zu koennen, das CSCsd13298 verursacht, wurden weitere Kommunikationsdaten gesammelt. Es wurden von mehreren unterschiedlichen Betriebssystemen (FreeBSD, Linux, Solaris, JunOS, IOS, Windows, ...) und unterschiedlichen Architekturen Pakete an den FreeBSD IPv6 Router an der problematischen PPPoE Verbindung gesendet. Im Folgenden werden einzelne extrahierte Headerteile dargestellt: * (UPROTO) ist das upper layer Protokoll aus Sicht von IPv6. * PEOL ist das PPPoE Laengenfeld. * VTTF FFFF LLLL NHHL sind die ersten 8 Octets des IPv6 Headers: V: IP Version TT: Traffic Class FFFFF: Flow Label LLLL: Payload Length NH: Next Header HL: Hop Limit Bis auf die modernen FreeBSD 6/7 Systeme sahen die Felder bei allen Verbindungen wie folgt aus (LLLL, NH und HL variieren je nach entferntem System und Art des Paketes): (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063a | Bei den FreeBSD 6/7 Systemen sah es so aus: (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 53a4 | 6004 53a2 002c 063c | Moderne FreeBSD Systeme koennen das IPv6 Flow Label automatisch setzen und machen dies auch in der Standardeinstellung. Mehr Informationen dazu finden sich z.B. in [7] und [8]. Wie deutlich zu sehen ist hat sich das PPPoE Laengenfeld um den Wert der niederwertigen 32bit des Flow Labels erhoeht: 0x0002 + 0x53a2 = 0x53a4 Da von den sonstigen getesteten Systemen keines das Flow Label gesetzt hatte, blieb der Wert konstant auf 0x0002. Warum 32bit aus dem Flow Label? ======================================== Darueber laesst sich schlussendlich nur spekulieren, denn ausser Cisco kennt niemand die genaue Implementation. Es scheint aber wahrscheinlich, dass entweder IPv6 wie IPv4 behandelt wird oder evtl. auch andere/alle PPP DLL Protokolle wie IPv4 behandelt werden. Im folgenden werden die Header der relevanten Protokolle mit Hinweisen auf die entsprechenden RFCs dargestellt. Dazwischen wird jeweils erlaeutert, wie das Protokoll im aktuellen Problem relevant ist. Zuerst betrachten wir den PPPoE Header. Worueber PPPoE transportiert wird, soll ausser Acht gelassen werden. RFC 2516 Transmitting PPP Over Ethernet 4. Payloads 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VER | TYPE | CODE | SESSION_ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LENGTH | payload ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Das relevante Feld im PPPoE Header ist das LENGTH-Feld. Dies enthaelt den je nach Fall ggf. inkorrekten Laengenwert. Direkt dahinter folgen die Daten auf der naechst hoeheren Schicht. Im Fall von PPPoE sind dies PPP Daten: RFC 1661 Point-to-Point Protocol 2. PPP Encapsulation +----------+-------------+---------+ | Protocol | Information | Padding | | 8/16 bits| * | * | +----------+-------------+---------+ Das "Protocol"-Feld enthaelt einen Wert, der angibt, welches Protokoll transportiert wird. So kann PPP mehrere Protokolle ueber eine Verbindung transportieren. Dort koennen pro Paket u.a. die Werte fuer IPv4 oder IPv6 stehen. Unter gewissen Umstaenden, falls ausgehandelt, kann das Feld auf 1 octet verkuerzt werden, in der Regel sind es aber immer 2 octets. Diese 2 Octets sind hoechst wahrscheinlich die 0x0002 im PPPoE Laengenfeld. In den meisten Faellen wird IPv4 uebertragen: RFC 791 INTERNET PROTOCOL 3.1. Internet Header Format 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Der einzige wichtige Punkt an IPv4 ist die Stelle im Header, an der die Laenge des IPv4 Headers und des zusaetzlichen Payloads zu finden ist. Das Feld "Total Length", welches in den Octets 3 und 4 direkt nach dem PPP Protokollfeld folgt, enthaelt diese Informationen. Das Problem besteht allerdings bei IPv6: RFC 2460 IPv6 Specification 3. IPv6 Header Format 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Wenn man sich nun die Stelle anschaut, die die niederwertigen 32bit des Flow Labels enthaelt, ist dies genau das 3. und 4. Octet nach dem PPP Protokollfeld. Genau an dieser Stelle steht bei IPv4 die Laenge der Daten nach dem PPP Protokollfeld. Da bei fast allen Testsystemen kein Flow Label gesetzt wurde und das Feld 0x00000 enthielt, blieb das PPPoE Length Feld auf 0x0002 stehen. Bei den modernen FreeBSD Systemen wurden die niederwertigen 32bit des Flow Labels zu den 0x0002 hinzu als PPPoE Payload Laenge angegeben. Cisco behandelt also zumindest IPv6 wie IPv4 Pakete und versucht die Laenge fuer das PPPoE Laengenfeld zu errechenen. Da PPP, wie bereits erwaehnt, viele Protokolle transportieren kann, muesste fuer jedes unterstuetzte Protokoll eine Spezialbehandlung implementiert werden. Dies ist unpraktikabel und Cisco hat sich, wie oben fuer CSCsf15121 erklaert, auch fuer eine andere Variante entschieden. Andererseits heisst dies auch, dass es trotz des Bugs moeglich ist, IPv6 Pakete mit korrektem PPPoE Laengenfeld bis zum Endkunden transportieren zu lassen. Dazu muss das Flow Label Feld nur geeignet auf Laenge des IPv6 Headers(40) + IPv6 Payload Length gesetzt werden. Da es nicht moeglich ist, bei einem IPv6 RAW socket das Flow Label zu setzen, muss ein geeignetes Paket komplett von Hand zusammengebaut und gesendet werden. Ein entsprechendes Paket kann sehr gut als Test genutzt werden, um festzustellen, ob es sich bei IPv6 Problemen um ein Problem wegen CSCsd13298 handelt. Entsprechendes wurde bereits erfolgreich getestet. Zusammenfassung: ======================================== Das Problem ist bereits laenger bekannt. Es war ein Cisco Problem, aber Cisco hat das Problem mittlerweile beseitigt. IPv6 wird immer populaerer. Es gibt einen Patch fuer FreeBSD, der es trotzdem ermoeglicht IPv6 zu nutzen, nur leider ist dies nicht fuer eine breite Masse einsetzbar. Es gibt eine Moeglichkeit zu testen, ob bei IPv6 Problemen wirklich der Cisco Bug verantwortlich ist. Die DTAG sollte ihre Router updaten, damit das Problem aus der Welt ist. Mehr Beispieldaten: ======================================== ----- "Windows" "2003" "i386" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | (TCP ) 0002 | 6000 0000 0018 063a | ----- "SunOS" "5.9" "sun4u" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 001c 0636 | (TCP ) 0002 | 6000 0000 001c 0636 | (TCP ) 0002 | 6000 0000 001c 0636 | (TCP ) 0002 | 6000 0000 001c 0636 | (TCP ) 0002 | 6000 0000 001c 0636 | ----- "IOS" "12.4(10)" "Cisco" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6c00 0000 0018 063a | (TCP ) 0002 | 6c00 0000 0018 063a | (TCP ) 0002 | 6c00 0000 0018 063a | ----- "IOS" "12.2(31)SB2" "Cisco" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6c00 0000 0018 0639 | (TCP ) 0002 | 6c00 0000 0018 0639 | (TCP ) 0002 | 6c00 0000 0018 0639 | (TCP ) 0002 | 6c00 0000 0018 0639 | (TCP ) 0002 | 6c00 0000 0018 0639 | ----- "IOS" "12.2(25)S10" "Cisco" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6c00 0000 0018 0638 | (TCP ) 0002 | 6c00 0000 0018 0638 | (TCP ) 0002 | 6c00 0000 0018 0638 | (TCP ) 0002 | 6c00 0000 0018 0638 | (TCP ) 0002 | 6c00 0000 0018 0638 | ----- "IOS" "12.4(10)" "Cisco" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6c00 0000 0018 063a | (TCP ) 0002 | 6c00 0000 0018 063a | (TCP ) 0002 | 6c00 0000 0018 063a | (TCP ) 0002 | 6c00 0000 0018 063a | (TCP ) 0002 | 6c00 0000 0018 063a | ----- "IOS" "12.2(25)S5" "Cisco" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6c00 0000 0018 063e | (TCP ) 0002 | 6c00 0000 0018 063e | (TCP ) 0002 | 6c00 0000 0018 063e | (TCP ) 0002 | 6c00 0000 0018 063e | (TCP ) 0002 | 6c00 0000 0018 063e | ----- "IOS" "12.2(25)SEE2" "Cisco" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6c00 0000 0018 063b | (TCP ) 0002 | 6c00 0000 0018 063b | (TCP ) 0002 | 6c00 0000 0018 063b | (TCP ) 0002 | 6c00 0000 0018 063b | (TCP ) 0002 | 6c00 0000 0018 063b | ----- "IOS" "12.4(8)" "Cisco" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6c00 0000 0018 063e | (TCP ) 0002 | 6c00 0000 0018 063e | (TCP ) 0002 | 6c00 0000 0018 063e | (TCP ) 0002 | 6c00 0000 0018 063e | (TCP ) 0002 | 6c00 0000 0018 063e | ----- "IOS" "12.4(2)T" "Cisco" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6c00 0000 0018 063d | (TCP ) 0002 | 6c00 0000 0018 063d | (TCP ) 0002 | 6c00 0000 0018 063d | (TCP ) 0002 | 6c00 0000 0018 063d | (TCP ) 0002 | 6c00 0000 0018 063d | (TCP ) 0002 | 6c00 0000 0018 063d | (TCP ) 0002 | 6c00 0000 0018 063d | ----- "IOS" "12.2(25)S11" "Cisco" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6c00 0000 0018 063d | (TCP ) 0002 | 6c00 0000 0018 063d | (TCP ) 0002 | 6c00 0000 0018 063d | (TCP ) 0002 | 6c00 0000 0018 063d | (TCP ) 0002 | 6c00 0000 0018 063d | ----- "IOS" "12.3(14)T7" "Cisco" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6c00 0000 0018 063c | (TCP ) 0002 | 6c00 0000 0018 063c | (TCP ) 0002 | 6c00 0000 0018 063c | (TCP ) 0002 | 6c00 0000 0018 063c | (TCP ) 0002 | 6c00 0000 0018 063c | ----- "IOS" "12.2(18)SXF7" "Cisco" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6c00 0000 0018 063c | (TCP ) 0002 | 6c00 0000 0018 063c | (TCP ) 0002 | 6c00 0000 0018 063c | (TCP ) 0002 | 6c00 0000 0018 063c | (TCP ) 0002 | 6c00 0000 0018 063c | ----- "Linux" "2.6.19.1-vs2.2.0-rc6" "i686" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | ----- "Linux" "2.6.19.1" "i386" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | ----- "Linux" "2.4.21-9.2.3.27.0smp" "i386" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0020 063c | (TCP ) 0002 | 6000 0000 0020 063c | (TCP ) 0002 | 6000 0000 0020 063c | (TCP ) 0002 | 6000 0000 0020 063c | (TCP ) 0002 | 6000 0000 0020 063c | ----- "Linux" "2.4.30" "mipsel" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (ICMPv6) 0002 | 6000 0000 0040 3a3a | (ICMPv6) 0002 | 6000 0000 0040 3a3a | (ICMPv6) 0002 | 6000 0000 0040 3a3a | (ICMPv6) 0002 | 6000 0000 0040 3a3a | (ICMPv6) 0002 | 6000 0000 0040 3a3a | (ICMPv6) 0002 | 6000 0000 0040 3a3a | (ICMPv6) 0002 | 6000 0000 0040 3a3a | ----- "Linux" "2.6.13-15.13-smp" "i686" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | ----- "Linux" "2.6.13-15.13-smp" "x86_64" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | ----- "Linux" "2.6.15-27" "i686" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | ----- "Linux" "2.6.8-3-686-smp" "i686" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | ----- "Linux" "2.6.18.1" "i686" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | ----- "Linux" "2.6.8-3-686-smp" "i686" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | (TCP ) 0002 | 6000 0000 0028 063c | ----- "Linux" "2.6.18-1.2869.fc6" "i686" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 0639 | (TCP ) 0002 | 6000 0000 0028 0639 | (TCP ) 0002 | 6000 0000 0028 0639 | (TCP ) 0002 | 6000 0000 0028 0639 | (TCP ) 0002 | 6000 0000 0028 0639 | ----- "Linux" "2.4.20-37.9.legacy" "i686" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 0639 | (TCP ) 0002 | 6000 0000 0028 0639 | (TCP ) 0002 | 6000 0000 0028 0639 | (TCP ) 0002 | 6000 0000 0028 0639 | (TCP ) 0002 | 6000 0000 0028 0639 | ----- "Linux" "2.6.17-1.2142_FC4" "i686" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 0639 | (TCP ) 0002 | 6000 0000 0028 0639 | (TCP ) 0002 | 6000 0000 0028 0639 | (TCP ) 0002 | 6000 0000 0028 0639 | (TCP ) 0002 | 6000 0000 0028 0639 | ----- "Linux" "2.4.22-1.2199.8.legacy.nptl" "i686" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | ----- "JunOS" "7.5-20060511.0" "m-series" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | (TCP ) 0002 | 6000 0000 0028 063b | ----- "JunOS" "7.6R3.6" "mm7i" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0018 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0018 063d | (TCP ) 0002 | 6000 0000 0018 063d | (TCP ) 0002 | 6000 0000 0018 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0028 063d | (TCP ) 0002 | 6000 0000 0018 063d | (TCP ) 0002 | 6000 0000 0018 063d | (TCP ) 0002 | 6000 0000 0018 063d | (TCP ) 0002 | 6000 0000 0018 063d | ----- "FreeBSD" "4.8-STABLE" "i386" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063a | (TCP ) 0002 | 6000 0000 0028 063a | (TCP ) 0002 | 6000 0000 0028 063a | (TCP ) 0002 | 6000 0000 0028 063a | (TCP ) 0002 | 6000 0000 0028 063a | ----- "FreeBSD" "7.0-CURRENT" "sparc64" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 8c41 | 6005 8c3f 002c 063a | (TCP ) c632 | 6001 c630 002c 063a | (TCP ) 4dc7 | 6001 4dc5 002c 063a | (TCP ) 9296 | 6005 9294 002c 063a | (TCP ) 8e37 | 6007 8e35 002c 063a | (TCP ) 8856 | 6003 8854 002c 063a | ----- "FreeBSD" "6.2-PRERELEASE" "i386" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 262d | 6002 262b 002c 063a | (TCP ) 82f4 | 6003 82f2 002c 063a | (TCP ) 1243 | 6006 1241 002c 063a | (TCP ) 1fc5 | 6005 1fc3 002c 063a | (TCP ) 0d53 | 6004 0d51 002c 063a | ----- "FreeBSD" "6.2-PRERELEASE" "amd64" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) b1f1 | 6008 b1ef 002c 063a | (TCP ) 0f7b | 600f 0f79 002c 063a | (TCP ) 52d7 | 6008 52d5 002c 063a | (TCP ) 7a65 | 6009 7a63 002c 063a | (TCP ) 497b | 6008 4979 002c 063a | ----- "FreeBSD" "7.0-CURRENT" "i386" ----- (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 53a4 | 6004 53a2 002c 063c | (TCP ) f47a | 6006 f478 002c 063c | (TCP ) d6da | 6004 d6d8 002c 063c | (TCP ) 0837 | 6002 0835 002c 063c | (TCP ) 6b0b | 6002 6b09 002c 063c | (TCP ) c320 | 6004 c31e 002c 063c | Vielen Dank...: ======================================== Mein besonderer Dank gilt Arnold Nipper, der nicht nur Hardware und einen Testzugang sondern auch Zeit fuer Analysen und die Installation zur Verfuegung gestellt hat. Viel Spass wieder mit IPv6 im Haus. Mein weiterer Dank gilt allen, die geholfen haben Beispieldaten zu generieren bzw. ein anderes betroffenes Testsystem zur Verfuegung gestellt haben (in alphabetischer Ordnung): Dominik Bay, Sascha Lenz, Daniel Roesen, Bernhard Schmidt, Marcus Stoegbauer Literaturhinweise: ======================================== [1] http://www.rfc-editor.org/rfc/rfc2516.txt RFC 2516 A Method for Transmitting PPP Over Ethernet (PPPoE) [2] ftp://ftp.rfc-editor.org/in-notes/std/std5.txt STD 5 / RFC 791 INTERNET PROTOCOL [3] ftp://ftp.rfc-editor.org/in-notes/rfc2460.txt RFC 2460 Internet Protocol, Version 6 (IPv6) Specification [4] http://groups.google.com/group/de.comm.internet.infrastruktur/browse_frm/thread/023669c284e526fa/636157d4dc28e6c7 Probleme mit native IPv6/DSL/C10k Message-ID: <1154073696.94242@server.nipper.de> [5] http://lists.cluenet.de/pipermail/ipv6-ops/2006-August/thread.html#662 C10k/PPPoE/IPv6 -> mess [6] http://www.cisco.com/en/US/products/ps6566/prod_release_note09186a008070efb4.html#wp3984150 Cross-Platform Release Notes for Cisco IOS Release 12.2SB Cisco Systems [7] http://www.maths.tcd.ie/~dwmalone/p/ec2nd05slides.pdf Slides from EC2ND conference about using the IPv6 flow label for firewalling, written by Orla McGann and David Malone. [8] http://www.maths.tcd.ie/~dwmalone/p/ec2nd05.pdf Paper from EC2ND conference about using the IPv6 flow label for firewalling, written by Orla McGann and David Malone. # end ################################################################################ $Log: not supported by cvs2svn $ Revision 1.4 2007/01/23 18:46:23 bz Log eingefuegt. Revision 1.3 2007/01/23 18:28:51 bz Literaturhinweise nach erstem Auftreten sortiert (Hinweis von Arnold Nipper). Revision 1.2 2007/01/23 18:26:04 bz Aenderungen nach review durch Arnold Nipper. Revision 1.1 2007/01/17 22:17:48 bz Analyse des Problems von Cisco Bug ID CSCsd13298.