Looking over a Wireshark trace this morning for an SMB over VPN issue and noticed a DNS lookup out to a local server requesting an A (host) record for isatap.datavalet.loc. Curious I looked into the source and nature of this connection.
DNS Query for isatap.datavalet.loc
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is a method of encapsulating IPv6 packets with an IPv4 header for transport across IPv4 routers. ISATAP uses a PRL (Potential Routers List) to discover routers; the PRL is built using DNS lookups for isatap host on local domain (ie. isatap.datavalet.loc).
The network I noticed this traffic on is provided by Bell, and in turn Datavalet Technologies Inc. is a Montreal-based company specializing in guest access solutions, along with related technology. When I initially connected to the network the DHCP server assigned my wireless adapter a domain name of datavalet.loc, hence the lookup to isatap.datavalet.loc.
The .loc TLD (top-level domain) is a privately assigned and administered name designated by the ISP, likely Datavalet is this case. The .loc TLD is not publicly hosted on the DNS root servers and would only be significant within the service-provider (Datavalet/Bell) network. Not to be confused with LOC DNS records which provide geographic location data.
The local DNS server is returning an affirmative answer to our query, resolving hostname isatap.datavalet.loc to IPv4 address 18.104.22.168. This may be a localized blackhole for unsupported services/protocols. According to APNIC the address is owned and managed by China Unicom.
ISATAP Wiki – http://en.wikipedia.org/wiki/ISATAP
DNS and BIND – http://my.safaribooksonline.com/book/networking/dns/0596100574