Imagine #2 (musings on the topic of proxies)

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Sat May 15 02:54:12 CEST 2010


On Thu, 13 May 2010 23:59:11 +0200
Andrew Yourtchenko <ayourtch at gmail.com> wrote:

> 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 ?
> 

I think fundamentally what that is doing is shifting the IPv6
deployment costs onto the IPv6 proxy provider, away from the cheap
hoster. While IPv6 traffic load is negligible enough, some people are
willing to wear that cost. However, there is a threshold where the
costs will become too high and they'll switch off their IPv6 proxy
service, resulting in the website now not being available over IPv6. I
think that ultimately would defeat the primary motivation of this idea,
which is to make IPv4 content available over IPv6. We want IPv6 websites
to continue to be available, not available for a short time until they
become popular, and then disappear because of that popularity.

I find what I'm about to suggest quite distasteful, although there
might be a saving grace at the end of it.

To cover the IPv6 costs, and even make a profit, the IPv6 proxy
service could intercept the requests and insert/replace advertising in
them.

However, here might be the saving grace. At the end of the week/month
etc., the IPv6 proxy service sends an email to the cheap IPv4 only
host/website, saying "we made this much money off of you not supporting
IPv6". ... I'm sure people can work out what will rapidly happen
next ;-)


Regards,
Mark.




> cheers,
> andrew


More information about the ipv6-ops mailing list