Hi Ole, > -----Original Message----- > From: Ole Troan [mailto:[email protected]] On Behalf Of Ole Troan > Sent: Thursday, March 04, 2010 12:16 PM > To: Templin, Fred L > Cc: WashamFan; [email protected] > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > > Fred, > > [...] > > >> 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. > > I can remove the sentence recommending advertising the tunnel MTU on the > LAN-side interface. or > change it from a SHOULD to a MAY. as you say this is just to minimize the > incidence of invoking > PMTUD.
Removing the sentence might be best. The MAY would be OK, but then you might need to also say something like: "(Note that advertising the tunnel MTU on the LAN-side interface would cause all hosts attached to the link to use a reduced MTU even for link-local communications.)" > it should be rare that path MTU discovery doesn't work on the first hop. If by first hop you mean exiting the customer network and entering the tunnel interface, then I agree. However, over-reliance on PMTUD has negative implications also, including degraded efficiency. Worst case is for short transactions (e.g., http over VPN) where up to 2x as many packets as necessary would be used. Also, setting a conservative fixed MTU on the tunnel interface would make it very difficult to go back and set a larger value later. This, I think, is a key question for how we want to see the IPv6 service deployed: if we want to go out with a robust MTU service in the first iteration, then we have the tools at hand to do so. Otherwise, we wait for the SP network to turn up IPv6 on all of their routers. Turning to SEAL again for the moment, SEAL is about more than just PMTUD. SEAL provides a way for tunnel endpoints to prevent source address spoofing even if the SP network itself has insufficient mitigations. That might possibly be even better than what we can do with native IPv6. Fred [email protected] > cheers, > Ole _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
