Next Tuesday, January 21^st 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!

IPv6: Theory, Protocol, and Practice by Loshin, Second Edition

IPv6 Essentials by Hagan, Second Edition

Cisco IOS IPv6 Configuration Guide, Release 12.4T

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:

IPv6 Command Recall Quiz

This post helps to celebrate the upcoming 3-Day IPv6 Bootcamp here at INE.

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:

R2# conf t

R2(config)# int fa0/0

R2(config-if)# no shut

R2(config-if)# ipv6 address autoconfig

R2(config-if)# do show ipv6 int fa0/0

FastEthernet0/0 is up, line protocol is up

  IPv6 is enabled, link-local address is FE80::C001:7FF:FEDA:0

  Global unicast address(es):

    2001:1212::C001:7FF:FEDA:0, subnet is 2001:1212::/64 [PRE]

      valid lifetime 2591911 preferred lifetime 604711

  Joined group address(es):

    FF02::1

    FF02::2

    FF02::1:FFDA:0

  MTU is 1500 bytes

  ICMP error messages limited to one every 100 milliseconds

  ICMP redirects are enabled

  ND DAD is enabled, number of DAD attempts: 1

  ND reachable time is 30000 milliseconds

  Default router is FE80::C000:7FF:FEDA:0 on FastEthernet0/0

How about that! One command - ipv6 address autoconfig - and the client autoconfigures its link-local and global unicast addresses. But now we want to have R1 provide R2 with its DNS server address and domain name. To do this, we will configure stateless DHCPv6.

R1# conf t

R1(config)# ipv6 dhcp pool DHCP_POOL

R1(config-dhcp)# dns-server 2001:1212::100

R1(config-dhcp)# domain-name ine.com

R1(config-dhcp)# int fa0/0

R1(config-if)# ipv6 dhcp server DHCP_POOL

R1(config-if)# ipv6 nd other-config-flag

Notice the key ND command here instructing that autoconfiguration process that there is additional configuration to obtain. What is there to do on the client device? Nothing! That is the whole point. :-) Let's verify this actually worked at the client, however:

R2# show ipv6 dhcp int fa0/0

FastEthernet0/0 is in client mode

  State is IDLE

  List of known servers:

    Reachable via address: 2001:1212::C000:7FF:FEDA:0

    DUID: 00030001C20007DA0000

    Preference: 0

    Configuration parameters:

      DNS server: 2001:1212::100

      Domain name: ine.com

  Rapid-Commit: disabled

I hope you enjoyed this preview from the course.

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

Module 3 Static Routing and RIPng

• Static Routing
• Basic RIPng Configuration
• Customizing RIPng

Module 4 OSPF Version 3

• Basic Configuration
• Network Types
• Multiarea Configurations
• Graceful Restart

Module 5 EIGRP for IPv6

• Basic Configuration
• Customizing EIGRP for IPv6

Module 6 Multi-protocol BGP

• Basic Configuration
• Customizing Multi-protocol BGP

Module 7 Filtering and Route Redistribution

• IPv6 Traffic Filtering
• IPv6 Route Update Filtering
• IPv6 Policy Based Routing
• IPv6 Route Redistribution

Module 8 IPv6 Transition Techniques

• Manual Tunnels
• GRE IPv6 Tunnels
• 6to4 Tunnels
• IPv4-Compatible IPv6 Tunnels
• ISATAP Tunnels
• NAT-PT

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.

MLD uses the Internet Control Message Protocol (ICMP) to carry its messages. All such messages are link-local in scope, and they all have the router alert option set.

MLD uses three types of messages - Query, Report, and Done. The Done message is like the Leave message in IGMP version 2. It indicates a host no longer wants to receive the multicast transmission. This triggers a Query to check for any more receivers on the segment.

Configuration options for MLD will be very similar to configuration tasks we needed to master for IGMP. You can limit the number of receivers with the ipv6 mld limit command. If you want the interface to "permanently" subscribe, you can use the ipv6 mld join-group command. Also, like in IGMP, there are several timers you may manipulate for the protocol's mechanics.

Configuring IPv6 multicast-routing with the global configuration command ipv6 multicast-routing, automatically configures Protocol Independent Multicast (PIM) an all active interfaces. This also includes the automatic configuration of MLD. Here are verifications:

R0#show ipv6 pim interface

Interface          PIM  Nbr   Hello  DR

 Count Intvl  Prior
Tunnel0            off  0     30     1     

 Address: FE80::C000:2FF:FE97:0

 DR     : not elected

VoIP-Null0         off  0     30     1     

 Address: ::

 DR     : not elected

FastEthernet0/0    on   0     30     1     
 Address: FE80::C000:2FF:FE97:0
 DR     : this system

FastEthernet0/1    off  0     30     1     

 Address: ::

 DR     : not elected

Notice the PIM is indeed enabled on the Fa0/0 we have configured in this scenario. Now for the verification of MLD:

R0#show ipv6 mld interface

Tunnel0 is up, line protocol is up

 Internet address is FE80::C000:2FF:FE97:0/10

 MLD is disabled on interface

VoIP-Null0 is up, line protocol is up

 Internet address is ::/0

 MLD is disabled on interface

FastEthernet0/0 is up, line protocol is up

 Internet address is FE80::C000:2FF:FE97:0/10

 MLD is enabled on interface

 Current MLD version is 2

 MLD query interval is 125 seconds

 MLD querier timeout is 255 seconds

 MLD max query response time is 10 seconds

 Last member query response interval is 1 seconds

 MLD activity: 5 joins, 0 leaves

 MLD querying router is FE80::C000:2FF:FE97:0 (this system)

FastEthernet0/1 is administratively down, line protocol is down

 Internet address is ::/0

 MLD is disabled on interface

Notice the similarities to IGMP are obviously striking.

Thanks for reading, and I hope to "see you" again soon here at the INE blog.

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.

Following the initial 8 bits, there are 4 bits (labeled 0RPT) which are flag fields. The high-order flag is reserved, and must be initialized to 0. If the R bit is set to 1, then the P and T bits must also be set to 1. This indicates there is an embedded Rendezvous Point (RP) address in the multicast address.

The next four bits are scope. The possible scope values are:

0  reserved
1  Interface-Local scope
2  Link-Local scope
3  reserved
4  Admin-Local scope
5  Site-Local scope
6  (unassigned)
7  (unassigned)
8  Organization-Local scope
9  (unassigned)
A  (unassigned)
B  (unassigned)
C  (unassigned)
D  (unassigned)
E  Global scope
F  reserved

The remaining 112 bits of the address make up the multicast Group ID. An example of an IPv6 multicast address would be all of the NTP servers on the Internet - FF0E:0:0:0:0:0:0:101.

Notice, like in IPv4 multicast, there are many reserved addresses of link-local scope. Here are some examples:

FF02:0:0:0:0:0:0:1 - all nodes
FF02:0:0:0:0:0:0:2 - all routers
FF02:0:0:0:0:0:0:9 - all RIP

A special, reserved IPv6 multicast address that you should be aware of is the Solicited-Node multicast address:

FF02:0:0:0:0:1:FFXX:XXXX

A Solicited-Node multicast address is created automatically for you by the router. It takes the low-order 24 bits of the IPv6 address (unicast or anycast) and appends those bits to the prefix FF02:0:0:0:0:1:FF00::/104. This results in a multicast address within the range FF02:0:0:0:0:1:FF00:0000 to FF02:0:0:0:0:1:FFFF:FFFF. These addresses are used by the IPv6 Neighbor Discovery (ND) protocol in order to provide a much more efficient address resolution protocol than Address Resolution Protocol (ARP) of IPv4.

Now that we understand the addressing, let us see it in action on a Cisco router.

R1#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

R1(config)#ipv6 unicast-routing

R1(config)#interface fa0/0

R1(config-if)#ipv6 address 2001:1::/64 eui-64

