IETF Logo Mail Archive

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 09:46 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 5B1473A68F3 for <ipv6@core3.amsl.com>; Wed, 16 Mar 2011 02:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.351
X-Spam-Level:
X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 AXo1xYA831Tx for <ipv6@core3.amsl.com>; Wed, 16 Mar 2011 02:46:50 -0700 (PDT)
Received: from mail.equinux.net (mail.equinux.net [194.145.236.10]) by core3.amsl.com (Postfix) with ESMTP id 6A9A93A68F7 for <ipv6@ietf.org>; Wed, 16 Mar 2011 02:46:50 -0700 (PDT)
Received: from mail.equinux.net (127.0.0.1) by mail.equinux.net (MlfMTA v3.2r9) id hg1qq20171sp for <ipv6@ietf.org>; Wed, 16 Mar 2011 09:32:02 +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 09:32:02 +0100
Received: from anaheim.muc.equinux.net (anaheim.muc.equinux.net [192.168.40.40]) by mail.muc.equinux.net (Postfix) with ESMTPS id 831E220F93A3; Wed, 16 Mar 2011 10:47:45 +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: <alpine.BSF.2.00.1103160951100.87087@mignon.ki.iif.hu>
Date: Wed, 16 Mar 2011 10:47:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3833B29B-1475-4BD7-B94D-7BD70AE4CB3B@equinux.de>
References: <C744C51B-F2B0-4137-B39F-54B8D62F1C97@equinux.de> <alpine.BSF.2.00.1103160951100.87087@mignon.ki.iif.hu>
To: Mohacsi Janos <mohacsi@niif.hu>
X-Mailer: Apple Mail (2.1082)
X-Mlf-Version: 7.2.1.2841
X-Mlf-UniqueId: o201103160832020094427
Cc: ipv6@ietf.org
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 09:46:51 -0000

On 2011-03-16, at 10:08 , Mohacsi Janos wrote:

> Yes. DAD can fail, and you system log you will see.


How will this help a network admin, when the system log says, that a server that is supposed to have a certain fixed IP or a DHCP client, that is also supposed to have a certain fixed IP (however, one assigned by DHCP) cannot obtain this IP, because some other host with privacy extension enabled is currently using this IP by plain coincident? How can you resolve that problem? Running around the building and asking all people with non-DHCP devices to please temporarily disconnect of the network? Assigning a different IP to the server or the DHCP device does not resolve the problem at all, because those are supposed to have a certain IP and not any IP. Assigning a different IP to the stateless device would work, but how can you know which of the maybe 100 stateless devices on the network is the device that captured the IP?

Best regards,
Markus

v2.23.0 | Report a Bug | By Email