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

汪涛

 
 
 

日志

 
 
关于我

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

网易考拉推荐
 
 

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

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

  下载LOFTER 我的照片书  |
   摘要:网络分层分离是一个基本的要求。网络的分层是经过长期发展被实践所证明的有效方法。IPv6在设计上混淆了网络的层次结构,接口ID将物理层的地址嵌入到了逻辑地址层中,这一方面导致物理地址的空间形成了对IP地址空间的限制,另一方面IPv6地址的设计反过来又限制了物理地址的发展。安全本不属于IP层的内容,在IP层设计安全技术是不应该的。因为随着安全技术的发展,安全方法及密钥长度会不断发生变化,这样安全技术的发展最终将导致对IP地址重新设计的要求。由于网络层次逻辑关系的混乱,IPv6创造出的新问题远远比它所要解决的问题多得多。

 

   网络技术的分层分离是一个基本的要求,它是经过长期发展被实践所证明的有效方法。通过网络层次的分离,可以使得网络技术不同层面的问题放在不同的层面去解决,以使不同技术发展之间不出现相互的干扰。在传统TCP/IP协议中,基本是做到层次清晰的。但在IPv6中,层次间的逻辑关系变得异常混乱。

    首先是地址结构中单播地址后64位采用接口ID,将物理层的技术嵌入到了IP地址中,这就造成了物理层技术的发展与IP层技术之间不再透明。一方面物理层的地址空间对IP地址空间形成了约束,另一方面物理地址的发展会对IP层的技术形成连动。例如,如果MAC地址技术发生变化,IPv6的协议,至少附录A就会随之要发生修改。这种不同层面的技术之间的直接捆绑必然会带来这样的后果。

    不仅物理地址对IPv6的空间形成了约束,IPv6反过来对物理地址的发展空间也形成了约束。因为接口ID是64位的,这样未来最长的物理地址就只能是64位以下的了。如果要想采用64位以上的物理地址设计,就将很难与IPv6兼容。例如,假设未来星际通讯时代,物理地址就需要设计成128位,这种128位的MAC地址如何装进IPv6里?我们先不讨论64位物理地址是否是人类“万岁”的物理地址长度,因为引入新的IPv6协议却把物理地址发展的上限给封死了,这是合适的技术设计方式吗?

    IP地址与物理地址是两个不同层面的、对相同网络接口的标识。因此,它们之间是必然有对应关系的。它们在总体空间数量上必然具有相互一致的关系。IP地址是128位,而物理地址却在64位以下,这本身就是自相矛盾的。如果IP地址是128位的,MAC地址最终也应该是128位的!

    IPv6号称简化了包头的设计,而其简化的是什么呢?主要是IPv4中真正用于IP层处理的分片字段。IPv6把这部分真正属于IP层的功能简化掉带来的结果是对网络MTU适应性的下降。

    IPv6增加的却大都是不应该在IP层考虑的问题,这样的增加必然带来逻辑关系的混乱和不同层面技术之间的复杂连动和耦合。

    安全性本来根本就不该属于IP层的内容,但IPv6却设计了太多安全性方面的内容。要知道,IP层协议直接涉及到路由和网络设备。它们需要有非常长期的稳定性,否则技术的升级成本会非常高。从过去的历史发展来看,任何一种安全技术的有效都是有生命期的。几十年前的安全技术今天都不再安全。如果技术发展几十年后,现在设置在IPv6中的安全技术还一定有效吗?如果失效了,需要新的安全技术,现在的包头设计都已经这样了,以后要么就得放弃现在的包头设计,最差情况是废弃这些字段,最好情况是对它们进行改造。但显然对IP扩展头进行技术改造又将是一场伤筋动骨的事情。安全设计当然是需要的,也是要不断进行技术升级的。但如果在应用层去考虑安全问题,显然其技术升级和成本要比在IP层容易得多。

    我们无法证明几十年以后安全技术的发展是否一定会照成现在IPv6安全设计的废弃,但我们可以从历史中获得证据。过去的安全技术不断发展无非两个方面:一是安全方法不断变化,另一个方面是密钥不断加长,短的密钥在一定时期后不再有效。未来安全方法会如何变化我们是无法预知的,但我们可以预知的是密钥长度是不断加长的。可IPv6包头和扩展包头的长度是固定的,这样在一定时期后相应长度的密钥肯定就不再有效。并且在该长度不再有效后也很难再废物利用。

    IPv6技术的出现倒底是为什么?无非就是要解决IPv4地址不足的问题。但现在IPv6却并不是以尽可能最小成本解决地址不足问题为出发点,而是借“IPv4地址不足之机大做文章、搞些别的事情”。问题是当人们心花怒放、欢心鼓舞地陶醉在IPv6新增的“强大功能”里的时候,是否认真想过:这些“强大的功能”真的是IP层应该考虑的问题吗?是否会造成IP层技术对其它层技术的“越位”,管了自己不该管、也不可能管好、另外会管出新的一堆麻烦的“闲事”呢?如果因为引入IPv6而“创造出”的新问题比它要解决的问题还多得多的时候,是否想过做IPv6最初的目的倒底是为什么?以为IPv6只要设计成了128位地址空间就无限宽阔、无论如何也用不完了,所以就根本不用考虑地址空间问题而放手去玩,最后玩到地址空间都已经快没了时候也浑然不知。只是随口一句“谁也没想到当年IPv4不够用”就把曾经的问题轻飘飘一带而过,而怎知IPv6就没有几十年后还会再喊“当年谁也没想到IPv6里会有这么多毛病”的问题?早知如此,为什么没有在设计IPv6之前对“谁也没想到当年IPv4不够用”问一个为什么?科学技术的发展中经常会有各种错误甚至失败,这本不值得大惊小怪,但科学的态度是需要对过去的失败和错误进行认真的总结和科学的分析。在没有对IPv4的历史性错误作出一个科学合理的解释之前,普通用户们又凭什么相信IPv6的设计就一定不会出现类似的历史性错误呢?(全系列完)

 

