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_paper09186a0080131
59f.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.