Re: [Autoconf] Autoconf addressing model

"Teco Boot" <teco@inf-net.nl> Thu, 05 March 2009 14:51 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 ACA6E3A67F5 for <autoconf@core3.amsl.com>; Thu, 5 Mar 2009 06:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.755
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4IOZy9oSRh4 for <autoconf@core3.amsl.com>; Thu, 5 Mar 2009 06:51:04 -0800 (PST)
Received: from cpsmtpo-eml03.kpnxchange.com (cpsmtpo-eml03.KPNXCHANGE.COM [213.75.38.152]) by core3.amsl.com (Postfix) with ESMTP id AF0D13A6809 for <autoconf@ietf.org>; Thu, 5 Mar 2009 06:51:03 -0800 (PST)
Received: from cpsmtp-eml102.kpnxchange.com ([213.75.84.102]) by cpsmtpo-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 15:51:25 +0100
Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml102.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 15:51:26 +0100
From: "Teco Boot" <teco@inf-net.nl>
To: "'Alexandru Petrescu'" <alexandru.petrescu@gmail.com>
References: <499F0BA7.90501@piuha.net> <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><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl> <49AFD85E.50403! 01@gmail.com> <004a01c99d9b$542e1e10$fc8a5a30$@nl> <49AFDE93.609 04@gmail.com>
In-Reply-To: <49AFDE93.60904@gmail.com>
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]
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: 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
|is
|---/                 attached)
|

Why?
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
|addresses
|> |> on all interfaces).
|> |
|> |Demonstrating the advantage of loopback0 vs eth0 would have implied
|that
|> |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.


Teco.


|Alex