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

[Vernon Schryver]

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

From: Vernon Schryver <vjs at calcite.rhyolite.com>
To: dan at obluda.cz
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 18:56:55 GMT

 > From: Dan Lukes <dan at obluda.cz>
 > To: Vernon Schryver <vjs at calcite.rhyolite.com>
 > CC: freebsd-gnats-submit at FreeBSD.org, bms at incunabulum.net,
 >         carlson at workingcode.com
 
 > > If an interface is point-to-point (it sets the IFF_POINTOPOINT bit),
 > > is it right to send to the RIPv2 multicast address?
 >
 > 	Why not ?
 > 	To send or not to send the multicast is question related to "is 
 > supported or is not supported multicasting on interface". It isn't 
 > related to question "is the interface of type X".
 
 Multicasting makes no sense to me on an interface that is really a
 point-to-point link between two systems.  All IP packets sent from one
 system always go to the other system.  Any IP packet that one system
 does not want to send to the other should not be sent.  Whether the
 destination IP address is in the multicast class as is irrelevant as
 whether the address is 255.255.255.255, some other broadcast address,
 an IP address of the remote system, or some other address.  It makes
 no sense to me to set both the IFF_POINTOPOINT and IFF_MULTICAST bits
 on an interface.
 
 Of course, I am not suggesting that the FreeBSD GRE code should be
 changed.  Whether it is right or wrong, it is what it is and will not
 change.
 
 
 > > Even on a GRE tunnel, why isn't it better to unicast to the router at
 > > the other end of the tunnel instead of multicasting?
 >
 > 'it is better' and 'it is right' is questions of wo different 
 > categories. The answer for the first is "yes, there is no reason to 
 > forbid multicast addresses on P2P interface when if network stack 
 > support it". There is no reason to punish GRE users even if we don't 
 > like the protocol personally.
 
 Adding to a program risks breaking something.
 
 It is not clear to me that sending RIPv2 packets unicast through GRE
 tunnels punnishes anyone.  It might, but I don't know.
 
 
 > 	The answer for the second is not simple. "Better" is subjective 
 > category - I don't know the all details of all network specifications of 
 > all networks.
 >
 > 	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.
 Do any existing installations using `routed` and GRE tunnels depend on
 RIPv2 packets being sent unicast?
 
 
 > 	The descripion "of the failuter" is simple. The administrator of other 
 > side use not FreeBSD nor your routed. 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.
 >
 > 	I don't want dispute about it's mad policy decision. 
 
 I also do not want to argue with the other person.  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.
 
 I am not saying that this particular firewall rule is bad.  I do not
 know whether it is good or bad.  I am only saying that the mere existence
 of a firewall rule at one site should not convince anyone of anything.
 
 
 >                                                       I dislike the GRE 
 > tunnels as you.
 
 I lack enough experience with GRE tunnels to have an opinion about them.
 
 
 > 	Despite of it, there is no technical reason not to allow RIPv2 
 > multicasting over a multicast capable interface, so the statement about 
 > incomplete implementation seems to be true.
 >
 > 	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 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.
 
 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.
 
 
 Vernon Schryver    vjs at rhyolite.com