>> 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.
the significant change to the architecture in your proposal, is that intermediate routers (in this case the tunnel ingress) are allowed to fragment packets. cheers, Ole > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
