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

Teco Boot <> Wed, 04 August 2010 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB8E03A6A49 for <>; Wed, 4 Aug 2010 11:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.213
X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7u7fZOy8eLKl for <>; Wed, 4 Aug 2010 11:11:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 59C4C3A6A74 for <>; Wed, 4 Aug 2010 11:11:14 -0700 (PDT)
Received: by eyb7 with SMTP id 7so2351153eyb.31 for <>; Wed, 04 Aug 2010 11:11:39 -0700 (PDT)
Received: by with SMTP id s15mr6942831ebc.48.1280945499787; Wed, 04 Aug 2010 11:11:39 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id a48sm13198982eei.12.2010. (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 11:11:39 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Teco Boot <>
In-Reply-To: <>
Date: Wed, 4 Aug 2010 20:11:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: "Charles E. Perkins" <>
X-Mailer: Apple Mail (2.1081)
Cc: "" <>
Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgotone [Was: RFC 5889)
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: Wed, 04 Aug 2010 18:11:32 -0000

Hi Charlie,

Op 4 aug 2010, om 18:17 heeft Charles E. Perkins het volgende geschreven:

> Hello Teco,
> Comments below:
> On 8/4/2010 8:37 AM, Teco Boot wrote:
>>> What about point-to-point links?
>> Even then, a host would not use this link if it is not mentioned in the routing table.
> Every host has a routing table.  Do you say
> otherwise?  If so, we have no vocabulary.
> IPv6 hosts can even have multiple routers
> in their routing table.


>> You could say a host with one p2p link could set the default gateway automatically.
>> But how can the opposite node learn the topology?
> Are we getting into solution space?

No. We are getting out-of-scope.
The document is about link with undetermined characteristics.
P2P links are not in that category.

> I didn't even say that a host had to have
> a default router.

Then, that host does not send packets.
(Assuming empty routing table and /128 (v6) or /32 (v4) address prefix). 
(Host learning more specific routes via p2p links could be exception)

>> If it is a single-homed host, this small setup of only two hosts would work.
>> Any other case results in nothing.
> Without presenting solutions, I cannot
> convince you otherwise.  For this discussion,
> suffice it to say that I am 100% certain your
> statement is incorrect.

I think I would call your solution topology exchange, thus routing.
Just guessing, of course.

>>> I never experienced this with AODV, which
>>> could use all point-to-point links.
>> So you stop AODV, and AODV still operates???
>> Can't be.
> I'm sorry, but I cannot understand what
> you meant.  Anyway, I wouldn't have
> "stopped AODV" unless I broadcast a
> directive to all nodes that they must
> cease operation.

It is not "all or nothing".
A router could stop acting as router. Think of maintenance, bugs etc.
Sure, before quitting, the router may advertise it's routing protocol 
is gonna die. I don't see why routing protocols on other nodes would 
cease operation. A bit too DOS friendly, I say.

>>> I'm still mystified, unless (as Henning opines)
>>> we've strayed into the magical land of politics.
>> A node that runs AODV is a router, because AODV is a routing protocol.
> I mentioned AODV as a counterexample to your
> statement about the infeasibility of running
> a network over /128 links.  It does not mean
> that I say "AODV" to every question you might
> ask.


> In particular, I claim that hosts in an ad hoc
> network often must adhere to the developed
> address model.  Of course they don't run AODV
> if they're not routers.

OK, now were are there. How can the routers know the host is there?
When the host belongs to a subnet, with a "subnet router" as gateway
to the rest of the network, I am OK. But this cannot happen, with the
current addressing model. 

>> More detailed answer: in AODV, the subnet router is responsible for
>> reachability for the subnet.
> Where's the subnet?

Somewhere in the network. Optionally with hosts. And a router, connecting
the subnet to the rest of the network.

>> In our addressing model, with /128 subnet,
>> there is only one node in the subnet, that is the subnet router.
>> So the document applies only to routers in ad hoc networks.
> Is there some weird magic that requires every
> /128 subnet to have an AODV subnet router?
> If not, then your conclusion is false.

There is no magic.
Point is: with /128, there are no hosts. Not on links with undetermined

>> Demystified ?
> Actually, I am further mystified -- especially
> to think that point-to-point routes get so little
> respect in this forum, and that anyone might
> claim that hosts don't have routing tables.

1) P2P is out-of-scope, as we assume nothing for our links.
2) hosts have routing tables.

> Do you claim that any program that utilizes
> #include <route.h> is a router?

No, not at all.
But if this piece of code sends out a routing packet, then yes, for sure.

With IPv6, we could support hosts in our links with undetermined 
characteristics. Router sends RA with PIO (/64), with L-bit is 0.
Nearby hosts can configure own address (SLAAC) and use the router
as gateway. This only works for satellite hosts. This model is 
suggested multiple times (Templin, in't Velt, others).
There was rough consensus not to support this addressing model.


>> We can discuss wrongly used _host_ in HIP, DHCP, Host Route etc., if time permits.
>> Not for today.
> Sounds like fun.

> Regards,
> Charlie P.