Hi, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Ole Troan > Sent: Friday, February 05, 2010 4:12 AM > To: Satoru Matsushima > Cc: [email protected]; [email protected] > Subject: Re: [Softwires] Fwd: I-D Action:draft-ietf-softwire-ipv6-6rd-04.txt > > >> it is expected that path MTU discovery works in the IPv6 Internet (sic!) > > > > The purpose of this specification is for avoiding PMTU at least the LAN > > side hosts of 6rd CPE. > > Is this correct? > > that's correct. > > cheers, > Ole
Regarding the 6rd MTU, I am going to replay a post I just made on softwire wrt to a related issue: http://www.ietf.org/mail-archive/web/softwires/current/msg01186.html I will make a very few minor revisions to the text in terms of 6rd below to show that the two cases (and their respective implications for MTU determination) are really one and the same:: Begin replayed post (with minor rewording for 6rd): *************************************************** Setting a reduced MTU on the 6rd CE router LAN interface seems like a safe option at face value, but can lead to undesirable inefficiencies. Consider for example the diagram below: L1 L2 | | W --|--R--|--CE1======BR2-- < IPv6 > --Z | | (ISP Network) < Internet > X--| L4, L5, Y--| L6, etc. Here, we have a tunnel between 'CE1' and 'BR2' over the ISP network to the IPv6 Internet. 'CE1' sets a reduced MTU 'M' on its LAN interface connected to link 'L2', and also advertises 'M' in the Router Advertisements it sends on 'L2'. Hosts 'X' and 'Y' pick up the reduced MTU from the RA and limit the size of the packets they send to at most 'M' bytes. But, host 'W' connected to link 'L1' does not see the MTU reduction, and hence will routinely send packets larger than 'M' to any hosts beyond router 'R' such as 'X', 'Y' and 'Z'. These packets will be dropped with an ICMPv6 PTB returned, then 'W' will be forced to reduce its packet size and retransmit. The only way to prevent this is to drive the reduced MTU 'M' deeply into the entire network stacked up behind 'CE1', which may contain arbitrarily many additional routers and links. Now, even if the reduced MTU 'M' were propagated deeply throughout the 'CE1' network, if most communications remain localized hosts would only be able to use a packet size of at most 'M' even if their links natively support a much larger MTU. Consider for example that link 'L2' in the diagram has a native MTU of 9kb, but the effective MTU across the 'CE1'===='BR2' tunnel is only 1400. 'CE1' will advertise 1400 on link 'L2', and communications between hosts 'X' and 'Y' will be restricted to using at most 1400 byte packets when they could have used 9kb. There are a couple of factors to consider in terms of what might be a better solution. First, what are the expected data rates over the 'CE1'===='BR2' tunnel, and second what are the performance characteristics of those gateways? If the data rates are such that GW1 and GW2 are already operating at their peak performance even without taking on any additional processing overhead, then the best solution would be to make sure that all links over which the tunnel might travel (e.g., 'L4', 'L5', 'L6', etc.) are large enough to "hide" the tunnel encapsulation artifact. For example, if all links 'L4' 'L5', 'L6', etc. configure a native MTU of no smaller than 1600 and the encapsulation overhead for the tunnel is 100 bytes, then all routers and hosts on the LAN side of 'CE1' would be able to happily use a 1500 MTU. If the MTUs of 'L4', etc. cannot be controlled, however, then there is no recourse but to set the reduced MTU on the CE1 LAN interface and cope with the inefficiencies. On the other hand, if the data rates across the tunnel are nominal and/or 'CE1' and 'BR2' have more than sufficient processing capability to take on a modest amount of additional overhead, the tunnel can use tunnel fragmentation so that 'CE1' can present a solid MTU on its LAN side interface that does not reflect the size of the tunnel encapsulation headers. If the tunnel fragmentation could accommodate an MTU of at least 1500 in this way, then 'CE1' would be able to observe the "de facto Internet cell size" of 1500. If we further assume that the vast majority of hosts in the world today either limit their packet sizes to no more than 1500 bytes or are willing to assume the risk of silent loss of packets larger than 1500 due to MTU restrictions, then there is no need to place artificial restrictions on the size of packets that can be used within the 'CE1' network. This latter class of hosts (those that send packets larger than 1500) would be best served to use their own host-based MTU probing mechanisms for sending packets larger than 1500 in case the network is somehow silently dropping PMTUD messages. RFC4821 was specifically designed for this purpose. End result - whenever it is practically possible, tunnel routers such as CE1 and BR2 should use tunnel fragmentation and hosts should use RFC4821. Fred [email protected] _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
