I could not agree more. It is simply unfair from the IETF to use Wi-Fi as if it was Ethernet and then complain to IEEE that in fact it is not.
IPv6 over Ethernet makes heavy use of multicast over Ethernet, which for the lack of a highly scalable Multicast service always ends up broadcasted over the whole fabric. When Wi-Fi is confused with Ethernet and the whole multi link becomes a single layer 2 fabric, we create a crisis that will not be solved by imputing the responsibility on the other SDO. A solution was developed in IoT were even less multicast was acceptable. That solution builds a multi link subnet where the Ethernet fabric is a single L2 domain but packets are routed to the wireless edges so the multicast domain is effectively split. The mechanism is simple and proven. The AP becomes a router and Wireless devices register their IP addresses to the router very much as a STA registers its MAC address at the association time. 6LoWPAN ND (RFC 6775) is effectively a L3 association, which is indeed the appropriate mechanism for Wi-Fi. Based on that registration, the AP/Router can proxy ND and filter unwanted multicast. We have running code for that proxy on Cisco IOS routers. It is derived from earlier (shipping, widely deployed) efforts that learn the registration by snooping, but that approach yields all sorts of issues and proprietary tricks. My suggestion is to finally recognize that Wi-Fi is not Ethernet, in particular from the perspective of multicast, and provide the appropriate L3 mechanisms for IPv6 over Wi-Fi, for which the backbone router discussed above is one candidate solution. Pascal > Le 6 août 2015 à 16:26, Mikael Abrahamsson <swm...@swm.pp.se> a écrit : > >> On Thu, 6 Aug 2015, Eric Gray wrote: >> >> It strikes me as something of a mistake generally to assume that multicast >> is as reliable as >> unicast. >> >> Unicast reliability depends on the mechanism(s) used to ensure reliability. >> Unicast traffic >> tends to get lost every now and then. > > Nobody doubts that packets get lost, but the general tendency since IP > networking was invented, was that multicast delivery of packets wasn't > especially worse than unicast. Packets get lost, but generally less than 1% > get lost, and multicast and unicast are affected equally. > >> All the same factors that affect unicast packet delivery also affect >> delivery of each packet with multicast. Hence multicast reliability should >> be worse than unicast reliability by an amount roughly proportional to the >> amount of packet replication necessary to support it. > > Hm, care to elaborate? That seems a lot worse than my experience in deploying > networks would tell me. > >> Each replicated packet is as likely to be lost as any unicast packet. Loss >> of one or more packets should be expected to be more likely with multiple >> packets than with a single packet. > > But it's still only a single packet per link. > >> Multicast reliability, even when considered at the link level and assuming >> replication is not required in transmission of multicast packets onto the >> link itself, is only slightly better. As full-duplex, point-to-point >> connectivity becomes increasingly likely (fat yellow cables are relatively >> rare any more), data replication still occurs - just not at the level where >> a router sending packets onto the link is likely to be aware of it. > > Correct, as of 20 years ago or something we do not use 10base5 so L2 devices > do L2 replication. > >> Hence it is interesting in this discussion that we are talking about an >> assumption that seems >> broken at the start. >> >> Have I missed something? > > Well, 802.11 treats multicast (and broadcast) packets as a second rate > citizen, I am not aware of any other L1/L2 technology that does this. 3GPP > uses basically a point-to-point tunnel, so unicast and multicast is treated > in very similar fashion without multicast being at a disadvantage. > > So IETF needs to sit down and work out a strategy on how its protocols should > work going forward, if everybody who designs protocols in the IETF should be > told that multicast and broadcast "doesn't work properly", and act > accordingly. > > What probably needs to happen is that over time, the IETF should try to use > less multicast, but on the other hand, 802.11 really needs to make sure that > multicast works a lot better than it does today. > > -- > Mikael Abrahamsson email: swm...@swm.pp.se > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
