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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------