From owner-freebsd-bugs@FreeBSD.ORG Mon Jul 30 20:50:08 2007 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEEDF16A418 for ; Mon, 30 Jul 2007 20:50:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B3EBD13C4B0 for ; Mon, 30 Jul 2007 20:50:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l6UKo86V088704 for ; Mon, 30 Jul 2007 20:50:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l6UKo8LD088702; Mon, 30 Jul 2007 20:50:08 GMT (envelope-from gnats) Date: Mon, 30 Jul 2007 20:50:08 GMT Message-Id: <200707302050.l6UKo8LD088702@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Dan Lukes Cc: Subject: Re: bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dan Lukes List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2007 20:50:08 -0000 The following reply was made to PR bin/111493; it has been noted by GNATS. From: Dan Lukes To: Vernon Schryver Cc: bms@incunabulum.net, carlson@workingcode.com, freebsd-gnats-submit@FreeBSD.org Subject: Re: bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces Date: Mon, 30 Jul 2007 22:42:54 +0200 Vernon Schryver napsal/wrote, On 07/30/07 20:56: >> If you trust the administrator to decide on ethernet interface, I see >> no reason not to trust them on P2P interface as well. > > The issue has nothing to do with trusting administrators. It is whether > sending RIPv5 packets over interfaces with IFF_POINTOPOINT and IFF_MULTICAST > bits set to the RIPv2 multicast address will break any existing installaions. The issue has nothing to do with P2P interfaces. For the purpose of multicasting, the only relevant question is "is the interface multicast capable ?". The exact name of the interface nor the "has the interface some others characteristict, for example, is the interface POINTTOPOINT" has no reason to be counted. > It makes no sense to me to set both the IFF_POINTOPOINT and IFF_MULTICAST bits > on an interface. Are you sure you didn't mis something ? Your arguments says that packets of all types can be routed over P2P tunnel including multicast packets, so all IFF_POINTOPOINT are multicast capable and IFF_MULTICAST is redundant and not necesarry. Well. even if I agree with you, your code are not consistent with those arguments - althougt you say "all P2P interface are multicast capable" the code treat them as unicast only ... IMHO the IFF_POINTOPOINT and IFF_MULTICAST are not related flags. The first says something, the second something and no one of them imply the presence or absence the second ... > Do any existing installations using `routed` and GRE tunnels depend on > RIPv2 packets being sent unicast? I don't know. But if yes, the current routed can be forced to use unicast even over multicast capable interfaces. So if an instalation depend on RIPv2 unicast over GRE, it still be possible, with small change in configuration. The current code - if a instalation want's to use multicast RIPv2 over multicast capable interface, it's not possible now. >> It's policy is - RIPv2 on multicasts. The RIPv2 on unicasts are blocked by firewall. He says that RIPv2 daemon on multicast link shall be able to use multicast, unless it's implementation is incomplete. > However, that someone > has a firewall rule should not convince anyone of anything. For example, > the stupid firewall rules that block all ICMP packets do not imply that > ICMP should changed. Dealing with idiots who know far less than they > think they do might justify a new kind of path MTU discovery, but only > after careful consideration. Your example is carefully selected, but interpretation is bad. ICMP is part of IP implementation. If someone create an environment where ICMP are blocked or are not supported at all by network stack, then it has incomplete implementation and need await problems. It's exactly the problem with routed - RIPv2 is multicast capable protocol, GRE interface is multicast capable interface - but the routed code can't send multicast over it. The implemetation is incomplete. Imagine the DNS resolver that can use the TCP only althought the DNS protocol is defined over both TCP and UDP. It shall work as all servers must support the TCP - but it's incomplete. Not because someone mad on the way with misconfigured firewall blocks TCP communication to port 53 allowing the UDP only, but because DNS shall support UDP also. As a routed - RIPv2 has defined unicasts and multicasts as transport protocol. Even all the components of the systems support multicasting, the routed can unicast only. The point of the problem is not that there is someone mad with misconfigured firewall, but the fact the routed implementation of RIPv2 protocol is incomplete - it doesn't support multicasting over some multivcast capable interface. Not becasue the specific multicast interface needs specific handling, but because is excluded by programmers decision. > I am only saying that the mere existence > of a firewall rule at one site should not convince anyone of anything. But you are saying that the fact the interface is point-to-point shall convince the code programmer to ignore the fact the interface is multicast capable and shall be treated differently despite it can be services as standard multicast interface. For me, mad firewall rule and "ignore multicasting on m-cast capable itnerface because it's P2P class interface" are both arguments that I don't understand so much. >> The required changes in the current code is simple, but the final >> decision is yours. > > I am sure that your proposed changes work for you. The problem is > whether they would work for other people. Would they break existing > implementations? I'm sure you know I can't answer your question. I'm sure this question is relevant for most of changes in the code. Use the same procedure before committing changes as usually. > I have the impression from Cisco web pages that multicast does not work > by default through GRE tunnels on Cisco routers. If that is true, then > making `routed` use multicast instead of unicast would be a big mistake. There are configuration parametr "use unicasts even on multicast interface". It shall be used when administrator doesn't want to use multicast over multicast-capable interface. If I found and vendor of black-box router that will not support multicast on thernet - do you count it as argument to break support for multicasting from ethernet also ? > A small problem is that if IFF_MULTICAST should overried IFF_POINTOPOINT, > then perhaps the two main changes are not the best style. Perhaps > IFF_MULTICAST should be checked and handled before IFF_POINTOPOINT. The suggested patch tried to minimize the amount of changed code. The decision about the best style is sovereign decision of code maintainer. I have no problem with it. Please remember I'm not the native English speaker. Nothing in this email shall be considered as attack of any way. Even if you found some strong wording, it's unintentional consequence of it also. Dan -- Dan Lukes SISAL MFF UK AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz