Subject: [Softwires] MAP-E - Ticket #21: Fragmentation must not be handled according to RFC 2473

From: Ole Troan <[email-masked]>
Date: Thu, 24 Jan 2013 12:01:09 +0100

hi,

Ticket #21 states (http://trac.tools.ietf.org/wg/softwire/trac/ticket/21)

----
The current MAP-E specifications says (sec. 10.1):
"Multiple BRs using the same anycast source address could send fragmented packets to the same CE at the same time. If the fragmented     packets from different BRs happen to use the same fragment ID, incorrect reassembly might occur."

Reason for this is that RFC 2473 says, in sec. 7.2:
"When an IPv4 original packet enters a tunnel, if the original packet size exceeds the tunnel MTU ...if in the original packet header the Don't Fragment - DF - bit flag is CLEAR, the tunnel entry-point node encapsulates the original packet, and subsequently fragments the resulting IPv6 tunnel packet into IPv6 fragments that do not exceed the Path MTU to the tunnel exit-point."

Incorrect reassembly is unacceptable but support of duplicated BRs is really needed, for scalability and relaiability.

Fortunately, the solution used in 4rd can be used in MAP-E too (R-13 of sec. 4.5.1): when a fragmentable IPv4 packet is too large for encapsulation in a single IPv6 packet, it MUST be fragmented in IPv4 BEFORE submission to encapsulation. This being done, RFC-2473 fragmentation never occurs. Multiple BRs can use the same anycast source address without risk of incorrect reassembly. 
----

I see a few possible resolutions to this ticket.

0) declare changes to how RFC2473 specifies fragmentation to be done for IPv4 over IPv6 tunnels out of scope
1) reference 4459 and suggest section 3.4 as a potential workaround, without being normative.
2) adopt R-13 from http://tools.ietf.org/html/draft-ietf-softwire-4rd-04
3) split the IPv6 fragmentation-id space between BRs

any views on this?

Best regards,
Ole