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
last updated 2009-01-12

Status

As of 2009-04-08, IPv6 is established in both FRGP routers, and DU is receiving IPv6 routes. We are feeding DU a default IPv6 route and DU is advertising its chunk of IPv6 space to us. DU has not yet pushed IPv6 into the campus from the border router. They want to get IPv6 to Sturm Hall for an IPv6 conference on April 22. CSM and NOAA have expressed interest in getting IPv6. We have BGP sessions to the CPS side and the R&E side of I2.

As of 2009-05-14, we don't yet have IPv6 to mlra from tcom-gs-1. Mlra is running 12.2(3)SXH, which doesn't accept "ipv6" commands, even though the Cisco document at http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-roadmap.html says it should. We need to upgrade it to an image that includes the "advanced ip" features, like s72033-advipservicesk9-mz.122-33.SXH2a.bin.

As of 2009-01-12, there has been little demand for IPv6. It was configured in the FRGP routers, but when the Juniper routers at the FRGP and BPoP were replaced with Ciscos, we didn't enable IPv6 in the Ciscos. FRGP members didn't notice. The minimal IPv6 monitoring that was being done by UCB stopped working long ago, and no one noticed. IPv6 is dormant. What follows is historical.

As of 2004-04-02, we were 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 Pollock 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.

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 the FRGP as 2001:0468:0503::/48. See FRGP IPv6 Address Space Delegations 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 ease the handling of IPv6 addresses.

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: A Dell PC with MAC address 00:06:5b:87:69:bf at the Foothills Lab (UCAR site 2) in MMM's VLAN 88 (hex 58) 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   2  58   00   06   5b   ff   fe   87   69   bf 

DNS

You might assume that DNS for IPv6 involves special new IPv6 DNS servers. 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 can be configured 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 IPv4 and IPv6 names and addresses.

Host Autoconfiguration

When an IPv6 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.

UCAR IPv6 subnets

To implement IPv6 in the UCAR network, I'll have to define an IPv6 subnet "next to" each IPv4 subnet. Demand is nonexistent, so there's no reason to do this on every UCAR 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 the network monitor can monitor IPv6, and the .8. subnet for testing (my laptop). Then I'll use OSPFv3 to distribute IPv6 in UCAR, as it does for IPv4 today.

Monitoring IPv6

As of 2009-01-12, we don't monitor IPv6. Back in 2003, Vince Biondolillo of UCB ran a Perl script that pinged various FRGP IPv6 addresses and sent email to me when something doesn't respond. Vince has left UCB and his script no longer runs.


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