[EMAIL PROTECTED] writes: > 1. PMTUD blocked by load balancing product
> so my suggestion is to make it impossible for users to block > ICMP need fragment messages. I don't see how you could enforce this on IP stacks everywhere. Anyway, I would make it difficult, but not impossible - easy to turn off only "unsafe" icmp, more work to turn off all icmp. MTU blackholing is unpleasant because admins at site A (with small MTU link) get complaints due to misconfiguration at site B. But nontechnical users at A only see that the website at B is viewable from their AOL dialup accounts, etc. so problem must be at site A. It helps for victims (site A) to have IP stacks that handle per interface and per destination MTU properly - which allows workaround of reducing MTU at end network. Also routers with IP stacks that allow clamping of MSS hint can help at site A. > 2. IPv6 DNS queries responded with wrong error > an (incorrect) example: spaceflight.nasa.gov. Again admins at site A have trouble providing good service to their users due to a problem at site B. Would it make sense to allow a tunable that would allow a dual-stack resolver to treat AAAA NXDOMAIN response as if it were empty NOERROR, as transitional workaround? Another thing to do is continue to raise awareness as in your email. For MTU, we used to refer remote admins to Marc Slemko's explanation, which is more tutorial than the rfc. Unfortunately the original is missing, but Google still has it: http://www.google.com/search?q=cache:-WajfjfglKYC:www.worldgate.com/~marcs/mtu/ Are there enough common IPv6 bugs for an informational rfc? --------------------------------------------------------------------- The IPv6 Users Mailing List Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
