Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

Henning Rogge <> Fri, 09 July 2010 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FF393A6A91 for <>; Fri, 9 Jul 2010 09:46:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8CaD263fpQDW for <>; Fri, 9 Jul 2010 09:46:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9B0813A6946 for <>; Fri, 9 Jul 2010 09:46:25 -0700 (PDT)
Received: by wyb40 with SMTP id 40so1822814wyb.31 for <>; Fri, 09 Jul 2010 09:46:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=McgXuaENcdyxFzgG25U1TfZULt+wscdvRPFtG4cMvqg=; b=gxzGRUEZxDLV2arq5ZLdS7bPdM0TQrJPHqXjI/+U5KyfqBukSCgMMG7Ghb+iJ1DCQY RDOOSzXfW4CzsTIsD0iBszwc5p7pQa9zdXJQHSb6Z+vYja6CGS4jM7eNL0p5vykymVp4 CkV5LtIhpUfxWgFLPumSnHOHxG1cwzzcxY+n4=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=YBVPrPO1z2wvhEOqI1tKO4yAJvmwWmr6pqaPfXCdu5Fbu4MOJ9fZ/+3wJ0jVAoZik6 TH4TQUtLpxUvpHFqH9FKAl81RZkxsaDfxugkNG3oMBTEoT9lIRDGhFjFsuDtIeZaK4GT eqNjgjAliQTATJwdq1jTudFGM8H5+ShkGqHik=
Received: by with SMTP id e20mr1496808wbe.44.1278693987616; Fri, 09 Jul 2010 09:46:27 -0700 (PDT)
Received: from core2.localnet ( []) by with ESMTPS id o54sm127197wej.29.2010. (version=SSLv3 cipher=RC4-MD5); Fri, 09 Jul 2010 09:46:25 -0700 (PDT)
From: Henning Rogge <>
To: Teco Boot <>
Date: Fri, 9 Jul 2010 18:46:19 +0200
User-Agent: KMail/1.13.5 (Linux/2.6.34-gentoo-r1; KDE/4.4.5; x86_64; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1386841.9Fnfz0l2Gv"; protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <>
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)
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: Fri, 09 Jul 2010 16:46:27 -0000

Am Freitag 09 Juli 2010, 18:12:45 schrieb Teco Boot:
> > I think this is still too strong.
> > "There is no mechanism to ensure..." does sound as there never will be
> > one. If we cannot find a mechanism/protocol to do this, we cannot find
> > one that creates routing unique adresses (because the later would do the
> > former too).
> > 
> > I think it should start with something like this:
> > "The default mechanisms of IPv6 cannot ensure that..."
> > (instead of "There is no mechanism to ensure that...")
> Although I think the document should not kept waiting, I don't agree on
> this. There is no mechanism to detect duplicate globals on different
> links. The ND DAD mechanism does not work in a MANET for LL, and _also_
> not for globals !! A mechanism that ensures unique Interface-IDs ensures
> unique LLs.
> We all agreed on that we shall not work on a new protocol for
> autoconfiguring LLs. It is globals and MANET-locals (ULAs) that we are
> looking for.
> That is in the document, in old and new text.
Yes... I just said that an autoconfiguration protocol that solves the 
configuration problem for global unique IPs or ULAs would be trivial to adapt 
for generating "link local" IPs, just by putting the LL-prefix to the 
generated ULAs.
> I would use unique LLs as router-IDs. I don't get what is wrong with this,
> as long as LLs are unique.
There is nothing wrong with this. This strategy will solve the LL-generation.
Which instantly contradicts the statement "there is no mechanism to ensure..." 

> But LLs MUST NOT be used for multi-hop forwarded traffic.
No problem with this one.

Henning Rogge
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized