Talk:IPv6 packet

Jumbogram is an option for future use

Here is a challenge: name any (historic, current, or future) link layer protocol that can natively carry a frame larger than 65535 octets. Such a protocol could be employed to implement a useful working implementation of the Jumbogram. If no such protocol exist, the Jumbogram is of not much use.

I say there never was, is no, and will not be any in the near future such a protocol. Please put me wrong! Then we can get rid of the ''. Otherwise, we change the text about Jumbograms so it clearly states that this is an option for future use. —— _D^an_d^or ⁱ_D (talk) 20:50, 21 February 2011 (UTC)

HIPPI is the classic example of a link level protocol capable of larger than 64K octet messages. It's also possible on ATM, but not with the standard AAL5 coding for IP packets (which carries a 16 bit length). You could also do it on Infiniband. Other proprietary intra-cluster interconnects have also been built for supercomputing applications. Now a semi-valid argument is that these networks use a smaller physical frame size than that (32 byte "micropackets" for HIPPI, 53 byte ATM frames), but the critical thing is that these are mainly *reliable* circuit switched networks, and the very small frame size is mainly a hardware artifact. Come to think of it, you could probably do jumbograms on and FC too. But we are generally talking about very local networks and supercomputing applications. Rwessel (talk) 06:30, 26 February 2011 (UTC)

So far, so good. Apparently there are candidates. Since HIPPI is no longer in use and others are only used for local high speed data transmission (therefore data is not encapsulated in an IPv6 packet before transmission, I presume) are there any candidates left that are actually used to carry IP traffic? —— _D^an_d^or ⁱ_D (talk) 12:22, 28 February 2011 (UTC)

Undid lay-out changes of the tables

The edits of 70.240.151.21 are hereby withdrawn, as they are not an improvement of the lay-out of the tables in this article. The stated reason for changing the font-size and type is "good proportional rendering of bits", but this is perfectly handled by the rendering engine of Wikipedia with the default fonts. All boxes with bits have equal width, whether filled with one digit or two. Furthermore, the change of fontsize for some fields makes the table code unreadable and difficult to edit.

The TCP tables might be created using explicit font changes, that does not necessarily mean that all tables in Wikipedia have to be changed to that style. —— _D^an_d^or ⁱ_D (talk) 17:23, 8 September 2011 (UTC)

Extension header IPv4 and IPv6 tunnels

One thing supported by extension headers is tunneling of IPv4 and IPv6 in IPv6. This allows 4in6 tunnels to be set up to carry IPv4 traffic over an IPv6 link. 6in6 tunnels may also be enabled in the same manner. To use 6in4 tunneling, a separate protocol number 41 was assigned for use over IPv4. Both 6in4 and 4in6 tunneling will be important as the world progresses to IPv6. — Preceding unsigned comment added by 74.198.9.80 (talk) 18:22, 26 February 2012 (UTC)

There's a case to be made that RFC 2473 ("4in6") tunneling should be included in the list of options headers, but it's not clear to me that there's significant usage. Alternatively having RFC 2473 accepted as a standard would justify it, but that hasn't happened. In any event the 4in6 article is just a stub. How much is it actually used? Are there expectations that it will be broadly used in the future? Rwessel (talk) 20:58, 26 February 2012 (UTC)

Well, I'm using 6in4. However, Comcast, with "DSLite" is providing IPv6 to customers and then using 4in6 tunneling and large scale NAT to provide IPv4 to them. In this example, IPv4 is a "next header" in IPv6. — Preceding unsigned comment added by 74.198.9.63 (talk) 13:27, 28 February 2012 (UTC)

TR 88.241.79.163 (talk) 03:33, 14 October 2024 (UTC)

Hop-by-hop header "must be examined" by all equipment

The phrase "must be examined" is too vague. If no detailed references are available, this phrase should be removed. — Preceding unsigned comment added by 192.55.54.40 (talk) 18:33, 11 February 2014 (UTC)

It seems adequately discussed in the surrounding sections. Rwessel (talk) 18:46, 11 February 2014 (UTC)