6in4 aware NAT?

[jimb]

I was reading some pages on the ARIN's IPv6 awareness page today, and it got me thinking about the common problems with 6in4/6to4 tunnels terminated behind a NAT.

A lot of people seem to be "stuck" behind a NAT, and want to get IPv6 connectivity, so they deploy some linux box, or hardware router which can do 6in4.  Often, they don't have control of the edge router/firewall which is doing the NAT, and the IT staff who do control it are either unable or unwilling to enter a static NAT for IP proto 41 traffic.  Or, the NAT device is incapable of doing a static NAT based on IP protocol.  Also, if the NAT device only has a single public IP available, then only one tunnel per separate 6in4 server can be brought up (and this presumes the NAT device even handles this correctly).  

Thus, if you have a user who wants more than one tunnel, or multiple users who each want tunnels, or, especially, multiple 6to4 users whose machines happen to be behind such a NAT setup, they're basically out of luck.

It struck me that it wouldn't be that difficult to make these NAT devices/firewalls "6in4 aware", and able to route tunnel traffic to the correct internal client based on the 6in4 payload packet's IPv6 addresses.  A 6in4 "fixup" (Cisco PIX speak) or "conntrack" (linux Netfilter speak) module, or the appropriate equivalent, could be added to any IPv4 NAT box fairly easily.  The module would hook into the firewall's NAT/connection tracking routines, and note the source IPv6 address of any outgoing 6in4 packet going out through the NAT, and its associated IPv4 NAT information.  It could then identify the return traffic's proper de-NATed IPv4 destination by peeking at the 6in4 payload packets' IPv6 destination address, and looking that address up in the approprate table(s) to figure out the original IPv4, de-NAT it, and send it on its way.  

It would operate just like any number of "fixups" already existing on various firewalls (ftp "port/non-passive mode" connection tracking, for instance).  So it wouldn't be reinventing the wheel or anything.  Just adding another intelligent connection tracking module to the ones already extant.

If this sort of "6in4" awareness were built into more NAT devices, it would make life much easier for people doing 6in4 tunnels behind a NAT.

IMHO, the biggest "win" would be for 6to4.  You could have a whole slew of people using 6to4 on various boxes living behind a NAT simultaneously without issues.  In fact, with some intelligence added to the client side of 6to4, you could have it as automated and simple to use as Teredo, without the complexity, infrastructure requirements, and overhead of Teredo (or AYIYA, as another example).

Anyway, I can't be the first person to think of this.  I'm wondering, has anyone seen "6in4" intelligence in an existing NAT firewall out there?  Maybe I should write a netfilter module to kickstart things on linux (although ... ugh ... it's been years since I've done any systems programming)?

[BobRobertson]

I don't think it would take any system programming to pass 6in4 "protocol 41" traffic through Linux, just the correct line in the iptables to pass it.

I recall specifying protocols TCP and UDP, I'd have to go back into my iptables learning mode to see what exactly would have to be specified, and like you I'm not going to do that today. But I'm pretty sure it's there.

If I have a Linux box acting as the router/firewall, what I'll do is terminate the 6in4 tunnel right there and simply route IPv6 behind that system. That is what I had at home for quit a while, very happily, until I got and IP phone and I just could not get it to work through the Linux router. I can see in a business environment how it may be impossible to do, sure, so finding out how to pass 6to4 still has application.

My present personal issue is with my idiot, excuse me, "inexpensive" home router. It knows what TCP is, it knows what UDP is, and can be configured to pass traffic coming in on those two protocols to specific systems that are using NAT behind it. The pre-defined settings are all about games, which should tell me more than I want to know about the expectations of the people at Belkin.

The only addition needed is to be able to specify the protocol number.

[jimb]

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.  

[BobRobertson]

I see. So "protocol 41" has no "port" designation which is how NAT keeps track of the separate streams.

It might be that it will require TCP encapsulation, rather than 6in4, to do multiple tunnels through a single NATing router.

