ipv6协议报文格式

一、ipv6的基本格式

ipv6报文格式从简单性来看,比ipv4较简单,而且ipv6的基本头部的长度是固定的。相较与ipv4,ipv6去掉了一些头部,把这些头部全部弄到了后面的扩展投不中。ipv6的报文格式如下:


version:4bits 版本号  ipv6为6

Traffic Class: 8 bits,传输类别,可用于源节点或转寄路由器标识和区分IPV6包中的不同类别或优先级;类似于实现IPV4的TOS/DIFF

Flow Label:20bits 流标签,数据流是指从某特定的源节点向某特定的目的节点发送的数据包序列。当源节点希望中间的路由器对数据包进行一些特殊处理时,就可以使用数据流标签,不支持数据流标签的可以赋值为0;

Payload Length: 16bits unsigned integer, ipv6的载荷长度,首部以外的长度(包括扩展首部)

Next Header:8 bits 指明紧跟IP首部后面的下一个首部的类型

Hop Limit:8bits unsigned integer,在每个传输此包的节点处减1,如果跳数限制减到0,就抛弃此包

Source Address:128 bit 源地址
Destnation Address:128 bit 目的地址

二、扩展首部格式:

1、下面是几个扩展首部的例子:
+-----------------------+--------------------------------------------
|    ipv6    header          |   tcp header + data
|                                     |
|    next header = tcp   |  
|                                     |
+-----------------------+---------------------------------------------

+-----------------------+-----------------------+-----------------------------
|    ipv6    header          |       routing header    |      tcp header + data
|                                     |                                    |
|    next header =         |    next header = tcp   |
|    routing                    |                                     |
|                                     |                                     |
+-----------------------+------------------------+-------------------------------

一般情况下(hop-by-hop选项首部例外),扩展首部在数据包的传递过程中,中间的任何节点不会检测和处理,一直到这个ipv6首部中目的地址所标识的那个节点。
特例:hop-by-hop选项首部,携带了包的传送路径中的每个节点都必须检测和处理的信息。包括源节点和目的节点。如果HOP-BY-HOP选项首部存在,就必须紧跟在ipv6首部后面。

2、扩展首部出现的顺序
当在同一个包中使用多个扩展首部时,建议按如下顺序排列这些扩展首部:
ipv6 header
hop-by-hop options header (HOP-BY-HOP首部)
destionaion options header   (目的地址选项首部)
routing header  (路由首部)
fragment header  (分片首部)
authentication header (认证首部)
encapsulating security payload header 封装安全载荷首部
destination options header    (目的地址选项首部)
upper-layer header 上层协议首部

3、选项
     在hop-by-hop和目的地址选项首部,包含若干个以类型-长度-值格式进行编码的选项,格式如下:
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------------
     | option type        | opt data len             |options data
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------------

     Option type:     8bit,标识选项类型;
     Opt data len: 8bit 选项数据字段的长度;
     Option data:可变长度,依选项类型而不同的数据;
     
     选项类型的最高两个比特,指明当IPV6节点无法识别这个选项时的处理方式:
     00: 跳过这个选项,继续处理首部
     01:丢弃这个包
     10:丢弃这个包,并给源地址发送一个“参数错误”的icmp,同时指针指向无法识别的选项类型
     11:丢弃这个包,并且如果目的地址不是组播地址时,给源地址发送一个参数错误的icmp,同时指针指向无法识别的选项类型

     选项的第三个比特:
     0:选项数据不会改变选路
     1:选项数据可能改变选路

 4、Hop-by-Hop选项头部
       用IPV6首部的”下一个首部“为 0(0x00)来标识,此选项头部用于传送在数据包的传送路径中每个节点都必须检测的可选信息。格式如下:
       
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   next   header  |  hdr ext  len          |                                                           |
        |                                                                                                                       |
        .                                                                                                                       .
        .                                            options                                                              .
        .                                                                                                                       . 
        |                                                                                                                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Next header:   8bits, 紧跟在hop-by-hop选项首部后面的首部类型式
        Hdr  Ext  len:8 bits hop-by-hop选项首部的长度,不包括开始的8个八位组
        options: 可变长度,包含一个或多个TLV的选项

        5、路由首部
            next header = 43标识;用于IPV6源节点列出到目的节点的路径中所应"访问"的一个或多个中间节点,格式如下:

            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |      next header |   Hdr Ext Len         |   Routing Type     |    Segments Left   |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                                                                                                                           |
             .                                                                                                                           .
             .                                 type-specific data                                                            .
             .                                                                                                                           .
             |                                                                                                                           |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Next header: 8bit 紧跟在路由首部后面的首部类型
            Hdr Ext Len: 8bit  路由首部长度,不包括开始的8个八位组
            Routing Type: 8bit 标识路由头部类型
            Segements left:8bit 到达目的节点前仍然应当访问的中间节点数
            type-specific data: 可变长度,格式由路由类型(routing type)来决定

            6、分片首部
            next header = 44标识;在ipv6中,只有源节点才可以分片,中间路由器不能分片,当发送的数据包长度大于MTU时,就需要分片,分片首部的格式如下:
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |  next header     | reserved        |             fragment offset    |          Res        |      m     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                                               Identification                                                                  |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             next header: 8bit  同上
             reserved : 3bit,保留
             fragment offset: 13bit,分片偏移量。首部后面的数据相对于原包中可分片部分的开始位置处的偏移量
             Res:2bit,保留,用0填充,接收时忽略
             M flag:标识是否还有分片(1: 分片;0:最后一个分片)
             Identification:32 bit,标识符

