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

Teco Boot <teco@inf-net.nl> Thu, 05 August 2010 08:27 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 7A1C93A682A for <autoconf@core3.amsl.com>; Thu, 5 Aug 2010 01:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.199
X-Spam-Level:
X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
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 gvPCbED56Gjw for <autoconf@core3.amsl.com>; Thu, 5 Aug 2010 01:27:01 -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 83AC33A68CF for <autoconf@ietf.org>; Thu, 5 Aug 2010 01:27:00 -0700 (PDT)
Received: by ewy22 with SMTP id 22so2564706ewy.31 for <autoconf@ietf.org>; Thu, 05 Aug 2010 01:27:30 -0700 (PDT)
Received: by 10.213.12.196 with SMTP id y4mr2921173eby.61.1280996850211; Thu, 05 Aug 2010 01:27:30 -0700 (PDT)
Received: from [192.168.2.197] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id a48sm14335147eei.19.2010.08.05.01.27.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 05 Aug 2010 01:27:29 -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: <4C59C19B.4070101@earthlink.net>
Date: Thu, 05 Aug 2010 10:27:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E35FDFA-F73F-4005-8354-87ECB7A4E12D@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>
To: "Charles E. Perkins" <charles.perkins@earthlink.net>
X-Mailer: Apple Mail (2.1081)
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 08:27:02 -0000

Hi Charlie,

Op 4 aug 2010, om 21:38 heeft Charles E. Perkins het volgende geschreven:

> 
> Hello Teco,
> 
> On 8/4/2010 11:11 AM, Teco Boot wrote:
> 
>>>> 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 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?
Can you come up with something other than p2p?


>>> 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?
And what mechanism takes care?
If it is a routing protocol, the node is router.
It it learns an on-link prefix, it is not using the 
proposed addressing model.
If it learns an off-link prefix, and use the provider of 
this prefix (router sending RA) as default gateway, I am OK.
If it learns other routing info, I am also OK.

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


>> (Host learning more specific routes via p2p links could be exception)
> 
> This isn't necessary.  Shall I make an example?

This may help.


> 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 ??
What about uni-directional link test ??


> I have other examples that are more normal :-)

Please do so, previous one frightened me. 


>>> 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 am not claiming that the other solutions are
> mine -- but there are numerous examples in the
> literature.

Refs are OK. Or describe one.


> 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.
We agreed on three indications for classifying node a router.
Now on indications for hosts:
Oldie, RFC1122:
 (c)  Routing complexity should be in the gateways.
         Routing is a complex and difficult problem, and ought to
         be performed by the gateways, not the hosts.  An important
         objective is to insulate host software from changes caused
         by the inevitable evolution of the Internet routing
         architecture
And:
      The host IP layer has two basic functions:  (1) choose the "next
      hop" gateway or host for outgoing IP datagrams and (2) reassemble
      incoming IP datagrams. 
And the whole 3.3.1 section.
RFC5942 is also relevant.

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? 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.

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.


>>> 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.


>> 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.
> 
> Why not?
> 
> 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.


> 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.


>>>> 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.
> 
> 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.
I expect some argumentation. I did't see such.


>>> 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. 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.


>>> 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.
> 
> We do assume that hosts can transmit packets.
> At least I do.  Hosts that can transmit packets
> can support P2P links.  Why not??

We need populated routing tables getting packets around.
Without on-link prefixes, hosts have difficulties.


>> 2) hosts have routing tables.
> 
> Well, I'm glad you cleared that up.
> 
> 
>> 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.
> 
> What if the router sends out RA with /128, and hosts
> receiving the RA configure P2P route table entries to
> the router?  That would work.

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?


Regards, Teco


> But it's not the only way, of course.
> 
> Regards,
> Charlie P.