IPv6 Peering, Part 2: The Next Steps for ISP Interfacing

August 6, 2012 - 5 Comments

In my first post on IPv6 peering, I provided some sample questions for your ISP and discussed considerations for the physical implementation.  After the physical details have been worked out, the next step is how to set up the control plane so that routing information can be exchanged.  From a routing perspective, most providers prefer that you peer with them either using BGP or static routing.  Static routing is typically used for single, homed organizations that do not want or need a dynamic routing capability.  In this case, the organization has a default route to the ISP, and the ISP distributes the organizational routes via the ISP BGP process.

If a dynamic routing behavior is needed, BGP is the routing protocol of choice to peer between your organization and your ISP.  If you are already peering to your ISP using BGP, you can extend that peering session to support the IPv6 address family.  In this situation, the peering routers would be configured to negotiate the capability to exchange IPv6 address family information using the underlying IPv4-based transport session.

A critical thing to remember at this point is that the next hop information has to be changed.  By default, BGP will use the underlying transport session information to install the next hop in the update.  So if you have an IPv4 transport session and are exchanging IPv6 prefixes, the next hop will be an IPv4 address that has been changed to an IPv6 address because the prefix address family and the next hop address family have to match.  The next hop will look like this – ::ffff:[IPv4 address]. If the next hop is unchanged in this scenario, the prefix will be marked inaccessible which could lead to potential routing “black holes.”  To remedy this situation a route-map should be applied to the peering session for the IPv6 address family to reset the next hop information to a reachable IPv6 address.

Another option is to separate your IPv4 and IPv6 address family peering sessions.  Use the IPv4- based transport session to exchange IPv4 prefixes, and use the IPv6 based transport session to exchange IPv6 prefixes.  One thing to remember in this scenario is that the capability to exchange IPv4 address family information will automatically be negotiated between peers.  This means that, by default, your IPv6 based transport session will negotiate the exchange of IPv4 prefix information.  This situation could lead to issues with how the next hop is set as mentioned above.  To fix this issue, the global BGP command “no bgp default ipv4-unicast” command can be used, or the neighbor statement can be nullified under the IPv4 address family via the “no neighbor [IPv6 address]” command.

In the dual peering session scenario, the next hop information does not have to be manipulated as the transport session and prefix information address families match.  This model also has some operational advantages.  When troubleshooting ISP connectivity issues, the separation of peering sessions makes it obvious which address family you are troubleshooting.  If an issue is found and the peering session needs to be reset or modified to resolve an issue, only the session for that address family is impacted.  The other session is not impacted and will continue to operate.  The separate session model also gives you the flexibility to implement different policies if desired. It should also be noted that peering to multiple ISPs is also an option as shown in the diagram below.  Peering to multiple ISPs is used to provide reliability to ensure that connectivity to your service and applications is continuously available.

Multiple ISPs also provide the ability to load balance traffic and engineer how traffic ingresses and egresses your network.  All of the points discussed above apply to a multiple ISP scenario.  It is critical to ensure that all ISPs that you choose to connect can support the requirements that you have. There are tools that are available to help organizations look into how ISPs implement their policies.

There are also several route servers and looking glasses that can be used to view how IPv6 prefixes are advertised.  See a list of several available looking glasses and route servers.

Peering with your ISPs is an important piece to your overall integration of IPv6 into the Internet edge.  You must consider how the ISP is offering IPv6 service to you, and how you peer and exchange routing information with your provider.  View a full list of activities that need to happen when integrating IPv6 at the Internet edge.

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Great post, Jim. I’m just planning our IPv6 peering model and this information is very useful to justify separated IPv4 and IPv6 address family peering sessions. Thank you!

  2. sir plz send me ccna lecture

  3. This is a great article. I am just learning about Cisco and Routing protocols, and this will help. Especially where IPV6 is concerned. Thanks!

  4. Perfect way to have more information about this good topic