Commit 08f4dfcb authored by Jørn Åne de Jong's avatar Jørn Åne de Jong
Browse files

Add preliminary text

parent 43561958
......@@ -29,13 +29,58 @@ IPv6 transition, Proxy, HTTPS, DNS, IPv6 only servers
\item Most transition technology focus on clients. SNIP addresses server
\item Most transition technology focus on clients.
\item Today, servers must be reachable on IPv4 and IPv6.
\item Using IPv4 on servers requires planning.
\item IPv6 advantages cannot be fully utilised when IPv4 must be supported.
\item Related work
In a client-environment, there are multiple solutions to address the IPv4 address shortage.
IPv6 is the long-term answer, but today IPv4 must be supported too.
This is typically adressed through NAT44, but new methods have been developed such as NAT64 and CLAT.
On the server side, however, there has not been as much development.
The use of VHosts (running multiple similar services on a single server) has succesfully kept the requirement for IPv4 adresses low, just as NAT44 has done for clients.
In modern models, where services run on containers, there is usually a proxy server which exposes all services on a single IP address, the same way VHosts work.
In an IPv6-only world, VHosts would not be necessary any longer, because every service can simply claim its own IPv6 address.
This provides advantages such as being able to set ACLs for a specific service (IPv6 address) in lower layers of the OSI model, for example in a router.
It also simplifies the stack, because application level routing is no longer required, sparing the administrator from configuring a proxy server or maintaining software that does this for him.
The reality, however, is that we do not live in an IPv6-only world.
In fact, we are almost as far from it as we were when IPv6 was just invented.
Because of this, running servers IPv6-only seems like an impossible task.
Clients must be able to connect from their IPv4-only phones, routers, ISPs to your servers; you will lose business and money if you don't.
However, something has changed in the last years.
Most services are available over HTTPS, encrypted HTTP connections.
When a client connects to an HTTPS server, it will send an SNI-value.
This is the hostname of the server the client thinks it's contacting.
The oldest browser today that still has some market share that doesn't support SNI is Internet Explorer 6.
It is still in use in some intranets, but on the public internet the browser is as good as unsupported now.
By utilising the facts that (1) virtually all communication happens over HTTPS and (2) all reasonably up to date clients support SNI, this documents proposed SNIP, an auto-configuring proxy that uses the SNI value.
This proxy will listen on TCP4 port 443 and read the SNI value on incoming requests.
It will then lookup the hostname on IPv6 and forward the request there.
This allows the servers to run IPv6-only and let the proxy handle the IPv4 clients.
The proxy can use an IPv6-mapped IPv4-address to contact the server,
so that the proxy cannot be used as an anonimiser.
There are some problems this proxy doesn't solve, namely non-HTTPS services.
Typically, there will be a low amount of these services on a network, compared to the amount of web services.
It is therefore possible to assign these services their own IPv4 address.
This can either be done directly on the server (requires infrastructure that supports IPv4),
or the proxy server can run a TCP proxy, for example through HAproxy (existing software).
Some services there will only exist one of in an organisation, for example mail, chat, VPN.
These can share the same IPv4 address while having different IPv6 addresses.
What should go here? I have been running it for some sites, it runs stable.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment