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

Teco Boot <> Fri, 27 August 2010 09:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6635B3A67F0 for <>; Fri, 27 Aug 2010 02:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l0y814vLpxMA for <>; Fri, 27 Aug 2010 02:52:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AAB783A6B9A for <>; Fri, 27 Aug 2010 02:52:55 -0700 (PDT)
Received: by eyd10 with SMTP id 10so2056533eyd.31 for <>; Fri, 27 Aug 2010 02:53:26 -0700 (PDT)
Received: by with SMTP id l10mr715796ebb.21.1282902806837; Fri, 27 Aug 2010 02:53:26 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id v8sm5789371eeh.14.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 27 Aug 2010 02:53:25 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Teco Boot <>
In-Reply-To: <>
Date: Fri, 27 Aug 2010 11:53:23 +0200
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <ABE739C5ADAC9A41ACCC72DF366B719D035CA5CE@GLKMS2100.GREENLNK.NET> <> <ABE739C5ADAC9A41ACCC72DF366B719D03609170@GLKMS2100.GREENLNK.NET> <> <ABE739C5ADAC9A41ACCC72DF366B719D036094AB@GLKMS2100.GREENLNK.NET> <> <>
To: "Charles E. Perkins" <>
X-Mailer: Apple Mail (2.1081)
Cc: "" <>, "Dearlove, Christopher \(UK\)" <>
Subject: Re: [Autoconf] Closing summary on consensus-call for RFC5889modifications
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Aug 2010 09:52:57 -0000

Hi Charlie,

More thoughts on the grey zone, separating host and routers.
You stick to the basic definition: routers forward packets, hosts do not. 

We had discussion on routing protocol speakers. I said: sending routing 
protocol packets makes a node a router.

But for routing protocol speakers, that:
 - do not forward packets
 - do not send RAs
 - do not advertise any willingness to forward packets
Would that be routers?

If you say: no, these are hosts, I can follow.
But for accepting such, it should be made clear to other nodes, that 
the routing protocol speaker is a host, not a router.
Some mechanisms:
 - passive mode / don't send routing protocol packets at all
 - OLSR willingness = WILL_NEVER (0)
 - not advertise any links
 - advertise links, but with "do not use" attribute / metric
 - only put reachability for itself in AODV / DYMO messages
 - never send BGP reachability with own address as next_hop

Using this classification, a BGP route server is a nice example for a 
host being an active routing protocol speaker.
|  Although a route server uses BGP to exchange
|  reachability information with each of its clients, it does not
|  forward traffic itself and is therefore not a router.

If we agree on such classification, there is some advertorial work to do.
Because many would say (ad hoc) routing protocol speakers are routers. 
E.g. we need errata on RFC's from MANET WG and update the active drafts.
Also, draft-ietf-autoconf-adhoc-addr-model-03 needs a revision. Change 
/router/node/, but not global change (not in section 6.1, last bullet).
RFC5998 is waiting for approval by Mark. 

And using Router-ID's on hosts?

Regards, Teco

Op 26 aug 2010, om 20:17 heeft Teco Boot het volgende geschreven:

> Charlie,
> Learning default gateways in a passive mode is well accepted behavior
> of hosts. It is mentioned in RFC 1122:
> |  This technique depends upon the host passively
> |  receiving ("wiretapping") the Interior Gateway Protocol
> |  (IGP) datagrams that the gateways are broadcasting to
> | each other. 
> But signaling from hosts to routers is another story. We have NDP or 
> ARP for this. One could think of redistributing NDP / ARP learned routing
> info into the routing protocol. I am not sure we should go there.
> Teco