注意
网络部署和测试正在进行中。 可能会有轻微修订。
概述
此提案旨在对SSU和NTCP2传输进行IPv6增强。
动机
随着全球IPv6的增长和IPv6-only设置（尤其是在移动设备上）的变得越来越普遍， 我们需要改进我们对IPv6的支持，并消除所有路由器具备IPv4能力的假设。
连接性检查
在选择隧道对等体或选择用于路由消息的OBEP/IBGW路径时， 计算路由器A是否可以连接到路由器B是有帮助的。 一般来说，这意味着要确定A是否具备匹配B所宣传的入站地址之一的传输和地址类型（IPv4/IPv6）的出站能力。
然而，在很多情况下，我们不知道A的能力，只能做出假设。 如果A是隐藏的或防火墙后面的，地址未被公布，我们没有直接的了解， 所以我们假设它具有IPv4能力，而不具有IPv6能力。 解决方案是为路由器信息增加两个新的“能力”来指示IPv4和IPv6的出站能力。
IPv6介绍器
我们的SSU 和 SSU-SPEC 规范在IPv4引介的IPv6介绍器支持方面存在错误和不一致。 无论如何，这在Java I2P或i2pd中从未实现过。 这需要得到纠正。
IPv6引介
我们的SSU 和 SSU-SPEC 规范清楚地表明不支持IPv6引介。 这是假设IPv6从不被防火墙保护。 这显然是不正确的，我们需要改进对防火墙后的IPv6路由器的支持。
引介图
图例：—– 是IPv4，====== 是IPv6
当前仅IPv4：
Alice Bob Charlie
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
Data <--------------------------------------------------> Data
IPv4引介，IPv6介绍器
Alice Bob Charlie
RelayRequest ======================>
<============== RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
Data <--------------------------------------------------> Data
IPv6引介，IPv6介绍器
Alice Bob Charlie
RelayRequest ======================>
<============== RelayResponse RelayIntro ===========>
<============================================ HolePunch
SessionRequest ============================================>
<============================================ SessionCreated
SessionConfirmed ==========================================>
Data <==================================================> Data
IPv6引介，IPv4介绍器
Alice Bob Charlie
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ===========>
<============================================ HolePunch
SessionRequest ============================================>
<============================================ SessionCreated
SessionConfirmed ==========================================>
Data <==================================================> Data
设计
将实施三个变化。
- 在路由器地址能力中添加“4”和“6”能力，以指示出站IPv4和IPv6支持
- 添加通过IPv6介绍器进行IPv4引介的支持
- 添加通过IPv4和IPv6介绍器进行IPv6引介的支持
规范
4/6能力
这最初是在没有正式提案的情况下实施的，但对IPv6引介是必需的，因此我们在这里包括它。 另见CAPS。
定义两个新能力“4”和“6”。 这些新能力将被添加到路由器地址的“caps”属性中，而不是路由器信息能力中。 目前我们没为NTCP2定义“caps”属性。 带有介绍器的SSU地址目前，按定义，是ipv4。我们完全不支持ipv6引介。 但是，该提案与IPv6引介兼容。见下文。
另外，路由器可能支持通过覆盖网络（如I2P-over-Yggdrasil）的连接， 但不希望公开一个地址，或者该地址没有标准的IPv4或IPv6格式。 这个新能力系统应该足够灵活，以支持这些网络。
我们定义以下更改：
NTCP2: 添加“caps”属性
SSU: 添加支持没有主机或介绍器的路由器地址，以指示对IPv4、IPv6或两者的出站支持。
两个传输: 定义以下能力值：
- “4”: IPv4支持
- “6”: IPv6支持
在单个地址中可以支持多个值。见下文。 如果路由器地址中未包含“host”值，则至少需要包含其中一个能力。 如果在路由器地址中包含“host”值，则至多一个能力是可选的。 将来可能会定义额外的传输能力，以指示对覆盖网络或其他连接方式的支持。
使用案例和例子
SSU:
SSU含host: 4/6可选，最大不超过一个。 例子: SSU caps=“4” host=“1.2.3.4” key=… port=“1234”
仅出站支持一，另一已发布: 仅需能力，4/6。 例子: SSU caps=“6”
SSU带有介绍器: 从不结合。需要4或6。 例子: SSU caps=“4” iexp0=… ihost0=… iport0=… itag0=… key=…
SSU隐藏: 仅需能力，4、6或46。允许多个。 无需两个地址，一个4一个6。 例子: SSU caps=“46”
NTCP2:
NTCP2含host: 4/6可选，最大不超过一个。 例子: NTCP2 caps=“4” host=“1.2.3.4” i=… port=“1234” s=… v=“2”
仅出站支持一，另一已发布: 能力、s、v 仅需，4/6/y，允许多个。 例子: NTCP2 caps=“6” i=… s=… v=“2”
NTCP2隐藏: 能力、s、v 仅需4/6，允许多个 无需两个地址，一个4一个6。 例子: NTCP2 caps=“46” i=… s=… v=“2”
IPv4的IPv6介绍器
为纠正规规范中的错误和不一致，所需进行的更改如下。 我们也将其描述为提案的“第一部分”。
规范更改
SSU 目前表示（IPv6备注）：
IPv6自版本0.9.8支持。发布的中继地址可以是IPv4或IPv6，Alice-Bob通信可以通过IPv4或IPv6进行。
添加如下内容：
虽然规范从版本0.9.8起已更改，但Alice-Bob通过IPv6的通信实际上直到版本0.9.50才得到支持。 旧版本的Java路由器错误地为IPv6地址发布了“C”能力， 即使它们实际上没有通过IPv6充当介绍器。 因此，路由器应仅信任0.9.50或更高版本的路由器的IPv6地址上的“C”能力。
SSU-SPEC 目前表示（中继请求）：
仅当IP地址可能不同于数据包的源地址和端口时才会包含IP地址。 在当前实现中，IP长度始终为0，端口始终为0， 接收方应使用数据包的源地址和端口。 此消息可以通过IPv4或IPv6发送。如果为IPv6，Alice必须包含她的IPv4地址和端口。
添加如下内容：
要通过IPv6发送此消息时引介IPv4地址，必须包含IP和端口。 此功能在版本0.9.50中支持。
IPv6引介
所有三个SSU中继消息（中继请求、中继响应和中继引介）都包含IP长度字段 以指示要跟随的（Alice、Bob或Charlie）IP地址的长度。
因此，不需要更改消息格式。 仅对规范进行文本更改，指示允许使用16字节的IP地址。
以下更改需要进行。 我们也将其描述为提案的“第二部分”。
规范更改
SSU 目前表示（IPv6备注）：
Bob-Charlie和Alice-Charlie通信仅通过IPv4进行。
SSU-SPEC 目前表示（中继请求）：
没有计划实施IPv6的中继。
更改为：
自版本0.9.xx起，支持IPv6的中继。
SSU-SPEC 目前表示（中继响应）：
Charlie的IP地址必须是IPv4，因为Alice将通过该地址在洞穿后发送SessionRequest。 没有计划实施IPv6的中继。
更改为：
Charlie的IP地址可能是IPv4，或者自版本0.9.xx起为IPv6。 Alice将在洞穿后通过该地址发送SessionRequest。 自版本0.9.xx起，支持IPv6的中继。
SSU-SPEC 目前表示（中继引介）：
Alice的IP地址在当前实现中始终为4字节，因为Alice试图通过IPv4连接到Charlie。 此消息必须通过建立的IPv4连接发送， 因为那是Bob知道要在中继响应中返回给Alice的Charlie的IPv4地址的唯一方法。
更改为：
对于IPv4，Alice的IP地址始终为4字节，因为Alice试图通过IPv4连接到Charlie。 自版本0.9.xx起，支持IPv6，Alice的IP地址可能为16字节。
对于IPv4，此消息必须通过建立的IPv4连接发送， 因为那是Bob知道要在中继响应中返回给Alice的Charlie的IPv4地址的唯一方法。 自版本0.9.xx起，支持IPv6，此消息可以通过建立的IPv6连接发送。
另外添加：
自版本0.9.xx起，所有带有介绍器且发布的SSU地址必须在“caps”选项中包含“4”或“6”。
迁移
所有旧路由器应忽略NTCP2中的caps属性，以及SSU caps属性中的未知能力字符。
任何不包含“4”或“6”cap的介绍器SSU地址被认为是用于IPv4引介。