On Jun 3, 2012, at 11:20 PM, Jimmy Hess wrote:
If one is so stupid to just block ICMP then one should also accept that one loses functionality. ICMP tends to get blocked by firewalls by default; There are legitimate reasons to block ICMP, esp w V6. Security device manufacturers tend to indicate all the "lost functionality" is
On 6/3/12, Jeroen Massar <jeroen@unfix.org> wrote: optional functionality not required for a working device.
If you feel the need to block ICMP (I'm not convinced this is an actual need), then you should do so very selectively in IPv6. Blocking packet too big messages, especially is definitely harmful in IPv6 and PMTU-D is _NOT_ optional functionality. Any firewall/security device manufacturer that says it is will not get any business from me (or anyone else who considers their requirements properly before purchasing).
If the people in the IETF would have decided to inline the headers that are ICMPv6 into the IPv6 header then there for sure would have been people who would have blocked the equivalent of PacketTooBig in there too. As long as
Over reliance on "PacketTooBig" is a source of the problem; the idea that too large packets should be blindly generated under ordinary circumstances, carried many hops, and dropped with an error returned a potentially long distance that the sender in each direction is expected to see and act upon, at the expense of high latency for both peers, during initial connection establishment.
Actually, this generally will NOT affect initial connection establishment and due to slow start usually adds a very small amount of latency about 3-5kb into the conversation.
Routers don't always know when a packet is too big to reach their next hop, especially in case of Broadcast traffic, so they don't know to return a PacketTooBig error, especially in the case of L2 tunneling PPPoE for example, there may be a L2 bridge on the network in between routers with a lower MRU than either of the router's immediate links, eg because PPP, 802.1p,q + MPLS labels, or other overhead are affixed to Ethernet frames, somewhere on the switched path between routers.
That is a misconfiguration of the routers. Any routers in such a circumstance need their interface configured for the lower MTU or things are going to break with or without ICMP Packet Too Big messages because even if you didn't have the DF bit, the router has no way to know to fragment the packet. An L2 device should not be fragmenting L3 packets.
The problem is not that "Tunneling is bad"; the problem is the IP protocol has issues. The protocol should be designed so that there will not be issues with tunnelling or different MRU Ethernet links.
And there are not issues so long as things are configured correctly. Misconfiguration will cause issues no matter how well the protocol is designed. The problem you are describing so far is not a problem with the protocol, it is a problem with misconfigured devices.
The real solution is for reverse path MTU (MRU) information to be discovered between L3 neighbors by L2 probing, and discovered MRU exchanged using NDP, so routers know the lowest MRU on each directly connected interface, then for the worst case reduction in reverse path MTU to be included in the routing information passed via L3 routing protocols both IGPs and EGPs to the next hop.
This could compensate for some amount of misconfiguration, but you're adding a lot of overhead and a whole bunch of layering violations in order to do it. I think it would be much easier to just fix the configuration errors.
That is, no router should be allowed to enter a route into its forwarding table, until the worst case reverse MTU is discovered, to reach that network, with the exception, that a device may be configured with a default route, and some directly connected networks.
I don't see how this would no cause more problems than you claim it will solve.
The need for "Too Big" messages is then restricted to nodes connected to terminal networks. And there should be no such thing as packet fragmentation.
There should be no such thing as packet fragmentation in the current protocol. What is needed is for people to simply configure things correctly and allow PTB messages to pass as designed. Owen