注意：本文档包含关于 I2P 当前 tunnel 实现替代方案的旧信息，以及对未来可能性的推测。有关当前信息请参见 tunnel 页面 。
该页面记录了版本 0.6.1.10 中当前的 tunnel 构建实现。在版本 0.6.1.10 之前使用的旧 tunnel 构建方法记录在旧 tunnel 页面 中。
配置替代方案
除了长度之外，每个 tunnel 可能还有其他可配置的参数可以使用，例如对传输消息频率的限制、如何使用填充、tunnel 应该运行多长时间、是否注入干扰消息，以及应该采用什么批处理策略（如果有的话）。这些功能目前都还未实现。
填充替代方案
有几种 tunnel 填充策略可供选择，每种都有其自身的优点：
- 无填充
- 填充到随机大小
- 填充到固定大小
- 填充到最接近的KB
- 填充到最接近的指数大小（2^n字节）
这些填充策略可以在多个层面使用，解决向不同对手暴露消息大小信息的问题。在收集和审查了0.4网络的一些统计数据，以及探索匿名性权衡之后，我们开始使用1024字节的固定tunnel消息大小。然而，在此范围内，分片消息本身完全不会被tunnel填充（尽管对于端到端消息，它们可能会作为garlic包装的一部分被填充）。
分片替代方案
为了防止对手通过调整消息大小在传输路径上标记消息，所有tunnel消息都具有固定的1024字节大小。为了适应更大的I2NP消息以及更有效地支持较小的消息，gateway将较大的I2NP消息分割成片段，包含在每个tunnel消息中。endpoint将在短时间内尝试从片段重建I2NP消息，但会根据需要丢弃它们。
Router 在片段排列方面有很大的灵活性，无论是将它们低效地作为离散单元填充，还是短暂批处理以便将更多有效载荷装入1024字节的 tunnel 消息中，或者机会性地用网关想要发送的其他消息进行填充。
更多替代方案
中途调整隧道处理
虽然简单的tunnel路由算法对于大多数情况应该是足够的，但还有三种可以探索的替代方案：
- 让除端点之外的其他对等节点临时充当tunnel的终止点，通过调整网关处使用的加密来为其提供预处理I2NP消息的明文。每个对等节点都可以检查它们是否拥有明文，在接收到消息时像拥有明文一样处理消息。
- 允许参与tunnel的router在转发消息之前重新混合消息 - 通过该对等节点自己的出站tunnel之一进行反弹，携带传递到下一跳的指令。
- 实现代码让tunnel创建者重新定义对等节点在tunnel中的"下一跳"，允许进一步的动态重定向。
使用双向 Tunnel
当前使用两个独立tunnel分别处理入站和出站通信的策略并不是唯一可用的技术，而且确实会产生匿名性影响。从积极的一面来看，通过使用独立的tunnel，它减少了暴露给tunnel参与者进行分析的流量数据——例如，来自网页浏览器的出站tunnel中的对等节点只会看到HTTP GET的流量，而入站tunnel中的对等节点则会看到沿tunnel传输的有效载荷。使用双向tunnel时，所有参与者都能够获知例如某个方向发送了1KB数据，然后另一个方向发送了100KB数据这样的事实。从消极的一面来看，使用单向tunnel意味着需要分析和处理两组对等节点，并且必须格外小心以应对前驱攻击速度的增加。下文概述的tunnel池化和构建过程应该能最大程度地减少对前驱攻击的担忧，不过如果需要的话，在相同的对等节点上构建入站和出站tunnel也不会有太大困难。
反向信道通信
目前，使用的 IV 值是随机值。然而，这个 16 字节的值有可能被用来从网关向端点发送控制消息，或者在出站 tunnel 中，从网关向任何对等节点发送控制消息。入站网关可以在 IV 中编码某些值一次，端点能够恢复这些值（因为它知道端点也是创建者）。对于出站 tunnel，创建者可以在 tunnel 创建期间向参与者传递某些值（例如"如果你看到 0x0 作为 IV，那意味着 X"，“0x1 意味着 Y”，等等）。由于出站 tunnel 上的网关也是创建者，他们可以构建一个 IV，使任何对等节点都能接收到正确的值。tunnel 创建者甚至可以给入站 tunnel 网关一系列 IV 值，该网关可以使用这些值与各个参与者进行恰好一次的通信（尽管这在共谋检测方面会有问题）。
这种技术以后可以用来在流中间传递消息，或者允许入站网关告知端点它正在受到DoS攻击或即将出现其他故障。目前，还没有利用这个反向通道的计划。
可变大小 Tunnel 消息
虽然传输层可能有其自己的固定或可变消息大小，使用其自己的分片机制，但 tunnel 层可能会使用可变大小的 tunnel 消息。这种差异是威胁模型的问题 - 传输层的固定大小有助于减少暴露给外部对手的信息（尽管整体流量分析仍然有效），但对于内部对手（即 tunnel 参与者）来说，消息大小是暴露的。固定大小的 tunnel 消息有助于减少暴露给 tunnel 参与者的信息，但不能隐藏暴露给 tunnel 端点和网关的信息。固定大小的端到端消息隐藏了暴露给网络中所有对等节点的信息。
如往常一样，这是一个关于I2P试图防范谁的问题。可变大小的tunnel消息是危险的，因为它们允许参与者使用消息大小本身作为与其他参与者的后门通道 - 例如，如果你看到一个1337字节的消息，你就和另一个串通的节点在同一个tunnel上。即使使用固定的允许大小集合（1024、2048、4096等），该后门通道仍然存在，因为节点可以使用每种大小的频率作为载体（例如，两个1024字节的消息后跟一个8192字节的消息）。较小的消息确实会产生标头开销（IV、tunnel ID、哈希部分等），但较大的固定大小消息要么增加延迟（由于批处理），要么显著增加开销（由于填充）。分片有助于分摊开销，但代价是由于丢失片段而可能丢失消息。
定时攻击在审查固定大小消息的有效性时也很重要，尽管它们需要对网络活动模式有大量观察才能生效。tunnel 中过度的人工延迟将被 tunnel 创建者通过定期测试检测到，导致整个 tunnel 被废弃，其中对等节点的配置文件也会被调整。
构建替代方案
旧的 Tunnel 构建方法
在 0.6.1.10 版本之前使用的旧 tunnel 构建方法记录在旧 tunnel 页面 中。这是一种"一次性全部"或"并行"方法，消息会并行发送给每个参与者。
一次性望远镜式构建
注意：这是当前方法。
关于使用探索隧道发送和接收隧道创建消息的一个问题是，这如何影响隧道对前驱攻击的脆弱性。虽然这些隧道的端点和网关将随机分布在网络中（甚至可能包括隧道创建者本身），但另一种替代方案是使用隧道路径本身来传递请求和响应，正如 Tor 中所做的那样。然而，这可能会在隧道创建过程中导致泄露，使对等节点能够通过监控隧道建立时的时序或数据包计数来发现隧道后续有多少跳。
“交互式"望远镜式构建
逐个构建跳点，每个跳点都通过tunnel现有部分发送消息。这种方法存在重大问题，因为对等节点可以通过计算消息数量来确定它们在tunnel中的位置。
用于管理的非探索性 Tunnel
tunnel建设过程的第二个替代方案是为router提供一组额外的非探索性入站和出站池，用于tunnel请求和响应。假设router对网络有良好的整合视图，这应该不是必需的，但如果router以某种方式被分区，使用非探索性池进行tunnel管理将减少关于哪些对等节点在router分区中的信息泄露。
探索性请求传递
第三种替代方案在I2P 0.6.1.10之前使用，对单个tunnel请求消息进行garlic encryption并单独传递给各个跳点，通过探索性tunnel传输这些消息，回复则通过单独的探索性tunnel返回。这种策略已被放弃，改用上述方案。
更多历史和讨论
在引入可变 tunnel 构建消息之前，至少存在两个问题：
- 消息的大小（由8跳的最大限制造成，而典型的tunnel长度是2或3跳… 当前研究表明超过3跳并不能增强匿名性）；
- 高构建失败率，特别是对于长（和探索性）tunnel，因为所有跳都必须同意，否则tunnel就会被丢弃。
VTBM 已修复问题 #1 并改进了问题 #2。
Welterde已提议对并行方法进行修改以允许重新配置。Sponge已提议使用某种形式的"令牌”。
任何学习tunnel构建的学生都必须研究导致当前方法的历史记录，特别是各种方法中可能存在的各种匿名性漏洞。2005年10月的邮件档案特别有帮助。如tunnel创建规范 中所述，当前策略是在I2P邮件列表上Michael Rogers、Matthew Toseland (toad)和jrandom之间关于前驱攻击的讨论中产生的。
节点排序替代方案
也可以使用不那么严格的排序，确保在A之后的跳点可能是B，但B永远不能在A之前。其他配置选项包括仅固定入站tunnel网关和出站tunnel端点的能力，或者按照MTBF（平均无故障时间）速率进行轮换。
混合/批处理
在网关和每个跳点应该使用什么策略来延迟、重新排序、重新路由或填充消息？这种操作应该在多大程度上自动完成，多少应该配置为每个 tunnel 或每个跳点的设置，tunnel 的创建者（以及用户）应该如何控制这种操作？所有这些都还是未知的，有待在未来的版本中解决。