Hi Brian, > -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Tuesday, March 02, 2010 4:23 PM > To: Templin, Fred L > Cc: Rémi Després; [email protected] > Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > > Fred, > > I agree that distinguishing between pragmatic operational practices > (such as clamping the MTU) and generic solutions is correct, but > as far as the current last call goes, I think that leaving the generic > solution FFS is also correct.
Still, I think an applicability statement with disclosure of some of the limitations I cited would be appropriate. It's not that I think that aspects of 6rd would not fit into a generic solution (I do!) - it is rather that the current manifestation of 6rd is not in itself a generic solution. > I don't think the text in section 9.1 really needs changing. It > doesn't exclude future mechanisms, it simply recommends what to do > if there is no MTU discovery or management in place. Focusing solely on the section 9.1 text for now: + MTU and fragmentation issues for IPv6 in IPv4 tunneling are discussed + in detail in section 3.2 of RFC4213 [RFC4213]. 6rd's scope is limited + to a service provider network. IPv4 Path MTU discovery MAY be used + to adjust the MTU of the tunnel as described in section 3.2.2 of + RFC4213 [RFC4213] or the 6rd Tunnel MTU may be explicitly configured. RFC4213 cites limitations of the IPv4 Path MTU discovery method, which I assume is why the explicit configuration option is listed and examined more closely in the following: + If the MTU is well-managed such that the IPv4 MTU on the CE WAN side + interface is set so that no fragmentation occurs within the boundary + of the SP, then the 6rd Tunnel MTU should be set to the known IPv4 + MTU minus the size of the encapsulating IPv4 header (20 bytes). For + example, if the IPv4 MTU is known to be 1500 bytes, the 6rd Tunnel + MTU may be set to 1480 bytes. But with SEAL, there is no need for a clamped MTU limit and the tunnel MTU can be set to infinity. + Absent of more specific information + the 6rd Tunnel MTU SHOULD default to 1280 bytes. 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. 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. Fred [email protected] > Regards > Brian > > On 2010-03-03 05:51, Templin, Fred L wrote: > > Brian, > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On > >> Behalf Of Brian E > Carpenter > >> Sent: Tuesday, March 02, 2010 1:00 AM > >> To: Rémi Després > >> Cc: [email protected]; Templin, Fred L > >> Subject: Re: [Softwires] SOFTWIRE working group last call on 6rd > >> > >>> As far as 6rd is concerned, doing it right is IMO keeping it as is. > >> Yes, given that we have just been told at APRICOT that the vast majority > >> of Google and YouTube's IPv6 traffic comes from one particular ISP in > >> France. It's a real success story, with a clamped MTU. > > > > You are right that the MTU clamping seems to be the approach > > being advocated under 6rd, but I disagree that that is the > > best we can (or should) do. > > > > During the NGTRANS days, the ISATAP team was strongly required > > to include a "Domain of Applicability" statement, and I think > > the same should be required of 6rd. I see a number of aspects > > of 6rd that IMHO would limit its applicability, including: > > > > - IPv6 prefix tied to IPv4 address (renumbering implications) > > - potential black holes when ICMPs can't be translated > > - provider-aggregated addressing only (no provider-independent) > > - not compatible with multihoming via a single, stable IPv6 prefix > > - not compatible with traffic engineering (i.e., CE can't select > > specific BRs) > > - interactions with load balancing; ECMP within provider network > > - MTU clamping exposes degenerate MTUs to the customer network > > and doesn't allow for automatic discovery of larger MTUs > > - requires operators to exercise tight controls on link MTUs > > - requires operators to exercise tight controls on ICMP > > generation and ICMP filtering > > > > So, while I see the 6rd stateless prefix delegation as a > > highly desirable contribution, I think the implications > > of these limitations should somehow be captured in an > > applicability statement the same as was required for the > > NGTRANS mechanisms. > > > > Thanks - Fred > > [email protected] > > > >> Brian > >> _______________________________________________ > >> Softwires mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/softwires > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
