找回密码
 注册

扫一扫,访问微社区

QQ登录

只需一步,快速开始

查看: 10362|回复: 6

关于分片报文的转换

[复制链接]
Tanker 发表于 2011-11-29 21:15:02 | 显示全部楼层 |阅读模式
RFC6145 Page 7,第三段:
When the IPv4 sender does not set the DF bit, the translator SHOULD
   always include an IPv6 Fragment Header to indicate that the sender
   allows fragmentation.
这么做的原因我没有想通,IPv6不能在中间分片,就是带着分片头也没有用呀?
满天星 发表于 2011-11-30 19:34:35 | 显示全部楼层
分片的转换处理还是相当复杂的么!RFC6145里面介绍的分好多种情况:
IPv6----->IPv4方向
非分片的数据:
packet size >1280,转换后set DF=1,这样可以实现IPv6 PathMTU的功能
packet size <=1280,则IPv4中节点可能存在MTU小于1280,因此允许IPv4节点二次分片,转换后set DF=0
分片数据:
转换后set DF=0 ,可以允许IPv4节点二次分片, MF和offset复制ip头相应部分,id复制low-order 16 bits

IPv4----->IPv6方向
非分片的数据:
if DF=1,则根据PathMTU来实现
if DF=0,则转换后添加分片头
分片数据:
转换后添加分片头, MF和offset复制相应分片头,id复制low-order 16 bits

至于你最关注的 indicate that the sender   allows fragmentation我也不懂,今天看了看,没有找到相关介绍,这几天有空再找找相关文档和资料看看哦!
回复

使用道具 举报

 楼主| Tanker 发表于 2011-12-1 09:37:26 | 显示全部楼层
感谢回复。
我后来反复看了几遍上下文,觉得很可能是为了在后面的IPv6节点返回ICMP差错报文时能恢复出IPv4报文的原始数据。
其实也就是恢复出IPv4首部的DF位而已。
个人感觉这一位恢不恢复意义也不大。
不知道是否还有其他原因。
回复

使用道具 举报

满天星 发表于 2011-12-1 19:29:24 | 显示全部楼层
嗯,你分析的这点还是非常有道理的!
但是从相关文档中没有明确体现出来,不确定是否还有其它可能性存在……这个细节部分我也没有仔细看过。
而且大量的操作都是一个非常灵活的范围,采用SHOULD或MAY之类的关键字标识。
具体的实现即使不符合要求,也能正常通讯,但可能引发不必要的分片或二次分片。
这一块还需要继续学习,整篇RFC大量介绍都是围绕分片和DF位以及ICMP和差错报文来介绍的。
回复

使用道具 举报

满天星 发表于 2011-12-26 22:13:23 | 显示全部楼层
将QQ群里面wissen兄发的分析贴进来:
这个是从ipv4 to ipv6的流程,然后反向再ipv6 to ipv4的一个流程

1. considering the case of IPv4(src domain)->IPv6->IPv4(dst domain), the typical case of double translation. throughout the mechanisms described in section 4, 5, and 6, we may have the following cases:

#1 IPv4-src: DF=1, MF=0, offset=0
IPv6: no fragment header
IPv4-dst: DF=1 if packet_size > 1280; DF=0 if packet_size <= 1280; MF=0.

#2 IPv4-src: DF=0, payload > 1232 bytes (*)
IPv6: fragment header (with default setting of domain IPv6 minimum MTU = 1280 bytes; for non-default cases, only values at * need to be changed)
IPv4-dst: DF=0, MF and offset copied from fragment header

#3 IPv4-src: DF=0, payload <= 1232 bytes (*)
two sub-cases:
#3.1 translator configured not to include the fragment header for the non-fragmented IPv6 packets (conforming to "The translator MAY provide a configuration function that allows the translator not to include the Fragment Header for the non-fragmented IPv6 packets.")
IPv6: no fragment header, packet_size <= 1280
IPv4-dst: DF=0 according to Sec 6; MF=0
#3.2 translator configured to include the fragment header even for the non-fragmented IPv6 packets (conforming to "When the IPv4 sender does not set the DF bit, the translator SHOULD always include an IPv6 Fragment Header to indicate that the sender allows fragmentation.")
IPv6: fragment header, MF=0
IPv4-dst: DF=0; MF=0 copied from fragment header

#4 IPv4-src: DF=1, MF=1 (the so-called corner case, not covered by RFC6145 as it is stated in Sec 4.1: "If the DF bit is set and the packet is not a fragment (i.e., the More Fragments (MF) flag is not set and the Fragment Offset is equal to zero)"
if this happens, translations really drops the offset information so that the reassembly is disabled.
回复

使用道具 举报

 楼主| Tanker 发表于 2011-12-27 10:40:35 | 显示全部楼层
受教了。
第四条在RFC6145 page9中,这是分片报文,需要加分片首部。只是这样在ipv6->ipv4之后DF bit无法恢复了。
回复

使用道具 举报

满天星 发表于 2011-12-27 19:26:18 | 显示全部楼层
是指这一段?
   If there is a need to add a Fragment Header (the DF bit is not set or
   the packet is a fragment), the header fields are set as above with
   the following exceptions:
很多地方我也确实没完全理解……最近也没时间投入这一块的细节分析或思考。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

Archiver|手机版|小黑屋|IPv6BBS ( 京ICP备13024693号 | 京公网安备11010802012238 )

GMT+8, 2024-3-29 00:12 , Processed in 0.053343 second(s), 17 queries .

Powered by Discuz! X3.5

© 2001-2023 Discuz! Team.

快速回复 返回顶部 返回列表