SonyCSL sNLA2 annual report 2001

Network Name



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.

Network Topology

Our IPv6 network topology is shown in the following figure. 2001 SonyCSL IPv6 Network Topology

Routing Control

Our border router connected to 6bone is a PC/AT box, running NetBSD 1.5R and advertises routes using RIPng from zebra. In the SonyCSL IPv6 network, RIPng is used and routing daemons are the built-in route6d and the ripngd from zebra.

Address Allocation

The CSL IPv6 administrator allocates ::/60 address space to individuals or projects. Currently five prefixes are allocated.

IPv6 related activities


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.

DNS Proxy

We developed a DNS proxy program running on Windows 2000 and Windows XP IPv6 environment. Since Windows can send a DNS query packet via only IPv4, Windows cannot work properly on network that supports only IPv6. This program translates an IPv4 DNS query packet into an IPv6 DNS query packet. It allows us to use Windows on IPv6 only network. This program is available at

Tunnel Server

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.

Troubles / Tips

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.