[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Translation versus tunneling document



Brian E Carpenter wrote:
On 2007-12-11 09:36, Iljitsch van Beijnum wrote:
On 8 dec 2007, at 20:34, Brian E Carpenter wrote:

I think you also have to consider whether there's something to
tunnel *to* - is there a significantly large class of dual stack
services that will be able to make use of tunnels? And don't forget
the third class of solution: application level proxies. Would
you advise the operator of a large IPv4-only web site to
a) dual-stack the whole site
b) install a dual-stack proxy for IPv6 clients
c) install a layer 3 translator for IPv6 clients?

As I said in the second session, dual stack isn't an appropriate mechanism for client computers. If we had that kind of address space we wouldn't have to have this discussion.

I agree. That's why my question was about a server site.

Proxies are good but generally don't address UDP applications

My question was specifically about a web site.
In the specific case of a web site, there are some interesting observations:
- the site operator is likely to care a great deal about reliable access, including all the corner cases - there is likely willingness to support a *small* number of methods/tricks/special support, to cover cases that need such support - the site operator may know more about which access is likely to be "better" (for some meaning of "better") than the client

Also note, that the web server software may have access to information (on a connection-by-connection basis) about where/how the client connects, e.g. special address space, v4 vs v6, etc.

And web servers have extra/special ways of potentially identifying/tracking special situations: cookies.

Suppose, for instance, there were a few well-defined cookies which could help refine and/or control which choice of access to use, if more than one were available.

The presence of a cookie could trigger HTTP redirects to specific (e.g. v4 or v6 or tunnel termination addresses) behavior.

Brian Dickson