Hi.
Related matters have been discussed in connection with potential
security problems mainly on the v6ops list.
Some thoughts below...
Regards,
Elwyn Davies
Nuno Garcia wrote:
Hi there:
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.
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...
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 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.
As mentioned above, actually '.. make the IPv6 packets no larger than
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 PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: quinta-feira, 15 de Dezembro de 2005 19:20
To: [EMAIL PROTECTED]; ipv6@ietf.org
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 PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, December 09, 2005 1:42 AM
To: ipv6@ietf.org
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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
