My heart is BLUE these days!But my life has to go on!
In the morning, after making some changes to the modules of L2TP and SEQ, I got the IPV6 protocol source code to study. Because the function parsing extended header has some bugs. I must admited that I was too reckless of my job, and too impatient. If I read the RFC two more times and thought it more deeper, these bugs wouldnot been in my code. Yough, calm down your uneasy heart.
OK, I want to summarize some points about IPV6, because I haven't any material on hand, so...
1)the changes of standard header of IP.In IPV6, the standard header's length is always 40 bytes.It only includes some important infomation.
2)follwing the standard header is the extended header or upper protocol data.We can get the type form the NEXT field of the standard header.Also, we can get the following next extended header's type form NEXT field in each extended header, which lies in the first byte of the header. In RFC, the sequence of all extended header is advised to follow, but in the source code, it does not make any check about that, so I think it is not compusive.
3)The length of each header is not the same, and the methods to get it are different. Most header follows the formula: length = (len + 1)<<3, in which the 'len' is the value of the second byte of the header, likes HOP, DEST. In the case of AUTH header, the '3' will be changed into 2.And for FRAG header, the length is a constant : 8.
4)The mechanical of fragment is the most changes.But some colleages says that IPV6 will not surport fragment, I donot know. The mechanical is some complex, I will explain it next time.I just want to say something about the extended header.As said above, the length of FRAG header is a constant.The 'NEXT' field tells us the NEXT header in the original integrity packet, not the header following this FRAG header. And in most times(all the times?), the data following the FRAG header is just some data which is not follow any forms of known header, except the first fragment packet.So we can say that the if there is a FRAG header, it is the last one?
5)There is a special type of extended header: NONE(59), which means the current header is the last extended header.If the NEXT field's value is NONE, there is none data following header. I guess there maybe special use of that, but I donnot know about it yet.
In the morning, after making some changes to the modules of L2TP and SEQ, I got the IPV6 protocol source code to study. Because the function parsing extended header has some bugs. I must admited that I was too reckless of my job, and too impatient. If I read the RFC two more times and thought it more deeper, these bugs wouldnot been in my code. Yough, calm down your uneasy heart.
OK, I want to summarize some points about IPV6, because I haven't any material on hand, so...
1)the changes of standard header of IP.In IPV6, the standard header's length is always 40 bytes.It only includes some important infomation.
2)follwing the standard header is the extended header or upper protocol data.We can get the type form the NEXT field of the standard header.Also, we can get the following next extended header's type form NEXT field in each extended header, which lies in the first byte of the header. In RFC, the sequence of all extended header is advised to follow, but in the source code, it does not make any check about that, so I think it is not compusive.
3)The length of each header is not the same, and the methods to get it are different. Most header follows the formula: length = (len + 1)<<3, in which the 'len' is the value of the second byte of the header, likes HOP, DEST. In the case of AUTH header, the '3' will be changed into 2.And for FRAG header, the length is a constant : 8.
4)The mechanical of fragment is the most changes.But some colleages says that IPV6 will not surport fragment, I donot know. The mechanical is some complex, I will explain it next time.I just want to say something about the extended header.As said above, the length of FRAG header is a constant.The 'NEXT' field tells us the NEXT header in the original integrity packet, not the header following this FRAG header. And in most times(all the times?), the data following the FRAG header is just some data which is not follow any forms of known header, except the first fragment packet.So we can say that the if there is a FRAG header, it is the last one?
5)There is a special type of extended header: NONE(59), which means the current header is the last extended header.If the NEXT field's value is NONE, there is none data following header. I guess there maybe special use of that, but I donnot know about it yet.