Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [Was: RFC 5889)

"Charles E. Perkins" <charles.perkins@earthlink.net> Wed, 04 August 2010 13:18 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 B2D243A6767 for <autoconf@core3.amsl.com>; Wed, 4 Aug 2010 06:18:18 -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 e-bD-dDS5waV for <autoconf@core3.amsl.com>; Wed, 4 Aug 2010 06:18:17 -0700 (PDT)
Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 92D0A3A63C9 for <autoconf@ietf.org>; Wed, 4 Aug 2010 06:18:17 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=retfwENvL9D+0B/lfGlPYo0wNqOH1frYnDoAJeenpq3EZeVMbvNhNydzD96udFUi; 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 [24.6.171.143] (helo=[192.168.1.107]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1Ogdrq-0000U5-H4; Wed, 04 Aug 2010 09:18:46 -0400
Message-ID: <4C596894.5050004@earthlink.net>
Date: Wed, 04 Aug 2010 06:18:12 -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.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: Teco Boot <teco@inf-net.nl>
References: <4C528979.7010006@oracle.com> <E21BA9FD-4715-4DA8-9586-9380126763E2@gmail.com> <4C58584D.2010604@earthlink.net> <379B3F32-224C-46C0-8599-913AD85A803E@inf-net.nl>
In-Reply-To: <379B3F32-224C-46C0-8599-913AD85A803E@inf-net.nl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52c5e4e8962ff5c8bab16d1e088ecd93e4350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 24.6.171.143
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [Was: RFC 5889)
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: Wed, 04 Aug 2010 13:18:18 -0000

Hello Teco,

On 8/3/2010 11:48 PM, Teco Boot wrote:

> What makes a node a router? (mentioned in meeting, maybe incomplete lsit)
>
> a) The device MAY forward packets. Even the case if it actually doesn't,
> e.g. the topology is such that no packet is sent to it for forwarding. Many
> OSses have a "Forwarding" config flag. When on, it is a router. This has
> nothing to do with routing protocols.

Check.

> b) The device sends out a routing protocol packet.  ...

Check.

> c) The device sends out an RA. Hosts MAY NOT do this.

Check.

...

> If a host uses tobe-RFC5889 and only uses a /128 prefix, and other nearby nodes
> also use /128's, there is no connectivity.

What about point-to-point links?

> 1-hop neighbors can't know that the
> host is reachable.

What about point-to-point links?

> I experienced this problem during maintenance or outage of
> the routing protocol, I couldn't remotely repair. That is why I use another
> addressing model, that doesn't has this shortcoming. It supports all types of
> nodes. A big, big difference.

I never experienced this with AODV, which
could use all point-to-point links.

> This is why I support the title change.

I'm still mystified, unless (as Henning opines)
we've strayed into the magical land of politics.

Regards,
Charlie P.