From dan@kulesh.obluda.cz  Wed Apr 11 23:03:09 2007
Return-Path: <dan@kulesh.obluda.cz>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id D624616A400
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 11 Apr 2007 23:03:09 +0000 (UTC)
	(envelope-from dan@kulesh.obluda.cz)
Received: from smtp1.kolej.mff.cuni.cz (smtp1.kolej.mff.cuni.cz [195.113.24.4])
	by mx1.freebsd.org (Postfix) with ESMTP id 65EF713C4B8
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 11 Apr 2007 23:03:08 +0000 (UTC)
	(envelope-from dan@kulesh.obluda.cz)
Received: from kulesh.obluda.cz (openvpn.ms.mff.cuni.cz [195.113.20.87])
	by smtp1.kolej.mff.cuni.cz (8.13.8/8.13.8) with ESMTP id l3BN35pC069775
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 12 Apr 2007 01:03:07 +0200 (CEST)
	(envelope-from dan@kulesh.obluda.cz)
Received: from kulesh.obluda.cz (localhost. [127.0.0.1])
	by kulesh.obluda.cz (8.13.8/8.13.8) with ESMTP id l3BN34Ts051685
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 12 Apr 2007 01:03:04 +0200 (CEST)
	(envelope-from dan@kulesh.obluda.cz)
Received: (from root@localhost)
	by kulesh.obluda.cz (8.13.8/8.13.8/Submit) id l3BN34fm051684;
	Thu, 12 Apr 2007 01:03:04 +0200 (CEST)
	(envelope-from dan)
Message-Id: <200704112303.l3BN34fm051684@kulesh.obluda.cz>
Date: Thu, 12 Apr 2007 01:03:04 +0200 (CEST)
From: Dan Lukes <dan@obluda.cz>
Reply-To: Dan Lukes <dan@obluda.cz>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [ PATCH ] routed doesn't use multicasts for RIPv2 via P2P interfaces
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         111493
>Category:       bin
>Synopsis:       [patch] routed(8) doesn't use multicasts for RIPv2 via P2P interfaces
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Apr 11 23:10:00 GMT 2007
>Closed-Date:    
>Last-Modified:  Sun Mar 17 04:32:16 UTC 2013
>Originator:     Dan Lukes
>Release:        FreeBSD 6.2-STABLE i386
>Organization:
Obludarium
>Environment:
System: FreeBSD 6.2-STABLE
src/sbin/routed/output.c,v 1.12 2005/05/31 20:28:48


>Description:
	RIPv2 should use multicasts when possible. Current code test IFF_MULTICAST
on IFF_BROADCAST interfaces only. It doesn't use multicast on non-broadcast interfaces 
even they are multicast capable.

>How-To-Repeat:
	Configure RIPv2 on a multicast capable point to point link (GRE or so), use
tcpdump to see packets
>Fix:

	Honor the IFF_MULTICAST on IFF_POINTOPOINT interfaces also. 

	P2P logic follow the ethernet logic - multicasts are not used when:
