Hi Simon / Senthil,
Please see below.
Cheers,
Ian
>>>
>>> It's possible to do it correctly without waiting for all fragments
>>> (e.g., what Cisco calls "virtual reassembly"). My suggestion would be
>>>to
>>> steal the very carefully written text from RFC 6146, page 19.
>>
>> [ian] My apologies - I wasn¹t familiar with the Cisco feature that you
>> mentioned, so researched it and all of the information that I¹ve found
>>is
>> the Cisco VFR (virtual fragment reassembly).
>
>It's just an example. Maybe not well chosen, since I can't find
>documentation explaining exactly the behaviour I think it implements.
[ian] That’s what threw me.
OK, what about (for the whole of the lwB4 fragmentation section):
5.2.1. Changes to RFC2473 and RFC6333 Fragmentation Behaviour
5.2.1.1. Processing of Incoming IPv4 Fragments Encapsulated in IPv6
The following process for handling fragmented packets is taken from
Section 3.4 of [RFC6146], adapted for use with fragmentation of
encapsulated IPv4 tunnel traffic and NAPT44.
On receiving an encapsulated packet containing an IPv4 fragment,
then more processing may be needed than for non-fragmented payloads.
This specification leaves open the exact details of how the lwB4 handles
incoming encapsulated IPv6 packets containing IPv4 fragments, and
simply requires that the external behavior of the lwB4 be compliant
with
the following conditions: The lwB4 MUST handle encapsulated IPv4
fragments. In particular, the lwB4 MUST handle fragments arriving
out of order, conditional on the following:
* The lwB4 MUST limit the amount of resources devoted to the
storage of fragmented packets in order to protect from DoS
attacks.
* As long as the lwB4 has available resources, the lwB4 MUST
allow the fragments to arrive over a time interval. The time
interval SHOULD be configurable and the default value MUST be
of at least FRAGMENT_MIN.
* The lwB4 MAY require that the UDP, TCP, or ICMP header be
completely contained within the fragment that contains fragment
offset equal to zero.
For incoming packets carrying TCP or UDP IPv4 fragments with a
non-zero
checksum, after de-capsulation, the lwB4 MAY elect to queue the
fragments as they arrive and perform NAPT44 on all fragments at
the same time. In this case, the incoming 5-tuple is determined
by extracting the appropriate fields from the received packet.
Alternatively, a lwB4 MAY translate the de-capsulated fragments as
they arrive, by storing information that allows it to compute the
5-tuple for fragments other than the first. In the
latter case, subsequent fragments may arrive before the first, and
the rules (in the bulleted list above) about how the lwB4 handles
(out-of-order) fragments apply
For incoming de-capsulated IPv4 packets carrying UDP packets with
a zero checksum, if the lwB4 has enough resources, the lwB4 MUST
reassemble the packets and MUST calculate the checksum. If the
lwB4 does not have enough resources, then it MUST silently
discard the packets. The handling of fragmented and un-fragmented
UDP packets with a zero checksum as specified above deviates from
that specified in [RFC6145].
Implementers of an lwB4 should be aware that there are a number of
well-known attacks against IP fragmentation; see [RFC1858] and
[RFC3128]. Implementers should also be aware of additional issues
with reassembling packets at high rates, described in [RFC4963].
5.2.1.2. Processing of Outbound IPv4 Packets Requiring Fragmentation for
Encapsulation
When an lwB4 receives an IPv4 packet from a connected host that
exceeds the IPv6 MTU size after encapsulation, the lwB4 SHOULD
fragment the IPv4 packet before encapsulation. This lwB4 behavior
avoids IPv6 fragmentation, so that the lwAFTR is not required to
re-assemble fragmented IPv6 packets. If the the Don't Fragment (DF)
bit is set in the IPv4 packet header (e.g. for PMTUD discovery), then
the IPv4 packet is dropped by the lwB4 and an ICMP Fragmentation
Needed (Type 3, Code 4) with the correct tunnel MTU is sent.
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
