On 03 Jan 2012, at 04:31 , Philip Homburg wrote: > In your letter dated Mon, 2 Jan 2012 19:21:45 -0500 you wrote: >> I have been told of real-world IPv6 deployments >> where the link MTU is smaller than 1280, >> while the limited link bandwidth makes adding a new >> segmentation protocol layer impractical. I believe >> these account for some of the 576 byte or 512 byte >> advertised Link MTU sizes in IPv6 PMTU "Too Big" >> messages that are seen in the real world. > > So if you run TCP over such a link then you an get > extra overhead of more than 60 octets (IPv6 header + TCP header) > compared to a link with an MTU of 1280. For UDP > the amount is about the same (IPv6, fragment header, UDP header). > > And you are saying that that sort of overhead > doesn't warrant finding an unused bit somewhere > to signal an adaptation layer?
Of course an adaptation layer has various costs beyond a single bit, but please also consider the case where there are no unused bits at hand. I'm saying the folks responsible for such links tell me they have looked into it in detail, tell me they looked at the whole problem including all of the system impacts and costs, and tell me that they concluded that it was MUCH better to continue to use IPv6 without adaptation layer overhead. Reports say their current approach is operationally very workable (i.e. with the IPv6 Fragment Header) and that multiple vendors' products work well in their deployment. I'll note that RFC-1883, Section 5 specified a minimum IPv6 Link MTU of 576 octets. If that number had not later been changed, then we would not be having this discussion. The choice of minimum IPv6 Link MTU is necessarily somewhat arbitrary. Different numbers are optimal for different deployments. It is merely sad that the IETF chose such a large number. The other approach I've heard about being taken for working over small MTU links is simply to perform (one-way) IPv6->IPv4 protocol translation, since IPv4 works natively on links that small. It seems sad that the IETF decision is pushing people towards a protocol translation approach. I can't blame the operations folks responsible for such deployments; they are simply trying to move their bits reliably and cost-effectively. Yours, Ran -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
