During IPv4/IPv6 dual-stack rollout, a city team treats anycast the same as local subnet broadcast for service discovery and opens overly broad multicast groups. What should the architect emphasize?
Select an answer to reveal the explanation.
Short Explanation
Not every address type shouts to the same crowd. Broadcast, multicast, and anycast behave differently—and mixing them up can leak discovery traffic or aim clients at the wrong place. Learn the flavors before dual-stack goes live.
Full Explanation
During IPv4/IPv6 dual-stack rollout, address types carry different reachability and trust implications. Unicast targets one interface; IPv4 broadcast floods a subnet; multicast delivers to subscribed groups; anycast routes to the topologically nearest of multiple providers of the same address. Service discovery and filtering designs must respect those semantics—treating anycast like local broadcast or opening overly broad multicast groups can leak discovery traffic, widen trust assumptions, or send clients to unexpected nodes.
Claiming IPv6 eliminates addressing-related security considerations is false; new stacks add ND, extension headers, and dual-stack attack surface. Treating broadcast, multicast, and anycast as interchangeable labels ignores distinct trust boundaries. Focusing only on MAC addresses while ignoring IP delivery types misses how discovery and filtering actually work on routed campus networks.
Exam caveat: CISSP network fundamentals expect correct use of unicast/broadcast/multicast/anycast when designing discovery and security controls—especially under dual-stack transitions.
Operational check: document which discovery protocols use which address types; constrain multicast with IGMP/MLD snooping and ACLs; treat anycast service VIPs with intentional routing and health checks; test dual-stack clients so IPv6 paths are not silently broader than IPv4; review firewall rules for both families.