Re: Why has RFC 4941 been designed in such a way, that it might cause address conflicts?

Markus Hanauska <hanauska@equinux.de> Wed, 16 March 2011 10:37 UTC

Return-Path: <hanauska@equinux.de>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1213A6935 for <ipv6@core3.amsl.com>; Wed, 16 Mar 2011 03:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.393
X-Spam-Level:
X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.207, 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 DbiK6C-WwJhN for <ipv6@core3.amsl.com>; Wed, 16 Mar 2011 03:37:01 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by core3.amsl.com (Postfix) with ESMTP id F20A03A690E for <ipv6@ietf.org>; Wed, 16 Mar 2011 03:37:00 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hg20m80171s6 for <ipv6@ietf.org>; Wed, 16 Mar 2011 10:21:51 +0100 (envelope-from <hanauska@equinux.de>)
Received: from mail.muc.equinux.net ([192.168.40.207]) by mail.equinux.net (equinux Secure Mail Relay) with ESMTP; Wed, 16 Mar 2011 10:21:51 +0100
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 7FDDE20F9535; Wed, 16 Mar 2011 11:37:35 +0100 (CET)
Subject: Re: Why has RFC 4941 been designed in such a way, that it might cause address conflicts?
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Markus Hanauska <hanauska@equinux.de>
In-Reply-To: <FBAEF08B-2E46-47BD-A432-31A584E72786@steffann.nl>
Date: Wed, 16 Mar 2011 11:37:35 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E78895C-8CFC-4B4B-9882-B20C29D25E01@equinux.de>
References: <C744C51B-F2B0-4137-B39F-54B8D62F1C97@equinux.de> <alpine.BSF.2.00.1103160951100.87087@mignon.ki.iif.hu> <3833B29B-1475-4BD7-B94D-7BD70AE4CB3B@equinux.de> <FBAEF08B-2E46-47BD-A432-31A584E72786@steffann.nl>
To: Sander Steffann <sander@steffann.nl>
X-Mailer: Apple Mail (2.1082)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201103160921510094670
Cc: ipv6@ietf.org, Mohacsi Janos <mohacsi@niif.hu>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Mar 2011 10:37:02 -0000

On 2011-03-16, at 11:05 , Sander Steffann wrote:

> The chance of this happening is *very* *very* small.

The chances that a MD5 hash of any data will ever be exactly zero (all octets are zero) is ridiculous tiny. It is probably so extremely unlikely that the world would rather be destroyed by a meteor tomorrow than this is ever going to happen. Still IPv6 implementations verify that the output of the MD5 hash function is not exactly zero when creating a temporary address as suggested by RFC 4941 (I verified this by source code). The scenario that I described is much more likely than a MD5 of zero, but here no code exists to prevent it.

> I would worry more about people choosing such an IP address intentionally to cause trouble...

That would rather be security issue, since why would anyone do that, unless he's doing it by intention? And if someone does that by intention, he's probably planing to do something evil.

Best regards,
Markus