Re: Liaison from BBF

Thomas Narten <narten@us.ibm.com> Mon, 09 November 2009 15:00 UTC

Return-Path: <narten@us.ibm.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 1814528C130 for <ipv6@core3.amsl.com>; Mon, 9 Nov 2009 07:00:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.885
X-Spam-Level:
X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 OyBoCZ647bUA for <ipv6@core3.amsl.com>; Mon, 9 Nov 2009 07:00:32 -0800 (PST)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 1912628C12A for <ipv6@ietf.org>; Mon, 9 Nov 2009 07:00:32 -0800 (PST)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id nA9EqkbR022085 for <ipv6@ietf.org>; Mon, 9 Nov 2009 09:52:46 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nA9F0vQ2061220 for <ipv6@ietf.org>; Mon, 9 Nov 2009 10:00:57 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nA9F0RZo012889 for <ipv6@ietf.org>; Mon, 9 Nov 2009 10:00:27 -0500
Received: from cichlid.raleigh.ibm.com (sig-9-65-253-113.mts.ibm.com [9.65.253.113]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nA9F0QUx012724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Nov 2009 10:00:27 -0500
Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id nA9F0PSm002116; Mon, 9 Nov 2009 10:00:25 -0500
Message-Id: <200911091500.nA9F0PSm002116@cichlid.raleigh.ibm.com>
To: David Allan I <david.i.allan@ericsson.com>
Subject: Re: Liaison from BBF
In-reply-to: <60C093A41B5E45409A19D42CF7786DFD4DEDE9BC10@EUSAACMS0703.eamcs.ericsson.se>
References: <60C093A41B5E45409A19D42CF7786DFD4DEDE9BC10@EUSAACMS0703.eamcs.ericsson.se>
Comments: In-reply-to David Allan I <david.i.allan@ericsson.com> message dated "Mon, 09 Nov 2009 00:10:33 -0500."
Date: Mon, 09 Nov 2009 10:00:25 -0500
From: Thomas Narten <narten@us.ibm.com>
Cc: "ipv6@ietf.org" <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: Mon, 09 Nov 2009 15:00:33 -0000

Sorry, I still don't get it. We need more detail!

Two things stand out:

> If two devices happen to have the same Ethernet MAC address as a
> consequence of incompetent manufacture, the link-local address derived
> for that interface will also be non-unique, provided it is derived
> from the EUI-64 identifier. This has been identified as an
> inconveniently frequent scenario (impacting ~4% of access nodes at any
> given time)

this 4% figure seems *very* high. Can you please provide more details
on how you reached that number?

Also, if you have two devices on the same link sharing the same MAC
address, you have problems. Period. Having duplicate IP addresses is
only one symptom. If you fix that problem, but still have duplicate
MAC addresses in use, it is not clear to me that your network will
function correctly. Have you done the analysis to be sure that the
duplicate MAC address scenario is something that is solvable in
practice?

> When numerous hosts share an Ethernet broadcast domain, the BNG/edge
> router needs to support a mechanism that ensures duplicate link-local
> addresses can be handled correctly without necessarily depending on
> cooperative action by the hosts
> 
> it is explicitly required to do something to make this happen

Again, it is not clear to me what "handling correctly" even means.

Finally, the charts say you are worried about a "malicious user"
sending out bogus ND packets. ND simply can't deal with this sort of
hostile environment, and there is no easy way to fix this. Is that
what you are asking this group to fix?

For that matter, ARP doesn't address this problem either. Is there a
new problem that shows up with IPv6 that didn't exist with IPv4? And
if not, what is wrong with using the IPv4 solutions (assuming they
exist)?

Thomas