例子如下图:


 7、目的选项首部
            next header = 60标识,用于携带仅需要目的节点检测的可选信息。格式如下:
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   next   header  |  hdr ext  len          |                                                           |
        |                                                                                                                       |
        .                                                                                                                       .
        .                                            options                                                              .
        .                                                                                                                       . 
        |                                                                                                                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      next header: 8bit 同上
      Hdr Ext Len:  8bit 目的选项首部长度,不包括开始的8个八位组
      options:可变长度。一个或多个TLV格式的选项

     8、无下一个首部:
            next header = 59 (0x3b)


IPv6 in IPv4 (IPv6inUOV4) 报文格式并不是标准的IP协议报文格式的一部分,而是描述了一种特殊场景下的一种传输机制。这种情况通常发生在IPv6流量需要通过仅支持IPv4网络环境传输时。 ### IPv6inUOV4 的应用场景 当有设备(如路由器、网关等)既支持IPv6又支持IPv4,但在向纯IPv4网络(例如ISP提供的出口)转发数据包时,如果该数据包含IPv6头部,那么为了使其能够穿越到IPv4网络中,就需要将IPv6报头转换为IPv4兼容的形式。 ### 转换过程概述 IPv6inUOV4转换的核心思想是在IPv4的数据包中封装了一个额外的UDP数据段,其中包含了原IPv6报文的有效负载部分以及IPv6的版本信息、流标签、长度、下一跳信息等字段。这个UDP数据段的源端口和目的端口分别被设置为特定值(通常是500),这表示它是一个专门用于IPv6数据传输的目的地。 ### 封装细节 - **UDP数据段**:这部分承载了实际的IPv6有效负载,并且包含了必要的IPv6头部信息(版本、流标签、长度、下一个头部等)。注意,这部分的IPv6头部会被转换为IPv4兼容的形式,以便适应IPv4网络环境。 - **IPv4头部**:封装了UDP数据段,包含了源地址、目的地址、协议字段(指定为6,代表UDP)、标识符、生存时间、报文偏移量、分片标志位、标识符、校验和等字段。 这种转换方法虽然解决了IPv6数据在网络环境中传输的问题,但由于额外封装带来的开销,可能会导致一些性能损失。此外,这种方法也限制了数据的直接处理和路由,在某些情况下可能导致更复杂的处理流程或是对网络架构的要求更高。 ### 相关问题: 1. 使用IPv6inUOV4的原因是什么? 2. IPv6inUOV4转换是否适用于所有情况? 3. 这种转换会对网络性能带来哪些影响? 了解IPv6inUOV4不仅有助于理解复杂网络环境下不同协议之间的交互,也能提供一种策略,在面对IPv4和IPv6共存的网络环境时如何高效地传输数据。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值