On 05  Aug 2013, at 05:14 , Ole Troan wrote:
> that would also be a significant change in the IPv6 architecture.

Actually, suggesting that hosts need to be able to perform
reassembly (which what I was suggesting) is NEITHER an 
architectural change NOR a change to existing IPv6 host requirements, 
because IPv6 hosts ALREADY have to be able to reassemble an IPv6 
packet from fragments.

For example, consider that an original NFS/UDP/IPv6 frame might be 
larger than link MTU (e.g. in a tunnelled environment with some 
DSL/PPPoE encapsulation overhead), relying upon IPv6 fragmentation 
inside the originating host to be sent through to the destination 
host.

At the point that a receiving host is receiving fragments, each
received fragment will have an IPv6 Fragmentation Header.  The
process of reassembly within a destination is identical,
regardless of who sent the packet to that receiver.  

Kindly note that I have implementation experience with this 
in 4.4 BSD, in Cisco IOS, and in another IPv6 implementation.  
The receiving system's reassembly procedure does not care why 
it is receiving fragments, and does not need to care why, 
because the reassembly process is identical.  Reassembly is 
computationally expensive, of course, which is why I earlier said 
I thought it desirable to pursue the ideas from C.M. Heard et alia.

RFC-2460 covers reassembly by hosts in a lot of detail, 
primarily in Section 4.5, but also in other places.  
There can be no doubt that IPv6 hosts already are
required to be able to perform IPv6 fragment reassembly.

Some example text fragments (supporting the notion that IPv6
hosts ALREADY need to support reassembly) from RFC-2460 follow...

RFC-2460, page 18:
        "In order to send a packet that is too large to fit 
        in the MTU of the path to its destination, a source node 
        may divide the packet into fragments and send each fragment 
        as a separate packet, to be reassembled at the receiver."

RFC-2460, page 21:
        "At the destination, fragment packets are reassembled 
        into their original, unfragmented form, as illustrated:
        ..."

RFC-2460, page 24:
        "In order to send a packet larger than a path's MTU, a node 
        may use the IPv6 Fragment header to fragment the packet at 
        the source and have it reassembled at the destination(s).  
        However, the use of such fragmentation is discouraged in any 
        application that is able to adjust its packets to fit the 
        measured path MTU (i.e., down to 1280 octets).

RFC-2460, page 25:
        "A node must be able to accept a fragmented packet that, 
        after reassembly, is as large as 1500 octets.  A node is 
        permitted to accept fragmented packets that reassemble 
        to more than 1500 octets.  An upper-layer protocol or 
        application that depends on IPv6 fragmentation to send 
        packets larger than the MTU of a path should not send packets 
        larger than 1500 octets unless it has assurance that the 
        destination is capable of reassembling packets of that 
        larger size."

Yours,

Ran Atkinson


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to