Hi Washam, > -----Original Message----- > From: WashamFan [mailto:[email protected]] > Sent: Wednesday, March 03, 2010 6:13 PM > To: Templin, Fred L > Cc: Brian E Carpenter; [email protected] > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > > 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.
Reducing the IP_ID range on each BR would increase the incidence of reassembly errors at high data rates [RFC4963]. So, I'm not sure new patch-type mechanisms like this would be all that helpful without taking the full step of going to something like SEAL. AFAICT, that just means that, under the current 6rd mechanisms, SP networks that want to have their BR's use an anycast source address had better ensure that the tunnels won't ever fragment. 6rd BRs that use anycast can help by setting DF=1. > > 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. PMTUD within end sites *has* to work in order for there to be any measure of robustness. Customer end systems and middleboxes that filter ICMPs are only hurting themselves and need to change their ways. That said, I believe the reason for asking the CE to advertise 1480 internally to the customer site is to minimize the incidence of invoking PMTUD. Otherwise, customer end systems would be constantly sending 1500 packets initially which would be thrown away by the CE until PMTUD kicks in. As I mentioned however, the issue with advertising the 1480 is that it would cause an MTU reduction even for communications that never leave the end site. Customers with 9K links might not like that. Thanks - Fred [email protected] > washam _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
