Re: Why has RFC 4941 been designed in such a way, that it might cause address conflicts?
Mohacsi Janos <mohacsi@niif.hu> Wed, 16 March 2011 10:44 UTC
Return-Path: <mohacsi@niif.hu>
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 93DAA3A693D for <ipv6@core3.amsl.com>; Wed, 16 Mar 2011 03:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.046
X-Spam-Level:
X-Spam-Status: No, score=0.046 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245]
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 Gt9R4+i39sbt for <ipv6@core3.amsl.com>; Wed, 16 Mar 2011 03:44:12 -0700 (PDT)
Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by core3.amsl.com (Postfix) with ESMTP id B6E3E3A693A for <ipv6@ietf.org>; Wed, 16 Mar 2011 03:44:11 -0700 (PDT)
Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 4F45A86D4B; Wed, 16 Mar 2011 11:45:37 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu
Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id fd-cycH3IYqI; Wed, 16 Mar 2011 11:45:21 +0100 (CET)
Received: by mail.ki.iif.hu (Postfix, from userid 9002) id BCEAF86D6D; Wed, 16 Mar 2011 11:45:21 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id BAA2B86D64; Wed, 16 Mar 2011 11:45:21 +0100 (CET)
Date: Wed, 16 Mar 2011 11:45:21 +0100
From: Mohacsi Janos <mohacsi@niif.hu>
X-X-Sender: mohacsi@mignon.ki.iif.hu
To: Markus Hanauska <hanauska@equinux.de>
Subject: Re: Why has RFC 4941 been designed in such a way, that it might cause address conflicts?
In-Reply-To: <3833B29B-1475-4BD7-B94D-7BD70AE4CB3B@equinux.de>
Message-ID: <alpine.BSF.2.00.1103161143220.87087@mignon.ki.iif.hu>
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>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
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:44:12 -0000
On Wed, 16 Mar 2011, Markus Hanauska 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 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? The servers are "always" working. Newcomers cannot hijack their addresses since DAD will fail for them.... Best Regards, Janos Mohacsi
- Why has RFC 4941 been designed in such a way, tha… Markus Hanauska
- Re: Why has RFC 4941 been designed in such a way,… Philip Homburg
- Re: Why has RFC 4941 been designed in such a way,… james woodyatt
- Re: Why has RFC 4941 been designed in such a way,… Markus Hanauska
- Re: Why has RFC 4941 been designed in such a way,… Philip Homburg
- Re: Why has RFC 4941 been designed in such a way,… Markus Hanauska
- Re: Why has RFC 4941 been designed in such a way,… Markus Hanauska
- Re: Why has RFC 4941 been designed in such a way,… james woodyatt
- Re: Why has RFC 4941 been designed in such a way,… Brian E Carpenter
- Re: Why has RFC 4941 been designed in such a way,… Philip Homburg
- Re: Why has RFC 4941 been designed in such a way,… Mohacsi Janos
- Re: Why has RFC 4941 been designed in such a way,… Markus Hanauska
- Re: Why has RFC 4941 been designed in such a way,… Sander Steffann
- Re: Why has RFC 4941 been designed in such a way,… Philip Homburg
- Re: Why has RFC 4941 been designed in such a way,… Markus Hanauska
- Re: Why has RFC 4941 been designed in such a way,… Mohacsi Janos
- Re: Why has RFC 4941 been designed in such a way,… Markus Hanauska
- Re: Why has RFC 4941 been designed in such a way,… Markus Hanauska
- Re: Why has RFC 4941 been designed in such a way,… Markus Hanauska
- Re: Why has RFC 4941 been designed in such a way,… Francis Dupont
- Re: Why has RFC 4941 been designed in such a way,… Brian Haley
- RE: Why has RFC 4941 been designed in such a way,… Hemant Singh (shemant)
- RE: Why has RFC 4941 been designed in such a way,… Hemant Singh (shemant)
- Re: Why has RFC 4941 been designed in such a way,… Brian E Carpenter
- RE: Why has RFC 4941 been designed in such a way,… Hemant Singh (shemant)
- RE: Why has RFC 4941 been designed in such a way,… Hemant Singh (shemant)
- Re: Why has RFC 4941 been designed in such a way,… Timothy Winters