中文网站
  Advanced Search
Read the latest Blogs from IT professionals in the field. Read and write community created documents. Need IT help? Ask our staff. Connect with your peers. Check our Tech Shop for posters, books and software tools. Home

13.1.3.5 Internal connectivity(1)

As mentioned above the Catalyst 6500’s with SUP720 will be used to form the IPv6 core network. In addition we have two Cisco 7206 routers at hand that can be used.

Most of the physical connection will use the same lines as for the IPv4 network. As the whole core
network is trunked we have the option to use transit VLANs if necessary.

To connect the clients we use:

• Dual-stack in the core and for the VLANs
• A tunnel broker for satellite subnets without native IPv6 connectivity
• A tunnel broker and ISATAP for satellite clients without native IPv6 connectivity

ISATAP

The ISATAP server is already running on one of the Cisco 7206 routers. Clients have to configure the proper target IP or - if capable - can use the name isatap.uni-muenster.de.

Tunnel broker

The tunnel broker is an OpenVPN system as described in Chapter 5. Currently hosts get a /64 prefix (if more than one host is connected) or a /128 address (if only that host is connected). As soon as the university gets an extended address space it is intended to assign proper /48-prefixes to end sites, to meet the requirements of RFC3177.

Currently the used addresses and prefixes are hard configured in the script we deliver with the clients OpenVPN files. In the future we will use DHCPv6 prefix delegation to assign the /48 prefixes to clients.

IGP

The IPv4 network uses OSPFv2 as internal routing protocol. So far there was no need for an IGP for IPv6 as we only had one router with multiple VLANs attached. But for the extended IPv6 network we need an IPv6 IGP. We had some experience from running the 6WiN where we used IS-IS, so now there are several combinations what IGP’s to use for these two networks.

• OSPFv2/OSPFv3
• OSPFv2/ISIS
• IS-IS single topology
• IS-IS multi topology

Running IS-IS with a single topology is not an option, as we do not intend to run IPv4 and IPv6 on the same topology. In any case, running IS-IS only would require that we substitute the current OSPFv2 with IS-IS. We feel that this is too much of an effort, at least for our size of network.

So the choice is only between OSPFv3 and IS-IS for IPv6. While we had some experience with IS-IS in the project, the University’s NOC has more experience with OSPF. As OSPFv2 and OSPFv3 don’t differ much, we felt it was best to go with the OSPFv2/OSPFv3 combination.