Re: IPv6 day and tunnels

[Jeroen Massar <jeroen () unfix org>]

On 3 Jun 2012, at 23:20, Jimmy Hess <mysidia () gmail com> wrote:

> On 6/3/12, Jeroen Massar <jeroen () 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

Which firewall product does that?

> ; There are
> legitimate reasons to block ICMP, esp w V6.

The moment one decides to block ICMPv6 you are likely breaking features of IPv6, chose wisely. There are several RFCs 
pointing out what one could and what one Must never block. Packet Too Big is a very well known one that one should not 
block.

If you decide to block anyway then well, your problem that your network breaks.

>   Security device
> manufacturers tend to indicate all the  "lost functionality"  is
> optional functionality  not required for a working device.

I suggest that you vote with your money and chose a different vendor if they shove that through your throat. Upgrading 
braincells is another option though ;)

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

High latency? You do realize that it is only one roundtrip max that might happen and that there is no shorter way to 
inform your side of this situation?

> Routers don't always know when a packet is too big to reach their next
> hop,  especially in case of Broadcast traffic,  

You do realize that IPv6 does not have the concept of broadcast do you?! ;)

There is only: unicast, multicast and anycast
(and anycast is just unicast as it is a routing trick)

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

If you have a broken L2 network there is nothing that an L3 protocol can do about it.
Please properly configure it, stuff tend to work better that way.

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

There is no issue as long as you properly respond with PtB and process them when received.
If your medium is <1280 then your medium has to solve the fragging of packets.

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

You do realize that NDP only works on the local link and not further?! ;)

Also, carrying MTU and full routing info to end hosts is definitely not something a lot of operators would like to do 
let alone see in their networks. Similar to you not wanting ICMP in your network even though that is the agreed upon 
standard.

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

If you want this in your network just configure it everywhere to 1280 and then process and answer PtBs on the edge. 
Your network, your problem that you will never use jumbo frames.

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

The fun thing is though that this Internet thing is quite a bit larger than your imaginary network...

Greets,
 Jeroen