R1(config-if)#no shutdown

R1(config-if)#

*Mar  1 00:03:32.627: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up

*Mar  1 00:03:33.627: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to up

R1(config-if)#do show ipv6 interface fa0/0

FastEthernet0/0 is up, line protocol is up

 IPv6 is enabled, link-local address is FE80::C001:1FF:FE47:0

 No Virtual link-local address(es):

 Global unicast address(es):

 2001:1::C001:1FF:FE47:0, subnet is 2001:1::/64 [EUI]

 Joined group address(es):

 FF02::1

 FF02::2

 FF02::1:FF47:0

 MTU is 1500 bytes

 ICMP error messages limited to one every 100 milliseconds

 ICMP redirects are enabled

 ICMP unreachables are sent

 ND DAD is enabled, number of DAD attempts: 1

 ND reachable time is 30000 milliseconds

 ND advertised reachable time is 0 milliseconds

 ND advertised retransmit interval is 0 milliseconds

 ND router advertisements are sent every 200 seconds

 ND router advertisements live for 1800 seconds

 ND advertised default router preference is Medium

 Hosts use stateless autoconfig for addresses.

Notice that because I enabled the IPv6 routing capabilities for this device, one of the multicast groups joined is ALL ROUTERS for the local-link (FF02::2). Also note the Solicited-Node multicast address of FF02::1:FF47:0.

I hope you have enjoyed this presentation on IPv6 multicast and will be joining us for more. If you want practice right away with these topics, check out any of our CCIE R&S products.

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.

Here is how ISATAP actually works. The networks DNS server is updated with a well-known name entry of "ISATAP" that resolves to the IPv4 address used in the tunnel on the ISATAP router (RouterA). HostA initializes and notes that it has been configured with ISATAP capabilities for IPv6. HostA then sends a request to the DNS server for the address associated with "ISATAP". DNS responds with the IPv4 address of the ISATAP router. HostA tunnels a router discovery packet (using an IPv6-in-IPv4 encapsulation approach) and sends this packet to the ISATAP router. RouterA responds with a router advertisement that includes the IPv6 prefix the host (HostA) should use. HostA takes this prefix and automatically constructs its own unique IPv6 address. It uses a reserved identifier for ISATAP (0:5efe) and its own IPv4 address to do this. Now the host is fully able to communicate beyond its local network using IPv6 and ISATAP.

One of the exciting things about the ISATAP soltuion is the fact that HostA will automatically transition to native IPv6 communications once the network is upgraded (in our case, once RouterB is replaced or upgraded). The minute HostA begins receiving unsolicited, native router advertisements, it ignores its ISATAP capabilities.

The configuration of the ISATAP router is very simple. Here is an example:

RouterA:

configure terminal

!

interface Tunnel 0

ip address 2001:80f0:4:300::/64 eui-64

no ipv6 nd suppress-ra

tunnel source 172.16.1.20

tunnel mode ipv6ip isatap

The prefix assigned to the tunnel interface is the prefix that will be assigned to hosts. Notice the no ipv6 nd suppress-ra command is required to ensure that router advertisements are sent over the tunnel to hosts. By default, these messages are not used on tunnel interfaces.

After setting the tunnel mode, your tunnel interface should launch. To verify that your tunnel has been assigned the appropriate ISATAP IPv6 address space, you can use show ipv6 interface brief as follows:

RouterA#show ipv6 interface brief

FastEthernet0/0            [up/up]

FastEthernet0/1            [administratively down/down]

Tunnel0                    [up/up]

 FE80::5EFE:AC10:114

 2001:80F0:4:300:0:5EFE:AC10:114

Awesome! We will investigate another transition option in the next part of this series. Thanks for tuning in! If you want more training targeted at this subject, check out any CCIE R&S product! You should have your Tier 1 understanding of this feature now, so you should target Tier 2 or Tier 3 products. Tier 2 would be workbook practice, while Tier 3 would be Poly-labs or Graded Mock Labs.

Join INE Instructors 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!