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
- RE: Liaison from BBF Mikael Abrahamsson
- Liaison from BBF David Allan I
- Re: Liaison from BBF Thomas Narten
- Re: Liaison from BBF Mikael Abrahamsson
- RE: Liaison from BBF Manfredi, Albert E
- RE: Liaison from BBF Mikael Abrahamsson
- RE: Liaison from BBF Manfredi, Albert E
- RE: Liaison from BBF Wes Beebee (wbeebee)
- Re: Liaison from BBF Phil Bedard
- RE: Liaison from BBF Manfredi, Albert E
- RE: Liaison from BBF David Allan I
- RE: Liaison from BBF David Allan I
- RE: Liaison from BBF Hemant Singh (shemant)
- RE: Liaison from BBF David Allan I
- RE: Liaison from BBF Hemant Singh (shemant)
- RE: Liaison from BBF Wojciech Dec (wdec)