Otherwise you're asking the NAT device to do some serious work.

At that point I would consider just terminating one tunnel at the institution and running IPv6 on the LAN, if it weren't for having to worry about all the previously installed campus hardware.

[jimb]

I see. So "protocol 41" has no "port" designation which is how NAT keeps track of the separate streams.

It might be that it will require TCP encapsulation, rather than 6in4, to do multiple tunnels through a single NATing router.

Otherwise you're asking the NAT device to do some serious work.

At that point I would consider just terminating one tunnel at the institution and running IPv6 on the LAN, if it weren't for having to worry about all the previously installed campus hardware.

There's already something which does encapsulation, using UDP:  Teredo .. and of course AYIYA.  But 6in4 already has all the info it needs in each packet for successful NAT traversal without the need to encapsulate it in a l4 proto which has ports.  Namely, the IPv6 addresses in the 6in4 payload.

What I'm proposing wouldn't be much different than what they're already doing with a lot of other protocols.  It's just a typical connection tracking deal like you'll find in most firewalls for certain protocols (like FTP).  Actually, I wouldn't be all too surprised if someone has already implemented something like this.

[uTasker]

Hi Jim

I have just started working with 6to4 tunneling and think that your ideas are similar to those thoughts that I have when trying to get this working.

1) I am behind a NAT which can't route 6to4. The only way that I can get my PC to use tunneling is to program its IPV4 address as DMZ. The NAT passes all outgoing packets and then all incoming packets get sent to the address in the DMZ (i.e. back to the PC). This then allows IPV6 web serving and pinging etc.

2) This is however not a very good configuration because the PC has no Firewall protection from the router (it is directly visible on the Internet at the router's IPV4 address). It also only allows one user to work.

3) My situation is that I would like to have multiple users. Not PCs but embedded devices (sensors, displays etc.) each with its own IPV6 address sharing the NAT but each having its own global IPV6 address for connections out of the Internet.

4) Theoretically I could have 2^64 devices sharing the /64 tunnel. Practically, as they all need to run 6to4 and have unique local IPV4 addresses in the sub-net it is more limited (say 2^16 with 255.255.0.0 local sub-net).

5) My present state of development is that the embedded devices can be assigned their global IPV6 address and can handle 6to4. They can ping IPV6 addresses in the internet and they can respond to pings originating from the Internet (eg. from the HE looking glass page). To do this the device has to however be in the NAT's DMZ - and, consequently, only one device can work at a time.

6) The next step is to overcome this restriction and my idea is as follows.
a) There is in fact no problem for any of these devices to sent tunneled IPV6 packets into the Internet
b) All tunneled IPV6 packets returning arrive however at the device in the DMZ. The same is true for any IPV6 (connection) packets originating from the Internet.
c) A 'router' situated in the DMZ doesn't need to know which device sent packets out since the global IPV6 address is contained in the IPV6 layer. It would only need to know if were performing firewall functions.
d) therefore the device in the DMZ needs only to strip off the IPV4 layer and deliver the frame as raw IPV6 to the internal device - or it could also deliver it to the internal devices link-local address
e) this requires that the device in the DMZ can map the global IPV6 address to the link-local address and deliver based on neighbor cache information, or else has a local global IPV6 to MAC cache. The size of the cache will probably be the physical limiting factor for the quantity of local IPV6 addressable devices to be behind the NAT. In my case I have devices with only a few kBytes of RAM available but this should still allow a few hundred sensors to be tested.

7) What doesn't address are problems with Firewall since, essentially, all tunneled IPV6 receptions are effectively routed to the global IPV6 address owner. In the case of embedded sensors etc. this is however not usually an issue. They are there to be "contacted". Also the anonymity principle of the huge IPV6/64 routed address space still makes it hard to find such a device when its exact address is not known...

Any comments??

Regards

Mark

