IPv6 day and tunnels

Jimmy Hess mysidia at gmail.com
Mon Jun 4 06:20:32 UTC 2012


On 6/3/12, Jeroen Massar <jeroen at unfix.org> 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
optional functionality  not required for a working device.

> 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.

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.

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.

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.

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.

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.


--
-JH




More information about the NANOG mailing list