IPv6地址格式_第1页
IPv6地址格式_第2页
IPv6地址格式_第3页
IPv6地址格式_第4页
IPv6地址格式_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、IPv6 地址格式IPv6的地址长度是128位(bit)。将这 128位的地址按每 1 6位划分为一个段,将每个段转换成十六进制数字,并 用冒号隔开。例如:2000:0000:0000:0000:0001:2345:6789:abcd 这个地址很长,可以用两种方法对这个地址进行压缩, 前导零压缩法:将每一段的前导零省略,但是每一段都至少应该有一个数字例如: 2000:0:0:0:1:2345:6789:abcd双冒号法:如果一个以冒号十六进制数表示法表示的 IPv6 地址中,如果几个连续的段值都 是0,那么这些 0可以简记为 :。每个地址中只能有一个 :。例如: 2000:1:2345:678

2、9:abcd单播地址( Unicast IPv6 Addresses)可聚合的全球单播地址( Aggregatable Global Unicast Addresse)s可在全球范围内路由和到达的,相当于 IPv4里面的global addresses前三个bit 是 001例如: 2000:1:2345:6789:abcd链路本地地址( Link-Local Addresses)用于同一个链路上的相邻节点之间通信,相当于IPv4里面的169.254.0.0/16地址。 Ipv6的路由器不会转发链路本地地址的数据包。前10个bit是1111 1110 10,由于最后是64bit的in terf

3、ace ID,所以它的前缀总是 FE80:/64 例如: FE80:1站点本地地址( Site-Local Addresses)对于无法访问in ternet的本地网络,可以使用站点本地地址,这个相当于IPv4里 面的 private address(10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/1)6。它的前 10 个 bit 是 1111 1110 11,它最后是 16bit 的 Sub net ID 和 64bit 的 in terface ID,所以 它的前缀是 FEC0:/48。值得注意的是,在RFC3879中,最终决定放弃单播站点本地地址。放

