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
