NETS header NETS Homepage UCAR Homepage NCAR Homepage SCD Homepage NETS Homepage About NETS Work requests & support
  Browse NETS topics: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

IPv6 (NETS notes)

Pete Siemsen
2004-11-09

Summary

As of 2004-04-02, Steve Pollock gave a presentation about IPv6 at NCAR. Until then, we had been waiting for Cisco to provide version of the IOS for our MSFCs that would support extended ACLs to allow us to implement a security perimeter for IPv6. Steve told us that release 12.2(17d)SXB provides initial support with Supervisor Engine 2 for these features in software (these features are already supported with Supervisor Engine 720 in hardware). With this release, we can finally do IPv6 on all internal networks.

As of 2004-04-02, we do IPv6 only to the UNIDATA "external" subnet, via a direct connection from gin to the UNIDATA. That connection does only IPv6 and not IPv4. UNIDATA gets IPv4 through the internal Cisco routers.

As of 2004-11-17, we have a Sup 720 in ml-mr-c1-gs and an MSFC3 running 12.2(17d)SXB. It's routing IPv6 between the 2 and 8 VLANs for testing, and seems to work fine. I haven't enabled IPv6 over the link to gin because I haven't done the serurity filters. HP OpenView is discovering/monitoring the rudimentary IPv6 network (1 router, 2 VLANs, 3 nodes), but doesn't represent mlra correctly because the IOS doesn't support the IPv6 MIBs.

Plans and notes

I attended a Denver Cisco User's Group (DCUG) meeting about IPv6 on 2003-12-11. See my trip report.

I bought the excellent book Cisco Self-Study: Implementing Cisco IPv6 Networks. This book suggests that IOS 12.3 supports extended ACLs for IPv6. If so, I should be able to safely do IPv6 inside UCAR.

Surfing on Cisco's website, I found "Implementing Security for IPv6", which says

In Cisco IOS Release 12.0(23)S and 12.2(13)T or later releases, the standard IPv6 ACL functionality is extended to support--in addition to traffic filtering based on source and destination addresses--filtering of traffic based on IPv6 option headers and optional, upper-layer protocol type information for finer granularity of control (functionality similar to extended ACLs in IPv4).

I also found "Start Here: Cisco IOS Software Release Specifics for IPv6 Features" which says

IPv6 features are supported only in the 12.0 ST, 12.0 S, 12.2 T, 12.2 S, 12.3, and 12.3 T Cisco IOS software release trains, starting at Cisco IOS Release 12.0(21)ST, 12.0(22)S, 12.2(2)T, 12.2(14) S, 12.3, and 12.3(2)T, respectively. The 12.0 ST Cisco IOS software release train was merged with the 12.0 S Cisco IOS software release train starting at Cisco IOS Release 12.0(22)S; therefore, subsequent releases of only the 12.0 S, 12.2 S, 12.2 T, 12.3, and 12.3 T Cisco IOS software release trains support additional IPv6 features.
We are running 12.1(19)E1 in the MSFCs at FL and CG, and 12.1(8b)E7 in the spare MSFC named y2kr-n243-4. IOS 12.1(19)E1 does not recognize even the most basic "ipv6 unicast-routing" command. Some surfing of Cisco marketing webpages implies that the only Catalyst board that supports IPv6 is the new 720 supervisor modules. To find out what IOS versions are available for UCAR's MSFCs, I used Cisco's "software advisor". Our MSFCs are "Multilayer Switch Feature Card-2 MSFC2 (Cat6k-MSFC2)", which use software images with file names that start with "c6msfc2". I then used the Cisco "IOS Upgrade Planner", which is not great either, but by trial-and-error I was able to find out that our "platform" is "CAT6000-MSFC2", for which there are no 12.2 or 12.3 images available. We can run only 12.1, which doesn't support IPv6 as of 2003-12-26.

I opened a Cisco TAC case to verify this, and received this:

To: Pete Siemsen
From: Arturo Bustamante
Subject: Case E884911 - 1222*How can I find out which features are supported in which IOS version?
Date: Mon, 22 Dec 2003 17:09:11 -0800

Hello Pete,

I'm the Cisco Engineer who will now be handling your case. I imagine that you were reading through documentation about the support for Ipv6. You could check this document that has info on that:

http://www.cisco.com/warp/customer/cc/pd/iosw/prodlit/scsd5_sd.htm But basically the answer you're looking for is no, the msfc2 doesn't support the ipv6, this is supported in the 720.

You can check that in the feature navigator:

http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp

I also found this:

Basically at L2, IPv6 host can be transparently connected as we do not look at the L3 header. Currently there is no L3 support for IPv6 in the Cat6 although it will be supported in the near future.
Let me know if you have questions.

Thanks!

Later,

Arturo Bustamante
Customer Support Engineer
Cisco Systems
abustama@cisco.com
Phone: 978 858 7002
Meet me via Cisco LIVE!
http://c1.cisco.com/ Ext: abustama
M-F 11:00 am - 8:00 pm CST

Eventually, I'll want to experiment with IPv6, probably on the spare MSFC on ml-y2k-c1-gs. So I played with it a bit, even though I know there's no IOS that will do IPv6 for us. I first reconfigured it to allow access to it from the UCAR network, as follows.

  1. I connected to ml-mr-c1-ts and connected to the console port on ml-y2k-c1-gs.
  2. I put port 6/1 on ml-y2k-c1-gs on VLAN 243, and port 2/1 on ml-mr-c1-gs on VLAN 243.
  3. I connected to the MSFC on ml-y2k-c1-gs by doing "session 15".
  4. I created an interface named VLAN243 on the MSFC, with IP address 128.117.243.6.
  5. I set the system name to "y2kr-n243-4" to match the existing DNS name for 128.117.243.6 (mlra already had the corresponding VLAN243 interface addressed as 128.117.243.5).
  6. I enabled OSPF.
