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

Teco Boot <teco@inf-net.nl> Wed, 04 August 2010 06:48 UTC

Return-Path: <teco@inf-net.nl>
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 3C9BA3A6B8F for <autoconf@core3.amsl.com>; Tue, 3 Aug 2010 23:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.465
X-Spam-Level:
X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 61G+NQrLggqt for <autoconf@core3.amsl.com>; Tue, 3 Aug 2010 23:48:15 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id F2A2F3A69FA for <autoconf@ietf.org>; Tue, 3 Aug 2010 23:48:14 -0700 (PDT)
Received: by ewy22 with SMTP id 22so2123909ewy.31 for <autoconf@ietf.org>; Tue, 03 Aug 2010 23:48:43 -0700 (PDT)
Received: by 10.14.47.6 with SMTP id s6mr3315075eeb.44.1280904523362; Tue, 03 Aug 2010 23:48:43 -0700 (PDT)
Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm12210549eei.6.2010.08.03.23.48.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 03 Aug 2010 23:48:42 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <4C58584D.2010604@earthlink.net>
Date: Wed, 4 Aug 2010 08:48:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <379B3F32-224C-46C0-8599-913AD85A803E@inf-net.nl>
References: <4C528979.7010006@oracle.com> <E21BA9FD-4715-4DA8-9586-9380126763E2@gmail.com> <4C58584D.2010604@earthlink.net>
To: Charles E. Perkins <charles.perkins@earthlink.net>
X-Mailer: Apple Mail (2.1081)
Cc: autoconf@ietf.org, Autoconf Chairs <autoconf-chairs@tools.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 06:48:21 -0000

Charlie,

I see it this way:

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.

b) The device sends out a routing protocol packet. The intention of the
device is arranging topology state, for itself or for neighbors. Hosts may
use a passive mode (often used with RIP). There are some corner cases, like
management boxes that get topology from OSPF/ISIS or BGP by adjacency with
real router. But often, such adjacency leads to topology change and thus the 
management box is a router.

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


Why is this important? Especially on b):
Lets say router with reactive protocol sends RREQs but not RREPs.
The router will be part of the topology, but never will receive a packet for
forwarding. But still, it is a router. Willingness=0 is example for an proactive 
protocol.

If a host uses tobe-RFC5889 and only uses a /128 prefix, and other nearby nodes
also use /128's, there is no connectivity. 1-hop neighbors can't know that the
host is reachable. 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.

This is why I support the title change.


Regards, Teco


Op 3 aug 2010, om 19:56 heeft Charles E. Perkins het volgende geschreven:

> 
> Hello folks,
> 
> I disagree that the addressing model and the
> implications upon link-local addressability
> are any less valid for hosts than they are
> for routers.
> 
> The danger I see is that the title change
> could at any time be cited as justification
> for restricting the work of [autoconf]
> so that only routers can get addresses.
> This sort of political device is often able
> to overcome any objection that the earlier
> language in previous documents was having
> unintentional side-effects (once they are
> published).
> 
> The point was raised during the meeting that
> any router could pretend to be a host by simply
> setting willingness == 0.
> 
> It was not explained why an energy-constrained
> device should have to implement thousands of lines
> of code just so it could have the privilege of
> being called a router when it should never ever
> be configured to forward packets.
> 
> But perhaps I digress from the point of the
> consensus call.
> 
> Regards,
> Charlie P.
> 
> 
> On 8/2/2010 5:14 PM, Ryuji Wakikawa wrote:
>> Hello all,
>> 
>> At the IETF78 meeting, we had the rough consensus to adapt
>> the Erik's modification for RFC5889 in the room.
>> 
>> To confirm our consensus on the list, we ask the WG consensus call
>> for adaption of Erik's modification for RFC5889.
>> 
>> The detailed modifications can be found at the attached email below. Thanks Erik.
>> 
>> Please vote for your opinion before "Aug 9th 12:00PM (PST)".
>> If you have any objections, please give us clear reason and propose your text.
>> 
>> thanks in advance,
>> Thomas, ryuji
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf