IETF Logo Mail Archive

Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Sun, 16 July 2017 06:41 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75FE12785F for <ipv6@ietfa.amsl.com>; Sat, 15 Jul 2017 23:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbU022Dz1W3b for <ipv6@ietfa.amsl.com>; Sat, 15 Jul 2017 23:41:48 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5951271DF for <ipv6@ietf.org>; Sat, 15 Jul 2017 23:41:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2218; q=dns/txt; s=iport; t=1500187307; x=1501396907; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=wm77yizVSqyFcrpfGk6sBuiyKfZOvxbxOs95wmz+5vM=; b=mIhjdz6kk3qZPbQqwwOtGe3m1P+N5uqYqC28Ze+EF/9EjVnZFh7NSd+k TgkFEXXMvuR21f5n6VIDGLP0KFy0P2TNI6VGHn48EkHZp2Qaw1tSKePF5 lBUirdToA2lRYsjOHfq5KbUrqqdppJyUbuxztXEe+6qC+1XbKDblWoOHS 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BoAgBECmtZ/5NdJa1cGQEBAQEBAQEBAQEBBwEBAQEBg1pkgRSfSCKILo1WghEhC4UbAoNxQBcBAgEBAQEBAQFrKIUYAQEBAQIBAQFsCwULAgEIGC4hBgslAgQOBYoXAw0IELA3hykNg10BAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMog02CDAuCboJXghODQ4IxBYlcBYc+jVo7Ao8khHAMkiOMColMASEBNYEKdRVJEgGFABwZgU52AYhVAQEB
X-IronPort-AV: E=Sophos;i="5.40,367,1496102400"; d="scan'208";a="268417567"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Jul 2017 06:41:46 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v6G6fkT3002960 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 16 Jul 2017 06:41:47 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 16 Jul 2017 01:41:46 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Sun, 16 Jul 2017 01:41:46 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
CC: Philip Homburg <pch-ipv6-ietf-4@u-1.phicoh.com>, "ipv6@ietf.org" <ipv6@ietf.org>
Subject: Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)
Thread-Topic: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)
Thread-Index: AQHS/a2ZuieUK0MP90SlnyedjyZgWqJWAdXp
Date: Sun, 16 Jul 2017 06:41:46 +0000
Message-ID: <E09CB996-1191-4700-9123-92BD31FD7A20@cisco.com>
References: <CAN-Dau2zgthR2w9e5ZVUdGc-vm+YvK2uTUJ8O=vrcv0jNc58RA@mail.gmail.com> <CAN-Dau03r_CKW53kegaLa=F_R_RG4cWaCT1j6idrqPm9UuN03A@mail.gmail.com> <5963BF27.1050300@foobar.org> <ff09ffcd-df65-4033-8018-fbe7ae98cff8@gmail.com> <6bf7f3d0e9c047b1b86d4bcc220f8705@XCH15-06-11.nw.nos.boeing.com> <CAN-Dau1bxm5y0v_6kUBc_ym39bSSxepjdwrzcS7YHWD=CV9-bw@mail.gmail.com> <3b34d6e9718a45ae80877e36fb55f2b4@XCH15-06-11.nw.nos.boeing.com> <CAO42Z2x+282VK7nMFHjcCz9tBmJ_=d4OhkiRZFZDLcZhakGB1Q@mail.gmail.com> <30cb27b2-007a-2a39-803d-271297862cae@gmail.com> <40d757eb97564bc8bb0511063bd9d3f4@XCH15-06-11.nw.nos.boeing.com> <CAO42Z2x7ER2fUietjT3Ns-jpCqscCmVDVubiM0Dgw1_L0bkw=A@mail.gmail.com> <c7b140bf69104cd3877a7da03fbf17e7@XCH15-06-11.nw.nos.boeing.com> <32924d19-e5ce-7606-77f4-925b682065f5@gmail.com> <745583ab45bb407a9a210020a96773c5@XCH15-06-11.nw.nos.boeing.com> <m1dVbRc-0000GQC@stereo.hq.phicoh.net> <b6da9e67-1f4e-8900-5a3b-575d0c6fd2fd@gmail.com> <m1dWNIL-0000FpC@stereo.hq.phicoh.net>, <3d2f1182-ec19-959e-a63f-ad0d316bbacf@gmail.com>
In-Reply-To: <3d2f1182-ec19-959e-a63f-ad0d316bbacf@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/wA69jC-ZnMz-aGoH1gCC2sXr878>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 16 Jul 2017 06:41:50 -0000

Hello Brian:

I'd say that DAD detecting a duplication is not a failure; just doing its job right.

The DAD failure that hurts is DAD false negative like can be easily obtained on wireless  because the reliability of the multicast is largely different from that of wire.

Are we ready to say that addresses that are generated with enough randomness in them do not need DAD?

Pascal

> Le 15 juil. 2017 à 23:01, Brian E Carpenter <brian.e.carpenter@gmail.com> a écrit :
> 
> On 16/07/2017 01:39, Philip Homburg wrote:
>>> This is backwards. The goals of pseudo-random IIDs are to reduce the
>>> probability that scanning attacks find hosts, and to reduce the risk
>>> of IIDs being used to breach privacy.
>>> 
>>> If these goals are met, the collision probability will in any case
>>> be low, so DAD failure will be exceedingly rare.
>> 
>> I completely disagree. A collision is fatal. We are nowhere near transparently
>> handling all collisions. At best we can hope that DAD can make one node
>> continue unaffected.
> 
> I'm confused.
> 
> Firstly, do we have any experimental evidence that collisions
> are a real operational problem? (Obviously, MAC address collisions are
> disastrous at layer 2 anyway, so although IPv6+(Modified EUI-64) needs to
> detect them, they are irrelevant to the current discussion.)
> 
> Secondly, if a collision does occur with IPv6+(pseudo-random IID),
> recovery is obvious: after DAD failure, generate a new pseudo-random
> IID and try again. This is perfectly compatible with RFC4862 section 5.5
> and is specfied in RFC7217 for stable IIDs and in RFC4941 for privacy
> addresses.
> 
>    Brian
> 
>> 
>> In contrast, people have been scanning my IPv4 ranges for the past 20 years
>> or so. That may be annoying. That may amplify attacks opportunities. But
>> in it self it is not fatal.
>> 
>> 
>> .
>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

v2.23.0 | Report a Bug | By Email