Since its inception, Wireshark has had a dissector for BOOTP. When DHCP became a commonly-used protocol, that was built into the BOOTP dissector since it was built upon the BOOTP protocol.
At this point, though, most network users have no idea what BOOTP is. While some of us may be familiar with it because many things (tools, instruments, printers, etc.) still operate with BOOTP, we recognize that DHCP in itself can and should be wholly separated from BOOTP, especially when it comes to analysis. By this, I mean that when I filter on "bootp," I expect to see only BOOTP traffic and no DHCP, and there needs to be a DHCP filter that shows either DHCP and BOOTP traffic, or exclusively DHCP traffic.
I personally believe this needs to be done in order to best support those of us who regularly analyze DHCP and BOOTP traffic, and that Wireshark needs to support DHCP as independent from BOOTP.
So, the question: does anyone in the community believe that DHCP needs to be or should not be separated from BOOTP? Why?
This question is marked "community wiki".
asked 13 Jun '16, 10:38
edited 13 Jun '16, 10:46
From a protocol design point of view DHCP is no more than an extension of BOOTP. Therefore it uses the BOOTP messages (BOOTREQUEST, BOOTREPLY) and uses the BOOTP UDP port. It uses the BOOTP message layout (to allow for interoperability between BOOTP, DHCP, BOOTP relay) and its overloading features. So where does BOOTP end and DHCP start? After the DHCP cookie? What to do with overloaded BOOTP fields?
It becomes clear that the protocol stack look like this:
And that the DHCP 'protocol' is no more than a profile of the use of the BOOTP protocol. In itself this profile has become a predominant player in host configuration. But from a protocol analysis point of view, it's just BOOTP (+extensions).
With Wireshark packet dissection trying to reflecting the pure protocol stack it's clear that the protocol stack as shown is reflected in this dissection. Therefore there is no DHCP protocol to speak of.
Is there nothing else possible? There is. Thanks to the display filter engine it is possible to correlate various protocol fields to determine if we have a pure BOOTP or BOOTP + DHCP extensions packet at hand. Wrapping such expressions into display filter macro's provides the desired functionality, while preserving the integrity of the protocol dissectors.
In short this is a vote against the notion of separation, because there is none.
answered 14 Jun '16, 02:06