On Jan 8, 2017, at 10:18 AM, Francesco Fondelli <[email protected]>
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 <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
