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

Teco Boot <teco@inf-net.nl> Wed, 21 July 2010 16: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 6279E3A6896 for <autoconf@core3.amsl.com>; Wed, 21 Jul 2010 09:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 6wMV050etOuI for <autoconf@core3.amsl.com>; Wed, 21 Jul 2010 09:57:23 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 40BDA3A67F8 for <autoconf@ietf.org>; Wed, 21 Jul 2010 09:57:22 -0700 (PDT)
Received: by eyb7 with SMTP id 7so2018309eyb.31 for <autoconf@ietf.org>; Wed, 21 Jul 2010 09:57:38 -0700 (PDT)
Received: by 10.213.12.196 with SMTP id y4mr387794eby.89.1279731458193; Wed, 21 Jul 2010 09:57:38 -0700 (PDT)
Received: from [192.168.2.168] (ip56530916.direct-adsl.nl [86.83.9.22]) by mx.google.com with ESMTPS id v59sm53665692eeh.10.2010.07.21.09.57.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Jul 2010 09:57:37 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Teco Boot <teco@inf-net.nl>
In-Reply-To: <AANLkTil6lRJPunxB1oAbnTL0d6gpIXHUTuyTBPi5NTbX@mail.gmail.com>
Date: Wed, 21 Jul 2010 18:57:36 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2B8E3E9-084B-45F0-860C-C88A0859BC95@inf-net.nl>
References: <4C2A6BB7.1000900@piuha.net> <4C2CFADD.3040909@piuha.net> <4C378C29.2040302@oracle.com> <AANLkTil6lRJPunxB1oAbnTL0d6gpIXHUTuyTBPi5NTbX@mail.gmail.com>
To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
X-Mailer: Apple Mail (2.1081)
Cc: "autoconf@ietf.org" <autoconf@ietf.org>
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)
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, 21 Jul 2010 16:57:26 -0000

Emmanuel,

Let's solve the duplicate unique MAC address problem. You bring the cards, I'll take the hammer. Then, we (IETF) can stop solving others problems.

DHCP fully relies on a client provided token, which must be unique.
An overwhelming majority of clients use MAC addresses.
I don't say there are no problems, but many of us accept the risk.

Posted before, I dealt with a DAD DOS attack. It is proven that it is broken.
I don't want to accept this risk.
Ideas?

Teco



Op 21 jul 2010, om 11:58 heeft Emmanuel Baccelli het volgende geschreven:

> Hi Erik,
> 
> 
> On Fri, Jul 9, 2010 at 10:52 PM, Erik Nordmark <erik.nordmark@oracle.com> wrote:
> ...
>  
> The result is that the document can easily be construed as discouraging approaches that make a lot of sense, which seems counterproductive.
> An example of such an approach is a routing protocol which uses IEEE MAC addresses as router ids, assigns IPv6 link-local addresses to the router's interfaces and uses that in the routing protocol exchanges, and configures global addresses for use by applications.
> 
>  
> 
> Using MAC addresses for unique identifier is considered dangerous by many people, as MAC addresses are not always unique. There were several cases where an order of several thousands of devices where shipped with the exact same MAC address, by mistake. Moreover, MAC addresses can be altered almost at will. This is why relying on MAC addresses for unique identifiers is not sufficient in my mind. It's merely another way to say: "let other people worry about our problems". This rarely works reliably.
> 
> As to using link local addresses, there are many cases where it is not appropriate, as discussed over and over in this working group and elsewhere. If you have any comments on http://ietfreport.isoc.org/all-ids/draft-baccelli-multi-hop-wireless-communication-04.txt please let us know. The fundamental properties of multi-hop wireless communications described in that document make it difficult to use link-local addresses in many cases.
> 
> And again, the goal of RFC5889 is not to describe all possible addressing models for each specific scenario, but rather to describe one specific model with which we have experience in multi-hop wireless contexts, and which has proven to work OK. In that respect, I think RFC5889 does the job.
> 
> Regards,
> Emmanuel
> 
> 
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf