Problem of Cisco Bug ID CSCsd13298 or Why does IPv6 no longer work when running on top of a PPPoE connection terminated on a Cisco C10k with an affected IOS release? Bjoern A. Zeeb, bzeeb+cscsd13298@zabbadoz.net, 2007-01-27 $Id: article-en.txt,v 1.1 2009-02-12 20:05:15 bz Exp $ [ This English version follows the original German version to make this information available to a wider audience. ] initial situation: ======================================== End users sometimes have to use PPP over Ethernet (PPPoE) Protocol[1] on broadband access links. Using PPP, it is possible to multiplex multiple protocols such as IPv4[2] or Internet Protocol Version 6 (IPv6)[3]. Lately people have started to experience problems when running IPv6 on connections that were evidently terminated on a Cisco 10000 by DTAG (Deutsche Telekom AG, also known as AS3320/T-Com.de/...). These problems became public in a posting to a German Usenet news group[4]. Initial observations showed a consistently wrong value in the length field of the PPPoE protocol header: 0x0002. A reply to a posting to the IPv6 operators mailing list[5] put things in perspective. Some IOS versions for the Cisco 10000 were affected by a well known bug. Cisco bug ID CSCsd13298 describes the symptoms of the aforementioned problem. The reply also stated that there were patched releases available. This was the case as of August 2006. that was then, what is now? ======================================== As of the beginning of 2007, this problem still exists for the affected customers. Arnold Nipper, who had initially analysed the problem, made available some hardware and spent some time installing a specially patched FreeBSD as his new IPv6 router. After the installation it became obvious that, although the FreeBSD was prepared to handle packets with an invalid value in the length field of the PPPoE header, not all IPv6 connections worked. Further debugging showed that that in addition to the static 0x0002 length field there were length values greatly in excess of the MTU. FreeBSD 6/7 systems at the remote end triggered those special characteristics. Refining the patches also solved the problems such that the FreeBSD IPv6 router doing PPPoE could also cope with length values exceeding the MTU. Cisco has also done some more bug fixing. You can find the details in "Cisco IOS Release Notes zu 12.2SB", bug ID CSCsf15121[6]. more details ======================================== To find out more details about the problem of CSCsd13298, more packets from various different operating systems (FreeBSD, Linux, Solaris, JunOS, IOS, Windows, ...) running on different architectures were captured on the FreeBSD IPv6 router. Below, you will see selected parts of headers where * (UPROTO) is the upper layer protocol from he point of IPv6. * PEOL is the PPPoE length field * VTTF FFFF LLLL NHHL are the first 8 octets of the IPv6 header: V: IP Version TT: Traffic Class FFFFF: Flow Label LLLL: Payload Length NH: Next Header On all but modern FreeBSD 6/7 systems, the header fields of all connections look like this (LLLL, HN and HL can vary depending on the distance of the remote system and type of packet): (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 0002 | 6000 0000 0028 063a | With FreeBSD 6/7 systems it looks like this: (UPROTO) POEL | VTTF FFFF LLLL NHHL | NH/UL DATA (TCP ) 53a4 | 6004 53a2 002c 063c | Modern FreeBSD systems may set the IPv6 flow label automatically; this is enabled by default. You can find more information about this in [7] and [8]. As you can see, the PPPoE length field increased by the values of the low-order 32 bits of the flow label: 0x0002 + 0x53a2 = 0x53a4 The reason the value of the PPPoE length field is a constant (0x0002) on all other systems is that none of them sets the flow label. why *those* 32 bits of the flow label? ======================================== On the one hand, we can only conjecture about this because, in the end, only Cisco has the code and knows their implementation. On the other hand, it seems likely that either IPv6 is treated as if it was IPv4, or maybe even all other PPP DLL protocols are treated like IPv4. Below we will show headers of all relevant protocols along with references to their RFCs. In between each of them we will explain how the problem affects the protocol. Let us start with the PPPoE Header. We will not talk about the transport layer below PPPoE. 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 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The relevant field of the PPPoE header is the LENGTH field. Its value is, where applicable, the invalid length value in the problem under discussion. Directly after the length field one will find the data of the upper layer protocol. In case of PPPoE, the payload will be PPP data: RFC 1661 Point-to-Point Protocol 2. PPP Encapsulation +----------+-------------+---------+ | Protocol | Information | Padding | | 8/16 bits| * | * | +----------+-------------+---------+ The "Protocol" field indicates which protocol is transported. That way PPP can multiplex multiple protocols on top of one PPP connection. The field could have values for IPv4 or IPv6, for example. If compression is negotiated, the field can only have a length of 1 octet, while in the common case it will be 2 octets long. These 2 octets, in all probability, conform to the 0x0002 in the PPPoE length field. In most cases IPv4 will still be the protocol carried over PPP: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The only interesting point regarding the IPv4 header is the position of the "Total Length" field. It is at the 3rd and 4th octet directly after the PPP "Protocol" field. The "Total Length" is the sum of the IPv4 header length and length of the additional payload. But our problem is with 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 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If you look at the position of the low-order 32 bits of the "Flow Label", you will find that this is at the 3rd to 4th octet after the PPP "Protocol" field too. In IPv4, this was the place where the length of all data past the PPP "Protocol" field was written to. Given that with almost all test systems the Flow Label is unset, the value of the Flow Label field is 0x00000, the PPPoE length field remains 0x0002. However, with modern versions of FreeBSD systems, there is a Flow Label set: the low-order 32 bits are added to the 0x0002 and then used as PPPoE payload length. This leads to the conclusion that Cisco deals at least with IPv6 as if it were IPv4 and even tries to calculate the PPPoE payload length. But PPP, as described, can carry many different protocols. Calculating the PPPoE payload length means that each of the PPP protocols would require special handling. This is impractical and Cisco chose a different solution for their bug fix. You can find more details about this in CSCsf15121[6]. On the other hand, this means that, despite the bug, you can send IPv6 packets that reach an affected customer with a correct PPPoE length field. All you have to do is set the "Flow Label" to an appropriate value of length of IPv6 header(40) + IPv6 payload length (including IPv6 Extension Headers). Because IPv6 raw sockets do not allow you to set the "Flow Label", a proper packet must be hand crafted and sent directly via the network device bypassing most of the stack. Such a packet can be used for testing whether a customer is really affected by CSCsd13298 or not. This has already been done successfully with two different implementations. summary: ======================================== The problem has been known for some time. It was a Cisco bug and Cisco has fixed it. IPv6 is becoming more and more popular. There is a patch for FreeBSD that allows one to use IPv6 even with the problem, but it is not for the rank and file. It is possible to test whether an IPv6 problem is really a symptom of the Cisco bug or not. DTAG should update their routers so we can all forget about this. More sample data: ======================================== ----- "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 | I would like to thank ... ======================================== Special thanks to Arnold Nipper for the test setup and all his time analysing the problem and for installing the specially patched FreeBSD on his hardware. Have fun with a working IPv6 setup again. Thanks also to all who helped to gather sample data, or in providing me with unpatched test setups for testing (alphabetical order): Dominik Bay, Sascha Lenz, Daniel Roesen, Bernhard Schmidt, Marcus Stoegbauer Many thanks to Robert Watson for proofreading this english version and providing much appreciated feedback. References: ======================================== [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.3 2007/02/09 21:38:30 bz 2nd pass. Revision 1.2 2007/02/04 19:34:21 bz Incorporate feedback from Robert Watson. Thanks! If you want to thank him too, he'll accept money, chocolate, bandwidth, ...;) Revision 1.1 2007/01/28 17:50:41 bz Initial revision