P.S. A typical device is on line at http://demo.uTasker.com - using IPV4. I expect that this can be made dual-stack capable quite shortly so that it is also browsable via IPV6. Since it is the device in the local DMZ it may then be used to do the internal routing as discussed above to enable multiple such internal devices.

[uTasker]

Hi

I just completed a first test where I fixed the MAC and IPV4 and IPV6 addresses of my PC in an embedded device (a single chip processor with LAN costing about $5).
Each received 6to4 tunneled frame that it receives in the DMZ, which is addressed to the PC's IPV6 address, is simply sent out on the local Ethernet with the following slight modifications:

1) MAC address is set to the PC's
2) IPV4 destination address is set to the PC's
3) The IPV4 check sum is re-calculated (due to the change in 2)

This is then received by the PC and passed up to the application (since all then matches).

In fact I just logged on to the HE web site in IPV6 mode and posted this with all reception being routed by this small chip (sitting in the DMZ) to the PC. The PC is working as normal behind the NAT's firewall and only its IPV6 6to4 reception tunneled data is being routed back out of the DMZ.

To extend the support to multiple PCs behind my otherwise 6to4 in-compatible NAT I would need to extend the fixed table (or to make it more dynamic by adding some discovery mechanisms).

The disadvantage is simply that the received Ethernet frame is seen on the network twice (first time going to the device in the DMZ and then coming back - slightly modified - from this device). The delay is about 1ms on average so not really noticeable. I would expect that such a simple device could quite easy handle a dozen or so PCs. It can simply be plugged in anywhere on the network since it is not routing between two Ethernet ports but instead simply relaying frames after the appropriate manipulation.

This means that I now have a first simple solution to allow multiple PCs or multiple devices (and mixtures of the two) using 6to4 tunneling to operate in the test network. RAW IP6 traffic is also relayed using a similar technique (actually simpler because it doesn't need to recalculate the IP content). It can also convert tunneled IPV6 to raw IPV6 local traffic. So I think that the next step will be to experiment with multiple devices in the local network transmitting with tunneling and receiving with either tunneled or raw traffic (depending on the relay's setting).

Regards

Mark

PS. I can also run the SW on a PC which means the PC gets a second IPV4 address (the one in the DMZ), but otherwise unknown to Windows. All traffic received here is handled by the same code and sent back to the network where the same PC or others in the network can receive it. So, the embedded device is not even actually needed when this is running - any chosen PC on the network can operate a relay... ;-)

[snarked]

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.

Is there a reason why the gateway/firewall owner can't obtain a /48 tunnel and divide it up into /64s for the clients that want it?

[jimb]

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.

Is there a reason why the gateway/firewall owner can't obtain a /48 tunnel and divide it up into /64s for the clients that want it?

Sure.  If they all knew each other and coordinated.  This whole thread was really sparked by a situation where one of the users was on a campus LAN and wasn't the only one trying to use 6in4 behind a NAT.  The IT department didn't want to have anything to do with it or didn't understand IPv6.

The basic idea here is that "it would be nice" if firewalls had better NAT connection tracking for 6in4 traffic so that multiple users of 6in4 could sit behind the same public IP.  The tracking could be accomplished by considering the IPv6 addresses contained in the tunnel packet and associating them with the IPv4 tunnel client addresses.  It'd be reasonable to presume each user was using a /64, and associate each /64 with a particular IPv4 tunnel client address.  

