I2P_Website/i2p2www/pages/site/docs/protocol/index.html

{% extends "global/layout.html" %}
{% block title %}{% trans %}Protocol Stack{% endtrans %}{% endblock %}
{% block lastupdated %}2024-01{% endblock %}
{% block accuratefor %}0.9.61{% endblock %}
{% block content %}

<p>{% trans docs=site_url('docs') -%}
Here is the protocol stack for I2P.
See also the <a href="{{ docs }}">Index to Technical Documentation</a>.
{%- endtrans %}</p>

<p>{% trans -%}
Each of the layers in the stack provides extra capabilities.
The capabilities are listed below, starting at the bottom of the protocol stack.
{%- endtrans %}</p>
  <ul>
    <li>
        <b>{% trans %}Internet Layer:{% endtrans %}</b>
        <br />
        {% trans %}IP: Internet Protocol, allow addressing hosts on the regular internet and routing packets across the internet using best-effort delivery.{% endtrans %}
    </li>
    <li>
        <b>{% trans %}Transport Layer:{% endtrans %}</b>
        <br />
        {% trans %}TCP: Transmission Control Protocol, allow reliable, in-order delivery of packets across the internet.{% endtrans %}
        <br />
        {% trans %}UDP: User Datagram Protocol, allow unreliable, out-of-order delivery of packets across the internet.{% endtrans %}
    </li>
    <li>
{% trans -%}
<b>I2P Transport Layer:</b> provide encrypted connections between 2 I2P routers. These are not anonymous yet, this is strictly a hop-to-hop connection.
Two protocols are implemented to provide these capabilities. NTCP2 builds on top of TCP, while SSU uses UDP.
{%- endtrans %}
        <br />
        <a href="{{ spec_url('ntcp2') }}">NTCP2</a>: {% trans %}NIO-based TCP{% endtrans %}
        <br />
        <a href="{{ site_url('docs/transport/ssu') }}">SSU</a>: {% trans %}Secure Semi-reliable UDP{% endtrans %}
    </li>
    <li>
        {% trans %}<b>I2P Tunnel Layer:</b> provide full encrypted tunnel connections.{% endtrans %}
        <br />
{% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%}
<a href="{{ tunnelmessage }}">Tunnel messages</a>: tunnel messages are large messages containing encrypted I2NP (see below) messages and encrypted instructions for their delivery.
The encryption is layered. The first hop will decrypt the tunnel message and read a part. Another part can still be encrypted (with another key),
so it will be forwarded.
{%- endtrans %}
        <br />
{% trans i2np=site_url('docs/protocol/i2np') -%}
<a href="{{ i2np }}">I2NP messages</a>: I2P Network Protocol messages are used to pass messages through multiple routers. These I2NP messages are combined in tunnel messages.
{%- endtrans %}
    </li>
    <li>
        {% trans %}<b>I2P Garlic Layer:</b> provide encrypted and anonymous end-to-end I2P message delivery.{% endtrans %}
        <br />
{% trans i2np=site_url('docs/protocol/i2np') -%}
<a href="{{ i2np }}">I2NP messages</a>: I2P Network Protocol messages are wrapped in each other and used to ensure encryption between two tunnels and are passed along from source to destination, keeping both anonymous.
{%- endtrans %}
    </li>
</ul>

<p>{% trans -%}
The following layers are strictly speaking no longer part of the I2P Protocol stack, they are not part of the core 'I2P router' functionality.
However, each of these layers adds additional functionality, to allow applications simple and convenient I2P usage.
{%- endtrans %}</p>
<ul>
    <li>
        {% trans %}<b>I2P Client Layer:</b> allow any client to use I2P functionality, without requiring the direct use of the router API.{% endtrans %}
        <br />
{% trans i2cp=site_url('docs/protocol/i2cp') -%}
<a href="{{ i2cp }}">I2CP</a>: I2P Client Protocol, allows secure and asynchronous messaging over I2P by communicating messages over the I2CP TCP socket.
{%- endtrans %}
    </li>
    <li>
        {% trans %}<b>I2P End-to-end Transport Layer:</b> allow TCP- or UDP-like functionality on top of I2P.{% endtrans %}
        <br />
{% trans streaming=site_url('docs/api/streaming') -%}
<a href="{{ streaming }}">Streaming Library</a>: an implementation of TCP-like streams over I2P. This allows easier porting of existing applications to I2P.
{%- endtrans %}
        <br />
{% trans datagrams=site_url('docs/spec/datagrams') -%}
<a href="{{ datagrams }}">Datagram Library</a>: an implementation of UDP-like messages over I2P. This allows easier porting of existing applications to I2P.
{%- endtrans %}
    </li>
    <li>
        {% trans %}<b>I2P Application Interface Layer:</b> additional (optional) libraries allowing easier implementations on top of I2P.{% endtrans %}
        <br />
        <a href="{{ site_url('docs/api/i2ptunnel') }}">I2PTunnel</a>
        <br />
        <a href="{{ site_url('docs/api/samv3') }}">SAMv3</a>
    </li>
    <li>
        {% trans %}<b>I2P Application Proxy Layer:</b> proxy systems.{% endtrans %}
        <br />
        {% trans socks=site_url('docs/api/socks') %}HTTP Client/Server, IRC Client, <a href="{{ socks }}">SOCKS</a>, Streamr{% endtrans %}
    </li>
  </ul>

<p>{% trans -%}
Finally, what could be considered the <b>'I2P application layer'</b>, is a large number of applications on top of I2P.
We can order this based on the I2P stack layer they use.
{%- endtrans %}</p>
<ul>
    <li>{% trans %}<b>Streaming/datagram applications</b>: i2psnark, Syndie, i2phex...{% endtrans %}</li>
    <li>{% trans %}<b>SAM applications</b>: IMule, i2p-bt...{% endtrans %}</li>
    <li>{% trans plugins=site_url('docs/plugins') %}<b>Other I2P applications</b>: Syndie, EepGet, <a href="{{ plugins }}">plugins</a>...{% endtrans %}</li>
    <li>{% trans %}<b>Regular applications</b>: Jetty, Apache, Git, browsers, e-mail...{% endtrans %}</li>
</ul>

    <div class="box" style="text-align:center;">
        <img src="{{ url_for('static', filename='images/protocol_stack.png') }}" alt="{{ _('I2P Network stack') }}" title="{{ _('I2P Network stack') }}" />
        <br /><br />
        {% trans %}Figure 1: The layers in the I2P Network stack.{% endtrans %}
    </div>
<br/>

<p>
* {% trans %}Note: SAM can use both the streaming lib and datagrams.{% endtrans %}
</p>

{% endblock %}