Ask Your Question

IPv6 after MPLS not being decoded

asked 2020-11-11 19:19:01 +0000

updated 2020-11-12 11:20:03 +0000

grahamb gravatar image

My IPv6 header is pretty deep in the frame and it is not being decode on Windows WS ver 3.4.0. (however it is decoded on linux WS ver 1.8.0).

WAs going to upload a picture but this site won't let me (it says that I need 60 points to do this).

The headers in the frame are (in the order from the wire up)

Eth (dot1q) IPv4 GRE MPLS IPv6

Any ideas? Thanks.

edit retag flag offensive close merge delete


Idea: put a capture file on a public accessible file share site and share the link here

(PS: this comment has to be added numerous times per week and should be standard instructions when filing a question....)

Jaap gravatar imageJaap ( 2020-11-11 19:35:46 +0000 )edit

here is the file

link text

kposcic gravatar imagekposcic ( 2020-11-11 22:01:01 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2020-11-12 09:36:55 +0000

grahamb gravatar image

In your capture the first nibble following the MPLS header is 0xd and this value isn't handled by the MPLS sub-dissector dispatching code. The value should be 4 or 6 for IPv4 or IPv6 respectively, and as it isn't, Wireshark calls the data dissector.

Looking a bit further in your capture the data following the MPLS headers appears to be an Ethernet header that then contains an IPv6 packet. I have no idea if this is a real "thing", but Wireshark as it stands won't dissect this.

There is a table in the MPLS dissector that dispatches the payload to a sub-dissector based on the label, but there is no preference or other code in Wireshark to add entries to this table that I can see.

Maybe you could raise an enhancement request to add such a user preference to allow setting the dissector to be used for a specific MPLS label.

edit flag offensive delete link more


I've already got a chain of MPLS issues from the past, which always boils down to the fact that MPLS is lacking proper identifiers for the carried higher layer protocol. It's all by configuration, which leave Wireshark to guess what it is. I've some old code which even goes so far as to assess the likelihood of the traffic being ethernet (like in this case). I've find the solution ugly, but it may be the best we can do.

Jaap gravatar imageJaap ( 2020-11-12 09:44:12 +0000 )edit

Wouldn't a UAT for the label table help?

grahamb gravatar imagegrahamb ( 2020-11-12 10:14:07 +0000 )edit

Since you mentioned UAT, is that a historical term or still best way to describe them?
Part of issue 16982 is to document UAT.

Chuckc gravatar imageChuckc ( 2020-11-12 14:55:28 +0000 )edit

Ok, thanks. But yes, the older version (specifically 1.8.0) interprets this correctly (by guessing, that the next header after MPLS is Ethernet). How do I raise an enhancement request? What I would like to see is something similar to what exist already but it does not work for me: - When I 'right click' on the undecoded portion of the frame "Data (92 bytes)", in my example, a 'Decode As...' (Ctrl-Shift-U) option appears on the menu. Currently this is set to to 'MPLS', but I have an option to change this (remove it and add a new option). A new choice should be Ethernet. Then it would work, where I select the undecoded portion of the data and say 'this is Ethernet', and from then on, WS should figure it out (after Ethernet header comes IPv6 header, etc).

kposcic gravatar imagekposcic ( 2020-11-12 14:59:20 +0000 )edit

I'm not entirely sure if Decode As... could be applied to this situation, mention it in the enhancement request.

To raise an enhancement request go to, fill out as much as you can and add your capture to it.

@Chuckc, re UAT, I'm an old guy, they've been UAT's forever.

grahamb gravatar imagegrahamb ( 2020-11-12 16:27:16 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2020-11-11 19:19:01 +0000

Seen: 43 times

Last updated: Nov 12