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

james woodyatt <jhw@apple.com> Tue, 15 March 2011 17:26 UTC

Return-Path: <jhw@apple.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 1B1013A6D28 for <ipv6@core3.amsl.com>; Tue, 15 Mar 2011 10:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.546
X-Spam-Level:
X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 RL9hFBxXkn1p for <ipv6@core3.amsl.com>; Tue, 15 Mar 2011 10:26:43 -0700 (PDT)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 603253A69F9 for <ipv6@ietf.org>; Tue, 15 Mar 2011 10:26:43 -0700 (PDT)
Received: from relay16.apple.com (relay16.apple.com [17.128.113.55]) by mail-out4.apple.com (Postfix) with ESMTP id 7D016D927791 for <ipv6@ietf.org>; Tue, 15 Mar 2011 10:28:08 -0700 (PDT)
X-AuditID: 11807137-b7c3cae0000010f5-4b-4d7fa1a89b21
Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay16.apple.com (Apple SCV relay) with SMTP id BB.34.04341.8A1AF7D4; Tue, 15 Mar 2011 10:28:08 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.193.13.64] by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LI400C4O0IWSH20@gertie.apple.com> for ipv6@ietf.org; Tue, 15 Mar 2011 10:28:08 -0700 (PDT)
Subject: Re: Why has RFC 4941 been designed in such a way, that it might cause address conflicts?
From: james woodyatt <jhw@apple.com>
In-reply-to: <C744C51B-F2B0-4137-B39F-54B8D62F1C97@equinux.de>
Date: Tue, 15 Mar 2011 10:28:07 -0700
Message-id: <E7CFEDBC-5048-413E-93C9-DBF79B4FC238@apple.com>
References: <C744C51B-F2B0-4137-B39F-54B8D62F1C97@equinux.de>
To: Markus Hanauska <hanauska@equinux.de>
X-Mailer: Apple Mail (2.1084)
X-Brightmail-Tracker: AAAAAA==
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: Tue, 15 Mar 2011 17:26:44 -0000

On Mar 14, 2011, at 05:00 , Markus Hanauska wrote:
> 
> [...] And here is my reply: How is DAD preventing this problem if the device with the conflicting address in question is not connected to the network the moment DAD is performed? [...]

Were RFC 4429 and I-D.ietf-6man-dad-proxy among the documents you read over the weekend?

In general, you cannot prevent address conflict simply by reserving interface identifier patterns according to a strict plan.  No plan ever survives its initial encounter with the enemy.  Address conflicts MUST be dynamically resolved by protocol action, and protocols can fail when packets are lost.  Retransmits help reduce failure rates, but failure cannot ever be made logically impossible.  (There is math for that claim.)

Duplicate Address Detection (DAD) is the mechanism by which address conflicts are resolved in IPv6.  If you set DupAddrDetectTransmits to zero on an interface where DAD is required to prevent address conflicts, then the network isn't required to work properly when you do that.  If the subscriber aggregation network by which you're connecting a mobile node to the Internet requires a DAD proxy to prevent address conflicts, and the DAD proxy is malfunctional, then you can expect damaged network service as a result.  There is nothing special about RFC 4941 temporary addresses or RFC 3972 cryptographic addresses in this regard.

Plan accordingly and stay calm.


--
james woodyatt <jhw@apple.com>
member of technical staff, core os networking