Top > JANOG22 Programs

General information about JANOG22

  • Date
    • 10th&11th Jul 2008
  • Venue
    • The Grand Hall, Shinagawa, Tokyo

JANOG update


  • Masaru MUKAI, JANOG Committee


  • Recent topics since JANOG21
  • Some statistics based on the JANOG22 meeting registration questionnaire


  • (updated:Sep.4 2008)

JANOG: Act locally, think globally - An introduction of the JANOG i18n team


  • Akinori MAEMURA, JPNIC
  • Yasuo IGANO, Verizon Business


Do you know "JANOG i18n" team?

"i18n" stands for "Internationalization." In Japan, many economists and executives are discussing a serious issue of Japanese industry. It's called "The Galapagos Effect" or "Paradise Isolation." This means that many excellent, and often superior, Japanese technologies which are used domestically aren't being deployed globally, and sometimes this causes harmful effects.

The JANOG i18n team has been trying to approach this BIG issue. One of the team's major activities is to globally disseminate information about what is being discussed in the JANOG community.

The project is just beginning. We would like to share our activities with JANOGers, and we solicit and would appreciate your advice.


Let's Discuss Operational Guidelines for ISPs' Bandwidth Control


  • Toshiharu Tanabe, SAITAMA UNIVERSITY
  • Kazuo Ishikawa, USEN CORPORATION
  • Hirotoshi Wakiyama, BitTorrent KK.


The Ministry of Internal Affairs and Communications (MIC) and four associations of telecommunications carriers finalized guidelines as operation standards for bandwidth control on May 23rd, 2008. In this session, based on these guidelines, we are going to discuss bandwidth control as implemented by Internet service providers, what kind of traffic should be controlled, and what should not be.

Bandwidth control by Internet service providers had been a controversial topic in connection with confidentiality of communications. In September 2007, MIC recognized the existence of implementations of bandwidth control in the final report compiled by the Panel on Neutrality of Networks and commented "It is advisable to formulate minimal operational rules linking to operational guidelines for bandwidth control". Additionally, some video service providers caused another controversy by suggesting possible implementation of bandwidth control on particular content by some telecommunications carries and asking those carries to disclose the fact.

In response to such circumstances, since September 2007, four associations of telecommunications carriers (the Japan Internet Providers Association, the Telecommunications Carriers Association, the Telecom Services Association, and the Japan Cable and Telecommunications Association) and MIC as an observer conducted the "Study Group on the Guideline for Packet Shaping", and a set of guidelines as operation standards for bandwidth control titled "Guideline for Packet Shaping," which was finalized on May 23rd.

In this session, we are going to examine the guidelines and discuss what should be bandwidth-controlled and how it should be implemented.

Report of Experiment on Notifying Route Hijacks - For The Benefit of Internet Engineers -


  • Masayuki Okada (Japan Network Information Center)


JPNIC began the notification experiment of route hijack information for the JPIRR registrants in cooperation with Telecom-ISAC Japan in May, 2008.

In this program, we introduce the outline of this coordinated experiment and the story of the experience of the JPIRR registrants who received the notification of route hijack information by the date of JANOG22.

We want the participants of JANOG22 to recognize the reality where route hijacks occur. And, we hope for the an increase in the number of entrants in this coordinated experiment that is one of uses of IRR.

Destructingly Internet


  • Masaru Mukai (KDDI Corporation)
  • Tsunehiko Suzuki (A Citizen)
  • Masato Minda (Japan Registry Services Co., Ltd.)
  • Jun Takemura (Japan Communications Inc.)


Couldn't the Internet be a tool for realizing the world of autonomous and creative intercourse that Ivan Illich proclaimed?
Couldn't the Internet be the appropriate technology that E. F. Schumacher announced?

Was the idea of autonomy that the Internet implied just a pipe dream?
What really is "an Internet" in the first place?

Is the Internet deteriorating?
Which does the society want, freedom or safety?

IPv4 Address Exhaustion News? ~ What will happen when using ISP-NAT~


  • Kousuke Shishikura (NTT Communications Corporation)
    • 2003: Joined NTT Communications Corporation, involved with designing and developing the ISP’s backbone network and external peering networks
    • 2004: Implement IPv4/IPv6 dual-stack in the ISP’s backbone and enable IPv6 multicast
    • 2005: IPv6 Technical Summit – programme committee member
    • 2007: Interop NOC member
  • Tomohiro Nishitani (NTT Communications Corportaion)
    • 1999: Joined NTT, worked at NTT Research Institute and NTT East Japan
    • 2006: Involved with research such as VoIP, NAT penetration and P2P at NTT Communications Innovative IP Architecture Centre
    • P2P Network Experiment Council member
  • Ryo Sato (Konami Digital Entertainment Corporation)
    • 1997: Joined Oki Electric Corporation
    • 2003: Joined Konami Studio (current Konami Digital Entertainment Corporation) Involved with development of online games and network technologies, especially NAT penetration algorithms and BITTorrent system
    • Major works: winning Eleven 2008 and Metal Gear Online


IPv6 is identified as the most promising option as a counter-measure against IPv4 address exhaustion in reports published by the Ministry of Internal Affairs and Communications. JPNIC has highlighted these conclusions.

These reports also mentions using ISP-NAT as a bridging transition mechanism while achieving wider IPv6 deployment. It has become clear that there are many issues regarding the application of ISP-NAT which require collaboration by various fields to overcome these challenges.

First, we would like to provide current discussions about ISP-NAT and share issues with participants. Then we would like to have discussions to identify countermeasures to overcome such issues.

  • What applications and services will be affected by deploying ISP-NAT?
  • Is there any possibility of address collisions with currently used private IP address by individual users?
  • Does NAT table log allow us to trace accesses?
  • What functions are required by ISP-NAT?

IPv6 address architecture on point-to-point links


  • Matsuzaki 'maz' Yoshinobu, IIJ


IPv6 shares similar routing and forwarding concepts with IPv4. However, there is a difference in term of addressing and it could be prone to unexpected problems. I'd like to discuss considerations and possible countermeasures against such things which everyone (including network operators and vendors) tends to forget.


BGP 4 byte AS implementation - miscellaneous thoughts


  • Miya Kohno, Juniper Networks


4 byte AS numbers have been discussed in various places including JANOG, and actual allocations have been started by RIRs. AS numbers is no less a resource depletion issue than IPv4 address space, but thanks to its built-in mechanism for co-existence and the limited number of concerned parties (BGP operators only), the deployment is thought to be taking place without big problems.

However, there is a point which has not yet been resolved, - a notation. AS numbers use a flat 32bit space and there is no concept of hierarchy or structure per se. But at this moment, it seems the "asdot" notation[*1], which separates the space into two 16bit spaces, is going to be adopted by RIR communities. It was my impression that the things were proceeded without enough intensive discussion. As presented in RIPE-55[*2], the asdot notation conflicts with the regular expression and filters/scripts/RPSLs could get incompatible.

[*1] draft-michaelson-4byte-as-representation [*2]

JunOS has implemented "asplain" at first, since it's simpler and not conflicting with reg-exps. But it has quickly added "asdot" as well.

In this session, I'd like to talk a little bit about miscellaneous thoughts on the 4 byte AS implementations.

Overlay Routing and Traffic Fee Distribution Issues


  • Tsuyoshi Hasegawa, Osaka University Cyber Media Center


Overlay Routing is a new route selection technology. In the Overlay Routing platform, hosts on the edge of the network are able to test connectivity between each other over multiple paths. The Overlay Routing platform then selects the best path based on delay, packet loss and bandwidth utilisation calculations. The result being the Overlay Routing path selection system provides better network performance than path selection based on current route selection algorithms.

