IPv6对/ 64进行子网划分-什么会中断,以及如何解决?


27

在IPv6中,不应将子网划分为小于/ 64(RFC 5375)的任何子网。除其他外,SLAAC不适用于较小的子网,并且显然其他一些功能也会中断。

对于ISP仅给您一个/ 64但内部需要多个子网的情况,有哪些解决方法?常见的建议似乎是找到另一个将分发/ 56或/ 48的ISP。在世界某些地区,这可能会奏效,但在我们所在的地区(美国),由于缺乏竞争,这是不可行的。我的大多数客户都很幸运,如果他们有一个ISP为其区域提供服务。这里许多人仍在拨号。

我的客户没有资格获得ARIN自己的/ 48。


9
在那种情况下,我不会尝试部署IPv6。继续向ISP加压以提供适当的连接。如有必要,使他们的错误非常明显并公开。引用RFC 6177中的章节。当然,您首先应该确保这他们的错,并且您的设备正在请求更大的子网。
迈克尔·汉普顿

5
这也是个坏建议。鉴于其所有优点,大多数人应该在第一个可用的机会上部署IPv6。不幸的是,许多ISP都对其IPv6服务完全dog之以鼻,使其使用不明智。
迈克尔·汉普顿

2
我们可能会整天争论到底是ISP用它做狗的早餐(他们确实做到了!),还是IPv6设计人员认为ISP 会这样做是不现实的。当然,我不会告诉我的客户永远不要离开IPv6,直到尘埃落定。我敢肯定,从现在甚至更早五年后,将会有一个支持较小子网的SLAAC 2.0和NAT(无论如何,许多路由器已经实现了它),以及在逆境中使IPv6正常工作所需的所有其他功能。不过,我更多地是在寻找即时解决方案。
凯文·基恩2015年

4
不要指望像NAT这样的IPv4混乱与IPv6一起正常工作。NAT是一个hack,不是一个功能……
Sander Steffann 2015年

3
@KevinKeane NAT一直都是黑客,而且永远都是。人们尝试使用NAT解决的每个问题都有一个真正的解决方案,该解决方案不涉及NAT,但是可能涉及IPv6。您所说的绝大部分故障都可归因于NAT或IPv6部署不完整。
卡巴斯德(Kasperd),2015年

Answers:


28

如果ISP不会给您超过/ 64的价格,那么该ISP很烂。如果可以解决的话,我可以告诉您,我必须面对比这更糟的ISP。在这附近,将公共IPv4地址从客户那里拿走并将它们放在CGN之后是完全正常的。如果您要求他们提供IPv6地址,他们会告诉您他们不提供IPv6,因为目前还没有IPv4地址,并且只要有不支持IPv6的服务器,它们就不会提供IPv6,因为双堆栈客户端以连接到仅IPv4的服务器。

如果有任何ISP会给我您所拥有的,我会选择它,因为它比我到目前为止所能获得的要少。

继续前进,我建议您同时采用两种方法。

向ISP施加压力

尽可能给ISP施加压力。这包括联系其他ISP,并可能在其他ISP可以为您提供更好的服务时进行切换。

确保您确实测试了如果路由器通过WAN上的DHCPv6请求委托的/ 48,/ 52,/ 56或/ 60会发生什么情况。我将测试所有四个前缀长度,以防万一DHCPv6服务器由于某种原因只会发出特定的前缀长度而忽略其他前缀长度的请求。

充分利用自己所拥有的

鉴于您可能将不得不面对一些不断发展的黑客攻击,因此您必须问问自己,哪些受黑客攻击的IPv4少,或受黑客攻击的IPv6少。

您可以使用一些技巧将一个/ 64扩展到很多主机。

将链接前缀转换为路由前缀

如果您在WAN链接上只有一个/ 64,但没有前缀路由到您的LAN,则可以通过几个步骤将该/ 64转换为路由前缀。在路由器上将WAN接口配置为/ 126而不是/ 64。在路由器上安装邻居通告守护程序(例如ndppd),以为/ 64中的每个地址(/ 126中的4个地址除外)通告其自己的MAC地址。通过这两个步骤,您将获得一个路由/ 64,除了用于WAN链接的4个地址外,您可以在您的LAN上使用它。

此hack的修改后的版本可以在多个路由器之间共享链接/ 64。然后,链接前缀必须比/ 126短一点,以容纳每个路由器的IP地址,/ 120则足够短,最多可容纳254个路由器。

每个路由器显然只会获得比/ 64长的前缀。我建议您尽可能为每个路由器添加前缀,同时仍要为该路由器上的LAN保留足够的IP地址。每个路由器的/ 112或/ 120可能是合适的。每个路由器都用自己的MAC地址进行响应,以便邻居发现该路由器前缀内的任何内容。

在此变体中,每个路由器将在其WAN端配置相同的前缀,并将响应邻居发现请求以分配给其LAN端的前缀。显然,没有一个局域网前缀可以相互重叠,也可以不与您在WAN端配置的前缀重叠。

