Re: [Autoconf] Autoconf addressing model
"Teco Boot" <teco@inf-net.nl> Wed, 04 March 2009 22:57 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 D6A8C28C12C for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 14:57:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.683
X-Spam-Level:
X-Spam-Status: No, score=-1.683 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
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 azGt6ZGVcIAh for <autoconf@core3.amsl.com>; Wed, 4 Mar 2009 14:57:20 -0800 (PST)
Received: from hpsmtp-eml20.kpnxchange.com (hpsmtp-eml20.KPNXCHANGE.COM [213.75.38.85]) by core3.amsl.com (Postfix) with ESMTP id 4A0883A68DA for <autoconf@ietf.org>; Wed, 4 Mar 2009 14:57:20 -0800 (PST)
Received: from cpsmtp-eml110.kpnxchange.com ([10.94.168.110]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 23:57:47 +0100
Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml110.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 23:57:46 +0100
From: Teco Boot <teco@inf-net.nl>
To: "'Charles E. Perkins'" <charles.perkins@earthlink.net>
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>
In-Reply-To: <49ADBCD8.9040301@earthlink.net>
Date: Wed, 04 Mar 2009 23:57:47 +0100
Message-ID: <000901c99d1c$a2d939c0$e88bad40$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmcV5tlk+ckocSzSGSdnilki1aSFgAqPI/Q
Content-Language: nl
X-OriginalArrivalTime: 04 Mar 2009 22:57:47.0039 (UTC) FILETIME=[A2A8DAF0:01C99D1C]
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 22:57:21 -0000
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 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.
- 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