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