With some extra work on the client, it could also be made to work with multiple 6to4 users sharing the same IPv4 public (it'd have to somehow automatically pick a /64 subnet for each user out of the /48).  Alternatively, it could just have a separate table entry for each outgoing source IPv6 it sees, although this could make for big tables, and also introduce the possibility of having overlapping IPv6 addresses for different users in the same 6to4 /48.  Although this is a bit moot since 6to4 isn't very practical because of the the way the internet handles it at this point (crappy routes for the anycast, etc).

[jimb]

@utasker:

I'm really not sure what you're trying to do here.  If what you need is global IPv6 connectivity for all of your little embedded devices or whatever they are, then you simply need to set up a 6in4 tunnel at the edge of your LAN(s) and use a /64 or /48 if you need multiple subnets.  This would obviate the need to establish a separate tunnel from each device on your LAN(s).  This would be by far the easiest thing for you to do, even if it involves replacing your existing firewall/gateway with something which can do NAT protocol forwarding, such as a linux netfilter/iptables firewall.

The situation I'm talking about in this thread is a 'special' situation where multiple users find themselves in a campus network which doesn't support IPv6 natively, where the net admin isn't willing to set up a tunnel at the edge, they're all behind the same public IP NAT, and they all want to run 6in4.  If the edge router had a 6in4 NAT connection tracking module (such as the ones found for FTP and such in netfilter/iptables), then something like this could be made to work, and really isn't rocket science.

Also, you're using the term 6to4, which is different than 6in4.  6to4 uses 6in4 as it's tunneling method, but it's more of a special behavior of 6in4 plus a (fairly crappy) internet infrastructure to support it.  Are you sure 6to4 is what you're after?

If what you're after is for multiple devices to establish independent global IPv6 connectivity behind a NAT without the NAT needing any additional configuration or awareness of IPv6, then Teredo is probably what you want.  It too has its issues, but it's designed for such cases.

[uTasker]

Hi Jim

Basically I am trying to do two things:

- First is to solve the same problem that you are addressing. That is, having multiple users behind a single NAT which can't be configured to allow forwarding protocol-41. My solution is to relay all incoming traffic via a single address in the DMZ (that is the address that all non-identified traffic is sent to - assuming that this is allowed). Of course having a NAT that supports this would be the ideal situation (I also found the following on the subject: http://www.ietf.org/proceedings/57/slides/v6ops-2.pdf) but I want a quick solution which allows operation in any network using any available NAT - as long as DMZ is enabled and I known the address, I can now use the network to work with 6in4 tunneling. I can also allow multiple users to do the same (I think this is your subject and that's why I though it relevant).

- Secondly I want users on the Internet to be able to access a number of global IPv6 addresses behind the same NAT (tunneled via the single public IPv4 address). Effectively the same works because, unlike the forwarding protocol-41 operation of a configurable NAT, it doesn't match outgoing traffic with incoming traffic. The relay agent, in this case, can deliver the incoming 6in4 frames to the respective device(s) either still in 6in4 mode or also extracted in raw IPV6 in the local network.

The first and second things are extremely similar. In fact the C-code that I have written to do this differs in only 9 lines of C-code depending on case 1 or case 2. The difference between case 2 forwarding 6in4 and extracting to RAW IPv6 is also only about the same amount of lines of C-code. This shows that these actions are also very related.


Probably I am mixing 6to4 and 6in4: I have only been experimenting with this technology for about 2 or 3 days now so am not up on all the terms; tunneling is the feature of interest so it should probably all read 6in4.


I learned about the tunneling method and HE, I think last weekend, so registered for an account and disabled the Teredo operation according to the instructions. Therefore I never used it and never heard of it before, so don't know at the moment any details. It is presently OFF - it is also presumably only relevant for Windows and not embedded devices (?).

The problem that I do have, with my NAT, is that no IPV6 traffic and no 6in4 traffic normally gets in through it at all. The only way that I can get any such traffic through it into the local network is via DMZ. Therefore it seems that I may be stuck with this before replacing the NAT with something more modern. However I have also experimented with some other NATs (also older ones except a Wireless router that was purchased quiet recently) and none of them seem to offer any configuration allowing such traffic to come through. I also went into a PC shop and asked whether they had anything suitable but they didn't know what I was taking about - so no progress there  - consumer electronics (possibly without considering mobile devices) doesn't seem to be very IPV6 oriented at all at the moment - the PC shop keeper confirmed this and recommended that enterprise networking equipment would probably be the solution.

