IPv6 multicast is an important new blueprint topic for the Version 4.X CCIE R&S Lab Exam as well as the Written Qualification Exam. In this post, we will start at the most logical starting point for this topic – the IPv6 multicast addressing in use.

Like in IP version 4, multicast refers to addressing nodes so that a copy of data will be sent to all nodes that possess the address. Multicast allows for the elimination of broadcasts in IPv6. Broadcasts in IP version 4 were problematic, since the copy of data is delivered to all nodes in the network, whether the node cares to receive the information or not.

Multicast addresses are quickly detected by the initial bit settings. A multicast address begins with the first 8 bits set to 1 (11111111). The corresponding IPv6 prefix notation is FF00::/8.

Read the rest of this entry »

It is time now for us to wrap up this series on IPv6 transition techniques (in the scope of the R&S CCIE Written and Lab exam). For this final part, we turn to an existing blog post from our own resident genius, Petr Lapukhov. I edited his post to ensure we mere mortals could understand it.

Here are the links for all the posts in the series:

IPv6 Transition Mechanisms Part 1: Manual Tunnels

IPv6 Transition Mechanisms Part 2: GRE/IPv4 Tunnels

IPv6 Transition Mechanisms Part 3: 6to4 Tunnels

IPv6 Transition Mechanisms Part 4: ISATAP Tunnels

IPv6 Transition Mechanisms Part 5: NAT-PT

Remember, when you are ready to test your Tier 2 and Tier 3 knowledge of these important topics, be sure to check out our many CCIE R&S products. If you have any questions about which product would be perfect for you, contact one of our Customer Success Managers.

For those of you that have been following the previous parts of this blog series (they are located in the IPv6 subcategory of the CCIE R&S category to the left), get ready for a major paradigm shift. So far, we have been experimenting with transition techniques (tunnels) that have focused on connecting remote “island” networks of IPv6 over an IPv4-only infrastructure. Now we are going to discuss a mechanism that was designed to help IPv4-only hosts communicate to other native IPv6 devices.

Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is most recently specified in RFC 5214. Notice the topology below that we will use to detail the workings of this transition approach. This internal network has RouterB in place that is not IPv6 capable . ISATAP provides a solution for the hosts behind this device! Dynamic tunneling will be done from these hosts to the ISATAP router (RouterA). Obviously, your job in the CCIE R&S Lab Exam might be to configure or troubleshoot this important device.

Read the rest of this entry »

Join Anthony Sequeira and Keith Barker as they cover IPv6 Multicast Part 1 in the Advanced Technologies Class on Demand – 10-Day. This is a key new topic found in the version 4.0 CCIE R&S blueprint.

This chapter is now active in all accounts subscribed to this best-selling course.

Enjoy!

For Part 1 of this series, click here. For Part 2 of this series, click here.

6to4 tunnels allow for the dynamic creation of IPv6 within IPv4 tunnels. While the previous two tunnel mechanisms we examined were point-to-point type structures, this tunneling approach is considered a dynamic point-to-multipoint type. Since it is dynamic tunnel, we are going to do the very strange step of NOT assigning a tunnel destination as you will see.

6to4 tunnels rely on reserved address space. The reserved prefix is 2002::/16 (Core Knowledge Alert!). To this prefix, the IPv4 address of the border router is added, resulting in a /48 prefix. For example, if the border router possesses an external IPv4 address of 192.0.2.1, the resulting 6to4 site address space becomes 2002:c000:0201::/48. Keep in mind that this site will utilize this address space in its whole network, but hosts inside the network do not need to support the 6to4 technology.

Read the rest of this entry »

For Part 1 of this series on IPv6 Transition Mechanisms, click here.

If you loved the simplicity of the IPv6 manual tunnel we created in Part 1, you should love the Generic Routing Encapsulation (GRE) approach to tunneling IPv6 traffic through an IPv4 cloud just as much.

This simple approach takes the IPv6 packet and encapsulates it using the standard IPv4 GRE tunnel. But wait a minute? In Part 1 of this blog series, we had IPv4 encapsulate the IPv6 packet directly for tunneling across the v4 cloud. Why do we even need this additional method that adds GRE encapsulation to the process? Well, the answer is that this method is required within integrated IS-IS and IPv6 tunnel environments. If you plan on sending both IS-IS traffic and IPv6 traffic over the tunnel, you need the protocol field of the GRE header that allows identification of the passenger protocol.

Read the rest of this entry »

This blog series was recommended by another of our awesome students and IEOC community members, Marcio A. Costa.

In the first part of this series, we will look at the Manual IPv6 tunnels that are simple to create in order to connect two “islands” of IPv6 separated by IPv4-only devices. For this blog, we will use the following simple topology:

Read the rest of this entry »

IPv6 NAT-PT is to be used with IPv4 to IPv6 migration scenarios and it’s purpose is to provide bi-directional connectivity between IPv4 and IPv6 domains. Cisco points out that many other transition techniques are possible, and NAT-PT (Network Address Translation – Protocol Translation) should not be used when other, more “native” options exist, such as having dual stack hosts communicate directly through dual stack routers. Another example provided of when NAT-PT is not needed is when two islands of IPv6 want to communicate over an IPv4-only backbone. We know that many different tunnels exist for this purpose. For more information about these tunnel techniques, see the Transition Technique series in this blog category.

For the job of NAT-PT, a dual-stack router with interfaces in both IPv4 and IPv6 networks is capable of performing this task. The difference from classic IPv4 NAT is that translations should be done both ways: IPv6 packets routed towards IPv4 hosts should have their src/dst addresses changed to some IPv4 equivalents and vice versa, while IPv4 packets sent toward IPv6 hosts should get both src and dst addresses replaced with IPv6 addresses.

Read the rest of this entry »