Our first network prefix 3ffe:501:1830::/48 was allocated by WIDE in August 1999, afterwards 2001:200:120::/48 was allocated in January 2000. Currently our network is connected to WIDE Otemachi NOC via a 44M ATM link.
XCAST6 is an implementation of XCAST[XCAST] over IPv6. XCAST is a new, flexible scheme for multicast suitable for a very large number of groups. We have attended a network conference once a week with WIDE xcast working group members using vic (video conferencing tool) and rat (robust audio tool) modified for XCAST6 since October 2001. From the MRTG graph measured at our border router, we found that the network traffic consumed was about 1 Mbps during the meeting.
LIN6[LIN6], Location Independent Networking for IPv6 is a protocol based on IPv6 and supports mobility and multi-homing with IPsec by employing a new addressing architecture. We have been developing and testing it on our IPv6 network. We have been doing mobility tests on LIN6 by using a video conferencing tool we developed to capture images from a USB camera, which is running on FreeBSD, NetBSD and Linux platforms.
In order to provide IPv6 connectivity to our lab members who have access to the Internet via ADSL, CATV or Fiber at their home, we established a tunnel server. Currently there are three users.
In this section, we describe a trouble and a solution when we used ospf6d to advertise aggregated routes.
We had been using ospf6d from zebra at our border router connected to the 6bone to advertise our prefixes to the 6bone. Since ospf6d did not have an ospf area feature yet, the router belonged to the backbone area of WIDE. Ripngd also ran on the router to exchange routes in our internal network. We had to advertise our aggregated routes, 2001:200:120::/48 and 3ffe:501:1830::/48 to the 6bone. But we could not do that due to a limitation of zebra. That was why ospf6d could not generate aggregated routes, and although ripngd could generate aggregated routes, ospf6d could not install the routes obtained from ripngd to its own routing table. Thus we took another way to solve this problem. That was that we injected the aggregated routes with a reject route flag to the routing table in the kernel by using the route command, and injected the routes in the kernel to the routing table of the ospf6d.
Thus we solved the problem by using a function that ospf6d could inject the routes stored in the kernel or static routes set by zebrad into its own routing table. We used a built-in route command to inject the aggregated routes into the kernel with "route add -inet6 2001:200:120:: -prefixlen 48 ::1 -reject". A reason why we did not use zebrad was it was not possible to specify a flag such as -reject, -blackhole, etc in the configuration file of zebrad.