MyIPScan
IP Ranges

KDDI IP Ranges

KDDI is the Japanese carrier behind the au mobile brand and the DION fixed-line service, and AS2516 is the number that carries it. The authoritative record sits in JPNIC: the copy APNIC serves states it has only been partially mirrored from JPNIC and refers queries to the JPNIC whois gateway, which is why the object shows no allocation date at all and nothing newer than a modification stamp of 24 June 2010. The consumer blocks underneath are registered with the netname KDDI to KDDI CORPORATION at Garden Air Tower, 3-10-10 Iidabashi, Chiyoda-ku, Tokyo, with abuse on those pools directed to abuse@dion.ne.jp.

ISP
Provider
KDDI
Primary ASN
AS2516
Category
ISP
Headquarters
Tokyo, Japan
Announced IPv4 prefixes
564
Registry
JPNIC

Known IP ranges

These prefixes are currently announced to the global routing table by AS2516 (KDDI - KDDI CORPORATION). Prefix sets change over time - use WHOIS Lookup for the authoritative record on any specific address.

106.128.0.0/11
36.8.0.0/13
111.236.0.0/14
49.132.0.0/14
14.10.0.0/15
106.72.0.0/15
114.20.0.0/15
14.12.0.0/15
14.8.0.0/15
106.190.0.0/15
240f::/24
240f:100::/24
240b:240::/26 (IPv6)

What does a KDDI IP mean in a privacy test?

The reverse name, not the ASN, tells you which KDDI product an address belongs to. Mobile sessions answer under au-net.ne.jp, fixed broadband under ppp-bb.dion.ne.jp, and a further pool under ppp.prin.ne.jp. A fourth zone, v4.enabler.ne.jp, is the shared IPv4-over-IPv6 platform operated by Japan Internet Xing, and it does not follow the registry: 106.72.0.0/15 is registered with the netname JPNE to Japan Internet Xing Co., Ltd. of Otemachi, abuse at abuse@jpne.co.jp, but 14.10.5.10 and 14.12.5.10 both sit inside 14.8.0.0/13, which is registered netname KDDI to KDDI CORPORATION, and both still answer under v4.enabler.ne.jp. So an address here is a Japanese consumer line, and the zone rather than the whois record is what tells you whose access platform is actually carrying it.

Where KDDI publishes its mobile address ranges

KDDI publishes the global address ranges used by its mobile service on its own developer site, on the au network-connection requirements page at au.com/developer/android/kaihatsu/network/. It is a flat list rather than a feed, and it is specific: for LTE NET and 5G NET the IPv4 side names 106.128.0.0/13 with 106.134.0.0/16 and 106.135.0.0/16 excluded from it, alongside entries such as 27.81.160.0/20, 59.132.0.0/19, 106.146.0.0/17, 182.249.0.0/16 and 182.250.0.0/15, while every IPv6 entry on the list falls inside 2001:268::/32. For the LTE NET for DATA and 5G NET for DATA services the same page says the global IP addresses used are non-public.

Two limits matter. The list covers mobile only, so the fixed-line pools are absent, and so is 240f::/24 - JPNIC registers that block with the netname KDDI-CIDR-BLK-JP to KDDI CORPORATION, but it appears nowhere on the published list, whose IPv6 side is entirely 2001:268: space. None of the objects checked here - the KDDI allocations covering 106.128.0.0/11 and 14.8.0.0/13, the JPNE block, and 240f::/24 - carries a geofeed, so nothing KDDI publishes maps a block to a city. For registration rather than product the JPNIC gateway at whois.nic.ad.jp is the authority the APNIC mirror itself points you to, and for routing KDDI gives PeeringDB two RADB sets, AS-KDD and AS-KDDI6.

Reading a KDDI hostname in a log

The hostname is a restatement of the address, not a description of the customer. 106.128.5.10 resolves to KD106128005010.au-net.ne.jp: a KD prefix followed by the four octets padded to three digits each, and the same generator runs across the other KDDI zones, so 36.8.5.10 comes back as KD036008005010.ppp-bb.dion.ne.jp and 114.20.5.10 as KD114020005010.ppp.prin.ne.jp. The Japan Internet Xing zone swaps the prefix for M and keeps the padding, giving M014010005010.v4.enabler.ne.jp on 14.10.5.10. No city, exchange or account identifier is encoded anywhere in any of them.

Some announced space has no reverse delegation at all. Addresses sampled in 49.132.0.0/14 and 106.190.0.0/15 return NXDOMAIN, and the SOA served for those zones is ns.apnic.net rather than a KDDI nameserver - the reverse zone was never handed to KDDI, so there is no hostname to read and the JPNIC record is the only label. For what sits on the space, PeeringDB files AS2516 as an NSP of global scope with a balanced traffic ratio and a selective peering policy, which is the shape of an access and transit carrier rather than a hosting estate.

Related tools

Frequently asked questions

Is every IP address on AS2516 registered to KDDI?

No. 106.72.0.0/15, one of the larger prefixes AS2516 announces, is registered with the netname JPNE to Japan Internet Xing Co., Ltd. of Otemachi, Chiyoda-ku, with abuse directed to abuse@jpne.co.jp. Addresses there resolve under v4.enabler.ne.jp and belong to that shared IPv4-over-IPv6 platform rather than to KDDI retail.

Does a v4.enabler.ne.jp hostname always mean the block is not KDDI's?

No, and this is the trap. The enabler zone also appears on space KDDI itself holds: 14.10.5.10 and 14.12.5.10 both fall inside 14.8.0.0/13, which is registered netname KDDI to KDDI CORPORATION with abuse@dion.ne.jp, yet both answer under v4.enabler.ne.jp. The zone tells you which access platform is carrying the line, not who holds the registry object.

What does an au-net.ne.jp hostname mean?

It is a mobile session on the au network. KDDI lists the global ranges used by LTE NET and 5G NET on its developer site, and 106.128.0.0/13, the block those hostnames come from, is on that published list, with 106.134.0.0/16 and 106.135.0.0/16 excluded from it.

Does KDDI publish a geofeed?

No. No geofeed appears on any of the objects checked here, including the KDDI allocations covering 106.128.0.0/11 and 14.8.0.0/13 and the IPv6 block 240f::/24. The published au range list tells you which service uses a block, not where it is used, so any city attached to a KDDI address is a commercial database making its own inference.

Why does the reverse name contain my own IP address?

Because that is nearly all it contains. KDDI generates these PTRs mechanically: a two-letter prefix, then the four octets zero-padded to three digits, so 111.236.5.10 becomes KD111236005010.au-net.ne.jp. Only the zone on the end carries information, and what it carries is the product.