因此,如果充当网关的ISP路由器位于地址2001:db8 :: 1/64上,则可以将2001:db8 :: / 120用作WAN,并且可以将2001:db8 :: 1:0/112分配给第一个路由器2001:db8 :: 2:0/112到第二个路由器,依此类推。

在LAN上,您可以通过子网划分或桥接将/ 64扩展到许多主机。您必须确定两者中哪一个最适合您。

子网划分

如果您将/ 64划分为子网,则最好使用最长的前缀,该前缀仍具有足够的地址供您需要的主机使用。不要将子网划分为/ 80前缀,而是每个子网使用/ 116,/ 120或/ 124。如果您不使用/ 64,那会破裂的事情不太可能在乎,通过使用/ 116或更长的时间,您将减少某些邻居发现DoS攻击(如果存在于您的任何系统中)的影响。

在这样的子网配置中,您将破坏SLAAC,因此需要DHCPv6服务器在每个段上做出响应,并在所有不支持DHCPv6的设备上配置静态IPv6地址。

桥接

桥接是另一种选择。从本质上讲,这意味着您不进行子网划分,而是将整个LAN作为带有/ 64前缀的单个IPv6网段运行。(应该,/ 64可以同时覆盖LAN和WAN。)

IPv6旨在允许网桥识别每个任意播地址都需要转发到哪个网桥网络。这样,您就不必在LAN的每个物理链路上广播数据包。

桥接器还可以应用防火墙并防止LAN上的邻居发现欺骗。

只要桥上具有足够的智能,原则上就可以跨一个/ 64桥接多少个交换机没有限制。


谢谢!那正是我在寻找的答案!我特别喜欢您将/ 64转换为路由前缀的想法。请您详细说明一下吗?首先,我不明白您为什么建议使用/ 126,而不是/ 127?哪些IP地址在哪里使用?其次,在我的一位客户中,我实际上有三个独立的内部路由器。在IPv4中,它们在ISP提供的/ 29中具有三个不同的公共IP。您的方案仍可与这些路由器一起使用吗?
凯文·基恩

另外,我不确定如何在任何路由器上安装邻居广告守护程序。一台路由器是Fortigate,一台是Belkin,第三台是Linksys。
凯文·基恩

@KevinKeane我建议使用/ 126的原因是,您通常经常需要在前缀内至少包含三个地址。在ISP端,路由器的前缀可能配置为2001:db8 :: 1/64,这意味着2001:db8 ::是特殊的,而2001:db8 :: 1被ISP路由器使用。您自己的路由器通常将配置为2001:db8 :: 2,这意味着您随后使用了三个地址,而/ 127将不足。如果您没有使用链接两端配置了不同前缀长度的技巧,则/ 127可能会起作用。
卡巴斯德(Kasperd),2015年

感谢您的解释!因此,当我有三个服务于三个不同内部网络的路由器时,我应该使用/ 125,并且每个路由器都将通过邻居通告仅针对相应子网中的IP通告自己的MAC?
凯文·基恩

1
有一个信息RFC,RFC 7421,《 IPv6寻址中的64位边界分析》,其中完整讨论了/64子网以及不使用子网时出了什么问题。
罗恩·莫平

10

是的,最好不要让您的ISP感到不舒服。RIR分配策略假定ISP为每个客户分配了/ 48;ISP完全没有理由这样做。

IPv6并不是较小子网的支持者,但是我所知,唯一应该打破的是SLAAC。您会在某些IPv6堆栈中遇到错误和假设的问题,这些错误和假设只是盲目地假设为“ / 64 == subnet”,但这是一个错误,而不是功能,您可以殴打供应商进行修复。另一方面,在您的ISP给您提供/ 48之前,它是否已固定...


我认为邻居发现协议的某些部分也应该中断。RFC 5375包含其他内容的完整列表,但我真的不知道实际含义。仅获得/ 64有时可能只是金钱问题。您的ISP可能仅向家庭用户提供/ 64,而仅将/ 48s提供给企业帐户。仅仅是因为您要将家庭办公室或WiFi与家庭其他地方分开,还是因为您想将单独的子网用于虚拟机?对不起,我在这里要解决一个问题,而不是试图改变我无法控制的事情。
凯文·基恩

2
如果您的ISP希望成为一个棘手的问题,他们会向每个住宅用户分发/ 128。我猜你可以在ISP上通过RFC 5375并告诉他们给您IPv6,而不是IPv5.5 ...
womble

实际上,我知道至少有一个ISP可以做到这一点(Verizon Wireless)。这是我认为IPv6仍需要NAT的原因之一。但这当然是与我的问题分开的。
凯文·基恩

1
RFC 3177中的/ 48建议不再有效,现在大多数RIR都建议针对最终站点使用/ 56,如RFC 6177中所述:tools.ietf.org/html/rfc6177
skrause

@skrause无论如何,这并不重要。有足够的/ 48,它们不会用完。即使以80%的高清比率,在IANA消耗掉2000 :: / 3的全部时间之前,也将需要分配2 ^ 36 / 48s。并且,除非您的最终站点是主要的数据中心,否则/ 56拥有足够的子网用于您的最终站点。
卡巴斯德(Kasperd),2015年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.