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

"Charles E. Perkins" <charles.perkins@earthlink.net> Thu, 05 August 2010 17:32 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 C86D43A69A8 for <autoconf@core3.amsl.com>; Thu, 5 Aug 2010 10:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.911
X-Spam-Level:
X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[AWL=-0.912, BAYES_50=0.001]
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 Nx0s8+Z71L+r for <autoconf@core3.amsl.com>; Thu, 5 Aug 2010 10:32:56 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id D74FD3A68B8 for <autoconf@ietf.org>; Thu, 5 Aug 2010 10:32:54 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Uxmkg76kd7dCDwQ6Mu0+rMmy8sTz0I0t339GPN791kLZbKc2d8HTWRkChQoYg2L4; 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 [12.204.153.98] (helo=[10.166.254.158]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charles.perkins@earthlink.net>) id 1Oh4Jm-0001tD-8f; Thu, 05 Aug 2010 13:33:23 -0400
Message-ID: <4C5AF5DD.8020409@earthlink.net>
Date: Thu, 05 Aug 2010 10:33:17 -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> <4C596894.5050004@earthlink.net> <28D40890-32BE-4925-94DD-049E54B71B43@inf-net.nl> <4C599292.9090507@earthlink.net> <AC7B3C2B-1130-4067-A7F7-083F49D034AE@inf-net.nl> <4C59C19B.4070101@earthlink.net> <0E35FDFA-F73F-4005-8354-87ECB7A4E12D@inf-net.nl>
In-Reply-To: <0E35FDFA-F73F-4005-8354-87ECB7A4E12D@inf-net.nl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52551987018c06da3a2ce8551c02591b49350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 12.204.153.98
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: Thu, 05 Aug 2010 17:32:58 -0000

Hello Teco,

Comments below.

On 8/5/2010 1:27 AM, Teco Boot wrote:

>>> No. We are getting out-of-scope.
>>> The document is about link with undetermined characteristics.
>>> P2P links are not in that category.
>>
>> I definitely don't agree with this conclusion.
>> The links with undetermined characteristics can
>> support time-bounded P2P links.  There is no
>> reason to declare P2P links out of scope.
>
> At least P2P is a special case.
> Has this to do with our discussion?

AODV often connects an ad hoc network with
100% P2P links.  Are networks using AODV out of
scope?

> Can you come up with something other than p2p?

For what purpose?


>>>> 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).
>>
>> Bad assumption!
>
> Then, what is in the routing table?

Whatever the host puts there.

> And what mechanism takes care?

Promiscuous mode can work, along with
other approaches.


> I still wonder how two hosts with off-link prefixes on same link can
> communicate.

802.11 doesn't care about prefixes.  What's
the problem?


>> One trivial example would be to just run in
>> promiscuous mode, listen for addresses, and
>> pretend that some neighbor is a router.
>
> Data plane populating routing table ??

Not unusual.  Even DSR did this.

> What about uni-directional link test ??

Life is hard, and then we die.

>> I have other examples that are more normal :-)
>
> Please do so, previous one frightened me.

Fear naught.

>> I am not claiming that the other solutions are
>> mine -- but there are numerous examples in the
>> literature.
>
> Refs are OK. Or describe one.


Your bait is lovely, but the adult in me
demands that I not go there just now.


>> As far as a host is concerned, topology
>> exchange isn't necessary -- unless you call
>> the simple fact of link establishment to be
>> "topology exchange".  And then our discussion
>> fails, because we have so little vocabulary.
>
> We may end up in discussing the width of the grey zone between
> host and router, and the exact borderlines.

Or not, because I'm out of time and don't see
much reward.

> We agreed on three indications for classifying node a router.
> Now on indications for hosts:

Check.


> Now I say: there are protocols for host-router relations, so host will
> know on-line prefix and default gateway, or more specific routes.
> But what about getting knowledge on routers for links to hosts, where
> hosts have off-link prefixes?


You're stuck on prefixes.  It's a nasty
affliction, but very widespread.


> If there are protocols for such (and done in
> a clean fashion), I call it routing. This, because hosts do not advertise
> themselves to routers as part of the topology. This is where routing
> complexity starts.


This paragraph is full of holes.
First, you have declared nodes using BGP to
not be routers because BGP is not clean.

Second, hosts don't advertise _anything_ as
"part of the topology".

Third, routing complexity arises from quite
a few sources.  Need I mention "policy"?

Fourth, a router can route without running
any routing protocol.  Of course such a
device would be quite cumbersome to deploy
in the Internet, requiring human intervention
to adapt to changes.  But, as one tiny example,
this is exactly how I first tested Mobile IP.

Sometimes I'm not sure if you're serious when
making these assertions.


> Complexity is increased with RFC5942, with our RFC5889 in mind.
> We don't configure on-link prefixes on our interfaces.
> RFC5942 Host Behavior (3.1):
>     In IPv6, an address is on-link (with respect to a specific link), if
>     the address has been assigned to an interface attached to that link.
> So one could say we do not comply to RFC5942. Luckily, RFC5942 is for
> hosts.

I'll be just as happy not to go there at all.


>>>> 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?
>>
>> If the host transmits a packet, the routers can know.
>
> IMHO mix data plane and routing control plane is bad.

IP is bad?

There are numerous counterexamples.  For instance,
many liveness strategies readily utilize information
about data plane traffic (instead of, say, keepalives).

Again I am left wondering if you are tweaking me.


>> If I remember correctly, the current addressing model does
>> not legislate that all links have to be /128.  It just
>> says that SOME links appear to be /128, so that without
>> additional information, protocols may not make too many
>> assumptions about the connectivity properties of the link.
>
> It says no on-link subnet prefix is configured.
> As a result, hosts are not supported. Some mechanism
> is needed making the router aware that other nodes
> are reachable via this interface. I call this routing.

I call it chocolate syrup.  Which is approximately
equally valid until we know what "it" is.


>> As many have pointed out, this world is not so black and
>> white.
>
> Indeed. But it is quite dark for hosts, using this addressing model.
> Routing enlighten.

Teco, I can't really go on with this.  Of course
routing enlightens.  Providing valid information
is always enlightening (as opposed to, say, some
discussions in this thread).  You want to say
that X is a router, even if it MUST NEVER forward
any packets.  I think this is nonsense, pure and
simple.  Maybe _also_ sophistry, and maybe _also_
a waste of time due to lack of entertainment value.


>> Optionally.  And, a node can forward packets
>> based only on P2P routes.  Such a node is,
>> I claim, a router.  No subnets are needed.
>
> Back to subject: addressing model is for routers.
> You disagreed with title change.

Do I _really_ have to unwind this thread for you?
I was responding to _your_ digression.

> I expect some argumentation. I did't see such.

Please look again.  Or I will save you the trouble:
i) hosts must obey the considerations in the draft
ii) [autoconf] producing a protocol that does not
     enable hosts to get addresses is plain silly.
 From these basic (invisible to you?) statements on
my part, we started traveling through the twilight
zone where routers don't forward packets and,
as a sort of very strange converse, P2P route
table entries get no respect even though ALL
manet routing protocols use them.

Traveling through this twilight zone, many people
in this group have acquired an ability to profess
that it's easier to configure routers than hosts,
regardless of 30 years of evidence to the contrary.

You might very well rightfully ask why I even
try to make any correction to the situation.
I know I am asking myself that question.

>>>> 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
>>> characteristics.
>>
>> Teco -- this is just wrong.
>>
>> Just because a network interface has undetermined
>> properties doesn't mean that the host utilizing
>> that network interface can't transmit or receive
>> packets.  Otherwise, what would be the point of
>> powering the interface?
>
> You miss the point.
> When some say routers, they don't intent the node MUST
> forward packets.

When some say routers, they mean boxes with multiple
interfaces.  When some say routers, they include boxes
that MUST NEVER forward packets.  When some say routers,
they mean <... ding!  time's up!  game over ...>

> The intention is that routing protocols
> are involved getting the routing tables populated. And
> bypass limitations for hosts. This is allowed, because
> routers understand the complexity.

Routers don't understand anything.  They're
machines, operating as programmed.  Oh, you
meant that a routing protocol is a program
of higher complexity than <... what? ...>.
Of course it's far more complex
than {} [{} == <null set>].

> Maybe.
> Any valid received RA info is reflected in default router list.
> But how can a host without on-link addresses populate the router
> routing table?

Here's my challenge to you.  Find a grad student
in networking who could NOT figure this out.
Of course, I am assuming that you do NOT mean what
you stated -- namely that the host must populate
the router's routing table.

If somehow the authors of 5942 have legislated that
hosts cannot transmit packets over wireless interfaces
with legal IP addresses, I send my regrets but I can't
fight that battle right now.

Regards,
Charlie P.