Wireshark-bugs: [Wireshark-bugs] [Bug 11802] ISO Internet Protocol is parsed as IPv4
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Sat, 28 Nov 2015 19:39:39 +0000

changed bug 11802


What Removed Added
Status UNCONFIRMED INCOMPLETE
Ever confirmed   1

Comment # 1 on bug 11802 from 
(In reply to boaz.brickner from comment #0)
> In the attached pcap file there's a single ISO Internet Protoocl over IPv6
> packet.
> Event though the IPv6 Authentication header says the next protocol is ISO
> Internet Protocol,

According to RFC 1070:

    http://tools.ietf.org/html/rfc1070

  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.

and an "ISO-gram" is

      An NPDU for any protocol in the OSI CLNL, including ISO 8473
      (CLNP), ISO DP 9542 (ES-IS), and ISO TC 97/SC 6/N xxxx (IS-IS).

I.e., if the IP protocol type/next header field is 80 (0x50), then the payload
is not necessarily a CLNP packet - it could be an ES-IS or IS-IS packet.

Therefore, something else is needed to indicate whether it's CLNP, ES-IS, or
IS-IS.  ISO/IEC TR 9577, "Information technology — Protocol identification in
the network layer", says that a one-byte "initial protocol identifier", at the
beginning of the PDU, indicates that 0xcc as an IPI is "not categorized by this
recommendation", but is "in widespread use", with that use being for "RFC 791",
a/k/a IPv4.

Furthermore, RFC 1070 also seems to indicate that there's an "SNAcP header"
before the ISO-gram.

So, as I read RFC 1070, if the "next header" field of an IPv6 datagram header
or extension header has the value 80, what follows that header is *NOT* an ISO
CLNP packet.  Perhaps some hardware or software transmits packets in which it
is, but that would require that the sending and receiving hosts agree to use an
encapsulation different from the one specified by RFC 1070.

The Protocol Numbers database at

   
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml#protocol-numbers-1

lists 80 as "ISO-IP", or "ISO Internet Protocol", with no reference other than
"Marshall T Rose", who was one of the authors of RFC 1070.  It doesn't have "Y"
in the "IPv6 Extension Header" column, just as 6 (TCP) and 17 (UDP) don't, so
presumably it, like TCP and UDP, are handled the same (other than for
checksumming) in IPv4 and IPv6.

So if there are encapsulations being used for a protocol identifier value of 80
other than the one in RFC 1070, there would need to be a preference controlling
how to handle those packets.

You are receiving this mail because:
  • You are watching all bug changes.