Re: [Autoconf] Autoconf addressing model

"Teco Boot" <> Thu, 05 March 2009 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACA6E3A67F5 for <>; Thu, 5 Mar 2009 06:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.755
X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f4IOZy9oSRh4 for <>; Thu, 5 Mar 2009 06:51:04 -0800 (PST)
Received: from (cpsmtpo-eml03.KPNXCHANGE.COM []) by (Postfix) with ESMTP id AF0D13A6809 for <>; Thu, 5 Mar 2009 06:51:03 -0800 (PST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 15:51:25 +0100
Received: from M90Teco ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 15:51:26 +0100
From: "Teco Boot" <>
To: "'Alexandru Petrescu'" <>
References: <> <> <007b01c99911$907facf0$b17f06d0$@nl><> <009501c99920$92154340$b63fc9c0$@nl><> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><> <000101c99c3c$3121a870$9364f950$@nl><> <><> <><> <> <> <> <> <> <> <> <49AF97FA.70200!> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9!> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.50403!> <004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.609>
In-Reply-To: <>
Date: Thu, 5 Mar 2009 15:51:26 +0100
Message-ID: <004b01c99da1$dc4ab9b0$94e02d10$@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: AcmdnONCHiOkeTlzT+mpjtL1LHF8CAAAhanA
Content-Language: nl
X-OriginalArrivalTime: 05 Mar 2009 14:51:26.0084 (UTC) FILETIME=[DBDE3C40:01C99DA1]
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: Thu, 05 Mar 2009 14:51:04 -0000

Hi Alex,

|> The 54 bits following 1111111011 are zero. There is little difference
|> between FE80::/10 and FE80::/64. On Ethernet, it is the latter.
|Which one should we picture on the AUTOCONF practical addressing scheme?
|  The /10 or the /64?

It depends.
With Ethernet (and related 802 addressing), it is /64.
For other interfaces, there is more freedom. But there is RFC4291:
   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

|In a picture like that I'd definitely put an address and the prefix like
|this, in the simplest case:
|     \ fe80::1/128   (the address)
|      ---------
|     / 2001:db8::/64 (the prefix of the subnet on which this interface
|---/                 attached)

Please read RFC4291 section 2.3 (Address Prefixes)

This "fe80::1/128" is an invalid address prefix. 
Address fe80::1 is OK, Address prefixes fe80::1/64 and 2001:db8::1/64 are
also OK.

|> |> I repeated the test with the link local addresses. Here also, I
|> |> experienced no problems. This is because there are two links with
|> |> exactly the same address pairs (an advantage to use same LL
|> |> on all interfaces).
|> |
|> |Demonstrating the advantage of loopback0 vs eth0 would have implied
|> |you start OSPFv3 on eth0 instead of loopback0 and that it would have
|> |crashed.
|> My routing protocols do not crash. I told you before.
|Sorry, I don't remember. So then they could work without loopback0
|interface, only over the Ethernet interface, right? (they wouldn't crash
|when the interface goes down and then up).
|> |But even then, I'm sure there may exist OSPFv3 implementation which
|> |would not crash when running over eth0 and ifconfig down eth0.
|> |
|> |In this sense, if the loopback0 interface is a solution to crashing
|> |OSPFv3-over-eth0, then it is an implementation solution. Some
|> |implementations do, others don't.
|> You totally missed the point.
|Your point seemed to motivate the use of loopback0 interface.  And so,
|because presumably the physical interfaces are not enough.  Am I
|catching your point?

You are free using loopback interfaces or not.
I explain why I have an advantage. This is not crashing protocols, it is
eliminating unneeded terminated sessions.

I do not accept a comment that I have no advantage. I have also different
scenarios, some have benefits from a loopback interface, some have not. I am
waiting on an answer from you, on your standpoint to be interoperable with
me or not. I hope your routing protocol doesn't crash when receiving a host
prefix. If so, I do not want to be compatible with you.