Posts Tagged ‘IPv6’
Next Tuesday, January 21st 2014, at 10:00 PST (GMT 18:00) I will be continuing our vSeminar series on new topics for the CCIE R&S v5 Blueprint, which will focus on IPv6 First Hop Security. You can sign-up for this seminar here. Additionally the link to attend is available at the top of the dashboard when you login to the INE Members Site.
The upcoming session will focus on security exploits and attack mitigation techniques that relate to IPv6 Neighbor Discovery, Stateless Address Autoconfiguration, and DHCPv6, just to name a few. This session will also include both theory and live implementation examples on the Cisco IOS CLI. This session is expected to run approximately 2 – 3 hours in length.
Please feel free to submit topic requests for additional upcoming vSeminar sessions below. I hope to see you in class!
Students in the 3-Day IPv6 Bootcamp were interested in seeing a Recommended Reading List of materials that were used to help create the class. Here is that list – enjoy!
Have you read any other greats? Be sure to let us know in the comments below.
A big thanks to the huge class we had for the 3-Day IPv6 Bootcamp!
Do you remember key commands we covered in the class? Test your knowledge by clikcing below:
We always hear much excitement regarding the stateless address autoconfiguration capability in IPv6, but we never seem to get to see it in action. And also, we realize that one router can provide another with the address information it needs, but what about things like DNS server information? In this demonstration I will show how the stateless autoconfiguration can be setup, as well as a nifty stateless DHCPv6 implementation that can assist with the other configuration information.
For this demonstration, I just fired up two routers in Dynamips (R1 and R2) and connected them via their respective Fa0/0 interfaces. R1 will be our “server” and R2 will be our dependent little “client”. Let us start at the server and ensure it is configured for the IPv6 stateless address autoconfiguration part.
R1# conf t R1(config)# ipv6 unicast-routing R1(config)# int fa0/0 R1(config-if)# no shut R1(config-if)# ipv6 address 2001:1212::/64 eui-64 R1(config-if)# ipv6 nd prefix 2001:1212::/64 R1(config-if)# no ipv6 nd suppress-ra
Simple stuff – notice that we are leveraging the Neighbor Discovery process of IPv6 in order to provide the prefix for autoconfiguration to the link. Notice also how we have to unsuppress the sending of Router Advertisements on the link.
Now we head over to the client device:
October 20-22, 2010. Book your seat now! Click here!
Cannot make those dates, purchase now and receive the on-demand version the week following the live event.
Module 1 IPv6 Addressing and Basic Connectivity
- Address Types
- IPv6 Neighbor Discovery
- Basic Connectivity
Module 2 IPv6 Protocols
- IPv6 ICMP
- DHCP for IPv6
- IPSec in IPv6
- QoS for IPv6
IPv6 multicast renames IGMP to the Multicast Listener Discovery Protocol (MLP). Version 1 of MLD is similar to IGMP Version 2, while Version 2 of MLD is similar to Version 3 IGMP. As such, MLD Version 2 supports Source Specific Multicast (SSM) for IPv6 environments.
Using MLD, hosts can indicate they want to receive multicast transmissions for select groups. Routers (queriers) can control the flow of multicast in the network through the use of MLD. Continue Reading
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.
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:
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.
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.