As briefly explained in the intro, I2P builds virtual "tunnels" - temporary and unidirectional paths through a sequence of routers. These tunnels can be categorized as either inbound tunnels (where everything given to it goes towards the creator of the tunnel) and outbound tunnels (where the tunnel creator shoves messages away from them). When Alice wants to send a message to Bob, she will (typically) send it out one of her existing outbound tunnels with instructions for that tunnel's endpoint to forward it to the gateway router for one of Bob's current inbound tunnels, which in turn passes it to Bob.
Routers performing the three roles (gateway, endpoint, participant) are given different pieces of data to accomplish their tasks:
In addition, there are a series of options that the creator of a tunnel sends when requesting a router to join a tunnel, such as the expiration date. In I2P 3.0, options specifying the pooling, mixing, and chaff generation settings will be honored, and limits on the quantity and size of messages allowed during the tunnel's lifetime will be implemented earlier (e.g. no more than 300 messages or 1MB per minute).
As mentioned above, each client requests that their router provide tunnels to include at least a certain number of hops (plus other criteria that aren't honored yet, such as bandwidth limits, etc). The decision as to how many routers to have in one's outbound and inbound tunnels has an important effect upon the latency, throughput, reliability, and anonymity provided by I2P - the more peers that messages have to go through, the longer it takes to get there and the more likely that one of those routers will fail prematurely. The less routers in a tunnel, the easier it is for an adversary to mount traffic analysis attacks and pierce someone's anonymity.
With no remote routers in a tunnel, the user has very basic plausible deniability (since no one knows for sure that the peer that sent them the message wasn't simply just forwarding it on as part of the tunnel). However, it would be fairly easy to mount a statistical analysis attack and notice that messages targeting a specific destination are always sent through a single gateway. Statistical analysis against outbound 0-hop tunnels are more complex, but could show similar information (though would be slightly harder to mount)
With only one remote router in a tunnel, the user has both plausible deniability and basic anonymity, as long as they are not up against an internal adversary (as described on threat model). However, if the adversary ran a sufficient number of routers such that the single remote router in the tunnel is often one of those compromised ones, they would be able to mount the above statistical traffic analysis attack.
With two or more remote routers in a tunnel, the costs of mounting the traffic analysis attack increases, since all remote routers would have to be compromised to mount it.
The router will by default use 2-hop tunnels, at least in the main distribution. Prior to the 0.2.5 release, all tunnels were 1-hop by default.
[explain tunnel pools, how we keep a free inbound pool, an outbound pool, and a client inbound pool, and how the pools are refreshed every minute or so, using the router's default settings]
All tunnels are periodically tested by their creator by sending a DeliveryStatusMessage out the tunnel and bound for another inbound tunnel (testing both tunnels at once). If either fails, both are marked as no longer functional, and if they were used for a client's inbound tunnel, a new leaseSet is created. Other techniques can be used to test tunnels later on, such as garlic wrapping a number of tests into cloves, testing individual tunnel participants separately (and using the tunnel configuration key to update the next hop to work around failures), etc, but that is not implemented at the moment.
Tunnel creation is handled by garlic routing a TunnelCreateMessage to a router, requesting that they participate in the tunnel (providing them with all of the appropriate information, as above, along with a certificate, which right now is a 'null' cert, but will support hashcash or other non-free certificates when necessary). The message also includes a SourceRouteReplyBlock, which allows the router to encrypt their TunnelCreateStatusMessage into a SourceRouteReplyMessage, which is sent to another router (specified in the SourceRouteReplyBlock), who then decrypts the rest of the SourceRouteReplyBlock, reads out the delivery instructions contained therein, and forwards the TunnelCreateStatusMessage accordingly. (the delivery instructions can specify delivery to a specific router or can point at a tunnel)