注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

汪涛

 
 
 

日志

 
 
关于我

南京邮电大学学士,北京邮电大学硕士。出版《生态社会人口论》(人民出版社),《通播网宣言》(北京邮电大学出版社) unsnet@163.com

网易考拉推荐
 
 

汪涛:IPv6重大缺陷之二——含混不清的地址空间设计  

2008-02-01 21:27:15|  分类: IPv6、IPv9和超级 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
    摘要:IPv6的地址空间并非人们想像的就是128位地址空间。由于特殊的地址结构设计,导致IPv6如果要真正实现128位地空间的话,本身要经历三个有重大差别的版本过渡,其有效地址空间分别为:

    47位有效地址空间的IPv06;

    64位有效地址空间的IPv16;

    128位有效地址空间的IPv26。

    三个版本之间的过渡如同要经历三次IPv4到IPv6的不同IP协议的过渡一样。认为IPv6可以为地球上每一粒沙子分配一个IP地址的说法也是很不科学的轻率之词。

    IPv6协议本身必然存在理论上不可完全消除的手工IP地址分配问题,这无疑也是让人难以理解的事情之一。

 

    IPv6除了需要全面更新设备和终端,成本极高,违反网络平滑升级的网络天条之外,还存在地址空间设计上的重大缺陷:

    IPv6地址有128位长度,人们普遍认为IPv6的地址空间就是128位。但事实上,由于IPv6地址结构设计上的特定方式,其地址空间并非如人们想像的就是128位空间。

    IPv6的地址设计是很特殊的,IPv6地址有很多分配给了一些特殊目的用途,如:

未指明地址                  ::

环回地址                    ::1

保留给NSAP分配的地址       前缀为0000 001

保留给IPX分配的地址        前缀为0000 010

嵌入IPv4的地址            ::x.x.x.x以及::FFFF:x.x.x.x

本地联接的地址              前缀为1111 1110 10

本地站点的地址              前缀为1111 1110 11

组播地址                    前缀为1111 1111

    除此之外,IPv6地址的主体是被称为“可聚合的全网单播地址”(The global aggregatable global unicast address),这些地址的前缀从001直到111。这种单播地址采用“子网前缀”加“接口ID”的基本模式,并且“可聚合的全网单播地址”采用子网前缀和接口ID各占64位的模式进行分配。

    IPv6版本最新的RFC2373中对此分配的细节如下:

   | 3|  13 | 8 |   24   |   16   |          64 bits               |

   +--+-----+---+--------+--------+--------------------------------+

   |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |

   |  | ID  |   |  ID    |  ID    |                                |

   +--+-----+---+--------+--------+--------------------------------+

   Where

      001          Format Prefix (3 bit) for Aggregatable Global

                   Unicast Addresses

      TLA ID       Top-Level Aggregation Identifier

      RES          Reserved for future use

      NLA ID       Next-Level Aggregation Identifier

      SLA ID       Site-Level Aggregation Identifier

      INTERFACE ID Interface Identifier

    这里面最大的蹊跷在于后面64位的接口ID。根据RFC2373附录A中对于如何获得接口ID的描述,IPv6设计上显然希望接口ID是全网唯一的。并且它最首选的方式就是采用现在最普及的IEEE 802的48位MAC地址。MAC地址是全网唯一的,生产商所生产的每一块网卡都被分配给了唯一的MAC地址。IPv6的接口ID通过在中间加上两个固定的字节“1111 1111 1111 1110”,并且将”u”比特设置为1来将MAC地址一一对应地转换为64位的接口ID。其中关键性的描述为:

