IETF Logo Mail Archive

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

"Hemant Singh (shemant)" <shemant@cisco.com> Sun, 20 March 2011 14:25 UTC

Return-Path: <shemant@cisco.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 017F53A6BC7 for <ipv6@core3.amsl.com>; Sun, 20 Mar 2011 07:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.452
X-Spam-Level:
X-Spam-Status: No, score=-10.452 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8]
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 Xk2dW5MmemRu for <ipv6@core3.amsl.com>; Sun, 20 Mar 2011 07:25:44 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 001353A6A03 for <ipv6@ietf.org>; Sun, 20 Mar 2011 07:25:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1349; q=dns/txt; s=iport; t=1300631236; x=1301840836; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=1yZuPM7XYYKui+ve3c5ZUd/YMNMBoJr6oyefK73sdpI=; b=Rl37B9w44pD/Vmo86fiZiYfvwH1angH7Ga0xlu3WniHBsfDKRnYjaQv1 1uYiHfDC5Agwih86GlOZnYx7S0ipyMG7DUbKkZXIKEbnwNx+pgZ8eDYmj 7O8wMbP9i9+95JgXHOaUZMrxLRSvFaGNMTD9OHuy2UALjGn+uL2x7D/Uy E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuIAAAushU2tJV2Z/2dsb2JhbACYPY06d6RGmxOFYwSFM4sL
X-IronPort-AV: E=Sophos;i="4.63,214,1299456000"; d="scan'208";a="668906887"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 20 Mar 2011 14:27:14 +0000
Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2KEREac027225; Sun, 20 Mar 2011 14:27:14 GMT
Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 Mar 2011 09:27:14 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Why has RFC 4941 been designed in such a way, that it might cause address conflicts?
Date: Sun, 20 Mar 2011 09:27:09 -0500
Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3010D2AF1@XMB-RCD-109.cisco.com>
In-Reply-To: <E7CFEDBC-5048-413E-93C9-DBF79B4FC238@apple.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Why has RFC 4941 been designed in such a way, that it might cause address conflicts?
Thread-Index: AcvjNmB7FvdLEHp1QVem+kmr/t2g/gD0SwYA
References: <C744C51B-F2B0-4137-B39F-54B8D62F1C97@equinux.de> <E7CFEDBC-5048-413E-93C9-DBF79B4FC238@apple.com>
From: "Hemant Singh (shemant)" <shemant@cisco.com>
To: james woodyatt <jhw@apple.com>, Markus Hanauska <hanauska@equinux.de>
X-OriginalArrivalTime: 20 Mar 2011 14:27:14.0581 (UTC) FILETIME=[E8743450:01CBE70A]
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: Sun, 20 Mar 2011 14:25:45 -0000

-----Original Message-----
From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of
james woodyatt
Sent: Tuesday, March 15, 2011 1:28 PM
To: Markus Hanauska
Cc: ipv6@ietf.org
Subject: Re: Why has RFC 4941 been designed in such a way,that it might
cause address conflicts?


>Duplicate Address Detection (DAD) is the mechanism by which address
conflicts are resolved in IPv6.  

DAD as per RFC 4862 does not resolve conflicts but detects the
conflicts.  See section 5.4.5 which punts a duplicate detected event to
the admin of the network to deal with.

>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.


Speaking of a mobile network (cellular) where it does make sense to set
DupAddrDetectTransmits to zero since the hosts use p2p and hosts use the
Modified EUI-64 format for Interface Identifier (IID) - see RFC 2472.
Modified EUI-64 uses a global token to generate the IID and thus the IID
is likely to be unique. 

Hemant

v2.23.0 | Report a Bug | By Email