What are the modern OS policies regarding IPv6 fragmentation?_问答_开发者

I'd like to know - if one writes a simple packet analyzer capable to deal with IPv6 which would analyze traffic collected between Windows (Vista or higher) and RHEL5 machines - what are the chances to see fragmented IPv6 packets there, i.e. that fragmentation of IPv6 packets would be performed by these OSes?

I know that technically it can be there and is described in RFCs, but taking in mind开发者_StackOverflow中文版 fragmentation-related security risks known from IPv4 era - I wonder - why wouldn't modern network stacks just drop IP6 fragmentation functionality at all? Why do we still need it, tunneling or something?

Update: as I mentioned above, IP fragmentation poses security risks. Here are the links to support that statement:

IP fragmentation attacks
Security Considerations for IP Fragment Filtering
Handling of Overlapping IPv6 Fragments

edited from original: OK, so IPv6 routers cannot fragment packets, they are dropped and a ICMPv6 packet-too-big is returned. This means end nodes perform negotiation on link MTU. However this all describes the link layer, as per OSI the higher layers shouldn't have to concern themselves with all the details of the lower layers.

Consider in IPv4 hardware may support jumbograms upto 9,000 bytes but datagram size can reach to 64KB. With TCP the OS can use the underlying link size and optimally carve up the data-stream, all well and good. With UDP however there is limited support for handling such negotiation above the system administrator noticing an issues and re-configuring software.

So say you have some software with a fixed datagram size of 8,000 bytes, to migrate from IPv4 to IPv6 there is the choice of fragmenting if the end-to-end MTU is say only 1,500 bytes, or dropping everything. In a nice cleanup you are asking to drop fragmentation completely, but this would break the application requiring a rewrite of more than just the socket init handling.

IPv6 is still IP, the idea isn't to break everything, the changes presented though drop all the features that affect performance: recommending a 1,500 minimum (like 576 in IPv4, cf 68/1,280 abs. min), not fragmenting en route.

Cisco page detailing various MTU limits due to ASIC hardware:

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml

Examples

On Linux 2.6.38-10-generic with IPv4 and IPv6. IPv4 shows the fragmentation in Wireshark, IPv6 is only showing application layer fragmentation.

tcpdump shows this:

11:13: IP aiko.hk.miru.hk.37505 > 239.192.0.1.7600: UDP, length 1972
11:13: IP aiko.hk.miru.hk.37505 > 239.192.0.1.7600: UDP, length 1117
11:15: IP6 fe80::230:1bff:feb7:a209.51993 > ff08::1.7600: UDP, length 1137

The packets are PGM above UDP above IPv4 or IPv6. 3,000 byte payload with 2,000 byte MTU so there should be IP fragmentation and PGM fragmentation.

In Linux IPv6 packets will be sent fragmented if an upper layer provides a packet larger than the discovered link MTU, this will not happen for TCP.

If any application ever attempts to produce a UDP datagram using IPv6 over a standard Ethernet connection (disabled jumbo frames), with a total payload (including headers) greater than 1500 bytes, then you will be guaranteed to see fragmentation at the IPv6 layer.

The stack may choose to start inserting fragments sooner, starting at a total payload (including headers) of as little as 1280 bytes, depending on the results of path MTU analysis.

By doing this with IPv6 you will break:

ICMP, UDP, TCP forwarders, TCP implementations which retransmit a previously sent frame in fragments due to receipt of packet too big and any other IP layer protocol expecting to be able to transmit message of size > MTU lacking protocol specific fragmentation layer.

UDP especially is huge. There are deployed systems that depend on this working for which there is no alternative solution. You might break some SIP or SNMP however for the most part it is able to be configured and worked around with knobs. Other protocols such as RADIUS offer no such options and will simply break with no recourse.