[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Introduction

There has been a steady stream of MPLS PW related comments and bugs over time,
and things haven't improved enough, apparently. This text tries to give some
insight in the issues so that possible solutions cover all cases involved.

Background

Multi Protocol Label Switching (MPLS) is highly optimized for speed. That is
speed of processing of network frames, getting frames forwarded as efficiently
as possible while handling pushing and popping labels at the predefined network
boundaries. Pseudo Wire (PW) tries to make the network connection so that it can
be seen as a literal replacement for a wire, or a circuit switched connection.
To do so optionally a control word if prefixed before transport across the MPLS
network.

These two combined allow a highly efficient and high bandwidth mesh of point-to-
point connections. So much so that the protocols carry little, if any,
information related to the type of data transported. This is especially true for
the MPLS label stack and the PW control word. Only a label number is assigned,
it is up to the endpoints between which frames are exchanged using this
(bottom-of-stack) label to decide (out of band) what format this data is in.
Also the presence of a control word is mutually agreed upon out of band. Usually
these are statically configured in the MPLS edge routers.

This fact complicates matter for a man-in-the-middle observer, like Wireshark.
Without the knowledge of the out-of-band agreed communication settings it takes
guesswork to decide what these are and thus how to interpret these frames.

Wireshark does try by means of heuristic analysis of the frame contents to
determine the makeup of each MPLS frame, and sets up the dissection of the inner
parts. Since there is so little to go on, heuristic analysis is error prone.
Often the user has to be involved, using other knowledge, to set the correct
dissection parameters.

MPLS RFC's

if you read the various RFCs on MPLS it becomes clear that other have struggled
with these matters also. See for instance RFC 4928, 4385 and 4448, and all RFCs
referenced from them.

Bug history

Combing through Bugzilla and the source code repository a collection of MPLS
related bugs and changes can be found. Here we try to list them in a
chronological order.

Remove MPLS preference that doubled for Decode As.
https://code.wireshark.org/review/#/c/7899/

Bug 11271: Dissecting engine stops after MPLS shims
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11271

https://code.wireshark.org/review/#/c/8912/
MPLS: always display payload when no 'Decode As' preference is set

Bug 11949: Wireshark 2.0.1 MPLS dissector not decoding payload when control word
is present in pseudowire
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11949

Only use nibble logic to determine MPLS payload
https://code.wireshark.org/review/#/c/12961/

Bug 13039: Ethernet-over-MPLS heuristic treats some "Ethernet without control
word" packets as "Ethernet *with* control word"
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13039

Add MPLS preference to potentially ignore Ethernet Control Word.
https://code.wireshark.org/review/#/c/18466/1

Bug 13295: Ethernet-over-MPLS heuristic treats some "Ethernet with control word"
packets as "Ethernet *without* control word"
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13295

Bug 13301: Ethernet-over-MPLS heuristic treats "eth-over-mpls" packets (without
control word) where eth destination starts with 6x or 4x as being
"ipv6-over-mpls" and "ipv4-over-mpls" respectively
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13301

Conclusion

There is non at the moment, other than that it takes work to develop an all
encompassing solution, which will probably be a tradeoff. Properly documenting
these will have to be part of the solution, so that this can be referenced when
the (inevitable) follow up questions/bugs come up.