A library consortium needs BGP to carry dual-stack public services: IPv6 for modern portals and IPv4 for legacy catalog systems. How should that be structured on the BGP speakers?
Select an answer to reveal the explanation.
Short Explanation
You can carry both service types cleanly with multiprotocol BGP: activate IPv4 unicast and IPv6 unicast address families so each advertises its own prefixes. Carrying IPv6 prefixes through IPv4 unicast alone won’t replace activating the IPv6 address family.
Full Explanation
A library consortium carrying dual-stack public services should activate the IPv4 unicast and IPv6 unicast address families, or equivalent AF configuration, so each family negotiates capabilities and advertises its own prefixes independently. Modern BGP (MP-BGP) separates NLRI by address family; IPv6 portal prefixes are not properly carried just by putting them into an IPv4-only session without IPv6 AF activation. Enabling both families lets legacy catalog IPv4 and modern portal IPv6 prefixes advertise cleanly on the same BGP speakers. Carrying IPv6 service prefixes as IPv4-unicast NLRI without activating IPv6 AF fails the multiprotocol model and does not properly negotiate or advertise IPv6 unicast NLRI. Disabling MP-BGP and using RIPng for all public dual-stack services abandons the ISP-facing BGP design needed for those public services. Replacing BGP address families toward the ISPs with OSPF stub areas confuses IGP area types with BGP AF negotiation and cannot substitute for ISP BGP dual-stack advertising. Exam caveat: remember AF activation under the neighbor, capability negotiation, and that IPv4-mapped tricks do not substitute for proper IPv6 unicast AF on ENARSI dual-stack edges. Practical check: confirm both address families are negotiated in show ip bgp neighbors or show bgp ipv6 unicast summary; verify IPv4 and IPv6 prefixes appear in their respective tables, then test reachability to public dual-stack services from outside.