The interface identifier would be of  the form:

  |0              1|1              3|3              4|4              6|

  |0              5|6              1|2              7|8              3|

  +----------------+----------------+----------------+----------------+

  |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|

  +----------------+----------------+----------------+----------------+

   When IEEE 802 48bit MAC addresses are available (on an interface or a

   node), an implementation should use them to create interface

   identifiers due to their availability and uniqueness properties.

    当然,就在附录A里也提供了如果只具有非全网唯一物理接口地址,以及没有物理地址情况下产生接口ID的方法。

    对于只具有非全网唯一物理地址的情况,是通过在前面填充0扩展到64位接口地址,在这种情况下要将u比特设置为0以表明它是本地而非全网的;

    对于没有物理地址的情况,可以采用三种方法来产生接口ID:

    手工配置;

    产生一个随机数字;

    利用节点的序号。

    并且在这里强烈推荐采用冲突检测的算法。

    在这个设计里,之所以采用“接口ID”( interface ID)这个名称,显然表明了它的根本目的就是要采用终端物理地址来建立这一个部分地址。从最普遍的设计原则来说,物理地址是需要具有全网唯一性的。并且在IPv6所设定的使用环境中,接口ID的全网唯一性也具有重要价值。这主要体现在两个方面:

    一是很好地支持移动。如果假设物理地址不具有唯一性的话,当两个具有相同物理地址的终端移动到同一个站点时,它们产生的IPv6地址将没有区别。如果太多冲突的话,将使整个系统崩溃。因此,尽管附录A里对不具有全网唯一物理地址、甚至不具有物理地址情况下如何获得接口ID进行了建议,并且建议中甚至有任意产生一个随机数字的方式,但这种方式显然不能成为主流,因为其如果成为主流的话,所谓“接口ID”就完全失去意义了。

    二是其安全性的考虑。就是通过全网唯一的物理地址来唯一地确定终端的身份。

    我们先假设严格要求接口ID必须具备全网唯一性。这样一来,地址空间将不再是128位,而将完全由后面64位的接口ID所决定。

    如果容许接口ID不具有全网的唯一性,则理论上必然会出现当两个具有相同接口ID的终端移动到同一个站点时其分配的IPv6地址会发生冲突的问题。虽然可以通过一定的算法进行冲突检测,并且在发现冲突后分配一个新的接口ID。但是,如果终端用户总量一旦超过64位的话,冲突就将大量增加,超出的越多,冲突的机率就上升的越快,并很快使冲突大到让整个系统无法运行的地步。

    为了更清楚地了解这个问题,我们把整个模型简化一下,我们假设用四个10进制数字来模拟这个地址系统。假设前两位代表站点前缀,后两位代表接口ID。这样就有100个站点空间和100个接口ID空间。

    我们先假设接口ID是全网唯一的,不容许有重复。这样四位号码的理论空间为1万,但在这种唯一接口ID要求下最多可分配的号码空间却为100个,因为如果再多的话就必然会出现有两个接口ID是重复的问题。在接口ID全网唯一的情况下,无论终端如何移动,所分配的号码都不会重复。即使当所有终端都移动到某一个站点时,每个终端的号码也都是唯一的。

    我们再假设容许接口ID可重复,以充分使用四位的号码空间,则每个接口ID最大可能情况下就会有100个重复。这样在网上可以有1万个终端。但是,我们只要看一个情况就知道系统在这种条件下是几乎无法运转的:当超过100个终端移动到一个站点里的时候,无论如何也无法使每个终端具有唯一的号码。这时只有当每个站点都正好100个终端,并且它们都正好是不同的接口ID这种极端特例的情况下,才可以为每个终端分配唯一的号码,并且不容许终端进行任何跨站点间的移动。

    由于每个接口ID都有100个重复,因此当一个终端接入任何一个站点时,都有接近100%的几率会发生冲突。由于具体的冲突几率模型非常复杂,其具体数量分析也相当困难。但可以肯定的是:超过接口ID的空间越多,冲突的几率就越大。这就使当容许接口ID不具有全网唯一性情况下真正的空间到底有多少成为一个几乎无法确定的糊涂帐。至少目前IPv6的支持者没有给出相应的数学模型解决这个问题。

    如果严格要求接口ID具有全网唯一性,则IPv6地址空间就只有64位,而不是128位了。我们先不讨论64位地址空间是否足够,而是128位与64位这两者之间的差异也实在是太大了。这两者可不是一半的关系,而是264 =18,446,744,073,709,551,616倍,约1845亿亿倍的关系。

    IPv6的支持者可以辩护说:现在单播地址仅仅分配了格式前缀为001的1/8空间部分,如果真的在地址不够了之后在启用010-111的前缀时可以改变“前缀”+“接口ID”这种地址结构,使得后64位可以不需要有全网唯一性要求。我们承认这的确可以解决上述接口ID决定总体地址空间的问题,但这意味着什么呢?这意味着地址的最基本的结构发生了极为重大的变化,全网路由协议将需要全部升级才可以支持!!!

    而这是否就算完了呢?还没有。因为现在真正最普遍采用的物理地址IEEE 802的MAC地址为48位,并且其中u比特在IPv6中要求设置为1,以表明其为全网唯一的地址。这个地址在IPv6中是通过正中间插入两个固定字节的方式来获得64位接口ID的。因此,在现实的物理ID技术条件下,真正的接口ID空间只有47位!!!

    47位的地址空间有多少呢?它仅仅比IPv4多了15位,相差的倍数是:215=32768倍。如果我们假设IPv4地址用完后采用当前的IPv6协议,每年的地址消耗量以年增长30%来计算,这个扩大的地址空间仅仅40年就全部消耗光了!当人们满心欢喜地以为只要采用了IPv6就以为地址空间无限宽阔的时候,如果知道了因为其特殊的地址结构设计又使地址空间受到MAC地址空间的限制,是否有刚出狼窝、又入虎穴的感觉?

    而如果运营商们知道了由于IPv6采用了这种特殊的地址设计,他们申请的IPv6地址块其实与可以获得的地址空间理论上没有直接关系的时候,是否又会感觉实在是太莫明其妙了?

    由于所申请的地址块仅仅决定前缀地址,而前缀地址仅仅是网络节点的标识,后面的接口ID是不受网络运营商管理的,这就如同电话网里运营商仅仅分配区号,而用户号码完全不受运营商管理一样。我们不知道世界上的运营商们是否真的都想清楚了这样一来后果到底会意味着什么?

    如果47位的MAC空间消耗光了怎么办呢?如果还是从IPv6的地址结构中来解决问题并不是绝对不可以的,但是其前提是要求采用全新的物理ID技术,将MAC地址从48位升级到64位。但这意味着什么呢?这意味着全世界所有的网络接口要全部升级才能实现!还要花大把的钱啊?!

    从以上分析可以看出:128位的IPv6地址协议并非是单一的协议,如果要实现真正的128位空间,中间事实上有三个具有重大不同的版本:

    当前正在开发的具有47位有效地址空间的IPv06;

    可以充分利用64位接口ID空间,具有64位有效地址的IPv16;

    完全改变“前缀”+“接口ID”的基本地址设计结构,真正具有128位有效地址空间的IPv26。

    以上三个不同的128位IP地址之间的过渡,几乎相当于三个完全不同的IP地址协议之间过渡的成本和难度。

    另一个让人遗憾的特性是:IPv6如果采用随机算法分配接口ID的话,理论上必然有一定几率存在地址冲突。采用随机分配方法的终端越多,地址冲突的几率就越大。如果当人们发现采用自己的MAC地址生成接口ID会带来安全上的麻烦时(参见下一篇"IPv6重大缺陷系列之三----漏洞极大的安全设计"),就都会倾向于采用随机算法生成自己的接口ID。这会导致最终几乎所有的接口ID都是随机生成的,利用MAC地址生成接口ID的算法几乎被废弃。这样地址冲突的几率就会极大上升。如果发生冲突后再次生成的接口ID还是冲突,建议的做法是采用手工配置接口ID。IPv4里在采用DHCP协议后,至少理论上可以完全消除手工配置IP地址了。而新的IPv6在协议设计中就必然要存在理论上不可绝对消除的手工配置IP地址问题,这无疑是非常让人懊恼的事情。

    现在IPv6地址非常少,这个问题根本看不出来,如果当巨大数量的IPv6终端出现在网上,并且用MAC生成接口ID的问题被用户发现而全部转向随机生成接口ID之后,地址冲突问题就会越来越明显。

    IPv6的支持者可能会说,47位,或者64位的地址空间根本就用不完了。本文并不似图去讨论47位或64位空间倒底够不够,我们要首先搞清楚的是:开发IPv6的根本目的就是为了解决IPv4地址空间不足的问题,并且面对IPv4地址空间不足的问题时,人们一再宣称的是“二十年前谁也没有想到(IPv4)空间会不够用”。而现在对IPv6自己的地址空间倒底有多少却又是如此的稀里糊涂,这能让人接受吗?128位地址空间与47位地址空间之间的差异意味着什么?意味着当有人要你花一万亿美元去买一个地球时,最后当你付出了一万亿美元后,他给你的竟然是一个只有万分之4.5立方毫米大小的沙子!!!(地球体积为1.1万亿立方米),并且告诉你,其实这粒沙子已经足够用了,但人们花钱购买的时候,对方明明告诉我们的是可以买到的东西是一个地球。如果你真的最终要想得到一个地球,对不起,其实还得分期付款,第二次花10万亿美元、第三次花100万亿美元才可以!!!

    每当人们谈起IPv6的地址空间问题时,都是带着得意洋洋的口气说到:IPv6可以为地球上每一粒沙子分配一个IP地址。这种得意洋洋不禁使我们想起泰坦尼克号出发时,人们对其抗沉性能得意洋洋、号称“永远不会沉没的”的情绪。先不说是否有必要为地球上每一粒沙子分配一个IP地址,也不说有没有先把我们现在开发的IPv6实际上倒底支持多少IP地址空间算清楚,我们要问的是有没有人真正认真计算过地球上倒底有多少粒沙子?

    什么是科学,科学始于观察。让我们到沙滩上去观察一下,倒底什么叫“一粒沙子”?我们可以看到大的石头能大到成百上千吨,而小的能小到风一吹就不知道飞到哪里去了的“灰尘级棵粒”,而那些巨大的数以吨计的石头一不小心就会被碰撞出无数的小石块来。如果沙滩上的沙子多少还算能数得出来的话,再来挖一箩筐土,里面倒底能数出多少粒沙子呢?一粒沙子的尺寸按多大计算?1厘米?1毫米?1微米?还是0.1微米?

    另外,“地球上”是什么概念?要知道沙子是三维空间的概念而不是二维的。地球的地壳有20-40公里厚,我们倒底取多少厚度来测量所谓“地球上”的沙子数量呢?10公里?1公里?100米?10米?还是1米?并且,大气层里飘浮的沙子算不算?

    现在让我们粗略地来算一算,取地球陆地表面积(不包括海洋面积)为:

