...在协商完成后，将为 PPP 链路的末端选择不同的接口标识符值。

换句话说，当协商完成时，链路的两端必须以 64 位接口标识符的两个不同值结束。IOW，PPP 链路的“客户端 1”端不可能以 0x1122334455667788 的标识符结束，而“虚拟接口 1”端也以 0x1122334455667788 结束。因为如果发生这种情况，这意味着“客户端 1”端的 IPv6 链路本地地址将与“虚拟接口 1”端的 IPv6 链路本地地址相同——这显然是一件坏事。

RFC 讨论了如何生成“暂定接口标识符”（从本地物理 MAC 地址、机器序列号等）。如果您的系统的两端（例如“客户端 1”和“虚拟接口 1”）能够正确执行此操作，以保证它们的“暂定接口标识符”是唯一的，那么协商将顺利进行，每一端都 ACKing对方的标识符。否则，一端（例如“客户端 1”）可以向另一端（“虚拟接口 1”）发送值 0，然后由另一端负责为另一端分配标识符。

假设 2

这个假设已经是错误的：

如果您有一个网络地址为 192.168.123.x 的本地 IPv4 网络，并且您通过 VPN 连接了一些计算机，这些计算机将被分配一个在此范围内的 IPv4 地址，并且 VPN 完全按照您描述的方式工作。

使用 IPv6 的计算机可能有不同的 IPv6 地址：

• 链接本地地址（如 FE80::1234）
• 可选的本地地址（如 FD12:3456::1234）
• 用于 Internet 访问的可选全局地址（如 2001:DB8::1234）

编写 VPN 软件有两种可能性：

• 您的软件使用自己的子网

  在这种情况下，通过 VPN 连接的计算机的地址范围与网络的地址范围不同。

  与 IPv4 相比，这意味着：通过 VPN 连接的计算机的地址为 192.168.45.x，而实际网络的地址范围为 192.168.123.x（网络掩码 255.255.255.0）。

  ...具有您在 IPv4 方案中的所有优点和缺点。

  示例：只有知道网络 192.168.45.x 和 192.168.123.x 之间的路由器时，才能访问网络打印机。如果配置不知道路由器，则连接将失败。

• 您的软件为每个 PPP 客户端模拟一个以太网卡

  在这种情况下，每台计算机的接口标识符必须是唯一的（在所有 PPP 客户端和以太网中的所有计算机中）。

  您还必须专门处理一些 ICMPv6/IPv6 数据包（例如那些替换 IPv4 的 ARP 协议的数据包）。

• 两者的混合也是可能的：

  PPP 客户端使用仅对 PPP 链接有效的链接本地地址，但它们使用与以太网计算机相同的子网中的本地和全局地址。

  实施这也将是一些挑战......

编辑

我实际上选择了第二种选择。

据我所知，RFC 假设使用了第一个选项。因此，无论如何您都不会真正符合 RFC。

...如果我应该根据 RFC 在这种情况下为每个客户端协商第二个 IID ...

RFC 中这句话的唯一背景是计算机的本地链路 IPv6 地址是根据其 IID 计算的。如果 PPP 链路的两端具有相同的 IID，则两端将具有相同的 IP 地址！

但是，您的 VPN 服务器应该只有一个链接本地 IP 地址。因此，所有 PPP 链路最好使用服务器真实网卡的 IID。（请注意，许多操作系统不使用 MAC 地址，而是使用随机数作为 IID。）

如果您使用不同的 IID，服务器将有多个 IPv6 地址！

不幸的是，在某些操作系统下，PPP 首先“声称”一些随机IID。如果您的网卡意外地具有与客户端声称的 IID 相同的 IID，则您必须使用不同的 IID（因此需要第二个 IPv6 地址 - 尽管您必须强制客户端使用另一个 IID）。

编辑 2

我不确定是否可以强制 PPP 链接的另一端使用某个 IID。我也不确定 PPP 堆栈是否允许发送任何本地链路地址，或者它是否只允许两端的两个 IPv6 地址。

如果没有给出这两个条件之一，当您的 VPN 服务器应该与“标准”PPP 客户端（不是您编写的软件）一起工作时，这将是“第二个选项”的“杀手”。

至少在 Linux 下两者都可以工作。