Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 26 August 2010 13:56 UTC

Return-Path: <alexandru.petrescu@gmail.com>
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 4F4A33A687B for <autoconf@core3.amsl.com>; Thu, 26 Aug 2010 06:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.129
X-Spam-Level:
X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 1bC6ZcLYP1F9 for <autoconf@core3.amsl.com>; Thu, 26 Aug 2010 06:56:45 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id AC01B3A6876 for <autoconf@ietf.org>; Thu, 26 Aug 2010 06:56:44 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o7QDvFUw016764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Aug 2010 15:57:15 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o7QDvFr1031763; Thu, 26 Aug 2010 15:57:15 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o7QDvFNi006711; Thu, 26 Aug 2010 15:57:15 +0200
Message-ID: <4C7672BB.2080608@gmail.com>
Date: Thu, 26 Aug 2010 15:57:15 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; 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
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications
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 13:56:46 -0000

Le 26/08/2010 14:31, Teco Boot a écrit :
> 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".

Ah well spot.  In practice that is actually a MUST - every IP stack has
a table of routes, be it ran by Hosts or by Routers.  There's no IP
stack without routing table.

This is one reason why I think it's difficult to identify a Host which
is not a Router, nor a Router which is not a Host.

Probably one could call a Host a Host if it does more TCP instructions
during 1 second, than routing instructions.

Alex

>
> 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
>>>
>>>
>>
>>
>
>