Re: [Autoconf] Autoconf addressing model

"Teco Boot" <> Tue, 03 March 2009 23:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 44A093A6908 for <>; Tue, 3 Mar 2009 15:24:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.317
X-Spam-Status: No, score=-1.317 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JmC4ZUYy5-98 for <>; Tue, 3 Mar 2009 15:24:44 -0800 (PST)
Received: from (cpsmtpo-eml04.KPNXCHANGE.COM []) by (Postfix) with ESMTP id EA8F43A67E9 for <>; Tue, 3 Mar 2009 15:24:43 -0800 (PST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 00:25:10 +0100
Received: from M90Teco ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Mar 2009 00:25:10 +0100
From: "Teco Boot" <>
To: "'Alexandru Petrescu'" <>
References: <> <> <> <000001c99845$1dc56190$595024b0$@nl> <> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <> <007201c99903$c4182c80$4c488580$@nl> <> <007b01c99911$907facf0$b17f06d0$@nl> <> <009501c99920$92154340$b63fc9c0$@nl> <> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl> <> <000101c99c3c$3121a870$9364f950$@nl> <>
In-Reply-To: <>
Date: Wed, 4 Mar 2009 00:25:10 +0100
Message-ID: <000d01c99c57$4c276db0$e4764910$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmcQUpKj5z7VM3RRZqIo24z+bHJJQAEHBYg
Content-Language: nl
X-OriginalArrivalTime: 03 Mar 2009 23:25:10.0372 (UTC) FILETIME=[4BBFD240:01C99C57]
Subject: Re: [Autoconf] Autoconf addressing model
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Mar 2009 23:24:45 -0000

Hi Alex,

We shall distinguish two subjects here:
 - Prefix assigned to MANET Interface or Loopback Interface
 - Usage of host prefix (/128 or /32 for IPv4).

I'll respond on host prefixes only.

I fully agree on minimizing overhead. All proposals I have done try to
realize this target. 
One of the mechanisms would be assigning a summary to a "mobile object",
e.g. a /60 summary for 16 /64 subnets. The router(s) in this "mobile object"
would only need to advertize the /60 prefix, nothing more. Some routers
support such a feature for a subset of the routing protocols, but most will
advertize all prefixes assigned to all (up) interfaces. 
I think for a MANET Routing Protocol, this summarization attribute is almost
mandatory (a SHOULD). I'll post this again on MANET when we discuss NHDP /
OLSR. A loopback interface could have a /128 out of this address block.
Using a /64 is OK also, but against guidelines for this.

Before a MANET Router has assigned such a summary prefix, it could act as a
router with LL addresses only and start exchanging routing messages. Now,
the router learns topology. It could be a requirement for the routing
protocol to use a unique identifier, e.g. an IPv4 address like what is being
used in OSPF (including OSPF-MANET). Maybe we need in MANET a 64-bit or
128-bit router-ID for randomly generated and unique IDs. So one of our
topics: what is (are) the unique IDs for the router, used by the MANET
Routing Protocol?

Also, if the router is MR (NEMO), it requires a globally unique address to
reach HA. This address is the only address that is required to distribute in
the MANET. Other prefix lengths are allowed, but of no help. So it doesn't
help scalability.

I still do not understand your concerns on using /128.


I think the /128 is mainly to be used for bootstrapping, for reaching a DHCP
server. Then, the router allocates a summary prefix. The summaries should be
optimized for MANET efficiency, e.g. address compression by RFC5444. Using a
self generated /64 (or shorter) ULA prefix is another option, but here we
might need more advanced duplicate detection mechanisms.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu []
|Verzonden: dinsdag 3 maart 2009 21:47
|Aan: Teco Boot
|Onderwerp: Re: Autoconf addressing model
|Teco, the problem is simple: host-based routes are not preferrable.
|Host-based routes in routers surrounding router X (this is what a /128
|address on a virtual interface on router X implies, be that loopback
|interface or not loopback interface) for a dynamically changing topology
|may lead to too many routes coming up and down, too many specific
|entries in the routing tables, too much dedicated routing messaging, and
|That only for the network itself.
|Connecting it to the Internet, with host-based routes propagated up and
|down throughout, may risk influencing the routes in the Internet proper.
|  A new host-based route inserted in the routing table of the gateway
|connecting this network to the Internet may propagate throughout the
|entire fixed access system.
|If you told me which part of the above were unclear I could explain
|further.  But I think there's large agreement on it.
|About the feasibility of _one_ /128 address on 'lo' while using _one_
|host-based route: as you pointed out with the ios-linux example, I fully
|agree a /128 address assigned on the 'lo' interface of one computer, and
|a host-based route in the other computer towards that /128 address -
|will work.  But just one.
|About posting to v6ops: which part do you think I should post there?
|About singling me out being the first and only mentioning some problem:
|I can only be happy about it and stop posting :-)  But this host-based
|route stuff is not new, I'm myself surprised I'm singled out about it.
|Teco Boot a écrit :
|> Hi Alex,
|> As far as I know, you are the first person that came up with problems
|>  using a loopback interface for globally unique addresses / host
|> prefixes (/128, /32) for routers. Please provide good argumentation,
|>  otherwise we follow the already accepted practice in the routing
|> community, also documented in RFC5375 (and others, e.g. RFC3484).
|> Maybe you should post this in v6ops, not in Autoconf.
|> Teco.