what is the size of "double tagged(CTAG+STAG) ARP request packet" ?
The preamble and the start-of-frame delimiter are present for physical layer needs (or for compatibility reasons) and they are not counted towards the frame size.
The ARP message itself is 28 bytes long, exactly as you indicated. Now, with correct Ethernet implementations, the outgoing frame has to be padded to be at least 64 bytes long. There are some quirks about this, however - the device that originated this ARP message may itself be capable of sending it in an untagged frame or in 802.1Q-tagged frame. The tag size is always accounted towards the total frame size, resulting in different paddings:
- If the ARP message is to be sent in an untagged frame then the frame overhead itself is 18 bytes. That would result in a frame of 28+18=46 bytes without padding. Additional 18 bytes of padding are necessary in this case to bloat the frame to the 64 byte length.
- If the ARP message is to be sent in an 802.1Q-tagged frame then the frame overhead is 22 bytes, resulting in the total frame size of 28+22=50 bytes. In this case, the padding needs to be 14 bytes long.
- If the ARP message is to be sent in a double-tagged frame then the frame overhead is 26 bytes, resulting in the total frame size of 54 bytes. In this case, the padding needs to be 10 bytes long.
The different size of the padding may have unpleasant consequences if the frame is untagged - some implementations of Ethernet data-link layer including selected Cisco Catalyst switches do not extend the padding after untagging a frame. As a result, a frame that was exactly 64 bytes long when tagged becomes shorter than 64 bytes after untagging, essentially becoming a runt. This is in direct violation of the IEEE 802.1Q-2005 section C.4.4.3 that explicitly states:
If untagging a given frame would result in violation of the minimum frame length requirements of CSMA/CD, the Bridge is required to adjust the PAD field to ensure that the frame length equals the minimum length of 64 octets
Unfortunately, as also indicated by you, many vendors seem to somehow not consider this fact.
I do not know of any method to increase the ARP message size, and I shall also point out that this is not a problem of the ARP message size but rather of the compulsory Ethernet frame padding. The padding is always the responsibility of the MAC/PHY layer that forwards the frame, i.e. all Ethernet controllers and cards that emit Ethernet frames must take care to properly pad it. Note that this does not apply just to the originator of a message but rather to all intermediary Ethernet devices through which the frame is being delivered.
Seeing some vendors to send ARP in frames with the total size of 60 bytes is okay - the FCS of 4 bytes is not usually displayed in Wireshark or similar sniffers because the FCS is processed in the Ethernet hardware and not forwarded to the upper layers. In other words, Wireshark always displays all Ethernet frames to be 4 bytes shorter than they really are, so a frame with 60 bytes in Wireshark is essentially a frame with 64 bytes in total.
I hope this helps - I did not try to answer all your questions because I suppose that the facts I have explained so far may already answer those or make you reconsider some of your views. You are welcome to ask further!