If the recommended MTU was dropped, the frag changes probably wouldn't be needed.
If the recommended MTU was dropped, could we raise the recommended MTU again later, on some evidence based process to confirm how its working? If this was only a recommendation, would it be enough? No code changes required: totally in the hands of operators and host configuration. Can be done on BSD and Linux systems trivially. APNIC has been running some of its web services on a dropped MTU for some time. It definitely reduced the incidence of pMTU related fail-to-fetch over V6 which we were seeing. (a bunch of people in Europe were seeing this facing us. We have seen this facing sites like ISOC and the IETF, in times past, as a result of dual-stacking) On Wed, Jun 26, 2013 at 9:23 AM, Randy Bush <ra...@psg.com> wrote: > > while the practical global MTU for IPv4 remains larger, then I would > > say that pretty much serves as a guarantee that the transition from > > IPv4 to IPv6 cannot ever be successful. > > i had a semi-discussion with olaf kolkman, who was saying dnssec and > ipv6 were slow and steady transitions. i pointed out that dnssec, with > all its warts, was forward compatible and there was no visible > alternative. ipv6, otoh, is incompatible on the wire and to the user, > and there are viable, though disgusting, alternatives, nat. > > i am not optimistic. in our second system syndrome religious ferver, we > have left the customer behind. if we have any last chance, it is to > make it as absolutely easy as possible for folk running ipv4 to add > ipv6, no excuses, no self-righteous crap, no ivory tower. all speed > bumps must br removed. > > st00pid terribly trivial example. why do i have to install a second > dhcp server for v6? why does the default one not do both? so building, > testing, installing, dhcpv6 goes on the enterprise's mess of a ipv6 > transition pert chart and the perceived cost goes up. and no, dhcp- > based enterprises are not gonna transition to stateless, i said no > religion. > > ron is actually deploying ipv6 in enterprises to see what his customers > are seeing, eating his own dogfood. he did not field this draft for his > amusement or to get his name on an rfc. > > randy > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
