Re: Overview of MPLS PW bugs

[Guy Harris <guy () alum mit edu>]

On Jan 8, 2017, at 10:18 AM, Francesco Fondelli <francesco.fondelli () gmail com> wrote:

> point 3 and probably point 4, are too risky. If we go against the best
> current practice (RFC 4928, BCP 128) we need a very-very strong
> indication that the following data is not IP. I agree on everything
> else.

We need to fix bug 13301 somehow.  BCP nonwithstanding, RFC 4448 says:

   The features that the control word provides may not be needed for a
   given Ethernet PW.  For example, ECMP may not be present or active on
   a given MPLS network, strict frame sequencing may not be required,
   etc.  If this is the case, the control word provides little value and
   is therefore optional.  Early Ethernet PW implementations have been
   deployed that do not include a control word or the ability to process
   one if present.  To aid in backwards compatibility, future
   implementations MUST be able to send and receive frames without the
   control word present.

and the captures in that bug may be real rather than synthesized (some obscure companies named "Cisco" and "Huawei" has 
OUIs that have 4 as the first nibble and some obscure companies named "Hewlett-Packard" and "Juniper" has OUIs that 
have 6 as the first nibble).

As I said:

> > We might also want to have a preference to deal with the "first nibble of the MAC address is 4 or 6" issue.

So perhaps what we should do is either

        1) have the "does this look like Ethernet" check *also* check whether the packet looks sufficiently like an 
IPv4 or IPv6 packet;

        2) have a preference to indicate whether to use the "heuristically check whether this looks like Ethernet" 
first for all MPLS payload not explicitly processed by specific label bindings (manually using Decode As might not 
scale if there are a significant number of labels carrying that traffic);

        3) both of them, in case the heuristics aren't sufficient for safety.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe