LIS Discovery Using DNS

Service discovery in IP networks is always a thorny topic. Do I use DHCP, or SLP, or DNS, or do I devise something new? This section proposes a LIS discovery technique that can be achieved through DNS SRV records. The reason for this choice is that many IP networks, in particular residential broadband networks, do not have a common means of providing network configuration data. Some use DHCP, and some use PPP. What is nice about DNS is that all systems must support it, making it an obvious choice.

To use a DNS discovery mechanism for a local service, such as an LIS, you must know the domain in which you are operating, and this must be the actual name of the access domain. The domain name of the access provider in many circumstances is available directly from the home router via DHCP (Option 15) and in many cases this domain name is adopted for use with the home computers and networks. Knowing the domain name of the serving access network allows an IP device to query the local DNS server and perform service discovery for the LIS. The service discovery technique described here is based around DNS SRV records.

In some cases, the domain name of the access network is not known, for example, when a laptop is taken home from work, it often maintains the domain name of the company owning the laptop, such as andrew.com. In this situation, more complex access domain name discovery techniques are required, and ways of achieving this are described in the following subsections.

External IP Address Determination

Figure 4.11 shows the domain discovery problem as it relates to a typical residential broadband network. The home-router runs an internal DHCP server that provides IP addresses from a private address range. The home-router itself is provided an externally routable IP address from the ISP, and the home-router performs NAT between the internal and external networks. The externally routable IP address is associated with the domain name belonging to the ISP, my.isp.net, as shown in Figure 4.11. To discover the local access domain name, a client must first determine the external IP address of the home-router. Three mechanisms for discovering this IP address are described next.

Figure 4.11: An external IP address discovery problem.

STUN

One way to determine the external IP address of the home-router is to use STUN. STUN is defined in Reference 13 and describes a mechanism for being able to determine the IP address on the public side of a NAT. STUN is a simple client-server based protocol and as such requires a STUN server. Due to the way in which STUN works, it is not necessary for the STUN server to reside in the same access network as the IP device, but it is necessary that the STUN server be reachable by the IP device.

It is likely that a voice service provider (VSP) will provide the STUN server to assist their customers in gaining access to a service from any access network. The rationale is that the User of the IP device must already have a trust relationship with the VSP, and so the various identity and integrity recommendations for STUN can be easily satisfied.

We will not go into a full working description of STUN, which is described in Reference 13. The expectation is that a STUN-client be associated with the HELD-client and that it issues a STUN binding request to the STUN-server. The STUN-server will respond with a MAPPED-ADDRESS message indicating the external IP address of the home-router gateway (see Figure 4.12).

Figure 4.12: Learning an externally routable IP address via STUN.

Universal Plug and Play (UPnP)

The Universal Plug and Play (UPnP) mechanism makes use of the UPnP Internet Gateway Device (IGD) specification which is supported in many home-routers to allow PC applications to operate seamlessly through the router's NAT function. The HELD-Client in this case acts as a UPnP Control Point (CP) and requests the external IP address of the router using the GetExternalIPAddress action defined in Reference 14.

This mechanism has the advantage that UPnP is a SOAP-based protocol running on top of HTTP, making it easy to implement as the HELD-Client is also built on top of HTTP.

WEB Report

To use the WEB report mechanism, a VSP or other known network entity establishes a web site, that when accessed returns the IP address of the requesting node. At the time of writing, a variety of web sites were available that support this functionality, for example, http://whatismyip.com/.

Domain Determination

Where the domain is not known, it must be determined. Once the device knows its external IP address, it can determine its access domain name by performing a reverse DNS lookup. This requires the ISP to populate in-addr.arpa records into its DNS for all IP addresses so that the resolution can occur. The generally accepted format for the resulting fully qualified domain name (FQDN) would be ip-address.my.isp.net.

DNS SRV Record LIS Discovery

The ISP must provide a DNS SRV record in the following form:

  _locserv+https._tcp       SRV 1 0 <port> <Hostname of LIS> 

In response to a query for the _locserv+https._tcp service, the DNS will return the FQDN and the port for the LIS service. The client will assume that all HELD requests are made against the root URI on the returned host.

For example, if the DNS were to return held.lis.my.isp.net with a port of 10001, then the client may obtain location from that service with the following:

• https://held.lis.my.isp.net:10001/.

Figure 4.13 shows the message flow between nodes when the DNS SRV LIS discovery mechanism is used. The figure shows STUN being used as an example for external IP discovery.

Figure 4.13: DNS SRV LIS discovery.