On 27 Jul 2011, at 17:03, Mark Andrews wrote:
0D20EB6-78C9-415D-9493-3AA08FAACEEF(_at_)ecs(_dot_)soton(_dot_)ac(_dot_)uk>,
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf