Hi, > Setting SEAL aside and considering only the existing > Section 9.1 text, no discussion of v6/v4 tunnel MTU is > complete without also examining the setting of the DF bit > in the IPv4 header. In particular, when the 6rd BR uses > an anycast address as the IPv4 source address, it truly > cannot allow fragmentation on the outer packet since that > could easily result in fragment misassociation within a > CE's reassembly buffer. > > For example, if BRs A and B both use the same IPv4 source > address X and destination address Y, then happen to also > choose the same IP_ID, any fragments from A would be > indistinguishable from B's fragments, and CE Y could be > left with a dangerous reassembly misassociation that > evades upper layer integrity checks. So, the document > should say that BRs that use an anycast source address > MUST set DF=1.
Or we fix this problem by some measures. How about allocating different IP_ID range for each BR? Although it might entail modification on BRs. > Yes, this means that BR use of an anycast source address > would be incompatible with IPv4 networks that mis-manage > their MTUs and/or include links with MTUs smaller than 1280. > This is not a show-stopper at all, but simply another bullet > for inclusion in an applicability statement. > > + A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined > + automatically or configured directly, on the LAN side by setting > the > + MTU option in Router Advertisements [RFC4861] messages to the 6rd > + Tunnel MTU. > > Here, hosts connected to the LAN that receive the RA MTU > option will be stuck with a degenerate MTU (1480) even for > communications that do not leave the LAN. This means that > even if the LAN supports a 9KB MTU any hosts that receive > the MTU option will only ever be able to talk to each other > using 1480. The other issue is that the customer's network > may have an arbitrarily-complex topology of additional links > and routers. So, unless the 1480 is somehow propagated deeply > into the customer network, hosts connected to those links > will not observe the MTU clamping and continue to use > 1500+ packets. Why advertise WAN side MTU to LAN side? Doesn't routers advertise LAN MTU via RA? PMTU would work out the optimal MTU for end-to-end communication. washam _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