IPv6重大缺陷系列:

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

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

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

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

 

 

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

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--推荐日志--> !b&tex上一篇杀韭一篇me="jst" id="m-3-jst-5"> il7">f40"> p;< on tag e1;还蚾#18cn0-62blank" cla {n8" hid163.com/${x.re/blog/static/6428422${b=blDetail.s="B=blog/static,8)|esb=blDetail.s="B=blT cla {/if} {/lis ap'} !!(b=blDetail.n B=blog/static) <> irg">f40"> p;< class="m2a">订阅 {if !!yx e1;还蚾#18cpan clblank" cla {n8" hid63.com/${a.us/blog/static/6428422${b=blDetail.n B=blog/static,8)|esb=blDetail.n B=blT cla {/if} {/lis f40"> 891223,er {{fn(x.recommli c)|891223,er { ${x.visitorNickname|esc891223,erNerror= {else} ${x.visitorNickname|esc891223,erNerror=
{/if} ag詔arget="_bn pnt pright" ap'} ==1} js- id= ='iphone'} ==2} js-t" id= ='iphone'} ==3} js-gpost_ ='iph
891223,er {{fn( {/if} 引用记录--> {if&tex 是舀一挛殴愀 me="jst" id="m-3-jst-5"> 推紉taggggg e1;还蚾#18ttl 6fn1(b.visi.visn 且ㄒ宦闻 {/liaggggggg e1;还蚾#18)" smend x} agggggggag詔arget="_h>)<)" swtrf="http://blog.1f="http://blog.163.com${h>)< s.}/?_3w {/d x} > mendeme)}"/>endsize(h>)< s.endsrc,240,150,tru> x} > mc07">转载记耰class还ess="tbac > mc07">转载记耰 ck">·)< s.a> ')&&)" s> class="fc06">他 {if )" s> ·3e07">转 li c)_lseex>7}{b}{/k
diag詎 class="iblankck"target="_blank" href="http://inpin.blog.1ca">m/?_3w {/d {list dpans="

dond ·03 m2a"ca">a> diag {/if} } &&/text> & e1;还蚾#18dowew Imges)" sw x} > 詔arget="_banReef="http://blog.16f="http://blog.163.com/${a.usmmenges/analyses015lt= 且ㄒ宦闻ck and一个籭f} x} > {/liaggggggg {/引用记录--> {if&tex右边模块徊捎me="jst" id="m-3-jst-5"tx {list tx -="fc03 no e1;还蚾#18ui div class="mbga 2 bdc0 fc07pan>/h4> ltnLirf="div cla被ul> a name="blo 2 {list d/h4> ltnLirf="div cla-> /h4> ltnLirf="div cla该作者的保iv style="w 2 {list d/h4> ltnLirf="div cla博主ul> me="blo 2 {list d/h4> ltnLirf="div cla随机aniRme="blo 2 {list d/h4> ltnLirf="div cla首页ul> me="blo 2 {list d 2bret=bret {if ! e1;d" szoom:1;"px;line-hemorecont/www.
&texa na模块徊捎me="jst" id="m-3-jst-5"tx {list tx - x} e1;还蚾#18891223,div class="mbga 2 e1;还蚾#18n1(t.vis2.visi.3" style="_zoom:1;"2ne">
&textare模块徊捎me="jst" id="m-3-jst-5"a arame" wst tx - 转载记 p;<5> t"s e1t { g e1;还蚾#18 gg詔ex博主发迫嗣投票me="jst" id="m-3-jst-5"a arame" wst tx - x} {if !!x}
  • mg alt="$/eef="http://blog.1 {n8" h
  • ca">lt=" {/if} ; <> {if {vi DetailLf !!xs i ToOpttp: <> li ci ToOpttp:==1} {if !!yx li cfir opttp:== cu}, l {if !!b li c8)|role!="s x) },“我是${c[)|role]}” xtagli c)|mg alt=" {/if} 引用记录--> "s e1t { javascript" id="wumiiRelatedItk {e();${y.recommendBlog/"; //iv s的永久链接家痒为iv s的唯一涫潜 {e(); P3.cixg.scom/sharb=blnges/anal/blog/5"; // wap的贗P乘时杭已魑 wap的唯一涫潜 {e();相关iv s数目,764e为默认v>显蔵模式(1为iv滓2为图片,3为自动) j> e1t {if !gg e1;还蚾#18 {l h" sc e1t {if ! e1;还蚾#18reamb lcr bh s="ctck {if !!y e1;还蚾#18l bl bhc e1t {ifj> e1t { j> e1t {if !gg e1;还蚾#18 wl g lg h" sc e1t { gg e1;还蚾#18); e1t { j> e1t { j> e1t { j e1;还蚾#18rea ta c-smock" e1;还蚾#18wkg h s="ctck" e1;还蚾#18l hck e1t" e1;还蚾#18r hck e1t" e1;还蚾#18c hck e1t"> e1tj> e1t {" e1;还蚾#18rea ta c-fond {if" e1;还蚾#18wkg hck {if !

    {if !" e1;还蚾#18k"

    " h 的照片书if} x}

    转载记 1="f-03 m2a" {if !!y"tarpt="="honeIcon">" h转载记 1="f-03 m2a" {if !!y"tarpt="="honeIcon">" hlock wapif} x}

    转载记 1="f-03 m2a" {if !!y"tarpt="="honeIcon">" h