Which security measure must you take for native VLANs on a trunk port?

A.
Native VLANs for trunk ports should never be used anywhere else on the switch.

B.
The native VLAN for trunk ports should be VLAN 1.

C.
Native VLANs for trunk ports should match access VLANs to ensure that cross-VLAN traffic
from multiple switches can be delivered to physically disparate switches.

D.
Native VLANs for trunk ports should be tagged with 802.1Q.

Explanation:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_white_paper09186a00801315
9f.shtml
Double Encapsulation Attack
When double-encapsulated 802.1Q packets are injected into the network from a device whose
VLAN happens to be the native VLAN of a trunk, the VLAN identification of those packets cannot
be preserved from end to end since the 802.1Q trunk would always modify the packets by
stripping their outer tag. After the external tag is removed, the internal tag permanently becomes
the packet’s only VLAN identifier. Therefore, by double encapsulating packets with two different
tags, traffic can be made to hop across VLANs.
This scenario is to be considered a misconfiguration, since the 802.1Q standard does not
necessarily force the users to use the native VLAN in these cases. As a matter of fact, the proper
configuration that should always be used is to clear the native VLAN from all 802.1Q trunks
(alternatively, setting them to 802.1q-all-tagged mode achieves the exact same result). In cases
where the native VLAN cannot be cleared, then always pick an unused VLAN as native VLAN of
all the trunks; don’t use this VLAN for any other purpose.
Protocols like STP, DTP, and UDLD (check out [3]) should be the only rightful users of the native
VLAN and their traffic should be completely isolated from any data packets.