IPv6 day and tunnels

Mon Jun 4 07:01:34 UTC 2012

On Jun 3, 2012, at 11:20 PM, Jimmy Hess wrote:

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