1. P2P interface is not multicast capable
2. RIPv1 compatibility requested
3. disabled by configuration (no_rip_mcast configuration directive - note, 
    it's not new directive created by patch, it exist already)


--- patch-sbin-routed-output.c begins here ---
--- sbin/routed/output.c.ORIG	Tue May 31 22:28:48 2005
+++ sbin/routed/output.c	Wed Apr 11 22:26:59 2007
@@ -140,7 +140,7 @@
 		flags = MSG_DONTROUTE;
 		break;
 	case OUT_MULTICAST:
-		if (ifp->int_if_flags & IFF_POINTOPOINT) {
+		if (ifp->int_if_flags & IFF_POINTOPOINT && ! ifp->int_if_flags & IFF_MULTICAST) {
 			msg = "Send pt-to-pt";
 		} else if (ifp->int_state & IS_DUP) {
 			trace_act("abort multicast output via %s"
@@ -874,7 +874,13 @@
 		} else if (ifp->int_if_flags & IFF_POINTOPOINT) {
 			/* point-to-point hardware interface */
 			dst.sin_addr.s_addr = ifp->int_dstaddr;
-			type = OUT_UNICAST;
+
+			if (vers == RIPv2
+			    && !(ifp->int_state  & IS_NO_RIP_MCAST)) {
+				type = OUT_MULTICAST;
+			} else {
+				type = OUT_UNICAST;
+			}
 
 		} else if (ifp->int_state & IS_REMOTE) {
 			/* remote interface */
@@ -963,7 +969,17 @@
 		} else if (ifp->int_if_flags & IFF_POINTOPOINT) {
 			/* point-to-point hardware interface */
 			dst.sin_addr.s_addr = ifp->int_dstaddr;
-			type = OUT_UNICAST;
+
+			/* Broadcast RIPv1 queries and RIPv2 queries
+			 * when the hardware cannot multicast.
+			 */
+			if (buf.rip_vers == RIPv2
+			    && (ifp->int_if_flags & IFF_MULTICAST)
+			    && !(ifp->int_state  & IS_NO_RIP_MCAST)) {
+				type = OUT_MULTICAST;
+			} else {
+				type = OUT_UNICAST;
+			}
 
 		} else if (ifp->int_state & IS_REMOTE) {
 			/* remote interface */
--- patch-sbin-routed-output.c ends here ---


>Release-Note:
>Audit-Trail:

From: Bruce M Simpson <bms@incunabulum.net>
To: freebsd-gnats-submit@FreeBSD.org,  dan@obluda.cz
Cc:  
Subject: bin/111493: [PATCH] routed(8) doesn't use multicasts for RIPv2 via
 P2P interfaces
Date: Fri, 20 Jul 2007 14:39:40 +0100

 Dan,
 
 Have you submitted this fix upstream to the maintainer of routed at 
 Rhyolite.com?
 
 I would much prefer it gets fixed at source before doing a vendor branch 
 import.
 
 Thanks!
 BMS

From: Dan Lukes <dan@obluda.cz>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: bin/111493: [PATCH] routed(8) doesn't use multicasts for RIPv2
 via P2P interfaces
Date: Fri, 20 Jul 2007 18:10:30 +0200

 	I didn't know there is a upstream. The sources are not in 'contrib' 
 tree, nor has readme/LICENSE or other similar file containing 
 information that the software is not FreeBSD but contributed source. In 
 the fact, nothing in the sources nor Makefiles mention Rhyolite.
 
 	So - the short answer is "no".
 
 	I will send a notice about this PR to Vernon.
 
 					Dan

From: Dan Lukes <dan@obluda.cz>
To: freebsd-gnats-submit@FreeBSD.org, vjs@rhyolite.com
Cc: Bruce M Simpson <bms@incunabulum.net>
Subject: bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces
Date: Fri, 20 Jul 2007 18:18:42 +0200

 	Hi Vernon.
 
 	Acording to BMS request:
 
   -------------------
 Bruce M Simpson napsal/wrote, On 07/20/07 15:39:
 > Have you submitted this fix upstream to the maintainer of routed at 
 > Rhyolite.com?
 > 
 > I would much prefer it gets fixed at source before doing a vendor branch 
 > import.
 > 
 > Thanks!
 > BMS
   -------------------
 
 	... I would like to inform you about the bug-report/feature request 
 related to your's routed. Please review the request and suggested patch 
 (attached to request). Commit to sources if you like it then inform the 
 BMS about it.
 
 	The full text of report is accesible at
 http://www.freebsd.org/cgi/query-pr.cgi?pr=111493
 
 	Thank you for maintaining routed's code.
 
 	Sincerely
 
 					Dan
 
 
 
 -- 
 Dan Lukes                                               SISAL MFF UK
 AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz

From: Vernon Schryver <vjs@calcite.rhyolite.com>
To: dan@obluda.cz, freebsd-gnats-submit@FreeBSD.org
Cc: bms@incunabulum.net, carlson@workingcode.com
Subject: Re: bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces
Date: Sat, 21 Jul 2007 13:45:45 GMT

 I'm sending a copy of this to James Carlson, who knows a lot about the
 `routed` code.
 
 
 The description in 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=111493
 says:
 
     RIPv2 should use multicasts when possible. Current code test
     IFF_MULTICAST on IFF_BROADCAST interfaces only. It doesn't use
     multicast on non-broadcast interfaces even they are multicast
     capable.
 
 If an interface is point-to-point (it sets the IFF_POINTOPOINT bit),
 is it right to send to the RIPv2 multicast address?
 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?
 I have the impression that GRE tunnels are utterly wierd--is the
 remote IP address of the GRE interface not that of the remote router?
 
 
 I also wonder if the proposed patch does what it is intended to do.
 Consider the error of the missing () in the first change:
 
 @@ -140,7 +140,7 @@
                  flags = MSG_DONTROUTE;
                  break;
          case OUT_MULTICAST:
 -                if (ifp->int_if_flags & IFF_POINTOPOINT) {
 +                if (ifp->int_if_flags & IFF_POINTOPOINT && ! ifp->int_if_flags & IFF_MULTICAST) {
                          msg = "Send pt-to-pt";
 
 C precedence rules require that expression be parsed as
              (!ifp->int_if_flags) & IFF_MULTICAST
 ifp->int_if_flags never 0,
 and so (!ifp->int_if_flags) is always 0
 and so ((!ifp->int_if_flags) & IFF_MULTICAST) is always 0
 and so the first alternative will never be taken even for ordinary, non-GRE
 point-to-point interfaces.
 
 
 I would be happier about the proposed change (with the () error
 fixed) if there were a test case or at least a description of the
 failure with the current code.
 
 
 Vernon Schryver    vjs@rhyolite.com

Adding to audit trail from misfiled PR bin/114799:

Date: Sun, 22 Jul 2007 00:36:12 +0100
From: Bruce M Simpson <bms@incunabulum.net>
 
 Dan,
 
 Thanks for pointing this out. routed is a problematic case, because it 
 was added to FreeBSD historically before the contrib/ part of the tree 
 was populated.
 
 You are quite right there should be a README or other file to indicate 
 that it is in fact on a vendor branch - the only way to see this is if 
 you check cvs or cvsweb for history.
 
 I'm not 100% happy about routed being in the base system, however 
 various people expressed that it's the only tool we have in the tree for 
 IPv4 Router Discovery (rdisc) so we haven't moved it to ports.
 
 Thanks again
 BMS

From: Dan Lukes <dan@obluda.cz>
To: Vernon Schryver <vjs@calcite.rhyolite.com>
Cc: freebsd-gnats-submit@FreeBSD.org, bms@incunabulum.net,
        carlson@workingcode.com
Subject: Re: bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces
Date: Sun, 22 Jul 2007 21:24:57 +0200

 Vernon Schryver napsal/wrote, On 07/21/07 15:45:
 > 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".
 
 > 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.
 
 	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.
 
 > Consider the error of the missing () in the first change:
 > +                if (ifp->int_if_flags & IFF_POINTOPOINT && ! ifp->int_if_flags & IFF_MULTICAST) {
 
 	You are true.
 
 > description of the failure with the current code.
 
 	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 dislike the GRE 
 tunnels as you.
 
 	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.
 
 	Please note my knowledge of english language is far from perfect.
 
 					Dan
 

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

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

From: James Carlson <carlsonj@workingcode.com>
To: Vernon Schryver <vjs@calcite.rhyolite.com>
Cc: dan@obluda.cz, bms@incunabulum.net, freebsd-gnats-submit@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@obluda.cz>
 > > To: Vernon Schryver <vjs@calcite.rhyolite.com>
 > > CC: freebsd-gnats-submit@FreeBSD.org, bms@incunabulum.net,
 > >         carlson@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@workingcode.com>

From: Dan Lukes <dan@obluda.cz>
To: Vernon Schryver <vjs@calcite.rhyolite.com>
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

From: Vernon Schryver <vjs@calcite.rhyolite.com>
To: carlsonj@workingcode.com
Cc: bms@incunabulum.net, dan@obluda.cz, freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces
Date: Fri, 10 Aug 2007 02:39:32 GMT

 > To: Vernon Schryver <vjs@calcite.rhyolite.com>
 > Cc: dan@obluda.cz, bms@incunabulum.net, freebsd-gnats-submit@FreeBSD.org
 > From: James Carlson <carlsonj@workingcode.com>
 
 
 > 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.
 
 that's interesting.
 
 > 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.
 
 and I suppose static configuration instead of PPP negotiation of the peer
 IP address could let a point-to-point RIPv2 packet get forwarded instead
 of delivered to the PPP peer.
 
 Ok, I yield.
 
 What do you think of the enclose patch?  It differs from the original
 in two ways that should reduce behavior changes seen by people with
 IFF_POINTOPOINT interfaces without IFF_MULTICAST.  If it makes sense,
 I'll generate a bundle on http://www.rhyolite.com/src/
 
 
 Vernon Schryver    vjs@rhyolite.com
 
 
 *** /d/backups/day.5/usr/home/vjs/routed/output.c	Thu Nov 11 17:34:52 2004
 --- output.c	Fri Aug 10 02:26:09 2007
 *************** output(enum output_type type,
 *** 142,148 ****
   		flags = MSG_DONTROUTE;
   		break;
   	case OUT_MULTICAST:
 ! 		if (ifp->int_if_flags & IFF_POINTOPOINT) {
   			msg = "Send pt-to-pt";
   		} else if (ifp->int_state & IS_DUP) {
   			trace_act("abort multicast output via %s"
 --- 142,149 ----
   		flags = MSG_DONTROUTE;
   		break;
   	case OUT_MULTICAST:
 ! 		if ((ifp->int_if_flags & IFF_POINTOPOINT)
 ! 		    && !(ifp->int_if_flags & IFF_MULTICAST)) {
   			msg = "Send pt-to-pt";
   		} else if (ifp->int_state & IS_DUP) {
   			trace_act("abort multicast output via %s"
 *************** rip_bcast(int flash)
 *** 876,882 ****
 --- 877,890 ----
   		} else if (ifp->int_if_flags & IFF_POINTOPOINT) {
   			/* point-to-point hardware interface */
   			dst.sin_addr.s_addr = ifp->int_dstaddr;
 + 			/* use multicast if the interface allows (e.g. GRE) */
 + 			if (vers == RIPv2
 + 			    && (ifp->int_if_flags & IFF_MULTICAST)
 + 			    && !(ifp->int_state & IS_NO_RIP_MCAST)) {
 + 				type = OUT_MULTICAST;
 + 			} else {
   				type = OUT_UNICAST;
 + 			}
   
   		} else if (ifp->int_state & IS_REMOTE) {
   			/* remote interface */
 *************** rip_query(void)
 *** 965,971 ****
 --- 973,986 ----
   		} else if (ifp->int_if_flags & IFF_POINTOPOINT) {
   			/* point-to-point hardware interface */
   			dst.sin_addr.s_addr = ifp->int_dstaddr;
 + 			/* use multicast if the interface allows (e.g. GRE) */
 + 			if (buf.rip_vers == RIPv2
 + 			    && (ifp->int_if_flags & IFF_MULTICAST)
 + 			    && !(ifp->int_state & IS_NO_RIP_MCAST)) {
 + 				type = OUT_MULTICAST;
 + 			} else {
   				type = OUT_UNICAST;
 + 			}
   
   		} else if (ifp->int_state & IS_REMOTE) {
   			/* remote interface */

From: James Carlson <carlsonj@workingcode.com>
To: Vernon Schryver <vjs@calcite.rhyolite.com>
Cc: bms@incunabulum.net, dan@obluda.cz, freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces
Date: Fri, 10 Aug 2007 08:46:56 -0400

 Vernon Schryver writes:
 > What do you think of the enclose patch?  It differs from the original
 > in two ways that should reduce behavior changes seen by people with
 > IFF_POINTOPOINT interfaces without IFF_MULTICAST.  If it makes sense,
 > I'll generate a bundle on http://www.rhyolite.com/src/
 
 It seems reasonable to me for RIP.  Looking at the code, it seems that
 rdisc already handles this case -- despite the comment to the contrary
 on send_adv's and send_rdisc's 'dst' argument, the value can be a
 multicast destination (not just 0 or unicast), and often is.
 
 -- 
 James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

From: Bruce M Simpson <bms@incunabulum.net>
To: James Carlson <carlsonj@workingcode.com>
Cc: Vernon Schryver <vjs@calcite.rhyolite.com>,  dan@obluda.cz, 
 freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces
Date: Fri, 10 Aug 2007 13:54:18 +0100

 James Carlson wrote:
 > Vernon Schryver writes:
 >   
 >> What do you think of the enclose patch?  It differs from the original
 >> in two ways that should reduce behavior changes seen by people with
 >> IFF_POINTOPOINT interfaces without IFF_MULTICAST.  If it makes sense,
 >> I'll generate a bundle on http://www.rhyolite.com/src/
 >>     
 >
 > It seems reasonable to me for RIP.  Looking at the code, it seems that
 > rdisc already handles this case -- despite the comment to the contrary
 > on send_adv's and send_rdisc's 'dst' argument, the value can be a
 > multicast destination (not just 0 or unicast), and often is.
 >
 >   
 
 +1 here.
 
 It is OK to allow the use of multicast addressing on links which do not 
 natively multicast. Indeed it is necessary for IPv4 and IPv6 multicast 
 forwarding to work across generic point-to-point links, as no special 
 encapsulation is performed.
 
 RIPv2's multicast address falls in the 224.0.0.0/8 link local scope, so 
 it should never be seen outside of the link anyway.
 
 I would just suggest that it should default to off to avoid confusing 
 folk. If Zebra/Quagga is disallowing multicasted RIP across 
 non-multicast links, that's another story entirely.
 
 Regards,
 BMS

From: James Carlson <carlsonj@workingcode.com>
To: Bruce M Simpson <bms@incunabulum.net>
Cc: Vernon Schryver <vjs@calcite.rhyolite.com>, dan@obluda.cz,
        freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces
Date: Fri, 10 Aug 2007 09:15:51 -0400

 Bruce M Simpson writes:
 > I would just suggest that it should default to off to avoid confusing 
 > folk.
 
 Defaulting what to "off?"  The point of the patch (as I understood it)
 was to use multicast on interfaces where the interface flags say
 multicast is supported (IFF_MULTICAST) and where RIP-2 is configured
 to run and multicast hasn't been explicitly disabled.
 
 Why would this work differently than it does on Ethernet?
 
 > If Zebra/Quagga is disallowing multicasted RIP across 
 > non-multicast links, that's another story entirely.
 
 Yes, it is doing that, and so is the proposed routed patch.  For
 Zebra, see:
 
 http://cvs.quagga.net/cgi-bin/viewcvs.cgi/zebra/zebra-cvs/ripd/rip_interface.c?rev=1.1.1.1&content-type=text/vnd.viewcvs-markup
 
 and for Quagga, see:
 
 http://cvs.quagga.net/cgi-bin/viewcvs.cgi/quagga/ripd/rip_interface.c?annotate=1.36#163
 
 The function of interest is rip_request_interface_send().  It checks
 for version 2 and whether the interface supports multicast.  If it
 does, then it calls through to rip_request_send and rip_send_packet --
 which uses the well-known multicast destination.
 
 It doesn't check for point-to-point first.
 
 (Sorry about the lame link to Zebra.  They don't seem to have a web
 interface.)
 
 -- 
 James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

From: Bruce M Simpson <bms@incunabulum.net>
To: James Carlson <carlsonj@workingcode.com>
Cc: Vernon Schryver <vjs@calcite.rhyolite.com>,  dan@obluda.cz, 
 freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces
Date: Fri, 10 Aug 2007 14:17:52 +0100

 James Carlson wrote:
 > Defaulting what to "off?"  The point of the patch (as I understood it)
 > was to use multicast on interfaces where the interface flags say
 > multicast is supported (IFF_MULTICAST) and where RIP-2 is configured
 > to run and multicast hasn't been explicitly disabled.
 >
 > Why would this work differently than it does on Ethernet?
 >   
 
 Ah, I must have misunderstood the original intent. Please ignore!
 
 regards,
 BMS

From: Dan Lukes <dan@obluda.cz>
To: Vernon Schryver <vjs@calcite.rhyolite.com>
Cc: carlsonj@workingcode.com, bms@incunabulum.net,
        freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces
Date: Fri, 10 Aug 2007 14:55:55 +0200

 Vernon Schryver wrote:
 > What do you think of the enclose patch?
 
 	Lets go.
 
 				Dan

From: Vernon Schryver <vjs@calcite.rhyolite.com>
To: dan@obluda.cz
Cc: bms@incunabulum.net, carlsonj@workingcode.com,
        freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/111493: routed doesn't use multicasts for RIPv2 via P2P interfaces
Date: Mon, 13 Aug 2007 15:53:36 GMT

 http://www.rhyolite.com/src/routed.tar.Z
 contains the changed output.c
 
 
 Vernon Schryver    vjs@rhyolite.com

From: Bruce Simpson <bms@incunabulum.net>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/111493: [patch] routed(8) doesn't use multicasts for RIPv2
 via P2P interfaces
Date: Sat, 10 Apr 2010 14:27:00 +0100

 This is a multi-part message in MIME format.
 --------------090908040401060704000003
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Pulled up proposed patch on HEAD.
 
 FreeBSD's routed has deviated from vendor branch too much, and the 
 vendor branch history got lost in the noise of the SVN conversion.
 
 
 --------------090908040401060704000003
 Content-Type: text/plain;
  name="routed-gre.diff"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
  filename="routed-gre.diff"
 
 diff -uNr -x '.svn*' -x 'Makefile*' -x md5.c routed/output.c routedx/output.c
 --- routed/output.c	2010-04-10 14:21:52.000000000 +0100
 +++ routedx/output.c	2007-08-13 16:33:55.000000000 +0100
 @@ -140,8 +142,8 @@
  		flags = MSG_DONTROUTE;
  		break;
  	case OUT_MULTICAST:
 -		if ((ifp->int_if_flags & (IFF_POINTOPOINT|IFF_MULTICAST)) ==
 -		    IFF_POINTOPOINT) {
 +		if ((ifp->int_if_flags & IFF_POINTOPOINT)
 +		    && !(ifp->int_if_flags & IFF_MULTICAST)) {
  			msg = "Send pt-to-pt";
  		} else if (ifp->int_state & IS_DUP) {
  			trace_act("abort multicast output via %s"
 @@ -862,9 +877,10 @@
  		} else if (ifp->int_if_flags & IFF_POINTOPOINT) {
  			/* point-to-point hardware interface */
  			dst.sin_addr.s_addr = ifp->int_dstaddr;
 -			if (vers == RIPv2 &&
 -			    ifp->int_if_flags & IFF_MULTICAST &&
 -			    !(ifp->int_state  & IS_NO_RIP_MCAST)) {
 +			/* use multicast if the interface allows (e.g. GRE) */
 +			if (vers == RIPv2
 +			    && (ifp->int_if_flags & IFF_MULTICAST)
 +			    && !(ifp->int_state & IS_NO_RIP_MCAST)) {
  				type = OUT_MULTICAST;
  			} else {
  				type = OUT_UNICAST;
 @@ -957,7 +973,14 @@
  		} else if (ifp->int_if_flags & IFF_POINTOPOINT) {
  			/* point-to-point hardware interface */
  			dst.sin_addr.s_addr = ifp->int_dstaddr;
 -			type = OUT_UNICAST;
 +			/* use multicast if the interface allows (e.g. GRE) */
 +			if (buf.rip_vers == RIPv2
 +			    && (ifp->int_if_flags & IFF_MULTICAST)
 +			    && !(ifp->int_state & IS_NO_RIP_MCAST)) {
 +				type = OUT_MULTICAST;
 +			} else {
 +				type = OUT_UNICAST;
 +			}
  
  		} else if (ifp->int_state & IS_REMOTE) {
  			/* remote interface */
 
 --------------090908040401060704000003--
>Unformatted:
