Re: [Autoconf] Closing summary on consensus-call forRFC5889modifications

"Charles E. Perkins" <charles.perkins@earthlink.net> Thu, 26 August 2010 14:06 UTC

Return-Path: <charles.perkins@earthlink.net>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DB973A69A6 for <autoconf@core3.amsl.com>; Thu, 26 Aug 2010 07:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98hZEixRYIMS for <autoconf@core3.amsl.com>; Thu, 26 Aug 2010 07:06:01 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id AC3ED3A699E for <autoconf@ietf.org>; Thu, 26 Aug 2010 07:06:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Ngv8aWs1tp3S/nVf0vD9x1QttaMDZ3+Qq5jcyAqhwlvUIN6IO1M4frEzD0qmLG9n; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [207.74.239.6] (helo=[10.150.0.248]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1Ood69-0003pU-6B; Thu, 26 Aug 2010 10:06:33 -0400
Message-ID: <4C7674E7.1010703@earthlink.net>
Date: Thu, 26 Aug 2010 07:06:31 -0700
From: "Charles E. Perkins" <charles.perkins@earthlink.net>
Organization: Wichorus Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Teco Boot <teco@inf-net.nl>
References: <AANLkTi=MZORvNSW7wHdHYOzkOwNZojBars26GfSPgWc9@mail.gmail.com><ABE739C5ADAC9A41ACCC72DF366B719D035CA5CE@GLKMS2100.GREENLNK.NET> <7ir5hoc4wq.fsf@lanthane.pps.jussieu.fr><ABE739C5ADAC9A41ACCC72DF366B719D03609162@GLKMS2100.GREENLNK.NET><4C74EAD5.7060300@gmail.com><90FAFCBF-7DEA-419E-8B0D-514EE8021B0B@inf-net.nl><4C753EC6.40800@gmail.com> <61F3EA79-9B63-46A9-856F-45478EA22043@inf-net.nl>
In-Reply-To: <61F3EA79-9B63-46A9-856F-45478EA22043@inf-net.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52036464c33c89deecb303ec684d8acc87350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 207.74.239.6
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Closing summary on consensus-call forRFC5889modifications
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Aug 2010 14:06:03 -0000

Hello Teco,

I'd like to propose how we can distinguish routers
from hosts, as follows:

- If a node forwards packets as an intermediate node
   in a routing path, it is a "router".
- Otherwise, it is "host".

As one example, suppose network entity X runs
a routing protocol and exchanges routing tables.
Furthermore, suppose X drops every packet that
it receives unless the destination address is
X's IP address.

I do not call X a router.

Suppose instead that X forwards every other
packet.

I call X a defective router.

You might instead prefer to call X a router
if it exchanges routing tables with its
neighbors.  That is also workable, I think,
but less convenient and vulnerable to arguments
related to the use of SNMP.

Anyway, for all those who cannot tell the
difference between routers and hosts by
any definition whatsoever, I can't see how
it matters what terminology the proposed
RFC might use.

Regards,
Charlie P.

On 8/26/2010 5:31 AM, Teco Boot wrote:
> Alex,
>
> You could take some time for research, on hosts having a routing table.
> Take a start with host requirements (RFC 1122):
> |  As an extra feature, a host IP layer MAY implement a table
> |  of "static routes".
>
> Teco
>
> Op 25 aug 2010, om 18:03 heeft Alexandru Petrescu het volgende geschreven:
>
>> Le 25/08/2010 15:21, Teco Boot a écrit :
>>> Alex,
>>>
>>> Your statement is not accurate. You say: "A router with [whatever]
>>> is a router to. Would someone doubt on that?
>>
>> Right, a router is a router - always valid.
>>
>> A "machine" with static routes is a router too.
>>
>>> If you intended to say:
>>>> A node with static routes (no routing protocol messages) is a
>>>> router too.
>>>
>>> This is definitely not true. Every host may have static routes.
>>
>> Right.  That's why I tend to accept that there are no Hosts in this
>> world and they're all routers, because they all execute longest prefix
>> match searches in their routing tables, they all have at least two
>> interfaces (lo is one), they all have entries in their routing tables.
>>
>> They're all routers, Hosts don't exist.
>>
>>> I call a node a router if it: - may forward packets; - may send
>>> routing protocol packets; - may send router advertisements.
>>>
>>> Reworded: a host - may not forward packets; - may not send routing
>>> protocol packets; - may not send router advertisements.
>>
>> Ah "may" makes it impossible to really distinguish.
>>
>>> I have device here on my desk. It is called a Wireless-N Home Router.
>>> I use it as WiFi AP, Ethernet switch and DHCP server. I don't use it
>>> for forwarding packets, because on the yellow marked port it does
>>> some nasty NAPT operations, which I can't use in my setup. Shall I
>>> bring it back to the shop, and ask for a Wireless-N Home Host?
>>
>> HA haha!!  I doubt shop vendor understands "Host" because s/he never
>> sells Hosts to anyone!  S/he could sell Routers, Switches, Desktops,
>> Servers ; or it could Host your website if you wish.  But never sell you
>> a Host.  Who sells Hosts?
>>
>>> It: - may forward packets, but I disabled it; - may send routing
>>> protocol packets, but I disabled it; - may send router
>>> advertisements, but I doubt if it supports IPv6.
>>
>> But that Access Point does have routing table entries, does execute the
>> longest prefix match algorithm, hence it's a Router.
>>
>>> By the way, if I use packet forwarding, NAPT and MAC NAT, it acts as
>>> a host on the Internet port.
>>
>> In a sense.  What do you mean it "acts as a Host on the Internet port"?
>> What does NAPT does as algorithm, data structures, which a Router does
>> not, on the Internet port?
>>
>>> Providers can't detect it is a router, it is all hidden. Powerful
>>> feature, for where providers don't allow routers connected to their
>>> networks.
>>
>> Hmm...
>>
>> I think also, as you say, that it is good to distinguish it based on
>> sending RA or NA: if it sends RA then it's a Router, otherwise it's a
>> Host; but disabling RAs on a Router doesn't make it a Host :-) - it
>> makes it an IPv4 Router (another Router :-)
>>
>> Alex
>>
>>>
>>> Teco
>>>
>>>
>>>
>>> Op 25 aug 2010, om 12:05 heeft Alexandru Petrescu het volgende
>>> geschreven:
>>>
>>>> Le 25/08/2010 10:41, Dearlove, Christopher (UK) a écrit :
>>>>> It's running the routing protocol, and not just listening to it,
>>>>> but engaging actively in it - sending necessary routing protocol
>>>>> messages. It's a router.
>>>>
>>>> And a router doesn't necessarily have to run a dynamic routing
>>>> protocol.  A router with static routes (no routing protocol
>>>> messages) is a router too.
>>>>
>>>> Alex
>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________ Autoconf mailing
>>>> list Autoconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/autoconf
>>>
>>>
>>
>>
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>