What if packet size cannot be represented as a value divisible by 8?

Tags:
Packet fragmenation networking
Packet Fragmentation
Packets
Suppose a packet contains 23 bytes of data, and the MTU of the network is 1024 bytes. We have to make sure the data is divisible by 8. But in this case, that is not possible since if the data is represented as 24 bytes,there will be an extra byte (where do we get it from?) and if the data is represented as 16 bytes, we will face a problem as 7 bytes are still remaining. What do we do.
ASKED: May 18, 2009  5:33 AM
UPDATED: May 28, 2009  11:47 AM

Answer Wiki

Thanks. We'll let you know when a new response is added.

I would think that you would pad the payload with leading 0s to make it divisible by 8… It will still be the same number.

If I try to read between the lines of your question I am led to think you are also asking what if your packet goes above the MTU. If it goes above the MTU, the packet will be fragmented by the first device who’s MTU is too small, and then re-assembled at the destination.

Discuss This Question: 5  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • BlankReg
    The IP protocol defines that the packet is padded with 0's to make it up to the minimum size allowed, if the data portion and header would not be this size on their own. This is done automatically by the IP software. They are not leading 0's, they go at the end of the data, so they have no significance to the contents.
    12,325 pointsBadges:
    report
  • Jfernatt
    Hmm... A couple of things need clarification... My assumption is that TC is needing to craft the packets themselves. According to RFC791 (I'm quoting this alot lately I know haha) the header will be padded to the next 32 bit boundary, but nothing is said about the payload. The closest thing I can seem to find is how RTP handles padding which is adding trailing zeros and then the last byte describes how many 0s were used for padding (which is far from automatic) My assumption was that if TC needed to craft a packet and needed to easily pad the packet without affecting the actual value of the data to ensure the payload fell on the 8 bit boundary then leading 0s would do the trick. Blank, I have actually looked around quite a bit to try and see if I can find documentation on how IP handles padding the payload (if at all) and haven't been able to find anything other than for padding the header. Could you share any RFC that you know of that references this?
    605 pointsBadges:
    report
  • BlankReg
    I bow to your superior knowledge Jfernatt. I am sure you are right, that any padding needed goes at the end of the header, and not after the data. I was thinking about an Ethernet frame, but made the assumption that we were talking about IP, which the original question did not mention, and managed to get that bit wrong anyway. Is the padding only relevent to the options, as the rest of the header is a full 20 bytes and doesn't change from that unless there are options included ? Two bad points made by me. Tut tut, shame on the Reg :-( I will risk all and have another go. Looking at the original question properly. The 'M' in MTU is the maximum, so it does not apply here. Most media types have a minimum size requirement, so this is where we will possibly need to pad. And it is this that I am fairly certain will pad after the data to make it up to the minimum frame size. But I am also not so sure that any protocol insists on there being an even number of bytes. Jfernatt may know if IP insists on this, but I am not so sure it would need to for any reason ? If you can specify the length of the IP datagram, then an odd number of bytes should be OK, and I am sure it can be. An interesting discussion, and I am learning as well :-)
    12,325 pointsBadges:
    report
  • Jfernatt
    There are also a couple of things I had not thought about when I posted for clarification, and also a couple of things I discovered while trying to figure out the correct answer to this question and now I have more questions myself. One thing I did not think about was the fact that any implementation is going to need some sort of transport protocol. Which still leaves me with the same questions but takes us to a different layer. I have not found anything about IP requiring the payload to be padded but what does have me scratching my head is that the total length field in the IP header defines the packet length in octets. Does this mean that the implementation would have to be smart enough to go ahead and pad the data? Or does it even matter? Maybe a packet capture will help shed some light Blank I've also enjoyed the discussion and it's helping me learn too. If you find anything interesting post it up :)
    605 pointsBadges:
    report
  • BlankReg
    I guess it would be the layer 2 that would pad this, as it will depend on the media as to what minimum size it would need to be. Then calculate the CRC and send it. At the other end, this will probably get passed up to the layer 3 protocol, but it will ignore anything after the packet length it expects, or is told about in the L3 header. ? I think you are right, getting some capture data, with minimum size packets might give a better clue.
    12,325 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following