Subject: RE: Fragmented IPv6 packets

From: "Nuno Garcia" <[email-masked]>
Date: Fri, 16 Dec 2005 11:42:46 -0000

Hi there:

I believe the issue is not about fragmentation.

The minimum Maximum Transmission Unit (MTU) of 1280 stated in RFC 2460 does not stops IPv6 packets to be smaller that 1280 octets - what it does say is that any link that is supposed to convey IPv6 packets must accept packets that are at least as big as 1280 octets - what the RFC says is that if an IPv6 node has a path MTU smaller that 1280 octets, then the IPv6 packets must be fragmented/reassembled at a layer bellow IPv6. 

Actually, is kind of dumb to have a protocol that defines packets to be as big as 64K and then mostly uses only 1500 bytes, but that another story, and btw, this was already true for IPv4... Ethernet issue I suppose...

So, if a given payload is to conveyed over a network whose path MTU is 1280 (but it can be bigger, as far as I know, there is no upper limit) the sender fragments the payload and encapsulates it in IPv6 packets whose size is 1280 octets. This does not mean that the last (or any) packet cannot be 100 octets long, it only says that an IPv6 node, after running Path MTU Discovery (RFC1981), must fragment its payloads as to make the IPv6 packets as big as the discovered MTU.

So here are my 2 cents, hope it helps, and I take this occasion to wish you all a very Happy Season, and a wonderful 2006.

Greetings!

Nuno Garcia
PhD Student 
SIEMENS S.A.
INFORMATION and COMMUNICATIONS * RESEARCH and DEVELOPMENT 1 * RESEARCH 

Rua Irmãos Siemens, 1
Ed. 1, Piso 0
Alfragide
2720-093 Amadora
Portugal 

Phone: +351-21 416 7159
Fax: +351-21 424 2082 
e-mail: [email-masked] 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: quinta-feira, 15 de Dezembro de 2005 19:20
To: [email-masked]; [email-masked]
Subject: RE: Fragmented IPv6 packets

The mandate is on the fragmentation is on the transmitting side (the one that applies the fragmentation). The receiving side may reassemble these packets. From at least one implementation (Open BSD) there is no such check.
Also the TAHI test doesn't test for this case.
All of the above and the common sense says that the receiver should assemble these packets.

Hope this helps!
Shuki

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, December 09, 2005 1:42 AM
To: [email-masked]
Subject: Fragmented IPv6 packets

I have a question on IPv6 fragments.  Since IPv6 mandates a minimum MTU of 1280,  IPv6 fragments (except the last fragment) should be of minimum 1280 bytes right? When an end host receives an IPv6 fragment which is lesser than 1280 bytes ( except the last fragment ) , should it treat it as invalid and drop it or should it still consider the fragment for reassembly. Are there any IPv6 implementations which reassemble them?

Thanks,
Muthu

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 16 Dec 2005 19:46:35 +0000

Hi.

Related matters have been discussed in connection with potential 
security problems mainly on the v6ops list.

Some thoughts below...

Regards,
Elwyn Davies

>I believe the issue is not about fragmentation.
As RFC2460 stands at the moment, there is no constraint on how a packet 
that needs to be fragmented should be split up.  Clearly the last 
fragment is generally going to be smaller than the path or link MTU (the 
full packet is very unlikely to divide up evenly into MTU sized 
pieces).  This is not a problem because there is no minimum size 
specified for an IPv6 payload (indeed you can send an IPv6 packet with 
*no* payload).

Currently, there is no requirement for the fragments before the last to 
be any particular size and it is entirely up to the implementation how 
an oversize packet should be broken up into fragments. This means that 
at present an implementation has to accept fragments, however small.

As was discovered with IPv4, allowing a packet to be divided into very 
small fragments can be a security problem.  Two hazards are that (1) 
with large numbers of fragments the reconstruction buffers may be 
overflowed and (2) the first fragment may not contain the information 
needed by middleboxes that are looking at transport port numbers for 
traffic classification. [A related problem, which has nothing to do with 
size of packets, is that RFC2460 does not forbid overlapping fragments.  
This can be a major security hazard but in practice many implementations 
will reject overlapping fragments.]

In my opinion, it would be desirable to at least recommend that all 
fragments before the last are (say) 1024 octets or longer in length.  
This would mean that even with a couple of tunnel headers added the 
packet would not exceed the smallest possible MTU and so it would not be 
necessary to mandate Path MTU discovery for fragmented packets.  Of 
course an implementation which does path MTU discovery on a path could 
send larger fragments if it knows the MTU is larger than 1280 octets.  
If this was recommended, receivers would be allowed to drop small 
fragments and avoid the security problems.  I have not researched what 
the fragmentation policies are used by the various implementations 
(which I ought to do) - this constrains to some extent what can be done 
for backwards compatibility.

>Actually, is kind of dumb to have a protocol that defines packets to be as big as 64K and then mostly uses only 1500 bytes, but that another story, and btw, this was already true for IPv4... Etherne…
Indeed:  Some higher speed versions of Ethernet can use larger frame 
sizes, but Ethernet doesn't handle fragmentation so it is up to IP (v4 
and v6) to fit its packets to the Ethenet frame size.  In fact if you 
look at IPv6 the default behaviour is closely fitted to using an 
Ethernet L2 (things like the MTU and the use of link local multicast for 
configuration).  Other types of L2 just have to conform (or be adapted).

>So, if a given payload is to conveyed over a network whose path MTU is 1280 (but it can be bigger, as far as I know, there is no upper limit) the sender fragments the payload and encapsulates it in…
As mentioned above, actually '.. make the IPv6 packets no larger than 
the discovered MTU'.