I think you misunderstood. I'm not talking about simply passing proto 41 through. I'm talking about smarter connection tracking for 6in4 traffic so that
multiple 6in4 clients can operate simultaneously behind the same NAT gateway/firewall, perhaps talking to the same tunnel server.
For instance, in a campus environment, if multiple users are behind the same many-to-one NAT and each want to get a tunnel from HE, from the same tunnel server, because they want their own separate IPv6 networks, it won't work because of ambiguity of where to direct the return traffic.
One way I thought of doing this is by creating connection able entries with a "tracking module" which peeks at the outgoing IPv6 source addresses (which are unique) and records these in the connection table along with the IPv4/NAT information. When the return 6in4 traffic comes back, it can again peek at the IPv6 destination address in the payload and figure out which inside 6in4 router to send it to. This is something that'd have to be implemented as a separate module similar to "nf_nat_ftp" (which allows port mode FTP through a NAT).
This might also be extended to 6to4 situations behind NATs, and with a bit of work, might be a means of completely automating 6to4 connection set up and making it work as easily as Teredo, but without the overhead. The problem would be that you'd have to somehow automate the generation of a IPv6 subnet using the 16 bit subnet field available to 6to4 such that each user behind the NAT would get a unique IPv6 /64 subnet (perhaps using the last two octets of the 6to4 router's IPv4 address as the IPv6 subnet field). Obviously, if you wanted more than a single /64, some other scheme would have to be employed (perhaps presuming a shorter prefix length while somehow ensuring uniqueness). But I digress.
