bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces

[Dan Lukes]

The following reply was made to PR bin/111493; it has been noted by GNATS.

From: Dan Lukes <dan at obluda.cz>
To: Vernon Schryver <vjs at calcite.rhyolite.com>
Cc: bms at incunabulum.net, carlson at workingcode.com,
        freebsd-gnats-submit at 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