[153257] in North American Network Operators' Group
Re: IPv6 day and tunnels
daemon@ATHENA.MIT.EDU (Jeroen Massar)
Mon Jun 4 02:42:10 2012
In-Reply-To: <CAAAwwbWqM0PZXVg+wTsuCJgoZjXU444_JZuHfPaMWNRHdJvCNw@mail.gmail.com>
From: Jeroen Massar <jeroen@unfix.org>
Date: Sun, 3 Jun 2012 23:41:24 -0700
To: Jimmy Hess <mysidia@gmail.com>
Cc: North American Networking and Offtopic Gripes List <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.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 o=
ne
>> 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 I=
Pv6, chose wisely. There are several RFCs pointing out what one could and wh=
at one Must never block. Packet Too Big is a very well known one that one sh=
ould not block.
If you decide to block anyway then well, your problem that your network brea=
ks.
> 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 thou=
gh ;)
>> If the people in the IETF would have decided to inline the headers that a=
re
>> ICMPv6 into the IPv6 header then there for sure would have been people wh=
o
>> would have blocked the equivalent of PacketTooBig in there too. As long a=
s
>=20
> 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 ha=
ppen 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, =20
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 a=
bout 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 w=
hen received.
If your medium is <1280 then your medium has to solve the fragging of packet=
s.
> 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 some=
thing a lot of operators would like to do let alone see in their networks. S=
imilar to you not wanting ICMP in your network even though that is the agree=
d 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 th=
en process and answer PtBs on the edge. Your network, your problem that you w=
ill 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 y=
our imaginary network...
Greets,
Jeroen