However the goal here is to identify a technique that works for "any old NAT" and can be used by anyone without having to change equipment. Eg. If I sell IPv6 sensors to people to put in their homes and be used to monitor their room temperature via Internet when they are on holiday and allow them to control the shutters remotely when it gets hot, and these sensors should each have a global IPv6 address I need a solution which doesn't require them to replace their existing NATs - I can't expect them to have to purchase a new NAT with advanced tunneling techniques but instead must find a work-around for the existing case. I also can't expect the purchasers of $20 sensors to be expected to install a new firewall/gateway or Linux based system to allow them to operate - with a good guide I could instruct them to set up their tunnel with HE (nice and un-burocratic and quite painless process) but that is about the limit...

What I have done is proven that it is possible (that is, I have a real working solution based on hardware and software that is now allowing me to post this in IPv6 mode across a NAT that doesn't support 6in4 and without having to expose the PC directly to the Internet) - maybe not the best solution but a first step on the learning curse. Maybe it has some other uses too...;-)

Regards

Mark

P.S. The development is being documented here in the form of an IPv6 User's Manual: http://www.utasker.com/docs/uTasker/uTaskerIPV6.PDF
Note that the document is updated as new work is performed and may presently contain some 'real rubbish' if things haven't been understood correctly up to now. The development period of such projects is usually many months so it will be changed as experience is gained and feedback comes in. This also involves learning by doing and also by making mistakes - so feedback welcome but, please, not too much harsh critisism for still being a 'newbee' at this stage.

[jimb]

Hi Jim

Basically I am trying to do two things:

- First is to solve the same problem that you are addressing. That is, having multiple users behind a single NAT which can't be configured to allow forwarding protocol-41. My solution is to relay all incoming traffic via a single address in the DMZ (that is the address that all non-identified traffic is sent to - assuming that this is allowed). Of course having a NAT that supports this would be the ideal situation (I also found the following on the subject: http://www.ietf.org/proceedings/57/slides/v6ops-2.pdf) but I want a quick solution which allows operation in any network using any available NAT - as long as DMZ is enabled and I known the address, I can now use the network to work with 6in4 tunneling. I can also allow multiple users to do the same (I think this is your subject and that's why I though it relevant).

- Secondly I want users on the Internet to be able to access a number of global IPv6 addresses behind the same NAT (tunneled via the single public IPv4 address). Effectively the same works because, unlike the forwarding protocol-41 operation of a configurable NAT, it doesn't match outgoing traffic with incoming traffic. The relay agent, in this case, can deliver the incoming 6in4 frames to the respective device(s) either still in 6in4 mode or also extracted in raw IPV6 in the local network.

The first and second things are extremely similar. In fact the C-code that I have written to do this differs in only 9 lines of C-code depending on case 1 or case 2. The difference between case 2 forwarding 6in4 and extracting to RAW IPv6 is also only about the same amount of lines of C-code. This shows that these actions are also very related.

The first situation is the typical tunnel user with a NAT firewall and a single public IP address, with a 6in4 tunnel client behind it.  Typically, these users' nat/firewall devices can't be configured to forward a IPv4 transport layer protocol like 6in4, but focus only on things like UDP and TCP ports.  A real oversight in most equipment.  Even some enterprise equipment can't do this.

However, most of the time these devices will forward 6in4 traffic iff it was generated internally first.  That is, if  6in4 traffic is originated from behind the NAT to a tunnel server, the NAT device will create a entry in the connection/NAT table, and any return traffic with IPv4 proto 41 will be sent to the inside machine which originally sent it.  That is, you can't statically configure an inbound NAT for proto 41 traffic to some specified IPv4 address, but most devices will create one dynamically.  Of course, these connection tables eventually time out if there is no traffic for a given amount of time.  The typical solution to this is to set up a IPv6 ping which goes off every few minutes that keeps the connection table entry "live" so that outside originated packets won't get dropped.

