Commit 9cb90d05 authored by Otto J Wittner's avatar Otto J Wittner

Intro polished and suplemented

parent 603c29aa
......@@ -3,6 +3,7 @@
\documentclass[a4paper,english]{IEEEtran}
\usepackage[T1]{fontenc}
\usepackage[latin9]{inputenc}
\usepackage{graphicx}
\makeatletter
......@@ -18,8 +19,8 @@
\title{SNIP: TLS based IPv6 transition proxy }
\author{Yorin Anne de Jong\\
Otto Jonassen Wittner}
\author{Yorin Anne de Jong, UNINETT\\
Otto Jonassen Wittner, UNINETT}
\maketitle
\begin{abstract}
<summarize everything> \end{abstract}
......@@ -27,33 +28,61 @@ Otto Jonassen Wittner}
IPv6 transition, Proxy, HTTPS, DNS, IPv6 only servers
\end{IEEEkeywords}
\section*{Introduction}
\begin{itemize}
\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
\section{Introduction}
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.
%\begin{itemize}
%\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
%\end{itemize}
Four year has passed since the last blocks of IPv4 addresse where handed out by the Internet Assigned Numbers Authority (IANA).
Still only less than 12\% of web sites in the world support IPv6 \cite{vyncke2015ip6stats} and the amount of IPv6 enable users is below 10\%.
Hence a full transition from ``legacy'' IPv4 to modern IPv6 addressing cannot be claimed to yet have taken place.
Since the introduction of IPv6 in 1995 \cite{deering1995rfc1883} IPv4-to-IPv6 transition technologies have been a research and development area.
Considering the still low penetration of native IPv6 servers and clients, transition technologies have indeed still relevance.
In a client environment, there are multiple transition solutions to address the IPv4 address shortage.
NAT44 (or just NAT), i.e. network address translation from one IPv4 address to another IPv4 address, is by far the most typical technology to ``save'' IPv4 address space.
Usage scale varies from small (a few nodes) home networks to WANs applying carrier grade NAT.
However alternatives to NAT44 has been around for a while, NAT64 \cite{bagnulo2011rfc6146} and CLAT (based on 464XLAT \cite{mawatari2013rfc6877}) being two well known options.
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.
The use of VHosts (running multiple similar services on a single server, e.g. \cite{apache2vhost} ) has succesfully kept the need for IPv4 server addresses low, similar to what 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, similar to the way VHosts work.
In an future ``IPv6-only'' world, VHosts and container proxies may become obsolete as every service can simply claim its own IPv6 address.
One immediate advantages of this is the improved ability to build service specific access control lists (ACLs) based on addresses in lower layers of the network stack, for example in a router.
It also simplifies the stack, because application level routing is no longer required, sparing the administrator from configuring a VHost and proxy servers as well as maintaining the related required software.
% 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.
This extended abstract presentes an alternative server side IPv4 to IPv6 transtion technology named S... N... IPv6 (SNIP).
The core concept is still based on a placing a proxy server between the application server and the clients.
To keep the complexity down and avoid the need for a classic address translation table,
SNIP exploits the fact that a majority of all web based services are available over HTTPS \cite{}, i.e. encrypted HTTP connections.
Embedded in the underlying Transport Layer Security connections (which provide the S in HTTPS) is a Server Name Indication (SNI) value, i.e. the domain name of the destination application server.
Hence the mapping required to perform address translation can be configured in the Domain Name System (DNS).
The rest of this extended abstract is organized as follows. Section \ref{sec:snip} describes SNIP in detail. Section \ref{sec:eval} prestents results from evaluating SNIP in a realistic environment. Section \ref{sec:related} presents related work, and Section \ref{sec:concl} summarizes and indicate future 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.
\section{\label{sec:snip}SNIP}
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.
Figure \ref{fig:snip-session} illustrate how SNIP operates....
\begin{figure}
\includegraphics[scale=0.5]{dummy.pdf}\caption{\label{fig:snip-session}The SNIP architecture including a SNIP session
connection setup.}
\end{figure}
% Otto stopped here....
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.
......@@ -77,10 +106,17 @@ or the proxy server can run a TCP proxy, for example through HAproxy (existing s
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.
\end{itemize}
\section*{Evaluation}
\section{Evaluation}
What should go here? I have been running it for some sites, it runs stable.
\section*{Conclusion}
\section{Related Work}
\section{Conclusion}
\bibliographystyle{ieeetr}
\bibliography{refs}
\end{document}
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