On 27 Jul 2011, at 17:03, Mark Andrews wrote: > 0D20EB6-78C9-415D-9493-3AA08FAACEEF@xxxxxxxxxxxxxxx>, Tim Chown writes: >> >> a) use 6to4 anyway on an open platform like OpenWRT > > Which may or may not still have the code. OpenWRT could remove > support just the same as another source could. OpenWRT is also not > widely supported by CPE vendors. i.e. you are own your own if > something goes wrong in most (not all) cases. In the event OpenWRT should remove 6to4 support, just get like-minded people together (if there are lots of people that consciously want to use 6to4 for application development and testing) and roll your own. >> b) use a tunnel broker - this works much better through NATs and with dynamic >> IPv4 addresses > > For which there is only experimental / ad-hoc code. Please name > CPE vendors that support tsp? Please name CPE vendors that support > tunnel re-configuration on re-number. Jeroen has answered this, but I would point out, as an example of what can be done in short time, that I had a student last year who developed a mini-ITX Linux build with tunnel broker support, and IPv6 firewall and QoS support, using a web interface driving existing tools like iptables and tc. He chose to use the HE broker, and it's a one-time registration after which it just works without further user intervention with HE. It would be very interesting to see brokenness figures for well-known broker prefixes as against 6to4, if anyone is gathering such data. >> c) use your $work VPN if it supports IPv6, which it could/should if your comp >> any values IPv6 >> d) get IPv6 from your ISP, or move to one that has it if yours does not > > Which is not always a viable option. It is in the UK, at least. Tim _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf