Abstract

1
Introduction
It is expected that IPv4 address space will deplete in someday in year 2011 as of the IANA’s storage, while IPv6 deployment is far behind the schedule which was expected when the Internet community had started to work for the next version of the Internet Protocol in early 1990's. One of the possible ways to mitigate the consumption rate of IPv4 and to allow growth of the Internet after the depletion of IPv4 address space is known as NAT444 [1] or introduction of LSNs — Large Scale NATs – In IETF79 Beijing Meeting (November, 2010), there was a discussion in DNSOP working group if some subsets of RFC1918 address space [2] can be used for assignment to ISP side of CPEs rather than to assign a special address space [3] [4] outside of Such an address space can be shared RFC1918. among ISPs globally. The question was if there were some region in RFC1918 space which is far less uti- lized than others. It may not be easy to know the current utiliza- tion of RFC1918 address space in precise manner as they are not appeared in the global routing table. *Keio University, Graduate School of Media Design, Email: Mainly due to the internal activities where RFC1918 address is used, some DNS reverse lookup queries on addresses in RFC1918 space have been leaked to the global Internet.  In order to avoid these queries served by one of the Root DNS servers, AS112 servers 1 [5] have been operational to be authoritative of the zones as follows: ● 10.in-addr.arpa ● 16～31.172.in-addr.arpa ● 168.192.in-addr.arpa By analyzing the traffic to the A$112 servers, we may able to know briefly how RFC1918 address space is utilized.
Methodology
2
CAIDA ² and DNS-OARC ³ coordinates DITL 4 (Days in the Life) event yearly. In DITL, DNS and other traffic data is captured by various operators for a scheduled 2～3 days period.  They are uploaded to a DNS-OARC server to allow global traffic trend anal- ysis. An AS112 server operated by WIDE Project 5 has participated the DITL activity since 2008. In this memo, following three DITL data sets cap- tured by the WIDE A$112 server have been analyzed: ● DITL2008 : 50 hours starting from 23:00 UTC of March 17, 2008 1
● DITL2009 : 74 hours starting from 23:00 UTC of March 29, 2009 ● DITL2010 : 59 hours starting from 13:00 UTC of April 13, 2010 Note that AS112 servers are highly distributed by using Anycast. In this memo the traffic data cap- tured by the AS112 server operated by WIDE Project in Japan is considered. It is possible that the anal- ysis of other AS112 servers yields a different result. But we are expecting that the trend described here is also applicable to the traffic observed by other AS112 servers. Only UDP DNS queries for reverse lookup for RFC1918 addresses were considered. Then the queries were classified by the target RFC1918 ad- The number of queries dresses into /16 chunks. counted was about 16 million, 33 million, and 45 mil- lion in DITL2008, DITL2009, and DITL2010 respec- tively.  Note that the source IPv4 addresses of the queries were not taken into account.
3
Analyzed Results
analyzed results in each of DITL2008, The DITL2009, and DITL2010 are illustrated in Fig. 1, Fig. 2, and Fig. 3 respectively. Note that the leftmost red bars in these graphs correspond to 10.0.0.0/16 while the rightmost blue bars corre- spond to 192.168.0.0/16. Some spaces in the both side of the plots were provided just for readability. The summarized number of queries in terms of three RFC1918 blocks were as seen in Table 1.
4
Tentative Conclusion
The graphs indicated that all of three spaces 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 were well utilized, and it may be difficult to find enough space for the ISP-shared address space. Someone may point that the graphs illustrated here can be applicable only to WIDE Project operated AS112 server. This may be true, however, it is less likely that the trend was seen only at WIDE Project operated AS112 server. So our tentative conclusions are followings: ● All of /16 chunks in 10.0.0/8 are well used. ● It is hard to find space from RFC1918 space for ISP-side ports of CPEs without conflict with customers' side (in other words, customers' side renumbering is necessary).