Re: [Int-area] [Softwires] Is it feasible to perform fragmentation on UDP encapsulated packets.

[[e-mail]]

> <Note that I have changed the subject of the email hence it has nothing to do with the WG adoption call now. It's just a discussion on a particular issue which is related to those WGs which are working on UDP tunnels. The reason for containing the old email is to use it as a background which may be useful for better understanding of this particular issue>
> 
> The possible side-effect of performing fragmentation on UDP encapsulated packets is to worsen the reassembly burden on tunnel egress since fragments of UDP encapsulated packets are more likely to be forwarded across different paths towards the tunnel egress than those of IP or GRE encapsulated packets.
> 
> It seems that most X-over-UDP proposals choose to prohibit the tunnel ingress from performing fragmentation on UDP encapsulated packets. See the following quoted text regarding fragmentation from those X-over-UDP drafts:
> 
> LISP:
> 
> When an ITR receives a packet from a site-facing interface and adds H
>   octets worth of encapsulation to yield a packet size greater than L
>   octets, it resolves the MTU issue by first splitting the original
>   packet into 2 equal-sized fragments.  A LISP header is then prepended
>   to each fragment.
> 
> VXLAN:
> 
> VTEPs MUST NOT fragment VXLAN packets.  Intermediate routers may
>   fragment encapsulated VXLAN packets due to the larger frame size.
>   The destination VTEP MAY silently discard such VXLAN fragments.
> 
> VXLAN-GPE:
> 
> VTEPs MUST never fragment an encapsulated VXLAN GPE packet, and when
>   the outer IP header is IPv4, VTEPs MUST set the DF bit in the outer
>   IPv4 header.
> 
> GEVENE:
> 
>   To prevent fragmentation and maximize performance, the best practice
>   when using Geneve is to ensure that the MTU of the physical network
>   is greater than or equal to the MTU of the encapsulated network plus
>   tunnel headers.
> 
> GUE:
> 
>    If a packet is fragmented before encapsulation in GUE, all the
>    related fragments must be encapsulated using the same source port
>    (inner flow identifier). An operator may set MTU to account for
>    encapsulation overhead and reduce the likelihood of fragmentation.
> 
> GRE/UDP
> 
> Regarding packet fragmentation, an encapsulator/decapsulator SHOULD
>   be compliant with [RFC7588] and perform fragmentation before the
>   encapsulation.
> 
> However, the above choice seems conflict with the requirements as described in https://tools.ietf.org/html/draft-ietf-intarea-tunnels-02
> 
> 
> I wonder whether the IETF should reach a consensus on whether or not the fragmentation on UDP encapsulated packets should be allowed.

Having just implemented fragmentation and reassembly support in a MAP BR...

MAP does IPv4 over IPv6 tunnels with shared IPv4 address (aka routing on ports).

- Inner IPv4 fragmentation is relatively easy, cause you don't need to reassemble you can do virtual reassembly
- Outer IPv6 reassembly is much harder, cause you have to do it on the tunnel egress.

It is not possible to implement reassembly complying with IETF RFCs.
The IPv4 reassembly buffer is specified in IPv4 as 15 seconds, in IPv6 as 60 seconds.
My implementation does upwards of 100Mpps, you do the numbers.

If you can:
 - Guarantee always in sequence
 - Maximum fragment chain of 2
 - Maximum time and packet gap between first and last fragment of _very_small_

Then sure it is implementable, but if not then you're just setting yourself up for a DOS attack.
And if you have that much control over the environment, just increase the MTU in the tunnel domain.

Code is here:
https://git.fd.io/cgit/vpp/tree/vnet/vnet/map/ip6_map.c#n530

So in short, IETF can say whatever they like, that's not going to change reality.

Best regards,
Ole