我在一个提供单个IPv6 / 64块的colo提供程序。
目标是将提供的/ 64个IPv6地址路由到运行RouterOS 6.24的Mikrotik后面的主机。
一些Mikrotik的例子，我发现总是有用户获得一个/ 48或至less一个/ 64和另一个小块连接网关，或博客major.io描述的可能性，但不build议使用链接地址连接与上行路由器。
我没有访问这个，所以我试图另一种方式。
我曾经尝试的是网关端口上的路由器IPv6地址，作为/ 126块aaaa.bbbb.cccc.dddd :: 2/126与aaaa.bbbb.cccc.dddd :: 1/126处的上行链路路由器对话。
然后，我在防火墙后面的主端口上创build了另一个路由器IPv6地址，掩码为aaaa.bbbb.cccc.dddd：8000：1/65。 我还configuration了邻居发现，以便客户端可以自动configuration。
从路由器terminal，我能ping通互联网，并ping防火墙后的主机。 在主机上，我能ping通防火墙两侧的路由器地址，但不能在需要进入上行链路时ping通。
在另一个networking中，我可以ping防火墙前面的外部路由器地址，但是无法访问aaaa.bbbb.cccc.dddd：8000：1/65，该防火墙后面的主端口具有静态路由条目。 在testing过程中，我在防火墙中没有任何规则。
我的理论是错误的，还是在Microtik上使用这个模型有问题？
你需要让自己成为一个更好的颜色提供者。 对于路由基础设施，它们应该给予比64分配更多的分配。
这就是说，在正确实施的设备，没有必要使用一个完整/ 64子网，所以原则上你所描述的应该是可行的，模你的提供者正确设置，所有的设备是明智的（一些旧设备制造一些关于“每个子网是/ 64”的无理假设）和你的configuration是完全正确的。
不过，就你的情况而言，我会阅读你的colo供应商关于build议的IPv6部署实践的暴动，并从中获得适当的阻止。