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

Philip Homburg <pch-6man@u-1.phicoh.com> Wed, 16 March 2011 10:26 UTC

Return-Path: <pch-b6B5344D9@u-1.phicoh.com>
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 39CFE3A6917 for <ipv6@core3.amsl.com>; Wed, 16 Mar 2011 03:26:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2]
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 i34s-XmG3HqW for <ipv6@core3.amsl.com>; Wed, 16 Mar 2011 03:26:25 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) by core3.amsl.com (Postfix) with ESMTP id 6AA5D3A6912 for <ipv6@ietf.org>; Wed, 16 Mar 2011 03:26:23 -0700 (PDT)
Received: from stereo.hq.phicoh.net ([127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #2) id m1PznxD-0001dSC; Wed, 16 Mar 2011 11:27 +0100
Message-Id: <m1PznxD-0001dSC@stereo.hq.phicoh.net>
To: Markus Hanauska <hanauska@equinux.de>
Subject: Re: Why has RFC 4941 been designed in such a way, that it might cause address conflicts?
From: Philip Homburg <pch-6man@u-1.phicoh.com>
Sender: pch-b6B5344D9@u-1.phicoh.com
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>
In-reply-to: Your message of "Wed, 16 Mar 2011 10:47:45 +0100 ." <3833B29B-1475-4BD7-B94D-7BD70AE4CB3B@equinux.de>
Date: Wed, 16 Mar 2011 11:27:29 +0100
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 10:26:26 -0000

In your letter dated Wed, 16 Mar 2011 10:47:45 +0100 you wrote:
>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 th
>at is supposed to have a certain fixed IP or a DHCP client, that is also suppo
>sed to have a certain fixed IP (however, one assigned by DHCP) cannot obtain t
>his IP, because some other host with privacy extension enabled is currently us
>ing this IP by plain coincident? How can you resolve that problem? Running aro
>und the building and asking all people with non-DHCP devices to please tempora
>rily disconnect of the network? 

You look up the MAC address for that IPv6 address and then block the MAC
address on your switches. Problem solved.

You can slightly better than that. For wired connections, you can look up
to which port the offending system is connected, and with an up-to-date cable
plan you can also find it.

For wireless, you want EAP anyhow, so you can just look up which user account
was used and then contact that user.