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.
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- [Autoconf] RFC 5889 (Was: Call for comments to a … Jari Arkko
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Jari Arkko
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Jari Arkko
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Ulrich Herberg
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Charles E. Perkins
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Stan Ratliff
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Zach Shelby
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Erik Nordmark
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Zach Shelby
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Ryuji Wakikawa
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Ryuji Wakikawa
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Emmanuel Baccelli
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Emmanuel Baccelli
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Jari Arkko
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Ulrich Herberg
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Jari Arkko
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Ulrich Herberg
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Thomas Heide Clausen
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Thomas Heide Clausen
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Thomas Heide Clausen
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Ulrich Herberg
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Thomas Heide Clausen
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Thomas Heide Clausen
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Henning Rogge
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Teco Boot
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Alexandru Petrescu
- Re: [Autoconf] RFC 5889 (Was: Call for comments t… Erik Nordmark
- Re: [Autoconf] RFC 5889 Erik Nordmark
- [Autoconf] Forgot one [Was: RFC 5889 Erik Nordmark
- Re: [Autoconf] RFC 5889 Dearlove, Christopher (UK)
- Re: [Autoconf] RFC 5889 Erik Nordmark
- Re: [Autoconf] Forgot one [Was: RFC 5889 Erik Nordmark
- Re: [Autoconf] Forgot one [Was: RFC 5889 Dearlove, Christopher (UK)
- Re: [Autoconf] what's a router Henning Rogge
- [Autoconf] WC consensus call for RFC5889 modifica… Ryuji Wakikawa
- Re: [Autoconf] WC consensus call for RFC5889 modi… Jari Arkko
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Henning Rogge
- Re: [Autoconf] WC consensus call for RFC5889 modi… Henning Rogge
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Henning Rogge
- Re: [Autoconf] WC consensus call for RFC5889 modi… Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Alexandru Petrescu
- Re: [Autoconf] WC consensus call for RFC5889 modi… Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Henning Rogge
- Re: [Autoconf] WC consensus call for RFC5889 modi… Dearlove, Christopher (UK)
- Re: [Autoconf] what's a router (was: WC consensus… Alexandru Petrescu
- Re: [Autoconf] what's a router (was: WC consensus… Henning Rogge
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] WC consensus call for RFC5889 modi… Emmanuel Baccelli
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] what's a router Teco Boot
- Re: [Autoconf] what's a router Henning Rogge
- Re: [Autoconf] what's a router (was: WC consensus… Ulrich Herberg
- Re: [Autoconf] what's a router (was: WC consensus… Teco Boot
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] what's a router Rogge Henning
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] what's a router Alexandru Petrescu
- Re: [Autoconf] WC consensus call for RFC5889 modi… Alexandru Petrescu
- Re: [Autoconf] what's a router Teco Boot
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Thomas Heide Clausen
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Thomas Heide Clausen
- Re: [Autoconf] WC consensus call for RFC5889 modi… Emmanuel Baccelli
- Re: [Autoconf] WC consensus call for RFC5889 modi… Charles E. Perkins
- Re: [Autoconf] WC consensus call for RFC5889 modi… Emmanuel Baccelli
- Re: [Autoconf] WC consensus call for RFC5889 modi… Emmanuel Baccelli