Wireshark-bugs: [Wireshark-bugs] [Bug 11802] IP "next protocol" value of 80 needs to support enc
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Sat, 05 Dec 2015 09:22:22 +0000

Comment # 3 on bug 11802 from 
(In reply to boaz.brickner from comment #2)
> Thanks!
> 
> I guess what's missing from my point of view is something in Wireshark that
> indicates how it parses the 0xcc (the byte right after the IPv6 header and
> before the IPv4 header).

According to RFC 1070, with a Next Header value of 80, the byte right after the
IPv6 header is parsed as the beginning of an OSI Network Layer packet, which
means it's parsed as an "initial protocol identifier" to specify the
*particular* OSI Network Layer protocol for that Network Layer packet.

Wireshark on the master branch, at least, is parsing it as exactly that:

Frame 1: 175 bytes on wire (1400 bits), 175 bytes captured (1400 bits)
    Encapsulation type: Ethernet (1)
    Arrival Time: Mar 26, 2082 17:21:46.-920941000 PST
    [Expert Info (Note/Sequence): Arrival Time: Fractional second -920941000 is
invalid, the valid range is 0-1000000000]
        [Arrival Time: Fractional second -920941000 is invalid, the valid range
is 0-1000000000]
        [Severity level: Note]
        [Group: Sequence]
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: -753167190.920941000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 175 bytes (1400 bits)
    Capture Length: 175 bytes (1400 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ipv6:ah:osi:ip]
Ethernet II, Src: ae:b4:6d:20:a3:f9, Dst: d4:b8:d9:78:89:72
    Destination: d4:b8:d9:78:89:72
        Address: d4:b8:d9:78:89:72
        .... ..0. .... .... .... .... = LG bit: Globally unique address
(factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: ae:b4:6d:20:a3:f9
        Address: ae:b4:6d:20:a3:f9
        .... ..1. .... .... .... .... = LG bit: Locally administered address
(this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: a099:40af:d129:a115:77ab:ca42:ef59:d77c, Dst:
712:cef7:bda3:ce48:e700:21cb:4b9a:5ad7
    0110 .... = Version: 6
    .... 1010 1111 .... .... .... .... .... = Traffic class: 0xaf (DSCP:
Unknown, ECN: CE)
        .... 1010 11.. .... .... .... .... .... = Differentiated Services
Codepoint: Unknown (43)
        .... .... ..11 .... .... .... .... .... = Explicit Congestion
Notification: Congestion Experienced (3)
    .... .... .... 0011 1001 1110 0010 0100 = Flowlabel: 0x00039e24
    Payload length: 121
    Next header: Authentication Header (51)
    Hop limit: 41
    Source: a099:40af:d129:a115:77ab:ca42:ef59:d77c
    Destination: 712:cef7:bda3:ce48:e700:21cb:4b9a:5ad7
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
    Authentication Header
        Next header: ISO Internet Protocol (0x50)
        Length: 0x30
        AH SPI: 0x2bf88d54
        AH Sequence: 826361051
        AH ICV: 23ecf7b5b3f27b5b0dc851dde141fd8a5e00248b62831f16...
>>>>> Network Layer Protocol Identifier: IP (0xcc) <<<<<
Internet Protocol, bogus version (14)
    1110 .... = Version: 14
        [Expert Info (Error/Protocol): Bogus IP version]
            [Bogus IP version]
            [Severity level: Error]
            [Group: Protocol]

as per the line I marked with ">>>>>" and "<<<<<".

> From Wireshark, it seems to be ignored even though it's actually being
> treated.

Not in the master version of Wireshark, it's not; it's being treated as a
Network Layer Protocol Identifier.

A value of 0xcc means that what *follows* the 0xcc is an IP packet.

> Maybe something like "ISO header" part, which says that the 0xcc is
> categorized as expecting IPv4 header to follow

Yes, that's exactly what's happening.  0xcc is a non-standard Network Layer
Protocol Identifier that is, nevertheless, acknowledged by ISO 9577 as being
"in widespread use" for "RFC 791", i.e. for IPv4.

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