Also an ISP's cost structure is based on traffic flows between itself and other ISP's. However compared with Overlay Routing, traffic flows can be unpredictable with current route selection algorithms , which can lead to unexpected costs. This is the "traffic fee distribution problem". This presentation discusses the following results in detail:

  1. Effects of using overlay routing path selection metrics based on delay, bandwidth utilisation and throughput.
  2. Correlation of latency on overlay paths to bandwidth utilisation.
  3. Effects of multipath data transmission. Using data from PlantLab's network.

Lastly the presentation will provide results for the use of the Overlay Routing algorithm on the "traffic fee distribution problem". Including comparing the balance of traffic using different Overlay Routing algorithms, showing that the "traffic fee distribution problem" is a difficult issue. Lastly the presentation will cover Overlay Routing selection algorithms that provide better performance for end hosts and reduces the effects of some of the "traffic fee distribution problem".

What is "show tech-support"?


  • Kinuko Mitsugi (Media EXchange, Inc.)
    • 2001: Joined Media EXchange. She's been involved in the network and datacenter


  • Whenever trouble happens, she is caught in a dilemma between the customer, the

sales team, and the hardware....


When we need any hardware maintenance service (ex. RMA), the hardware support vendor will ask us to send a summary of the system information, the results of the so-called "show tech-support" command.

To investigate a problem with an interface or with BGP flapping, trying to do "show tech-support" can cause the system to go down. Do you have such an experience?

When trouble happens we want to give the necessary information to the hardware vendor. But typing "show tech" and waiting for the log takes a long time even though we'd like to recover our services ASAP. Sometimes the "show tech" seems irrelevant but the vendor still asks us to give it to them.....

I'd like to discuss with other attendees what we really need to collect as data in case of trouble, then propose it to the hardware vendor in this meeting or via JANOG ML.

IPv4 Depletion: Can Web services you use survive?


  • Tetsuji Koyama (BeatCraft, Inc.) - Moderator
  • Tetsuya Sato (Dwango Co., Ltd.) - Panelist
  • Gosuke Miyashita (paperboy&co.) - Panelist
  • Koichi Ise (livedoor Co., Ltd.) - Panelist


Depletion of IPv4 addresses is seen as inevitable in the coming few years.
As an alternative, after IPv4 depletion, IPv6 is a strong candidate, but in reality it is not yet widely deployed. With regard to the transition to IPv6, various discussions have happened which focused on both backbone networks and on deployment by end-users.
But there are small/medium business web service operators who do not have their own networks, and use iDC housing and other services to provide their services to end-users. There have been very few discussions from the perspective of such Web service providers.
In today's Internet, a variety of Web services offered by this kind of provider generate great value for end-users. They can not be ignored when we think about the world after IPv4 depletion.
However, today, if they want to prepare to provide IPv6 Web services, only a limited number of Hosting services offer IPv6 connectivity to them. Even for an experimental lab, there are high barriers.
In this session, we have invited the following people to discuss Web service providers' IPv6 migration, future developments and related issues.

  • Data Center / Server Hosting Operators
  • Web services providers

Topics of the Internet and What's the Role of the Japanese Community in the Future



  • Tomoya Yoshida (NTT Communications ) - Modelator
  • Philip Smith (Cisco Systems)- Panelist
  • Miwa Fujii (APNIC) - Panelist
  • Yuichi Ikejiri (JANOG Chair) - Panelist
  • Seiichi Kawamura (NEC Biglobe) - Technical translator


We will discuss the topics of interest to the worldwide internet community and the role of the Japanese community with Philp Smith who is NANOG's Steering Committee chair and is familiar with the internet community.

Part I: BGP

Philip Smith will talk about the current status of BGP and it's future .

Part II: The Internet Community and Future of JANOG

Panel discussion in terms of the topics of interest to the worldwide internet and the roll of the Japanese community in the future.

Attach file: fileJanogUpdate_en_ver3.ppt 3814 download [Information]

Reload   New Lower page making Edit Freeze Diff Upload Copy Rename   Front page List of pages Search Recent changes Backup Referer     RSS of recent changes
Last-modified: (2790d)