From owner-freebsd-net@FreeBSD.ORG Sat Jan 11 17:42:45 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40C10422 for ; Sat, 11 Jan 2014 17:42:45 +0000 (UTC) Received: from smtp1.bushwire.net (f5.bushwire.net [199.48.133.46]) by mx1.freebsd.org (Postfix) with SMTP id DE11E1389 for ; Sat, 11 Jan 2014 17:42:43 +0000 (UTC) Received: (qmail 6943 invoked by uid 1001); 11 Jan 2014 17:36:01 -0000 Delivered-To: qmda-intercept-freebsd-net@freebsd.org DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=s384; d=romeo.emu.st; b=KkVra6nD6IyReNbBemNDD/cuZSOMI18YEr4TFGgHGB7quManaJXiVWVjIVhrge7c; Comments: DomainKeys? See http://en.wikipedia.org/wiki/DomainKeys DomainKey-Trace-MD: h=13; b=49; l=C18R70D32M64F38T27S76R58?38M17C39C27I50; Comments: QMDA 0.3 Received: (qmail 6935 invoked by uid 1001); 11 Jan 2014 17:36:01 -0000 Date: 11 Jan 2014 17:36:01 +0000 Message-ID: <20140111173601.6934.qmail@f5-external.bushwire.net> From: "Mark Delany" To: freebsd-net@freebsd.org Subject: Re: Merge ping+ping6 and traceroue+traceroute6 to single utilities? References: <1063008459.20140111160525@serebryakov.spb.ru> <20140111164047.GA97150@edge.bac.lab> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140111164047.GA97150@edge.bac.lab> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jan 2014 17:42:45 -0000 On 11Jan14, mp39590@gmail.com allegedly wrote: > From a developer's point of view: since the underling raw sockets API is > totally different between IPv4 and IPv6, we would end up having two types of > code base. > From an operator's point of view: unlike ordinary network applications like > remote login tools, we are usually aware of address family when using network > management tools. We do not just want to know the reachability to the host, Breaking this down by class of users is useful. Another class of users are tool writers. The contortions you have to go thru in a shell script to determine which ping command to run is currently particularly unfriendly. You have to work out whether both ends have one or both classes which is non-trivial. Then you run different commands accordingly and react to all four possible outcomes. Ugly and bug-prone. Furthermore, all existing scripts that have been written over the last couple of decades are gradually breaking and have to be patched as the world evolves to v6. In short, every script writer on the planet is going to have to re-invent a ping4/ping6 wrapper to solve this problem and patch it into all of their existing code. Wouldn't it be nice it those tool writers could just add an option to their existing ping command to encompass both their 4&6 requirements? Or as others have suggested have it "just work" without change? A third way is to provide a "reachability" wrapper around ping4/ping6 but that means training all FBSD users to use a different tool resulting in scripts that don't easily port across platforms. What I'd like semantically in my scripts is: ping [-46..] [-e 1|2|all] Where -e defines minimal reachability for an exit(0) and multiple classes are tested based on -4, -6, -8. So, ping -46 -e2 means both 4 and 6 addresses must respond and ping -46 -e1 means either of 4 or 6 must respond. (It'd also be nice if all the ping writers across platforms agreed on a standardizes output to express results, but that's a whole other problem.) Mark.