Here is a packet diagram for the tag.

"The certificate for docs.pica8.com expired on 06/11/2024."

The server returns HTTP 404 for the page. Other sources suggest that "VN tag" is an alias for 802.1Qbh, which is a work in progress. It seems best not to do any work on this feature request until there is an example packet capture.

An early proposal is documented here: https://www.ieee802.org/1/files/public/docs2009/new-pelissier-vntag-seminar-0508.pdf - around page 30 is a packet layout. There are other sources backing each other up on the layout:

Pica8 linked above looks like it's moved to https://pica8-fs.atlassian.net/wiki/spaces/PicOS4443beta/pages/115898307/VN-tag
LearnDuty: https://learnduty.com/articles/vn-tag-explained-configuration/
CCIE or Null! (blog): https://ccie-or-null.net/tag/vntag/
Define the Cloud: https://www.definethecloud.net/access-layer-network-virtualization-vn-tag-and-vepa/

They all give the same layout, which is essentially this for a full Ethernet header:

 0               1               2               3               4               5              
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
|               |               |               |               |               |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                      Destination Address                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                         Source Address                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           EtherType           |                             VNTag                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |                              VLAN                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

And this for VNTag itself with an EtherType of 0x8926:

 0               1               2               3               4               5              
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
|               |               |               |               |               |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Ethertype           |D|P|    vif_list_id/dvif_id    |L|R|ver|        svif_id        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Like all layer 2-ish protocols (VLAN, MPLS, etc.) it's entirely likely that VNTag could appear anywhere an EtherType could appear. E.g. it's entirely plausible that you could end up with Ethernet -> VLAN -> VNTag -> VLAN -> IPv4 -> ...

VNTag, as an extension of 802.1Q, requires an 802.1Q (VLAN) header after the VNTag header. This makes sense since VNTag 'eats' the EtherType and has no native "next payload type" (EtherType) itself. This creates a syntax headache for handling the VLAN after the VNTag.

If we force a user to always write vntag and vlan and ... that seems like it would simplify the code to contain VNTag to itself, but as there's no "and the next thing is VLAN identified by EtherType 0x8100 (and friends)" then we'd need to leave the linkhdr pointed at the VNTag EtherType. Then that means we would need to add that EtherType in as another known VLAN acceptable EtherType value and adjust the VLAN processing to jump over the VNTag to get to the VLAN information. That's not terrible, but it's also not "simpler" code and has the bad side effect of making what should be intuitive (vntag and src ip 192.0.2.0) fail because the current EtherType is VNTag, not a valid IP type.

So, we should probably look for vntag as always vntag and vlan ... implicitly. Personally I always prefer explicit over implicit any time I can; it usually makes a more capable and easier to understand system. But in this case, the expected thing is the implicit behavior so it might be better. One down side to this is if vntag implies vntag + vlan then there's no way to specify the VLAN ID since vntag and vlan 42 and host 192.0.2.0 would mean vntag -> VLAN (any ID) -> VLAN 42 -> IP address 192.0.2.0. There's also always the hack of eth[20:2] & 0x3fff == 42 or vntag[6:2] & 0x3fff == 42, but then you have to remember magic numbers. Instead, maybe we could add a sub-keyword to be able to select on the VLAN ID:

vntag vlan 42

This opens the door for other vntag fields if anyone wants to expose them (although I don't see a request for that in this issue and no one I've talked to is looking for it).

vntag d
vntag p
vntag dvif_id
vntag l
vntag r
vntag ver
vntag svif_id

I am planning on working up a PR using the vntag vlan 42 concept and seeing how that works out. That should expose two new grammar entries:
Just plain vntag:

• Identify EtherType 0x8926 as VNTag traffic
• Move the linkhdr and linkpl forward 6 bytes to skip over the VNTag header to the 802.1Q (VLAN) header
• Call gen_vlan_no_bpf_extensions(...) with has_vlan_tag=false
  Then for adding vntag vlan ... support it's the same as above, but with had_vlan_tag=true and the VLAN tag supplied to the call.

I missed a key piece that VLAN may not be REQUIRED; VNTag is similar to VLAN in that it "splits" the ethernet header between dest addr and EtherType. There's still an EtherType after the VNTag header. That could be the TPID of VLAN or it could be 0x0800 (IPv4) or anything else. All of the VNTag diagrams show VLAN, but it might be better to be explicit in the syntax and require "vntag and vlan and ...".

So I was wrong the VLAN is required "because there's no EtherType" - there absolutely is one, and so vntag and vlan 42 would work just fine for the first VLAN tag after vntag! Updates to PR incoming shortly...

Here's a better, more accurate, diagram of a VNTag packet:

 0               1               2               3               4               5              
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
|               |               |               |               |               |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                      Destination Address                                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                         Source Address                                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                             VNTag                                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           EtherType           |                           Payload...                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+