I'd like to put forward some additional points which should perhaps be concise enough to clarify the liaison and questions a bit more. There are actually two issues, out of which the duplicate MAC address issue is IMO a far less tractable problem (as it needs to be solved at L2 for anything to work). 1. Within a shared L2 domain with constrained forwarding (aka NBMA), for two users A & B with *different* MAC addresses, user B may spoof the LL address of user A and thus lead possibly to a DoS attack (on a FCFS basis). Similarly user B may try to spoof the LL address of N users (again on an FCFS basis). Does SAVI propose to solve this problem and if so how?
2. A duplicate MAC address in a shared broadcast domain is a possibility. At L2, this problem is tractable by any one of a) denying the dupe addresses access to the network service on a FCFS basis (common practice today) b) assigning each duped MAC to a different broadcast domain c) MAC address translation (MAC NAT). Solution c) requires some form of ALGs (for v4 and v6). Eg In the v6 case any EUI-64 derived LL addresses will still be the same and thus an ND ALG appears needed. What is the IETF's opinion about this type of solution (c), if any? Regards, Woj. > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On > Behalf Of David Allan I > Sent: 10 November 2009 00:31 > To: Thomas Narten > Cc: ipv6@ietf.org > Subject: RE: Liaison from BBF > > HI Thomas: > > Unfortunately having just changed jobs I'm having trouble > exactly recreating all my sources of information... > > The following was one anecdotal example offered during our > discussions in the spring..."...in a real nationwide telco > today with approximately 3.5million DSL ports there is about > 300-400 duplicate MAC@ alarms active on the DSLAMs at any > time, and this is only where 2 of the same MAC@ appear on the > same DSLAM (384-1000 users each)..." > > TO take it back up a notch... > > In a perfect world where all MACs were properly unique and > all implementations correctly constructed link local via > EUI-64 we'd all be happy campers, it works as intended. > Unfortunately that is not the case and we seem to have a > hierarchy of grief..... > > 1) Some carriers have deployed MAC address translation in the > Access node/DSLAM to ensure MAC uniqueness. This means ALG > functionality is required for Ethernet OAM and other > protocols, and while fixing MAC uniqueness, does not address > duplicates in link local construction unless NAT of the lower > 64 bits of LLA is included in the mix. > > 2) Our liaisons with IEEE on the subject and some proposals > to the forum focus on the fact that uniquness only needs to > exist in a given Ethernet broadcast domain, hence keeping a > few extra VLANs in the back pocket to shift duplicate > customers to solves the problem, and my math suggested this > would inflate VID usage by a corresponding few percent. Issue > being this then breaks down if the link local address is not > constructed from the MAC, and RFCs have been trotted out at > the BBF on NOT using the EUI-64 specifically to defeat > traffic analysis attacks. This being an expected deployment > scenario when wireless media in the home is considered and an > emerging class of FMC capable terminals is deployed. > > So a solution analogous to DAD appears to be needed, that > originates with the edge router, where if the detected > duplicate does not subsequently behave in a prescribed manner > service may then be denied in the interest of the common > good. As DAD is already deployed that would appear to be a > path of least resistance vs waiting years for a roll out of a > fix. However if my memory serves correctly, unicast from the > edge router would be a desirable form and I am unsure if that > is supported in standards or implementations... > > Cheers > D > > > > > > -----Original Message----- > From: Thomas Narten [mailto:nar...@us.ibm.com] > Sent: Tuesday, November 10, 2009 12:00 AM > To: David Allan I > Cc: ipv6@ietf.org > Subject: Re: Liaison from BBF > > 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 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
