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

[James Carlson]

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

From: James Carlson <carlsonj at workingcode.com>
To: Vernon Schryver <vjs at calcite.rhyolite.com>
Cc: dan at obluda.cz, bms at incunabulum.net, 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 15:26:14 -0400

 Vernon Schryver writes:
 > > 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.
 
 Agreed, at least for the well-known multicast ranges that aren't
 forwarded, but I'm not sure if that's the point.
 
 The standard (RFC 2453) makes it fairly clear that you're supposed to
 accept messages sent to either the well-known multicast address or a
 valid unicast address.  It doesn't appear to say that an
 implementation must treat point-to-point specially.
 
 On the Solaris variant of this code, we do the following:
 
   - For RIP-1, we send our periodic unsolicited Response messages
     (advertisements) to the unicast address of the peer, or
     255.255.255.255 if no such address is available on that link.
 
   - For RIP-2, we send advertisements to the RIP-2 multicast address,
     or to the peer's address no_rip_mcast is set.  (For the special
     case of no_rip_mcast and no peer address, we would use
     255.255.255.255.)
 
   - We allow the actual address to be overridden on a per-interface
     basis via the "rip_neighbor=x.x.x.x" option in /etc/gateways.
 
 We chose those defaults because they seem the most natural.  Multicast
 might not mean anything special on the link itself, but it is a little
 special for applications.
 
 We've done a fair amount of compatibility testing, and I don't know of
 any issues with the default above.  The Zebra/Quagga code seems to
 perform similarly: it checks if the interface supports multicast
 (IFF_MULTICAST) before bothering to check whether it's point-to-point.
 
 >  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.
 
 One key difference is that unicast IP messages can be accidentally
 forwarded by innocent misconfigurations, while 255.255.255.255 and
 link-local multicast must not be.
 
 > > > 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.
 
 I don't think it makes much difference, really.
 
 However, given a customer who wants multicast messages over point-to-
 point links, I'll send them if the sending is easy.
 
 > > 	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?
 
 I don't know.  I do know that Solaris has long lacked GRE (we have
 IP-IP only), so I don't have access to any good information about it.
 
 > 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?
 
 They won't break Solaris.  (Though I agree that there's some
 suspicious use of parenthesis here.)
 
 -- 
 James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>