4、弃的理由 是,由于其固有的二义性带来的单播站点本地地址的复杂性超过了它们可能带来 的好处。它在 RFC4193中被ULA取代。唯一的本地 IPv6 单播地址( ULA, Unique Local IPv6 Unicast Address)在RFC4193中标准化了一种用来在本地通信中取代单播站点本地地址的地址。ULA拥有固定前缀FD00:/8,后面跟一个被称为全局ID的40bit随机标识符。未指定地址(Un specified address0:0:0:0:0:0:0:0 或者::当一个有效地址还不能确定,一般用未指定地址作为源地址。未指定地址不能作 为一个目标地址来使用。回环地址(Loopb

5、ack address回环地址:1用于标识一个回环接口,可以使一个节点可以给自己发送数据包。相当于IPv4的回环地址127.0.0.1兼容 IPv4 的地址(IPv4-compatible address形如:w.x,y.z,这里的w.x.y.z是IPv4公共地址的十进制点号表示法,用于IPv6/IPv4节点们(同时支持)在使用仅支持IPv4的网络上用IPv6的协议进行通 信。但是事实证明这种技术不是个好主意,RFC4291中废弃了对这类地址的使用。IPv4 映射地址(IPv4-mapped address形如:FFFF:w.x.y.z,这里的w.x.y.z是IPv4公共地址的十进制点号表示法

6、,用于一 个仅支持IPv4的节点表现为一个IPv6的节点6over4地址64bit-prefix:0:0:WWXX:YYZZ,其中的 WWXX:YYZZ 是 w.x.y.z IPv4 公共地址 的十进制点号表示法,用于一个使用6to4协议的隧道机制的节点。6to4地址2002:WWXX:YYZZ:SLA ID:Interface ID, 用于表示一个使用 6to4协议的隧道 机制节点。多播 IPv6 地址(Multicast IPv6 Addresses前 8 个 bit 为 1111 1111,其中FF01:到FF0F:的多播地址是保留专用地址FF01:1节点本地范围所有节点多播地址FF02

7、:1链路本地范围所有节点多播地址FF01:2节点本地范围所有路由器多播地址FF02:2链路本地范围所有路由器多播地址FF05:2站点本地范围所有路由器多播地址一、引言下一代网络(NGN是以IP为中心,支持语音、数据和多媒体业务的全业务网 络。因此,IP协议的研究对下一代网络的发展至关重要。然而,IPV4已经很难 独自担当起支撑下一代网络发展的重任。相对于IPv4而言,IPv6改进了许多功能,如单播和组播地址空间、任意广播地址、分层路由的集体寻址等。通过这些改进,IPv6扩大了地址空间,提高了网络的整体吞吐量,改善了服务质量和安 全性,增强了对即插即用和移动性的支持,更好地实现了多播功能,从而使

8、IPv6成为下一代网络的基础。目前,IETF及相关机构正在努力完善IPv6地址结构体 系和地址分配策略,使之能更好地为下一代网络服务。二、IPv6地址结构体系研究的进展RFC3513是IETF最近公布的IPv6地址结构体系,该体系取消了早期公布的 RFC2373虽然在RFC3513中保留了 RFC2373的部分内容,IPv6地址仍分为单播、 任播、组播三种类型,地址和地址前缀的表示方法也未变, 但在其它许多方面作 了重大调整。另外,IETF还在RFC3587公布了新的IPv6全球单播地址格式,并 取消了 RFC23741. 大大扩展了全球单播地址空间在RFC3513中, IETF对IPv6的地

9、址类型及其所占地址空间的比重进行了重 新调整,调整的结果如表1所示。表1 IPv6的地址类型及其所占地址空间的比重地址类型二进制前蛾符号占地址空间的比重不确定型00-'-0 C128©:):/1261/2128环画00-11 羽位组播lmmiFFOO:/B1/256本地惟蹌单播UH111D1OFFS0:/101/1024本地站点单播1111111011FFC0:/W1/1024全球单播C所有耳他)通过与RFC2373对比可知,RFC3513取消了为NSAP和 IPX等保留的地址, 将原来的保留地址全部划入了全球单播地址的行列,从而大大扩展了全球单播地址的空间。2. 给出了新的

10、全球单播地址格式RFC3513合出了新的IPv6全球单播地址通用格式,见图1。n bitsm bi ts128-hf bits全球路由前縫子网口)接口 ID图1新的IPv6全球单播地址的通用格式在图1中,全球路由前缀是分配给站点(一组子网/链接)的一个典型层次结 构值,子网ID是一个站点内子网的标识。全球路由前缀由 RIR和ISP设计为分 层结构,子网域由站点管理员设计为分层结构。 在RFC351沖还删除了格式前缀 (FP)这个术语,以保证执行简便,而不需要掌握任何有全球单播格式前缀的知识。由于RFC3513要求所有的单播地址(除了以二进制000开头的地址外)有64 位接口 ID并具有改进EU

11、I-64格式的结构(以二进制000开头的全球单播地址在 接口标识大小和结构方面没有这个限制),即要求n+m=64为进一步明确IPv6 全球单播地址格式,RFC3587合出了新的格式,见图2。n bi tsbits54 bits全球路曲前騷子网ID接口 ID图2RFC3587合出的IPv6全球单播地址新格式RFC3513规定,IANA对IPv6全球单播地址的空间分配权限只局限于以二 进制001开头的地址范围。RFC3587®废除了 RFC2374中全球可聚集单播地址的 前缀格式001,但同时又指出,只有001前缀格式供IANA分配,其余的全球单 播地址空间(大约是IPv6地址空间的85

12、%要保留下来,以备将来定义和使用, 暂时不再由IANA分配。所以,由IANA代理、与RFC3177中的建议相一致的2000 :/3前缀的全球单播地址就成了如图 3所示的格式。3 bits45 bits15 bits64 bits而全球路由前蹶子冏ID接口TD图3 IANA代理的2000工/3前缀的IPv6全球单播地址格式根据RFC3177RFC3513和 RFC3587并结合目前LIR的分配情况,可将IANA 有权分配的全球单播地址格式表示为图 4所列的形式。345166400129 bill18 bits16 bits64 bitsUR/32客户站点/朝子网/忘4设备/123图4 IANA有

13、权分配的IPv6全球单播地址格式从该格式可以看出,在IANA有权分配的地址空间中,前三个比特是固定的, 29比特地址空间分配给各LIR,LIR可将后面的16比特地址空间分配给客户站 点。这样,客户站点前缀即为48比特,并具有16比特的子网划分空间。3. 进一步明确了本地使用的IPv6单播地址本地使用的单播地址有两种,分别是链路本地地址和站点本地地址。链路本地地址格式见图5。10 bits54 litsS4 bits0接口邛图5链路本地地址格式链路本地地址用于单个链接,可进行自动地址配置、邻居发现或在没有 路由 器时进行单个链接编址。RFC3513规定,路由器不能转发任何到达其他链路的具 有链路

14、本地源或目的地址的包。站点本地地址格式见图6。10 bits54 hits64 bitslllUUOll子网TD接口邛图6站点本地地址格式站点本地地址用于单个站点,即用于不需要全球前缀站点的内部编址。尽管子网ID可以长达54位,但最好还是保证全球链接站点能在站点本地前缀和全球 前缀中使用相同的子网ID。RFC3513规定,路由器不能转发站点以外的任何具有 站点本地源或目的地址的包。4. 巩固了 IPv4和IPv6联合应用的基础在RFC3513进一步明确了 “内嵌IPv4地址的IPv6地址”的概念。“内嵌 IPv4地址的IPv6地址”包括“ IPv4兼容的IPv6地址”和“ IPv4映射的IPv

15、6 地址”。“ IPv4兼容的IPv6地址”的格式如图7所示。80 bitsIB bits32 bits00000000000地址图7 IPv4兼容的IPv6地址格式这里使用的IPv4地址必须是全球唯一 IPv4单播地址。“IPv4映射的IPv6 地址”用于代表IPv4节点的IPv6地址,其格式如图8所示。SO bits1G bits32 bits00000000FFFFUM 地 iit图8 IPv4映射的IPv6地址格式IPv4兼容地址和IPv4映射地址用于与传统网络之间的互联互通,以使IPv4网络和IPv6网络之间能进行无缝 通信。三、地址注册机构的IPv6地址分配策略虽然新的IPv6地址

16、结构已经发布,但还没有相应的新的地址分配策略出台, 地址分配仍沿用按 RFC3177制定的分配方法(RIPE-267)。目前,IPv6的地址空间管理是按规定的等级结构在全球范围内分配,即IANA-区域注册机构RIR(-国家注册机构NIR)-ISP/本地注册机构LIR-最终 用户(或ISP)。地址分配的方法分为两种。一种是上层注册机构将抵制划分给下 层注册机构进行管理,称为分配。另一种是注册机构将地址划分给用户使用,称为指派。为了互联网发展的长期利益,IETF将IPv6地址空间管理的目标确定为 保证世界范围内的唯一性、统一在注册数据库中注册、尽最大可能保证易聚合、 避免无谓的空间浪费、分配公平公

17、正及注册管理开销的最小化等。上面所描述的这些管理目标经常相互冲突或与某些注册机构 (IR)个体及终端用户的需要相冲 突,故必须寻求申请者的需要与整个互联网社区的需要之间相互平衡,并能正确地判断出哪方面的需要更为重要。一般情况下,在IPv6地址分配策略中,聚合的目标被认为是最重要的。此外,IPv6地址空间管理还要遵循如下基本原则:不能把地址空间当作私有财产。IPv6单播地址空间只能凭许可证使用而不 能拥有。尤其IP地址是基于许可机制进行分配和指派的,许可证需进行周期性 更新。许可证的批准取决于其初次申请或续借申请时的特殊要求。不能保证路由的可选性。 即不能保证所分配的任何地址在全球范围都能进行

18、路由选择。因此,要求RIR采取措施减少产生地址空间碎片的可能性,以避免路由的可选性受影响。IPv6地址空间的最小地址分配块为 32比特。RIR使用最小地址块进行IPv6 地址分配,这样做的目的是为了使基于前缀的过滤更加容易。 对于已经持有 IPv6 地址空间的组织,也就是那些已经按照原有分配策略获得 35比特IPv6地址的注 册机构,一般不需要提供证明文件就可以直接将他们所分配的地址扩展到 32比 特。该 32比特地址块包含已经分配的地址块 (多数情况下为一个或多个 35比特 地址块),RIR已经将这些地址预留给原有组织以进行后续分配。超过最小地址 块(32 比特)的额外地址空间的申请需要在评估后再决定是否分配。兼顾原有 IPv4 基础设施。已有的 IPv4 服务提供商由现有业务向 IPv6 过渡 而申请 IPv6 地址空间时,可将现在 IPv4 客户数一并考虑。LIR在将地址空间指派给用户时,要按照已有的 RFC3177操作,即通常情况 下,采用 4

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论