This is a typical situation and shouldn't require any special software or hardware, as most devices support this type of arrangement.

Of course problems can arise with this type of situation.  For instance, if another host inside decides to send a 6in4 packet, the behavior is somewhat "undefined" since it depends on the router/NAT device.  I think most of them simply blindly replace the existing connection table entry with a new one with the IPv4 address of whoever just sent the 6in4 packet.  This is why it's always best to define a NAT entry if your device allows it.  

And of course, this situation segues into the original reason for this thread, e.g., that a NAT device could be fairly easily made to correctly track 6in4 from multiple internal 6in4 clients by peeking at the IPv6 addresses in the payload, allowing you to have multiple tunnel clients behind a single NAT.

Also, as I said earlier, there's already a tunneling protocol out there, well, more than one actually, which allows you to tunnel IPv6 via just about any NAT.  One is called Teredo, and is implemented on every windows box, and Linux has an implementation called Miredo.  It uses a rather byzantine protocol coupled with a number of Teredo servers and relays out on the internet, along with UDP encapsulation and NAT hole punching techniques to automagically tunnel IPv6 packets through just about any typical NAT.  There are also other things such as AYIYA, but its deployment is somewhat more limited (sixxs providers use it, etc).

The "relay agent" you talk about in your 2nd paragraph sounds suspiciously like an IPv6 tunnel router.    At least in the mode where it accepts 6in4 packets and sends them as "RAW IPv6".  That's what a router configured with a 6in4 tunnel does.  This allows you to have multiple global IPv6 addresses and subnets behind a single "relay agent".

In the case where it accepts and forwards 6in4 traffic, well, that sounds like a typical IPv6 router with 6in4 tunnels established to multiple other routers.  

In the end, you still need a router, either behind a NAT with proto 41 directed to it either via a static NAT, a dynamic table entry, or a DMZ setting, or a router with a public IPv4 address on it, which accepts 6in4 tunnel traffic, and routes IPv6 on the other end.  

It sounds like you're trying to reinvent the wheel a bit here.  Unless I'm simply not understanding what you're doing.  

Probably I am mixing 6to4 and 6in4: I have only been experimenting with this technology for about 2 or 3 days now so am not up on all the terms; tunneling is the feature of interest so it should probably all read 6in4.

Yeah they are different.  6in4 is a simple IPv6-in-IPv4 tunneling method which stuffs IPv6 packets into an IPv4 packet and sets the protocol header field to 41 to identify itself as 6in4.  

6to4 is an automatic tunneling method which uses 6in4 as a tunneling protocol.  It uses a set of 6to4 relay servers, which are really just specialized 6in4 tunnel servers, and the special 6to4 IPv6 netblock (2002::/16) in which one's public IPv4 address is encoded into a /48 prefix which is used for one's globally addressable IPv6 space.  i.e., if your public IPv4 is 192.0.2.10, your 6to4 prefix would be 2002:c000:20a::/48, from which you can break out multiple /64 prefixes for your LANs.  Your 6to4 router living on the edge of your network sends IPv6 traffic to the internet by encapsulating IPv6 packets in a 6in4 packet, and sending it to either a configured 6to4 relay host, or more commonly, the 6to4 anycast address (192.88.99.1 ) which ostensibly routes your IPv6 traffic to the closest 6to4 relay.  Return traffic is of course sent to your 6to4 router by the relays by extracting the IPv4 address from the 6to4 IPv6 address, encapsulating in 6in4, and sending it to the extracted IPv4.

I learned about the tunneling method and HE, I think last weekend, so registered for an account and disabled the Teredo operation according to the instructions. Therefore I never used it and never heard of it before, so don't know at the moment any details. It is presently OFF - it is also presumably only relevant for Windows and not embedded devices (?).

