The answer is in draft-ietf-isis-ext-eth-01, Sections 3-5. Ethernet uses the same two bytes different ways in the Ethernet II (DIX) and 802.3 encapsulations:
- Ethernet II uses the first two bytes after the Ethernet source mac-address for a Type
- 802.3 uses those same two bytes for a Length field.
I'm including an annotated diagram below of each frame type, which shows exactly where the conflicting bytes are in the ethernet header:
RFC 894 (commonly known as Ethernet II frames) use these bytes for Type
+----+----+------+------+-----+
| DA | SA | Type | Data | FCS |
+----+----+------+------+-----+
^^^^^^^^
DA Destination MAC Address (6 bytes)
SA Source MAC Address (6 bytes)
Type Protocol Type (2 bytes: >= 0x0600 or 1536 decimal) <---
Data Protocol Data (46 - 1500 bytes)
FCS Frame Checksum (4 bytes)
IEEE 802.3 with 802.2 LLC / SNAP (used by Spanning-Tree, ISIS) use these bytes for Length
+----+----+------+------+-----+
| DA | SA | Len | Data | FCS |
+----+----+------+------+-----+
^^^^^^^^
DA Destination MAC Address (6 bytes)
SA Source MAC Address (6 bytes)
Len Length of Data field (2 bytes: <= 0x05DC or 1500 decimal) <---
Data Protocol Data (46 - 1500 bytes)
FCS Frame Checksum (4 bytes)
Both Ethernet II and 802.3 encapsulations must be able to exist on the same link. If IEEE allowed Ethernet payloads to exceed 1536 bytes (0x600 hex), then it would be impossible to distinguish large 802.3 LLC or SNAP frames from Ethernet II frames; ethernet's Type values start at 0x600 hex.
EDIT:
I am including a link to pdf copies of the Ethernet Version 1 spec and Ethernet Version 2 spec, in case anyone is interested...
Regarding jumbo frame support on the Cat6k, IIRC the default system MTU size is 9216, but there are some modules where a maximum ingress frame size of only 8092 bytes is supported vs 9216 bytes (they'll drop frames larger than 8092 bytes at ingress). Double check the documentation to find out which modules exactly have this limitation.
Regarding the port-channels, if both ports in the port-channel are already set to the same MTU of 9216, it shouldn't make a difference if you configure the port-channel interface to have a 9216 MTU, but it wouldn't hurt for completeness'/clarity's sake in your configuration. You actually can't have two ports in an EtherChannel that have different MTU sizes.
Regarding the SVI's, there's really not much of a difference between routing jumbo frames across a routed L3 interface or an SVI (they're essentially the same thing) - just realize that if fragmentation is required across an L3 interface (ie a jumbo frame is routed from one L3 interface to another with a smaller MTU), the frame is punted to the CPU for fragmentation in software, and this can lead to problems. The rule of thumb here is to keep your jumbo frame traffic localized to other destinations/networks that also support jumbo frames.
While changing the MTU on the VLANs themselves shouldn't really be necessary, make sure that the interface MTU is the same across all the interfaces in the VLAN before setting the VLAN MTU to that same value. And similar to the port-channels, if you already have 9216 as the interface MTU's and the VLAN MTU for those interfaces, it shouldn't actually cause problems to set the MTU of the SVI for those VLANs to 9216.
Best Answer
Let me address question 2:
There can be a big problem it there is an MTU mismatch between two connected devices. If routers A and B are physically connected together, and A's interface MTU is 2000, but B's interface MTU is only 1500, then A can create a frame that is 2000 bytes long. But because B's interface MTU is only 1500, it will consider that frame a "giant," and drop the frame.
If devices are connected together at layer 3, then their common interfaces and all the (layer 2) devices between them must have the same MTU size.
EDITED to include question 7:
It's common to forget this important fact: Routers are responsible for fragmenting packets, but the receiving host is responsible for putting the fragments back together.
You could, with specially designed routers, fragment packets all day long with no throughput impact to the router, but you put a tremendous load on the receiving host who has to reassemble the fragments back together. You want the MTU of the path from sender to receiver to be the same so no device has to fragment, and therefore the receiver doesn't have to put them back together. That is the purpose of path MTU discovery -- to insure that fragmentation is not necessary.
Note that in IPv6, fragmentation is not allowed. Path MTU discovery is essential for IPv6 to work.