Also das "Tunnel Encapsulation Limit" ist im RFC 2473 von 1998 erstmals definiert worden. Es zeigt sich ja immer mehr, daß das ganze Kabelgeraffel nur durch reinen Zufall funktioniert. :zerstör:
4.8. Defining New Extension Headers and Options Defining new IPv6 extension headers is not recommended, unless there are no existing IPv6 extension headers that can be used by specifying a new option for that IPv6 extension header. A proposal to specify a new IPv6 extension header must include a detailed technical explanation of why an existing IPv6 extension header can not be used for the desired new function. See [RFC6564] for additional background information. Note: New extension headers that require hop-by-hop behavior must not be defined because, as specified in Section 4 of this document, the only extension header that has hop-by-hop behavior is the Hop-by-Hop Options header. New hop-by-hop options are not recommended because nodes may be configured to ignore the Hop-by-Hop Options header, drop packets containing a Hop-by-Hop Options header, or assign packets containing a Hop-by-Hop Options header to a slow processing path. Designers considering defining new hop-by-hop options need to be aware of this likely behavior. There has to be a very clear justification why any new hop-by-hop option is needed before it is standardized.<i>
</i> Instead of defining new extension headers, it is recommended that the Destination Options header is used to carry optional information that must be examined only by a packet's destination node(s), because they provide better handling and backward compatibility.<i>
</i>4. IPv6 Extension Headers
[...] At the destination node, normal demultiplexing on the Next Header field of the IPv6 header invokes the module to process the first extension header, or the upper-layer header if no extension header is present. The contents and semantics of each extension header determine whether or not to proceed to the next header. Therefore, extension headers must be processed strictly in the order they appear in the packet; a receiver must not, for example, scan through a packet looking for a particular kind of extension header and process that header prior to processing all preceding ones. If, as a result of processing a header, the destination node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header. Each extension header is an integer multiple of 8 octets long, in order to retain 8-octet alignment for subsequent headers. Multi- octet fields within each extension header are aligned on their natural boundaries, i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8.<i>
</i> A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options Fragment Destination Options Routing Authentication Encapsulating Security Payload The first four are specified in this document; the last two are specified in [RFC4302] and [RFC4303], respectively. The current list of IPv6 extension headers can be found at [IANA-EH].
cfreak: 
<i>
</i>ifconfig ds-wan6_4
ds-wan6_4 Link encap:UNSPEC HWaddr 2A-XX-XX-XX-XX-00-00-00-00-00-00-00-00-00-00-00 inet addr:192.0.0.2 P-t-P:192.0.0.1 Mask:255.255.255.255 inet6 addr: fe80::XX14:XXff:XX8f:XXaa/64 Scope:Link UP POINTOPOINT RUNNING NOARP MTU:1280 Metric:1 RX packets:1268377 errors:0 dropped:0 overruns:0 frame:0 TX packets:1525465 errors:6 dropped:0 overruns:0 carrier:6 collisions:0 txqueuelen:1000 RX bytes:4869040437 (4.5 GiB) TX bytes:644510163 (614.6 MiB)
ip link | grep -A1 ds-wan6_4
6: ds-wan6_4@eth0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN qlen 1000 link/tunnel6 2a:02:80:70:61:00:00:00:XX:XX:XX:XX:XX:XX:XX:XX peer 2a:02:80:70:60:00:00:00:00:00:00:00:00:00:40:00
Was hat DS-Lite mit Kabel zu tun?
In der Schnittstellenbeschreibung von Unitymedia ist angegeben, dass die TCP-Paketlänge maximal 1420 Bytes betragen darf. Im Zweifelsfall muss sich dein Router an diese Angabe halten, auch dann, wenn er vom AFTR keine oder eine anderslautende Konfigurationsoption erhält.
Suppi :super:
... Als ich das gelesen habe, kam mir eine Vermutung :brüll:
... hat dann meinen Verdacht bestätigt...
Ein Schelm wer böses denkt
Die Email wird am 1st Level so schnell abprallen, wie ein dickes Kind auf der Wippe nach unten fällt :mussweg: :brüll:
Ich weiß wie UM das handhaben wird: erst kommen ein paar Beschwerden von Kunden rein, dann werden Sie ihre Schnittstellenbeschreibung ändern (. :vertraghai: ) damit diese "destination option" abgelehnt werden kann, ich mein, wozu sollte man sich an bereits lange geltende Standards halten, wir machen was wir wollen.
Warum lässt Du Dir kein Dual Stack schalten :kratz:
Hab es gerade erst gesehen - bin dran. Danke für den Hinweis!
DualStack wird langfristig von DualStack Lite abgelöst werden. Auch bei der Deutschen Telekom übrigens mit der nächsten Netzgeneration (TeraStream), diese unterstützt nämlich kein natives IPv4 mehr.
Hoffe ich darf deinen Code dazu als Vorlage verwenden (müsste eig. da unter GPL stehend ?! ^^)
