| > many will treat it as broadcast traffic and flood it across the network segment and some will silently swallow them until you update their firmware. Broadcasts on the other hand are so common (and required for ipv4 to work) that they are rarely broken. If multicast is treated as broadcast, stuff works "fine", but because of IGMP snooping and additional "intelligence" the switches often employ, unfortunately, the failure modes I have seen tend to be packet loss rather than overeager packet forwarding. And with multicast packets dropped in a v4 network, some niche applications will stop working, but with multicasts packets dropped in a v6 network, your network will stop working. Period. > and you might have already ran into these problems in the IPv4 world if you have multiple network interfaces anyway of course you have. My point isn't that v6 multi-homing is any different from v4 multi-homing. My point is that multi-homing is rare with v4 but very common and required for v6. So what's often not an issue at all on anybodies radar in a v4 network is something everybody has to deal with in a v6 network. > most of the problems can be trivially solved. absolutely. But they don't have to be solved by staying with v4 and thus inertia is even harder to overcome than it normally is. That was my point. |
Multi-homing (connecting to multiple different networks) isn't required in IPv6 at all. Having multiple different addresses on the same subnet isn't multi-homing, and the link local address of fe80:: isn't a different network. Operating systems won't even use the link local address to establish a connection unless specifically forced to.