Re: Spurious MTU in IPv6 RAs Where WAN is PPPoE
On 9 jul 2011, at 15:51, Sabahattin Gucukoglu wrote: You're invited to file a report with http://bugreport.apple.com about this. Be sure to explain why fixing the broken path MTU discovery in the network is not an option and requiring the AirPort user to know enough about IPv6 router advertisement MTU options to set the value properly is an appropriate mitigation. This is bug #9739722, Airport: Configurable IPv6 RA link-MTU or MSS Clamping. Severity 2. THIS IS A BAD IDEA. MSS clamping is modifying packets exchanged between consenting hosts. As a rule the network doesn't get to do this. Unfortunately the situation with IPv4 is so bad that it's not realistically possible to avoid this when you have a path MTU smaller than 1500. But with IPv6 we have a new chance to punish the people creating the problem rather than the ones implementing PMTUD properly, so The Right Thing To Do is NOT fix any PMTUD breakage in properly behaving systems, but rather push people that configure their systems incorrectly to fix this. And it seems to be working, PMTUD black holes happen with IPv6, but they're relatively rare. Advertising MTUs smaller than 1500 when the uplink has an MTU smaller than 1500 is completely unnecessary because IPv6 has good path MTU discovery and doing this also limits the size of packets exchanged locally. Advertising an MTU of 1500 is also not proper behavior, BTW. However, I do think that it's a good idea for makers of home routers to allow users to set the MTU advertised in RAs to anything between 1280 and 1500 (inclusive, assuming ethernet), but this should not be done by default. I still plan to get http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-03 published at some point and having widespread reduced MTUs advertising in RAs means one more hurdle to an internet with larger packets. This is something that's sorely needed: 100 gigabit ethernet transmits more than two average sized IP packets in the time 10 megabit ethernet sends one bit with the current average packet size of ~ 500 bytes. Despite the fact that virtually all hardware supports larger packets these days. But unfortunately our friends over at the IEEE aren't in the position to increase the ethernet maximum packet size because that would break backward compatibility (of course with every new standard they create new stuff that's going to break if they eventually do it, those NE2000 cards aren't an issue anymore today). So if anyone is going to do it it's going to be us here at the IETF because unlike ethernet, IP allows for some parameter exchange between hosts during neighbor discov ery (or ARP). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Spurious MTU in IPv6 RAs Where WAN is PPPoE
Iljitsch van Beijnum wrote: But with IPv6 we have a new chance to punish the people creating the problem rather than the ones implementing PMTUD properly, so The Right Thing To Do is NOT fix any PMTUD breakage in properly behaving systems, but rather push people that configure their systems incorrectly to fix this. Let's see the reality. IPv6 is broken to request packet too big ICMPs must be generated even against multicast packets, which causes serious periodic ICMP implosions when MTUs are, because of tunneling, below 1500 near many receivers and is 1500 at a sender and other part of the network. It means that rational operators MUST filter some ICMP and, not surprisingly, some operators will block all ICMP or all packet too big ICMPs, which means PMTUD won't work. Who are the people to be punished for creating the problem? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Spurious MTU in IPv6 RAs Where WAN is PPPoE
On 10 jul 2011, at 17:20, Masataka Ohta wrote: I was wondering what kind of unique perspective you would have here, and I wasn't disappointed: It means that rational operators MUST filter some ICMP and, not surprisingly, some operators will block all ICMP or all packet too big ICMPs That is more or less ok as long as they don't send any packets larger than 1280 bytes. If you want to send 1281-byte packets you MUST use PMTUD and thus you MUST accept incoming packet too big messages. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Spurious MTU in IPv6 RAs Where WAN is PPPoE
Iljitsch van Beijnum wrote: I was wondering what kind of unique perspective you would have here, and I wasn't disappointed: You always outperform me with your imagination. It means that rational operators MUST filter some ICMP and, not surprisingly, some operators will block all ICMP or all packet too big ICMPs That is more or less ok as long as they don't send any packets larger than 1280 bytes. That's not an assumption on end users' behavior rational operators can rely on. If you want to send 1281-byte packets you MUST use PMTUD and thus you MUST accept incoming packet too big messages. End users might think they can, but operators won't, accept them. Note that it's operators who filter. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Spurious MTU in IPv6 RAs Where WAN is PPPoE
On 6 Jul 2011, at 22:52, Sabahattin Gucukoglu wrote: On 6 Jul 2011, at 19:03, james woodyatt wrote: You're invited to file a report with http://bugreport.apple.com about this. Be sure to explain why fixing the broken path MTU discovery in the network is not an option and requiring the AirPort user to know enough about IPv6 router advertisement MTU options to set the value properly is an appropriate mitigation. Thank you, and what should the severity of the bug be? This is bug #9739722, Airport: Configurable IPv6 RA link-MTU or MSS Clamping. Severity 2. Hurricane Electric very generously lowered my tunnel's MTU to 1476 bytes IPv6 payload, so I'm now back on the IPv6 Internet again. (Yay!) There is still one important detail to clear up, though. My ISP, BT Infinity Business in the UK, seems to be ensuring that its links do not overflow by Clamping the MSS option in TCPv4 SYN packets to 1400, and no sight of ICMPv4 Datagram too large and DF set messages. Can I take it for granted that you didn't choose the same value, or do a similar terrible thing, in the Airport products? I don't have any other PPPoE servers to try it on. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