The MSFC was then able to communicate with the rest of the UCAR network over IPv4. This set up the possibility of upgrading the MSFC to an IOS version that supports IPv6, if there ever is one.

IPv6 Addressing Plan for UCAR

IPv6 addresses consist of 128 bits (16 bytes). It is convenient to discuss the 128 bits as a 64-bit "top" half and a 64-bit bottom half.

The top 64 bits

The first 48 bits (6 bytes) of UCAR IPv6 addresses are defined by Abilene as 2001:0468:0503::/48. In IPv6 lingo, these 6 bytes are called the Public Routing Topology or (PRT) prefix. They function something like IPv4 CIDR blocks. The next 2 bytes are called the Site-Level Aggregation  or SLA ID, and can be used to define local topology within a site. In IPv4, local topology was defined with subnets; IPv6 has an explicit place for it.

Top 64 bits of IPv6 addresses
48-bit PRT 16-bit SLA ID
20 01 04 68 05 03 xx xx
00100000 00000001 00000100 01101000 00000101 00000011 xxxxxxxx xxxxxxxx

I propose that we use the top 4 bits of the SLA ID as a UCAR site id and the bottom 12 bits as a VLAN id. This provides for up to 16 sites and 4096 VLANs. For now, we could use the IPv4 subnet number already in use on the VLAN as the VLAN id, simply because it provides a unique scheme that is easy to understand. With this scheme, when a human reads an IPv6 address, the site id and VLAN id can be "seen". This might make handling IPv6 addresses a little easier than another scheme would.

Top 64 bits of UCAR IPv6 addresses
48-bit PRT 16-bit SLA ID
20 01 04 68 05 03 xx xx
00100000 00000001 00000100 01101000 00000101 00000011 uuuuvvvv vvvvvvvv

In the SLA ID:

Site IDs would be:
SiteUCAR Site ID
Mesa Lab1
Foothills Lab2
Center Green3
Jeffco4
Marshall5

The bottom 64 bits: the EUI-46 part

The trailing 8 bytes of each IPv6 address contains the EUI-64 interface identification, which includes the MAC address.

Bottom 64 bits of IPv6 addresses
OUI code (1st 3 bytes of MAC) constant last 3 bytes of MAC
xx xx xx FF FE xx xx xx
xxxxxxxx xxxxxxxx xxxxxxxx 11111111 11111110 xxxxxxxx xxxxxxxx xxxxxxxx

UCAR IPv6 example:

An Dell PC with MAC address 00:06:5b:87:69:bf at the Foothills Lab (UCAR site 2) in MMM's VLAN 88 (hex 058) would have the IPv6 address 2001:468:503:2058:6:5bff:fe87:69bf, as follows:

UCAR PRT Prefix SLA ID 64-bit EUI-64 Interface ID
20 01 04 68 05 03 20 58 00 06 5b ff fe 87 69 bf

DNS

It is natural to assume that DNS for IPv6 might involve special IPv6 DNS servers that handle DNS requests from IPv6 hosts. Actually, DNS for IPv6 uses the same DNS servers as those for IPv4. The DNS servers should be "dual-stacked" so that they accept IPv4 packets or IPv6 packets.

UCAR's existing DNS servers could be configured today to resolve IPv6 names and addresses. For example, they could resolve test.ipv6.ucar.edu into 2001:468:503:009::2a0:a5ff:fe12:5b43 and vice versa. DNS requests could arrive at the DNS servers in IPv4 or IPv6 packets, and the DNS servers would respond using the protocol of the request. Thus, IPv4 and IPv6 hosts could resolve both IPv6 and IPv4 names and addresses.

Autoconfiguration

In IPv6, when a host boots, it asks the local router for part of it's IPv6 address. This is called Autoconfiguration or Neighbor Discovery. The router supplies the first 64 bits of the IPv6 address, which specifies the globally unique part and the VLAN-specific part. The host supplies the second 64 bits, which is unique to the host. For this to work, the router must be configured to advertise the first 64 bits of the addresses used on each VLAN.

Router Configuration

To implement IPv6 in the UCAR network, I'll have to define an IPv6 subnet "next to" each IPv4 subnet. Initially, there's no reason to do this on every network. I'll only do it on UCAR router interfaces connected to networks that have IPv6 hosts. Initially, I'll do the .2. subnet so netman/HP OpenView can monitor IPv6, and the .8. subnet for testing (my laptop), and UNIDATA's network. Then I'll use OSPFv3 to distribute IPv6 in UCAR, as it does for IPv4 today.

To make a Juniper router do IPv6 on an interface, do two things

  1. configure an IPv6 address on the interface
  2. configure the interface to do neighbor discover router advertisement

Monitoring IPv6

As of 2003-12-23, we don't monitor IPv6 directly. Vince Biondolillo of UCB runs a Perl script that pings various FRGP IPv6 addresses and sends email to me if something doesn't respond.

When IPv6 is working on UCAR networks, I'll make HP OpenView monitor IPv6, including the DU, UCB, NOAA and Abilene routers.

Address comments or questions about this Web page to the Network Engineering & Telecommunications Section at nets-www@ncar.ucar.edu. The NETS is part of the Computational & Information Systems Laboratory of the National Center for Atmospheric Research, which is sponsored by the National Science Foundation and managed by the University Corporation for Atmospheric Research. This website follows the UCAR General Privacy Policy and the NCAR/UCAR/UOP Terms of Use.