Subject: IPv6 message size with OpenBSD. Is it a must that IPv6 packet len gth will be a multiply of 8?

From: "sasson, shuki" <[email-masked]>
Date: Thu, 20 Feb 2003 11:24:51 -0500

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

Hi all, observing the code of OpenBSD and also trying it, I see that the
code takes care that the IPv6 packet length will be a multiplication of 8.
I read the IPv6 RFC 2460 and I didn't see ant restriction there that
suggests that the IPv6 packet length should be a multiplication of 8.
Does any of you have an idea why is that?
Can I safely send IPv6 packet with a length that is not a multiplication of
8 and make a better use of the MTU?

Example:: In a system where the MTU is 1500 the Ethernet packet sent in
OpenBSD systems are 1510 instead of 1514 thus a loss of additional 4 bytes
as a result.

Your help is appreciated,

Shuki Sasson
Principal Engineer, Network Storage Group
	EMC²  		
where information lives

Phone: 508 305 8515
FaxNo: 508 435 8901
Pager: 877 919 0794
Email:  [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 21 Feb 2003 15:21:56 +0100 (CET)

> 8 and make a better use of the MTU?

This is confusing. You talk about IP, but what you really mean is TCP.
IP can't modify packet sizes: it must always use the exact size of the
payload data because there is no provision for padding the payload. But
TCP gets to divide the data over multiple packets. If a TCP
implementation decides it is more efficient to use multiples of 8 bytes
for the payload than fill up the maximum packet size, it is free to do
so. (For sending. For receiving it just has to take whatever the other
end sends as long as it's within the maximum segment size.)

I did some tests with www.netbsd.org (assuming they use their own stuff
for their web server) and I don't see what you're talking about:

13:58:07.491586 3ffe:2500:310:1:203:93ff:fec5:2d28.49510 > www.netbsd.org.http: S [tcp sum ok] 579406933:579406933(0) win 32768 <mss 1433,nop,wscale 0,nop,nop,timestamp 1240432902 0> (len 40, hlim 64)
13:58:07.785009 www.netbsd.org.http > 3ffe:2500:310:1:203:93ff:fec5:2d28.49510: S [tcp sum ok] 2373548153:2373548153(0) ack 579406934 win 32768 <mss 1440,nop,wscale 0,nop,nop,timestamp 19282560 1240432902> (len 40, hlim 56)
13:58:08.261964 www.netbsd.org.http > 3ffe:2500:310:1:203:93ff:fec5:2d28.49510: . 1:1209(1208) ack 494 win 33120 <nop,nop,timestamp 19282561 1240432902> [flowlabel 0x83ed9] (len 1240, hlim 56)

And it seems they play fast and loose with the specs in v4:

14:45:56.117122 torreya.muada.com.49566 > www.netbsd.org.http: S [bad tcp cksum 8118!] 452120277:452120277(0) win 32768 <mss 1457,nop,wscale 0,nop,nop,timestamp 1240438638 0> (DF) (ttl 64, id 12748, len 60)
14:45:56.288690 www.netbsd.org.http > torreya.muada.com.49566: S [tcp sum ok] 192546578:192546578(0) ack 452120278 win 32768 <mss 1460,nop,wscale 0,nop,nop,timestamp 19288297 1240438638> (ttl 51, id 17146, len 60)
14:45:56.612624 www.netbsd.org.http > torreya.muada.com.49566: . 1:1449(1448) ack 303 win 33580 <nop,nop,timestamp 19288298 1240438639> (ttl 51, id 17162, len 1500)

I don't get why they send the MSS option if they're going to ignore it
anyway.