Wireshark-bugs: [Wireshark-bugs] [Bug 10706] A byte is skipped between IPv6 and IPv4 layers
Comment # 3
on bug 10706
from Guy Harris
(In reply to Pascal Quantin from comment #2)
> Wireshark is interpreting the Next Header of type ISO Internet Protocol (80)
> as ISO-TP4 ISO Transport Protocol Class 4 [RFC905,RC77],
Hmm. As per
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml#protocol-numbers-1
80 is "ISO-IP", for ISO Internet Protocol. Marshall Rose is given as the
contact for that assignment; a bit of Googling found RFC 1070:
http://tools.ietf.org/html/rfc1070
of which he is one of three authors. The relevant part is
Encapsulating ISO-grams in IP datagrams
The entire OSI network layer PDU, whether it be an ISO 8473 PDU, an
ISO DP 9542 PDU, or an IS-IS PDU, will be placed in the data portion
of an IP datagrams at the source. The ISO 8473 entity may fragment
an NSDU into several NPDUs, in which case each NPDU will be
encapsulated in an IP datagram. The intent is for the OSI CLNL to
fragment rather than to have IP fragment, for the purpose of testing
the OSI CLNL. Of course, there is no guarantee that fragmentation
will not occur within the IP subnet, so reassembly must be supported
at the IP level in the destination participating system.
SNPA-addresses (Internet addresses) will be algorithmically derived
from the NSAP-addresses as described below. The "protocol" field of
the IP datagram will take the value 80 (decimal), which has been
assigned for this purpose.
which indicates that the payload is an OSI network layer PDU.
Note, however, that, in the Protocol Numbers registry, the "IPv6 Extension
Header" column, in the entry for 80, does *NOT* say "Y", so 80 is technically
*NOT* a valid way of putting an OSI network layer PDU inside an IPv6 datagram.
> which seems to use the first byte as a NLPID (per X.263 / ISO/IEC TR 9577).
> Unfortunately it seems like those ISO spec are not available for free.
ITU-T recommendations, however, *are* available for free:
http://www.itu.int/en/ITU-T/publications/Pages/recs.aspx
Section 5.1 "General" of TR 9577 says:
The location of the IPI for a header-oriented protocol is the first octet
of the protocol control information; this is depicted in Figure 1. The value of
the IPI unambiguously identifies the initial protocol within the set of
header-oriented protocols.
It also says in Table 2 that 1100 1100, i.e. 0xCC, is for "RFC 791", an RFC
number that I suspect most of us recognize :-) (for those who don't, it's
called "Internet Protocol", and describes version 4 of that protocol...).
> Is it a hand made packet? I would have expected to see a Next header of type
> IP (4) or IPv6 (41) instead of 80 if you wanted to encapsulate respectively
> an IPv4 or IPv6 packet.
Yes - as indicated earlier in my comment, it's not clear that this is truly
valid for IPv6.
In the IPv6-over-IPv6 capture, there's an 0x8e byte, which is 1000 1110, which
the table says is for RFC 2460, also known as "Internet Protocol, Version 6
(IPv6) Specification".
In any case, the dissector should, at least, indicate that the 0xCC is a
network layer protocol ID (NLPID) for OSI; I think the OSI dissector code can
do that - I'll see why that's not happening.
(Strange things
You are receiving this mail because:
- You are watching all bug changes.
