Looks good to me..

Thanks
Senthil

On 2/10/14 6:46 AM, "[email protected]" <[email protected]> wrote:

>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

Reply via email to