Re: [Autoconf] Autoconf addressing model
Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 04 March 2009 23:40 UTC
Return-Path: <alexandru.petrescu@gmail.com>
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 C68A528C19C for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 15:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 wsbUbbcpie1P for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 15:40:49 -0800 (PST)
Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id C8DC83A6B14 for <autoconf@ietf.org>; Wed, 4 Mar 2009 15:40:47 -0800 (PST)
Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 72DB74C8079; Thu, 5 Mar 2009 00:41:11 +0100 (CET)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 2A9494C809B; Thu, 5 Mar 2009 00:41:09 +0100 (CET)
Message-ID: <49AF1191.1080307@gmail.com>
Date: Thu, 05 Mar 2009 00:41:05 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Teco Boot <teco@inf-net.nl>
References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl> <49AD90D9.5040100@earthlink.net> <000c01c99c4f$d1ab1750$750145f0$@nl> <49ADBCD8.9040301@earthlink.net> <000901c99d1c$a2d939c0$e88bad40$@nl>
In-Reply-To: <000901c99d1c$a2d939c0$e88bad40$@nl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 090303-2, 04/03/2009), Outbound message
X-Antivirus-Status: Clean
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Autoconf addressing model
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: Wed, 04 Mar 2009 23:40:50 -0000
Teco Boot a écrit : > Hi Charlie, > > Yes, I think the issues in this thread touch our basic problems. Here some > follow-up: > > - on little wireless nodes that have a single interface: > The scope of MANETs is quite large, e.g. from aircraft carriers to smart > dust. For the most tiny devices, I am not sure we should deal with these. > There are other WGs working on PAN / sensor networks, maybe we could focus > on the somewhat larger stuff. And were a device type have a single > interface, new versions in this category may have more. > Example: my 8 years old phone has 2 wireless interfaces, 1 wired and one IR. > Only one is IP enabled. Maybe I'll buy a new one some time, I think this one > would have almost all interfaces IP enabled and it would have more than 4 > interfaces. > > > - on guideline for using router loopback interface for management: > I think this is a no-brainer for ISP / enterprise network engineers. Many > documents provide this advice, but I was looking for something that has not > a logo from a certain company. The problem here is, this company has a high > market share in this arena and also publish a lot of guidelines. > Here some refs, I hope this will convince you this is a well accepted > practice. > http://www.apnic.net/training/download/irm-1/irm1-7-addrplan.pdf > http://ws.edu.isoc.org/data/2004/604610702427ef01785c49/loopback-6up.pdf > ftp://ftp.hp.com/pub/networking/software/ProCurve-SR-BGP-Config-Guide-08-05. > pdf > http://www.juniper.net/techpubs/software/junos-es/junos-es92/junos-es-swconf > ig-interfaces-and-routing/special-interfaces.html#loopback-interface-section > http://www.apnic.net/meetings/26/program/apops/transcript.html#yoshinobu-arc > hitecture > > > - on status of address / interface; socket api for this: > I discussed this with some colleagues, on what the requirements are. We came > to the conclusion that applications should be able to select an address that > belongs to a stable (ifup) interface, e.g. the loopback interface. > Applications should also be able to select an address that belongs to a > physical interface. Multicast applications can take benefits here. Having > different options could make defining default behavior somewhat complex. > Shim mechanisms (MIP/MIP6, Shim6, HIP) and socket interfaces based on names > hide addressing details from the applications. But such an approach may > affect applications for high availability, and in my environment this is > important. > > > > == back to the addressing model: > After some more thoughts, I come to the conclusion that MANET Routers should > advertize as little as possible, for reducing overhead. This is about > routing prefixes. The advertized prefix should "belong" to the indivisible > "mobile object", this means the summary prefix must not split and > sub-prefixes (subnets??) shall be interconnected within the "mobile object". > Single router "mobile object" has this behavior by nature. > Addresses assigned to interfaces come from the advertized prefix and may > have any prefix-length equal or longer than the advertized prefix-length. > Loopback interfaces should have /128 (or /32), as defined in RFCs for this. > Ethernet typically have /64, this is specified in std track RFC and it is a > MUST if SLAAC is used. > Still the question on using /128, /64 or other for globally unique > address-prefixes that are assigned to MANET interfaces of this "mobile > object". Maybe we do not need to restrict this. Mentioning the options and > the consequences is good enough, I think. > Some consequences with /127 are described in RFC3627. This RFC also mentions > /128: > Using two /128 addresses is also one, though often cumbersome, > approach. Naturally, not much would be lost if even a shorter > prefix was used, e.g., /112 or /120. > > > The diagram in MANET-ARCH 5.1 could be adjusted to reflect my thoughts. > Below, it is more an example and less a "model". > > > <~~~~~~+~~~~~~> > | Assigned Prefix > | =================== > 2001:db8:0::EUI-64/64| <=== 2001:db8:0::/64 = > FE80::EUI-64/64| =================== > MANET Interface| Delegated Prefix > +-----------------------+ /-------------\ > | | <<<<<<<<<<<<| 2001:db8::/60 | > | MANET | \-------------/ > | Router | > | | > | ................... | Assigned Prefix > | !Loopback ! | ===================== > | !2001:db8:F::0/128! | <=== 2001:db8:F::0/128 = > | ''''''''''''''''''' | ===================== > +---------------+-------+ > Ethernet Interface: Assigned Prefix > FE80::EUI-64/64: =================== > 2001:db8:1::EUI-64/64: <======== 2001:db8:1::/64 = > : =================== > .............. > : : > FE80::EUI-64/64: :FE80::EUI-64/64 > 2001:db8:1::dhcp/64: :2001:db8:1::EUI-64/64 > +--------------+-+ +--+--------------+ > | Host with DHCP | * * * | Host with SLAAC | > +----------------+ +-----------------+ In the above figure: I agree with many points that I won't mention. But I don't agree using the loopback interface for this. And I don't understand why there's a "MANET Interface" and a "Ethernet interface". I really don't see the need for any virtual interface. Let me give my take on virtual interfaces... Some routing protocols use virtual interfaces because at least the following problem: it has been shown in practice that when a e.g. wifi interface gets disassociated from the AP the interface may go down, and in some implementations it may SIGKILL (or worse) the app using that socket. And if the app is the routing protocol the net effect is very bad: routing protocol crashes. This was very bad. It also meant that whenever I would disconnect the Ethernet cable (on some implementations, again), the routing protocol implementation would crash; or when my bluetooth interface gets down. Or similar 'mobility' event which would never previously appear in the fixed-router-Internet, because people wouldn't consciously disconnect Ethernet cables whereas phone lines would still get jammed (a modem line being overloaded wouldn't SIGKILL the app running on that kernel, because modem separated from computer by rs-232 and rs-232 no interface structure). To cope with that, put up a virtual interface and add routes between that virtual interface and the wifi interface. And run the routing protocol on top of _that_ virtual interface instead of the wifi interface. Since it is virtual it never gets down (unless maybe a tree falls), the routing protocol implementation will crash less. It was thus shown that the routing protocol running on a virtual interface is advantageous, dealing better with mobility events - at least it could be deterministic! However, there exist also implementations of wifi drivers which won't put the interface down when the interface gets dissasociated. Also there exist kernels which won't SIGKILL the app, and there exist also protocols implementations who'd deal with that SIGKILL more gently if it popped up. Also there exist implementations of routing protocols who would not deal at all with any particular interface structure (be that real or virtual) - they're independent on the kernel's interface structures being up or down or whatever state, but use directly the card's buffers to send or receive data. I agree though these implementations are less widespread. Overall, I think a safe bet is somewhere in the middle: to not talk about virtual interfaces (neither loopback, nor others) but only about real interfaces and of specific types. And to consider the virtual interfaces to be a detail of _some_ implementations. Alex > > In a table format: > > Delegated summary prefix: 2001:db8::/60 > 15 x /64: MANET Interface: 2001:db8:0::/64 > Ethernet Interface: 2001:db8:1::/64 > " " " " " " " > up to: 2001:db8:E::/64 > Block for longer prefix lengths: 2001:db8:F::/64 > Loopback Interface #0: 2001:db8:F::0/128 > (others, e.g. P2P) " " " > > > This model provides RFC4862 SLAAC service for nearby hosts, also useful for > MANET Router (or NEMO Router) bootstrapping. For getting a delegated prefix, > the a SLAAC address could be used for communication with a DHCP server, > using unicast (to be verified). Important: the /64 prefix that corresponds > with the SLAAC address-prefix MUST NOT be advertized in the MANET Routing > Protocol. Advertizing this as a host prefix is allowed, but getting an own > /60 or whatsoever summary is advised. The result here is a MANET Routing > Protocol requirement (not advertizing /64 SLAAC prefixes). > The MANET Router may act as DHCP Server (or relay agent) for its Delegated > Prefix(es). SLAAC is also supported. > > > > On dec 2007 I posted similar thoughts > (http://www.ietf.org/mail-archive/web/autoconf/current/msg00901.html). > Are we making progress? I think: yes! > > > Teco. > > > > > > |-----Oorspronkelijk bericht----- > |Van: Charles E. Perkins [mailto:charles.perkins@earthlink.net] > |Verzonden: woensdag 4 maart 2009 0:27 > |Aan: Teco Boot > |CC: autoconf@ietf.org > |Onderwerp: Re: [Autoconf] Autoconf addressing model > | > | > |Hello Teco, > | > |You raise interesting questions, but I think mostly > |not definitive for the questions at hand. I don't know > |if I have any good answers, but here are some comments. > | > |Teco Boot wrote: > |> As long as I designed and maintained network infrastructures, I worked > |with > |> "/32 management addresses" on loopback interfaces. Still, I have > |annoying > |> experiences with routers that select the outgoing interface address as > |> default source address. Shutting down an interface could have > |unintended bad > |> impact on your terminal session. Same for link flapping due to other > |causes. > |> > | > |I guess this is relevant for packet forwarders with more than one > |network interface. For our little wireless nodes that have a single > |interface, I don't imagine we'd see that kind of interface aggravation. > | > |> For this reason, many routers on the Internet use the loopback > |interface for > |> "management". "Management" is the host application on routers. There > |are > |> lots of design guidelines for this. My proposal is using the "Internet > |> lessons learned" in the MANET. Nothing wrong with this, agreed? > |> > | > |I know only a small bit about this. Do you have a favorite > |document that I could read to learn more? > | > |> > |> With MobileIP, we are discussing a host (could be NEMO Router, but > |then it > |> acts as host on the visiting link). The MobileIP stack is interested > |in the > |> status of the visiting link, but does it propagate this to the > |applications? > |> Or use the applications some kind of virtual interface (e.g. a > |loopback > |> interface)? Or spoof ifup for interface to home link? > |> > | > |Whether or not applications have access to link information is > |something not closely related to Mobile IP. Whether or not > |the care-of address is available to applications is a surprisingly > |complicated question, which in my opinion opens the door to > |many interesting questions and indicates the insufficiency of > |today's typical application socket interface. > | > |I've had a lot of ideas about how to fix this, but never been > |able to initiate a project to supply a finished proposal. > | > | > |Regards, > |Charlie P. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf >
- Re: [Autoconf] new charter Jari Arkko
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Paul Lambert
- [Autoconf] new charter Jari Arkko
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Ryuji Wakikawa
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Charles E. Perkins
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter HyungJin Lim
- [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] practical addressing (was: new cha… Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] practical addressing (was: new cha… Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] practical addressing Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- [Autoconf] radio neighbors in range Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] radio neighbors in range Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] new charter Rex Buddenberg
- Re: [Autoconf] practical addressing Teco Boot
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] radio neighbors in range Teco Boot
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] radio neighbors in range Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Joe Macker
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] radio neighbors in range Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Joe Macker
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Joe Macker
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- [Autoconf] new charter Ryuji Wakikawa
- Re: [Autoconf] new charter Teco Boot