Ole,

I think the document is also lacking an analysis on the
implications of 6rd using anycast in the presence of IPv4
fragmentation.

When CE C sends IPv6-in-IPv4 encapsulated packets to the
6rd anycast address, and it sets DF=0 on the outer header,
there is a chance that if fragmentation occurs in the SP
network that the fragments of the same datagram could go
to different 6rd BRs. If that happens, some pieces of a
fragmented packet could end up in the reassembly cache of
BR A and others in the reassembly cache of BR B. But, as
long as any routing oscillations are short-lived, this
should not present a major problem since the reassemblies
at A and B will simply time out, and C will simply notice
that a packet has been lost.

When multiple IPv6 sources outside the 6rd domain (e.g, S1
and S2) send IPv6 packets toward C, however, the flow from
S1 may traverse BR A while the flow from S2 may traverse BR
B. In that case, if A and B are using the 6rd anycast address
as the outer IPv4 source address, and if there is chance of
fragmentation within the SP network, the fragments of S1's
packets could easily be misassociated with the fragments of
S2's packets. In that case, there is very real opportunity
for data corruption which could escape detection by upper
layer checksums.

This suggests to me that CE C SHOULD NOT set DF=0 in the
IPv6-in-IPv4 packets it sends to the 6rd anycast address
and that BRs A and B MUST NOT set DF=0 in the IPv6-in-IPv4
packets they source from the 6rd anycast address.

For further consideration, I have seen advertisements
to the effect that certain SPs will soon be offering
much higher data rate services. In that case, there
may be opportunity for undetected data corruption when
DF=0 even if the 6rd anycast address is not used for
either the source or destination.

This suggests to me that setting DF=0 should be
strongly discouraged within 6rd domains. This also
means that the domain of applicability of 6rd should
be restricted only to those networks that can pass
minimum-MTU IPv6-in-IPv4 packets (1280 + 20) without
fragmentation in the network. Unless of course SEAL
is used; in that case, DF=0 would be appropriate and
there is no limitation to the domain of applicability.

Fred
[email protected] 
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to