IETF Logo Mail Archive

Re: [v6ops] Routers are hosts too!

Jared Mauch <jared@puck.nether.net> Fri, 08 January 2016 13:48 UTC

Return-Path: <jared@puck.nether.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D7E1B29C7 for <v6ops@ietfa.amsl.com>; Fri, 8 Jan 2016 05:48:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJWUBJUmdLQu for <v6ops@ietfa.amsl.com>; Fri, 8 Jan 2016 05:48:12 -0800 (PST)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3D41B29C8 for <v6ops@ietf.org>; Fri, 8 Jan 2016 05:48:12 -0800 (PST)
Received: from [IPv6:2601:401:3:6a00:685d:4ce:972d:1748] (unknown [IPv6:2601:401:3:6a00:685d:4ce:972d:1748]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id C7655540AF8; Fri, 8 Jan 2016 08:48:10 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Jared Mauch <jared@puck.nether.net>
X-Mailer: iPhone Mail (13C75)
In-Reply-To: <20160108.121015.74737501.sthaug@nethelp.no>
Date: Fri, 08 Jan 2016 08:48:10 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <67D93E4D-714A-4566-A308-D9EFBB71C43B@puck.nether.net>
References: <568E6552.9030008@gmail.com> <568EACE4.2070408@isi.edu> <568F8F37.3050708@gmail.com> <20160108.121015.74737501.sthaug@nethelp.no>
To: sthaug@nethelp.no
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/6B_e2uMaALtJg6bz9nnFQgkilZE>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Routers are hosts too!
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jan 2016 13:48:14 -0000

I've not encountered a device in the past 20+ years that doesn't do longest match. 

Jared Mauch

On Jan 8, 2016, at 6:10 AM, sthaug@nethelp.no wrote:

>>>>>>           - a router does implement longest-matching algorithms, a Host
>>>>>>             doesn't.
>>>>> 
>>>>> Of course hosts do.  Why would any implementor not do that?
>>>> 
>>>> Why would a Host need to look out a nexthop in routing table?  To
>>>> forward to whom?
>>> 
>>> Source address selection. See RFC1122 Sec 3.3.4.3.
>> 
>> I grepped "match" and it doesnt say whether exact match or longest-match 
>> are used.
>> 
>> As such I think it's exact match.
> 
> Irrespective of the source address selection issue, normal "host"
> operating systems that I know of (e.g. FreeBSD) most definitely
> implement longest match.
> 
> Think of it this way: If a host *can* be turned into a router by
> changing a configuration knob, why on earth would you want to
> implement exact match to be used only for host mode (when longest
> match is needed in any case for router mode)?
> 
> Steinar Haug, AS2116
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email