1.49×108平方千米

=1.49×1014平方米

=1.49×1020平方米毫米

=1.49×1026平方微米

    取地球表面10千米的厚度,并且假设不考虑球面申缩带来的表面积变化,则其体积粗略估计为:

1.49×109立方千米

=1.49×1018立方米

=1.49×1030立方米毫米

=1.49×1036立方微米

    如果我们假设最小的沙子尺寸按0.1微米计算,地球上10千米厚度的陆地表面全部变成这种尺寸的沙子的话数量为:

1.49×1039

    再来计算一下IPv6各个协议地址空间。128位地址空间为:

2128=3.4×1038

    平均1个0.1微米尺寸的沙子只有约0.2个地址,这就算免强够数吧。但是64位地址空间为:

264=1.845×1019

    这个数量与上述地球表面区域按照0.1微米尺寸计算的沙子相比,大约每1万亿亿粒沙子才能分到1个IP地址。如果要为每粒沙子分配1个IP地址的话,沙子尺寸要大到0.1立方米大小!而47位地址空间为:

247=1.41×1014

    这个数量要10万个1立方米大小的巨型沙子才能分上一个IP地址!

    如果说泰坦尼克号是第一次这样的轮船出航,盲目乐观还有情可原的话,IPv6是前面一艘IPv4的“泰坦尼克”刚刚撞到冰山上,新造的第二艘“泰坦尼克”对其抗沉性能又是无比的盲目乐观,这就让人无话可说了。

    那么,IPv6花了这么多代价,就算其地址空间萎缩81位,从128位缩小到47位,其新增加的设计如安全性总该是有可取之处吧?遗憾的是,正是IPv6的安全设计存在极大的安全漏洞。

请看下集:

    IPv6重大缺陷系列三——漏洞极大的安全设计。

 

IPv6重大缺陷系列:

一、IPv6重大缺陷之一——违反网络平滑升级的天条

二、IPv6重大缺陷系列二——含混不清的地址空间设计

三、IPv6重大缺陷之三——漏洞极大的安全设计

四、IPv6重大缺陷之四——逻辑混乱的整体结构

 

 

 

 

  评论这张
 
阅读(923)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017