在我的以前的帖子我写了所有我们从几乎不可思议的海量IPv6地址空间得到积极,都在那里给我们享受,如果我们只是摆脱我们长期以来根深蒂固的IPv4地址保护的心态。
我们最常看到的IPv4保守主义的不利影响的地方是在一个寻址点至点链接。我写了一篇关于我们如何能够被引入逻辑思维,因为我们没有把握,我们正在使用的规模:我们似乎都没有问题,在局域网上与5000点的地址,浪费了其他264-5000地址,但我们只是无法让自己浪费264-点对点链路上的地址。在1800万亿个地址的规模上,5000和2之间的差别是微不足道的。
我经常听到一个与子网地址大小问题相关的不合逻辑的问题:“为什么他们用了整个64位的接口id ?”为什么不是32位呢? 32位在子网中仍然可以提供比我们使用的更多的地址,而且还可以留给我们96位前缀。”
我的回答是:你为什么想知道?
这仍然只是一种无谓的浪费担忧。我们可以很容易地问为什么他们不把IPv6地址设置为64位,32位作为前缀(位置),32位作为接口id(身份)。在可预见的未来,可能仍然会有足够多的地址。你知道,如果IPv6地址是64位,就会有人问为什么他们不把接口设置为16位(65,536个地址对于任何子网来说都已经足够了),这样我们就可以有48位的前缀。
你是否看到了你担心地址浪费而陷入的困境?IPv6地址是128位,平均分为前缀和接口id,正是因为它给了我们比以往任何时候都可以使用可以想象更多的地址。设计师击中了地址枯竭的问题真的,真的大铁锤。与IPv4不同,没有期望,你将有效地使用所有的A / 64子网中可用的接口地址。
所以真的。别担心了。
有其他原因使用/ 127上的点至点的链接?
嗯,是有。
下面是一些背景:RFC 4291,第2.5.4节,明确指出IPv6接口-ID是/ 64对于所有全球单播地址。这并不是说“除非你担心,你是浪费的。”而只是为了让事情更清晰的乡亲都坚持使用上点至点链接/ 127S,我们有RFC 3627就在标题中,“在被认为有害的路由器之间使用/127前缀长度”。然后就来了RFC 6164上面写着使用上点至点链接/ 127前缀毕竟只是罚款和花花公子。事实上RFC 6547移动3627到历史(废弃)地位,取代6164。
困惑了吗?其实没那么复杂。
RFC 3627已过时有很好的理由
为RFC 3627的结论的主要理由是/ 127前缀是有害的,有做子网路由器选播地址。这些地址的前缀是完整的,但是接口id位都被设置为零。因此,该地址由前缀限定到特定的子网,但是地址的标识部分是未指定的。一个设备可以将数据包发送到子网路由器的任意地址,然后它们将被连接到子网的路由器拾取。RFC 4291要求路由器支持子网路由器Anycast地址;这个想法是,应用程序可以使用这个地址与子网上的“任意一个路由器”进行通信,尽管还不清楚为什么应用程序会使用这个Anycast而不是所有路由器的多播地址。
这里的场景,假设/ 127前缀是有害的:
- 您使用点对点链接连接两个路由器,RA和RB。
- 配置RA的接口与二零零一年地址:DB 8:1:2:A:B:C:127分之1。路由器的链接,这个地址上运行重复地址检测(DAD)和地址通过。
- RA,符合RFC 4291,增加了子网路由器任播地址2001:DB8:1:2:A:B:C:0/127。RFC 2462第5.4节,则指定DAD不为任播地址(这是有意义的,因为根据定义的任播地址可以驻留在多于一个的接口)上运行。因此,没有爸是运行这个地址。
- 现在你去RB,并为/ 127前缀配置其他地址:2001:DB8:1:2:A:B:C:0/127。请问路由器对象,它不能使用该地址为单播,因为它的子网路由器任播地址前缀?是否接受该地址,然后添加相同的地址作为其所需的子网路由器选播?如果是这样,并执行DAD,地址会失败,因为它已经是RA。
这听起来像一个大问题,但有几件事情知道
- 子网路由器选播,那样的模糊,因为它的目的似乎,显然是一个多路访问网络上使用。为什么它曾经点至点链路上使用?
- 尽管RFC 4291使得地址强制性的,但事实是,它是不是很广泛实施。即使RFC 3627,铺设了上述情况后,确认其没有在野外观测到。我已经配置了许多/ 127地址,尚未有问题的。
DAD是地址自动配置机制和邻居发现协议,这两者对点至点链接有限的实用性非常有用。保险的容易一点,如果你的路由器操作系统支持,是禁用DAD您点至点链接。如果您使用的是以太网点至点链接许多点至点技术,如SONET不使用NDP,但是,你可能会需要手动禁用NDP。
邻居缓存攻击
还有另外一个原因,确保NDP已在以太网点至点链接无效。如果链接是/ 64子网,攻击者可以发送数据包流与上属于链接的子网但有未使用的接口-ID的目的地址的链接。对于接收到的每一个地址,路由器创建在其邻居缓存的INCOMPLETE条目,并发送NDP邻居请求消息到链接来尝试解决该条目。通过流足够不同的未使用的地址,攻击者可能会导致邻居缓存才能填满,链接无法解答的NS消息拥塞。
RFC 6164引用此漏洞为理由,使用您点至点链接/ 127S。虽然这是真的,这将阻止这种特定的攻击(因为有对子网中没有未使用的地址),只要在您点至点链接禁用NDP还消除了漏洞。更重要的是,该漏洞存在于支持NDP任何子网,你不能在你的局域网子网禁用NDP。需要的ICMPv6速率限制和智能边缘过滤来控制邻居缓存攻击的影响。
更重要的原因引述RFC 6164使用/ 127S被暴露于乒乓攻击。
乒乓
乒乓攻击利用了较旧的ICMPv6实现与RFC 2463。这里的问题:
- 您使用点对点链接连接两个路由器,RA和RB。
- RA给出的地址2001:DB8:1:2 :: 1/64。
- RB给出的地址2001:DB8:1:2 :: 2/64。
- 分组到达RA与目的地址2001:DB8:1:2:3。
- 目的地是点对点链路的子网,但不是RA的接口地址。所以RA将数据包转发到链路中。平。
- RB接收该分组。
- 目标是为点至点链接的子网,而不是RB的地址,所以RB转发数据包返回到的链接。傍。
- RA接收分组,并且该循环重复其本身。
你可以看到这是如何被利用:攻击者洪水未使用的目标地址的数据包到子网,包来回反弹的两个路由器之间,直到他们的跳数限制到期。这些数据包的洪水不够 - 和A / 64提供批量的命中未使用的地址 -和弹跳包效果的电容效应会吃带宽和路由器资源。
有两件事情来观察这个行为:
- RA和RB不能确定目的地址是否属于子网中的现有设备,因为在大多数点至点链接没有邻居发现。
- 一个简单的水平分割规则会假设,如果你收到属于子网中,但不属于接收接口子网的数据包,没有必要转发数据包背出相同的接口。据推测,如果在子网中存在的目的地,它已经收到的数据包。
事实证明,这个漏洞存在于IPv4的也;它只是从来就没有多大风险,因为在IPv4上点至点链接大多数人都使用/ 30或/ 31子网,以保存地址。
RFC 4443淘汰了RFC 2463并在其3.1节明确要求路由器接收到数据包的目的地址属于接收接口的子网,但其接口-ID不属于接口,不能发送数据包背出相同的接口。问题解决了。
您的供应商运行过时的代码吗?
这个问题让我恼火的是,一些供应商更喜欢继续运行ICMPv6的过时版本,而不是将他们的代码升级到与RFC 4443兼容的ICMPv6。他们对这个问题的回答是告诉你在点对点链接上使用/127s。
IETF标准推荐使用/ 64子网无处不在。各地RIR支持你的跑步/ 64子网无处不在。那么,你会扰乱不错,你的IPv6地址设计的一贯简约,以适应谁不希望自己的现代化码的路由器供应商?或者是你要告诉您的供应商停止使用过时的代码?
你有几个选择来处理这个问题:
- 如果您运行的较旧的,“预RFC 4443”的Cisco IOS,升级到新的版本。思科支持RFC 4443。
- 在您的点对点链接上运行未编号的IPv6。对于许多操作人员来说,这不是一个好的解决方案,因为它使监视和跟踪复杂化。这也使得在链接上运行EBGP变得复杂。
- 阻止访问点至点子网中的任何不信任区域。你可能不希望您点至点接口的IP地址,从您的网络外部访问反正。
即使你采取“站起来,你的供应商”的方法,我建议,它会带他们一段时间来现代化。一个临时的解决方案,如果您有关于乒乓脆弱性的担忧,是分配/ 64个子网,每个点至点链接,但选择链接接口/ 127出/ 64和配置子网。这种方法可以让你缓解有关安全漏洞的紧迫问题,也可以让您以最小的网络中断更改/ 127子网到其相应/ 64S时,时间是正确的。
你将与你的地址的设计很长一段时间的生活。不要让一个供应商的短期懒惰破坏你的长期计划。