@parthrawat979 to your OP question, concerning specifically named protocols (and presuming a .1Q trunk), my initial reply's sentence was "I believe (?) they are always untagged.". The question mark because I wasn't 100% certain.
From the multiple other replies, some agree, some don't agree. The latter, though, being conditional on whether VLAN 1 is being tagged or not.
My experience, over decades, has been as technology evolves backward capability is often maintained yet possibly modifications are made that aren't well documented especially if default behavior is changed but without any impact to normal behavior.
Two examples come to mind, which I believe are:
Will an ordinary access port, without a configured voice VLAN send or accept .1Q tagged frames?
Well, as .1Q also can use a tagged frame with a VLAN ID of zero, for CoS markings, I believe the answer is yes.
On a .1Q trunk port, which is sending untagged frames, will it only accept untagged frames?
I believe the native VLAN will accept untagged or tagged frames, the latter with the VLAN ID of zero or that's correct for whatever VLAN is configured as native.
So, I believe, for any control plane frame that logically needs the correct VLAN ID, the frame will be so tagged.
If the particular control plane protocol doesn't logically need a VLAN ID, but for whatever reason, a non zero VLAN ID is provided, it's likely to always be VLAN 1.
To the belief that a control plane frame that doesn't always logically need a non zero VLAN ID is never, ever, tagged, well, personally I'm very nervous of the words "always" or "never", especially over decades of software revisions.
To correctly answer what the behavior should be, we would need to see the original design specifications and all its revisions, if any. Any device that doesn't conform to specifications is either using an out-of-date specification or is defective.
User documentation, which is what we're working with, often isn't as well maintained as specifications or code. Further, as programmers can misunderstand specifications, technical documentation writers even more so.
Lastly, in the real world, your questions only usually matter if taking some certification test or if one of these protocols aren't working as expected. (Not working as expected, isn't always obvious. Over a decade ago, had some non Cisco VoIP phones, doing LLDP, having issues with a Cisco switch's ports while the switch wasn't LLDP capable. Had to update the switch's IOS, which still didn't support LLDP, but no longer affected by the phone using it.)
