IPv6 - Help with router QoS for a Hurricane Electric tunnel

[#1]

As a relative newbie to this 6in4 tunnel lark, I would like to experiment with reducing the IPv6 tunnel latency of my router.
I am using the IPv6 tunnel from Hurricane Electric, and my router has the following tunnel QoS options -

I was expecting find an option for "proto-41" or "6in4", but I don't recognize any of these. 
Any idea which option I should use ?   

[#2]

You might well be out of luck on that front. This could well be a case of a device providing 'IPv6 capability' but not across the board for all features.

[#3]

I wonder whether the QoS only applies to traffic crossing the router interfaces (WAN > LAN, and LAN > WAN),
rather than traffic (such as a 6in4 tunnel) that uses the router as it's endpoint, even though the IPv6 payload is subsequently forwarded.
Having said that, I can adjust the QoS for the router responding to pings on the WAN side.

[#4]

Just how much difference in latency is there? It may only be the difference between the Titanium and Gold traffic, as the 6in4 packets are all classed as VPN (according to Dave in another thread).

[#5]

It's not so much what the 'background' latency of the 6in4 tunnel is, because if you click on the right-hand TBB graph in my signature below, it is already surprisingly good compared with the native IPv4 connection in the other TBB graph.
It is more a case of managing the outbound QoS (LAN to WAN) when I have multiple other native IPv4 programs uploading low-priority data at the same time.
My feeling is that for each program that is uploading, that each has it's own connection thread and priority.
Assuming that priorities are equal, then the upload speed for each will be the total upload bandwidth divided by the number of threads.
I think when I am running multiple IPv6 uploads, that rather than being allocated a thread for each IPv6 upload, I think they are possibly sharing the 6in4 tunnel which is being treated as one thread.  Therefore the available bandwidth for the 6in4 tunnel reduces rapidly as other native IPv4 connections are made,  therefore the latency of the IPv6 tunnel peaks more than expected.
I would just like to see whether it is possible to control the peaks in the 6in4 tunnel latency by either assigning a guaranteed percentage of upload bandwidth, or by raising the 6in4 tunnel priority up one level.
Hopefully if my theory is right, then tunneled connection thread prioritization will disappear when NATIVE IPv6 is available !. 

[#6]

you know the ipv4 address for the tunnel so its relatively simple to assign the QoS to that wan IP from your router and set it to all traffic on that IP address or specify a particular device, although unless your running a dedicated server (raspberry Pi etc) QoS isn't likely to make a noticeable difference in fact it might well cause you problems,
as for the protocol the tunnel is running on if you didn't get the details from HE and your router doesn't display a list of upnp tunnels your last resort is trawl through HE's forums to find the default tunnel type, personally I see lots of different entries in mine but there listed as EA tunnel, Teredo tunnel, Skype tunnel etc
as for getting native ipv6, it wouldn't change the problem of the ipv4 side of things just split your available bandwidth in half between ipv4 and ipv6, direct everything it could via ipv6 and cause greater slowdowns

[#7]

The tunnel type provided by HE is 6in4 (aka protocol-41 using static endpoints).