Imagine #2 (musings on the topic of proxies)
Andrew Yourtchenko
ayourtch at gmail.com
Thu May 13 23:59:11 CEST 2010
Folks,
Yesterday I had this odd idea, which today due to the bank holiday in
Belgium and the unsunny weather resulted in something very very
experimental that you can toy around with
(http://github.com/ayourtch/sxxis - I flipped the name of a wonderful
service that is typically used in reverse way), and I thought to ask
what's your opinion:
The use case scenario of it is as follows:
1) Joe Sixpack hosts hosts the website www.foobar.example.com at
FooHosters. He would like to experiment with making it available via
IPv6, but FooHosters do not provide the IPv6 yet.
2) The progressive thinkers of this world have installed a bunch of L7
proxies, that listen on IPv6 and can go back to IPv4 world (that's the
sxxis toy in the git url above).
3) These proxies are listening on the same IPv6 address, which is
anycasted similar to 6to4 one into the internet.Let's call this
address <AP>
4) Joe Sixpack creates a DNS record which points the
ipv6.foobar.example.com towards <AP>, and
real-target.ipv6.foobar.example.com which points to the address as
www.foobar.example.com [ alternatlively, ipv6.foobar.example.com can
also have an A-record that points to the real host]
5) the users around the world, when they point their browser
ipv6.foobar.example.com, would normally hit their closest proxy -
therefore the impact of the two-legged topology is decreased.
The second use case is the one from the "Imagine" thread - put this
kind of device onto an IPv6-only network and give it an IPv4 address,
and mangle all the empty AAAA responses from the internet into the
ones that point to the proxy. Everything besides the HTTP will be
indeed broken, but this would be better than everything *and* HTTP
broken...
Of course all of this has its problems:
1) Same story as open proxies that allow CONNECT, this is quite a bit
of a pain from the security/auditing point of view. How big of a pain
is it ?
Does the logging help solve it ?
2) TCP with anycast address is, yes, thoroughly impure from the
theoretical standpoint - however, my understanding is in practice i'd
be hitting the same physical box at least on a 5 minute interval.
Which is almost enough from the practical point of view.
3) Heavy - maintaining 2 TCP states per one client connection. This
might be solvable by using not just one <AP> but multiple, and using
DNS to distribute the load.
Thoughts ?
cheers,
andrew
More information about the ipv6-ops
mailing list