|
|
|
| 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 | |
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.
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.
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 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 first 48 bits (6 bytes) of UCAR IPv6 addresses are defined by
the FRGP as 2001:0468:0503::/48. See
| 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:
| Site | UCAR Site ID |
|---|---|
| Mesa Lab | 1 |
| Foothills Lab | 2 |
| Center Green | 3 |
| Jeffco | 4 |
| Marshall | 5 |
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 | 20 | 58 | 00 | 06 | 5b | ff | fe | 87 | 69 | bf |
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.
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.
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.
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.