Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Enhancement suggestion: OUI tool for IPV6 SLAAC addresses

From: "Maynard, Christopher" <Christopher.Maynard@xxxxxxx>
Date: Tue, 3 Aug 2021 01:13:10 +0000


- Chris

> -----Original Message-----
> From: Wireshark-dev <wireshark-dev-bounces@xxxxxxxxxxxxx> On Behalf
> Of João Valverde via Wireshark-dev
> Sent: Friday, July 30, 2021 10:20 AM
> To: wireshark-dev@xxxxxxxxxxxxx
> Cc: João Valverde <joao.valverde@xxxxxxxxxxxxxxxxxx>
> Subject: Re: [Wireshark-dev] Enhancement suggestion: OUI tool for IPV6
> SLAAC addresses
>
> CAUTION: This email originated outside of IGT. Do not click links or open
> attachments unless you recognize the sender and know the content is safe.
>
>
>
> On 30/07/21 12:28, Marco Davids (SIDN) via Wireshark-dev wrote:
> > Hello,
> >
> > I have an idea for a new feature in Wireshark and would like to hear
> > your take on it:
> >
> > In Wireshark, under the 'Ethernet II'-section (when the 'name
> > resolution' preference is set appropriately) the MAC addresses are
> > 'resolved' to manufacturer names. This can be a handy feature.
> >
> > What about extending this capability to (applicable) IPv6 SLAAC
> > (RFC4862) addresses as well?
> >
> > Unless some form of privacy enhancement was used (like RFC4941), quite
> > a few SLAAC IPv6 addresses contain an RFC4291 interface identifier,
> > that can easily be reversed into a MAC-address, which in turn can be
> > used to discover manufacturer names. As such, these IPv6 addresses
> > contain useful debugging information and it would be great is
> > Wireshark can easily display a manufacturer to the IPv6 address in
> > question, especially in the 'statistics endpoints' overview.
> >
> > I realize that for privacy reasons a majority of IPv6 addresses is
> > generated differently nowadays and can't be used this way, but some
> > preliminary testing showed that there are still quite a few addresses
> > that can.
> >
> > Examples:
> >
> > 2001:db8::86c7:eaff:fe1e:fe46 would resolve to 'Sony Corporation'
> > 2001:db8::de91:bfff:fec5:4f66 to 'Amazon Technologies Inc.'
> > 2001:db8::215:5dff:fe01:b446 to 'Microsoft Corporation'
> > 2001:db8::201:c0ff:fe06:3552 to 'CompuLab, Ltd.'
> > 2001:db8::be05:43ff:fefb:281f to 'AVM GmbH'
> > etc.
> >
> > Looking a bit closer to the last example:
> >
> > Address:        2001:db8::be05:43ff:fefb:281f
> > translates into:    bc:05:43:fb:28:1f
> > is:            'AVM GmbH'
> >
> > That's a well-known vendor of Fritz!Box and related products.
> >
> > So, If I would be debugging traffic from
> > 2001:db8::be05:43ff:fefb:281f, reaching me from a few hops away on the
> > internet, in this particular case I could assume it was some sort of AVM
> product I'm dealing with.
> >
> > Let me know what you think and if you deem this feasible.
>
> There is already an IPv6 "SA MAC" field in Wireshark that does what you
> want.
>
> The aggregate statistics for that could probably find a place under
> "IPv6 Statistics". Not so much "Endpoints" IMO.

I don't know if there's any interest, but I updated the tap-resolved.lua[1] Tap to resolve the ipv6.sa_mac fields.  While at it, I added support for sll.src.eth fields as well.
- Chris

[1]: https://gitlab.com/wireshark/wireshark/-/wikis/Lua/Examples/Taps/tap-resolved
CONFIDENTIALITY NOTICE: This message is the property of International Game Technology PLC and/or its subsidiaries and may contain proprietary, confidential or trade secret information. This message is intended solely for the use of the addressee. If you are not the intended recipient and have received this message in error, please delete this message from your system. Any unauthorized reading, distribution, copying, or other use of this message or its attachments is strictly prohibited.