It's built into windows, and available for linux and other platforms.  I'm not sure if it could be easily ported to your embedded devices.

The problem that I do have, with my NAT, is that no IPV6 traffic and no 6in4 traffic normally gets in through it at all. The only way that I can get any such traffic through it into the local network is via DMZ. Therefore it seems that I may be stuck with this before replacing the NAT with something more modern. However I have also experimented with some other NATs (also older ones except a Wireless router that was purchased quiet recently) and none of them seem to offer any configuration allowing such traffic to come through. I also went into a PC shop and asked whether they had anything suitable but they didn't know what I was taking about - so no progress there  - consumer electronics (possibly without considering mobile devices) doesn't seem to be very IPV6 oriented at all at the moment - the PC shop keeper confirmed this and recommended that enterprise networking equipment would probably be the solution.

As I said earlier, I haven't seen many NAT devices which won't properly relay inside originated 6in4 traffic.  It's is a common setup used by many HE tunnel broker users.

However the goal here is to identify a technique that works for "any old NAT" and can be used by anyone without having to change equipment. Eg. If I sell IPv6 sensors to people to put in their homes and be used to monitor their room temperature via Internet when they are on holiday and allow them to control the shutters remotely when it gets hot, and these sensors should each have a global IPv6 address I need a solution which doesn't require them to replace their existing NATs - I can't expect them to have to purchase a new NAT with advanced tunneling techniques but instead must find a work-around for the existing case. I also can't expect the purchasers of $20 sensors to be expected to install a new firewall/gateway or Linux based system to allow them to operate - with a good guide I could instruct them to set up their tunnel with HE (nice and un-burocratic and quite painless process) but that is about the limit...

Well, this sounds like a job for Teredo.  It's exactly what Teredo was created for (although it doesn't work behind everything, for instance "symmetric nat").  Another option would be to build 6in4 tunneling into your devices and rely on a user's NAT device relaying the 6in4 traffic, which most will do, as long as no other devices attempt to initiate 6in4 traffic.  You could have some sort of menu on your device allowing the user to turn on either Teredo, or configure a 6in4 tunnel.  

Doing 6to4 behind a NAT is problematic because there's no way to know which relay server will be sending traffic to your NAT device and I've found from experience that they don't all send the traffic with the anycast address set as the source address.  Some seem to do so, others use their normal IPv4 address.  So to pass through a NAT, one would either need a protocol forward set up, or point the DMZ to your 6to4 router.  So you're sort of back to square one with 6to4.

Another possibility is implementing or porting AYIYA to your devices, but you'd be limited to tunnel providers which support AYIYA such as sixxs.  I don't know much about it since I use 6in4 with HE, which works quite well for me.  

What I have done is proven that it is possible (that is, I have a real working solution based on hardware and software that is now allowing me to post this in IPv6 mode across a NAT that doesn't support 6in4 and without having to expose the PC directly to the Internet) - maybe not the best solution but a first step on the learning curse. Maybe it has some other uses too...;-)

Yeah I'm still how sure how exactly you've done this.  But the only ways I can think of that it could be done is by simply implementing a 6in4 router on your devices, and/or perhaps some code which allows a node to act as a 6in4 tunnel relay by peeking at the IPv6 addresses (sort of like my theoretical NAT helper module) and sending them to the appropriate device.  The latter thing would be a bit of an odd way to do things, since typically once a 6in4 packet reaches its end point, the IPv6 packets are sent natively over the LAN, and not over further 6in4 tunnels.  It also sounds somewhat like a alternative to ISATAP, which is a method of routing IPv6 in a LAN environment across IPv4 only routers, using IPv4 as a link layer protocol.  :-)

Anyway, you should probably study the IPv6 transition methods a bit to get an idea of "how things are done already" before spending a lot of time/energy on reinventing ways of doing things which may already have a standard solution.

A good page to start is:  http://en.wikipedia.org/wiki/IPv6#Transition_mechanisms