 




<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: What if packet size cannot be represented as a value divisible by 8?</title>
	<atom:link href="http://itknowledgeexchange.techtarget.com/itanswers/what-if-packet-size-cannot-be-represented-as-a-value-divisible-by-8/feed/" rel="self" type="application/rss+xml" />
	<link>http://itknowledgeexchange.techtarget.com/itanswers/what-if-packet-size-cannot-be-represented-as-a-value-divisible-by-8/</link>
	<description></description>
	<lastBuildDate>Thu, 23 May 2013 23:54:02 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: blankreg</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/what-if-packet-size-cannot-be-represented-as-a-value-divisible-by-8/#comment-64022</link>
		<dc:creator>blankreg</dc:creator>
		<pubDate>Thu, 28 May 2009 11:47:28 +0000</pubDate>
		<guid isPermaLink="false">#comment-64022</guid>
		<description><![CDATA[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.]]></description>
		<content:encoded><![CDATA[<p>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. ?</p>
<p>I think you are right, getting some capture data, with minimum size packets might give a better clue.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jfernatt</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/what-if-packet-size-cannot-be-represented-as-a-value-divisible-by-8/#comment-63985</link>
		<dc:creator>jfernatt</dc:creator>
		<pubDate>Wed, 27 May 2009 17:57:27 +0000</pubDate>
		<guid isPermaLink="false">#comment-63985</guid>
		<description><![CDATA[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&#039;ve also enjoyed the discussion and it&#039;s helping me learn too.

If you find anything interesting post it up :)]]></description>
		<content:encoded><![CDATA[<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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</p>
<p>Blank I&#8217;ve also enjoyed the discussion and it&#8217;s helping me learn too.</p>
<p>If you find anything interesting post it up <img src='http://itknowledgeexchange.techtarget.com/itanswers/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: blankreg</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/what-if-packet-size-cannot-be-represented-as-a-value-divisible-by-8/#comment-63950</link>
		<dc:creator>blankreg</dc:creator>
		<pubDate>Tue, 26 May 2009 17:45:25 +0000</pubDate>
		<guid isPermaLink="false">#comment-63950</guid>
		<description><![CDATA[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&#039;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 &#039;M&#039; 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 :-)]]></description>
		<content:encoded><![CDATA[<p>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&#8217;t change from that unless there are options included ?</p>
<p>Two bad points made by me. Tut tut, shame on the Reg <img src='http://itknowledgeexchange.techtarget.com/itanswers/wp-includes/images/smilies/icon_sad.gif' alt=':-(' class='wp-smiley' /> </p>
<p>I will risk all and have another go.</p>
<p>Looking at the original question properly. The &#8216;M&#8217; in MTU is the maximum, so it does not apply here. </p>
<p>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. </p>
<p>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. </p>
<p>An interesting discussion, and I am learning as well <img src='http://itknowledgeexchange.techtarget.com/itanswers/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jfernatt</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/what-if-packet-size-cannot-be-represented-as-a-value-divisible-by-8/#comment-63877</link>
		<dc:creator>jfernatt</dc:creator>
		<pubDate>Fri, 22 May 2009 16:27:10 +0000</pubDate>
		<guid isPermaLink="false">#comment-63877</guid>
		<description><![CDATA[Hmm... A couple of things need clarification... My assumption is that TC is needing to craft the packets themselves.

According to RFC791 (I&#039;m quoting this alot lately I know haha) the &lt;i&gt;header&lt;/i&gt; 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&#039;t been able to find anything other than for padding the header. Could you share any RFC that you know of that references this?]]></description>
		<content:encoded><![CDATA[<p>Hmm&#8230; A couple of things need clarification&#8230; My assumption is that TC is needing to craft the packets themselves.</p>
<p>According to RFC791 (I&#8217;m quoting this alot lately I know haha) the <i>header</i> will be padded to the next 32 bit boundary, but nothing is said about the payload. </p>
<p>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)</p>
<p>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.</p>
<p>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&#8217;t been able to find anything other than for padding the header. Could you share any RFC that you know of that references this?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: blankreg</title>
		<link>http://itknowledgeexchange.techtarget.com/itanswers/what-if-packet-size-cannot-be-represented-as-a-value-divisible-by-8/#comment-63854</link>
		<dc:creator>blankreg</dc:creator>
		<pubDate>Fri, 22 May 2009 06:48:03 +0000</pubDate>
		<guid isPermaLink="false">#comment-63854</guid>
		<description><![CDATA[The IP protocol defines that the packet is padded with 0&#039;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&#039;s, they go at the end of the data, so they have no significance to the contents.]]></description>
		<content:encoded><![CDATA[<p>The IP protocol defines that the packet is padded with 0&#8242;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&#8242;s, they go at the end of the data, so they have no significance to the contents.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

Page Caching using memcached
Database Caching 6/9 queries in 0.015 seconds using memcached
Object Caching 336/339 objects using memcached

Served from: itknowledgeexchange.techtarget.com @ 2013-05-23 23:59:48 -->