DHCP Option for street address, PSAP for VoIP E911

While for various reasons I believe that the efforts to enforce E911 requirements on Voice over IP phones are bogus and largely designed to make it harder for smaller players to compete with established companies, there is a legitimate need for ways to give your location to emergency services.

To protect privacy, I suggest that this be done in the endpoints. To assist this, I would propose a set of option extensions to the DHCP protocol to tell an endpoint what the server knows about its location, including address, zip and even what emergency contact center to use. This would start with RFC3825 for geolocation, and move on to other features. The endpoint device, when calling 911 or other emergency services, could include this information in the SIP invite, or provide it on request.

For those who don't know, DHCP is the system which lets a computer connect to an ethernet and ask for an IP address as well as important local network information (such as the addresses of routers, name servers, domain names etc.) Some DHCP servers know exactly who the client device is and effectively act as the client's memory. Some just give the next available address and return information about the local network area.

For example, most people with home networks, and almost all of them who use Voice over IP services like Vonage have a local network with its own DHCP server, built into the home-router they use. That home router could be told the address of the home, and all devices, including VoIP phones, could learn it. For companies, it is the same.

DHCP is also used for ISPs to give addresses to DSL and Cable modem customers who hook up to the internet without a home gateway because they have only one computer. That's pretty rare for VoIP users. In these cases they may or may not know the street address of the computer. DHCP is also very common for people who connect to wireless access points. The AP in a Starbucks could easily tell your device the address of the Starbucks.

As noted, we could start by the device fetching this address and forwarding it on with emergency calls, but not doing so for regular calls. This puts privacy control in the hands of the user, where it should be.

However, we could do even more than just give location as in rfc3825. The DHCP server could publish the direct contact information for the local area for police, fire, ambulance or general emergencies. They could simply include the contact number of a PSAP (Public Service Access Point, the gateway to emergency services) for the location, or in a corporate setting, might direct emergency calls to the corporate security desk, with the PSAP/911 as a fall-back. (There should be laws however about use of such features and protection of privacy. Network owners can already reroute any traffic but we want it to be clear how this might be done.)
The flaw in the E911/VoIP rules it that it assumes that because something looks like a telephone, it must be regulated like one. We want emergency services, and we want to make phone calls to them, but we might also just like panic buttons that summon the police or other things not yet invented.

If we build in a smart-endpoint regime, where the endpoints have a way to learn their location and tell the emergency services, regardless of what protocol they use or what the application looks like, there's the answer.

Of course, older equipment would not know how to use this new information. So the VoIP companies providing 911 service would need a fallback method for people who can't set the new system up. This is what they are building now, but they don't plan for it to be the fallback, they expect it to be the main operation. But it's bad from a privacy standpoint, and probably less accurate too, with no ability to roam.

Note for security reasons we would also like a way to digitally sign DHCP results to know they can be trusted.

A recent commenter suggested the use of DNS LOC records. Aside from the fact that these are public, your domain and your network are not the same, even though they are often related. One might be at a wifi hotspot but still be using the domain and DNS servers of your "home," especially if behind a VPN. (Mind you if you are using a VPN you must understand you have two connected networks with possibly two DHCP addresses, and one is the local one.) Ideally you would do your (secure) VoIP over the local network unless calling somebody also inside the VPN, as using the VPN would degrade the call a lot.

Another comment brings up the troublesome point that spyware could make troublesome use of a locally available address information. However, it's hard to see a system that would allow convenient roaming and not allow spyware to pretend to be a phone asking for its address, which doesn't also create a public mapping of IPs to addresses. It may make sense to offer the DHCP street address only where people like to roam, and at residences to enter it permanently in the phones. Or, while it's messy, the DHCP server could contain the address encrypted with a public key available only to emergency services.

This key would probably be compromised over time, but the emergency services could just routinely issue new ones. They would continue to decrypt the old ones of course, but users concerned over spyware could switch to any of the new ones.

Sure, If I correctly understand what's suggested, we could go to a model where the consumer has to program the address of the PSAP (or other "push-button" contact), but his own endpoint learns its home address automatically.

On the other hand, we could enlist the aid of the ISPs such that a VoIP call originating to "911" is routed initially to the appropriate VoIP service provider, who does a database dip (e.g. parallel to SS7) against the originating IP address and redirects the call to the appropriate PSAP with the address information attached.

ISPs would need to track their IP assignments in near real-time, and make that information available to the registered authorities as needed. Non-conforming ISPs would presumably be tracked against ICANN IP allocations, with responsibility for 911 databases tracking alongside the responsibility for the IP address generally.

The non-geographic nature of the IP address assignments, I suspect, is a bit of a red herring. The majority of residential users today are assigned an IP address by a competent corporation based on a DHCP request from a specific phone wire or coax cable, at a determinable physical address.

A danger would exist in abuses of the database: just as a phone number can be traced to an originating household (or business), an IP address would become tracable by competent authorities. Legal issues surrounding such questions as copyright violation would need to be settled on their merits, with reduced opportunities to frustrate the matter under false pretenses of privacy.

We're not too far away from this.

Cisco switches let you record a comment for each port. I use them to store the name of the server, or whatever, is plugged into each one. Those move around a lot and sometimes get out of date quickly.

As far as offices are concerned, we put into the comment the room number. While people move around a lot, we find that since we have a one-port-per-office rule (which we abide by 99% of the time) we only change those ports when there is new construction. That's rare enough that we can be pretty sure that we'll remember to update the comment field.

E911 services should be able to query the switches to build up a map of MAC address -> port number -> comment string. They can then send the E911 service the comment string. Easy.

Its rumored that Cisco does that already, but I couldn't find a way to enable that in the mere 15 minutes that I tried.

Cable modems and DSL are essentially 1 port per house. It may be a virtual port, or a port off a distant remote relay or switch.

The point is that you never can trust the PC connected to a switch, but I can trust my technicians to update the comments coded into a switch port... because I can audit them.

I like your DHCP idea, but I think it would be much more powerful to give a way for endpoints to ask their switch for the information. Tons of privacy issues there, but it could be worked out.

I misspoke. I didn't mean the E911 service would query the switches. I meant that the ISP would put up a "E911 data collection service" which would gather the data supplied to the client when it asks for it.

If you don't have a home NAT box, your DHCP queries would hit the ISP's DHCP server which can't do anything with your MAC address alone. It would have to look up the MAC address on the CAM or ARP table of every switch in the subnet. That's not efficient. Instead, that data would have to be pre-collected.

If you do have a NAT box, you could program it yourself, or it could provide a DHCP pass-through. Some do this with DNS information already. The router queries the ISP for DNS servers and uses this info to populate its own DHCP server's configuration file.

Either way this means that the ISP is now tracking your location. That is the privacy problem with what you suggest.

If privacy is your only concern, it would be better to have a new protocol that lets an end-point ask the switch directly "where am I?". This would have to be some kind "broadcast that doesn't propagate past the first switch" which would be very difficult to implement. Though, DHCP could give you the IP address of the switch you need to query, and you'd use the new protocol to speak to that switch. Though, I think the same kind of MAC/location gathering would be needed to answer that query. We're back to square one.

Do we really need a new DHCP extension for this? I was thinking you could do this with the existing DNS LOC standard. Have the DHCP server (be it the Starbucks AP or your home router) support DNS LOC, the VOIP software can use that to look up your location and forward it along with the call.

providing location info to clien

It must be ensured that the location provided to the client is physically as close as possible to it. To me the best place to do this is the first L2 element encountered by the client. For 802.11, this is the access point. For Ethernet, the first switch

This implies you need a L2 protocol to discover your location; IP layer and above are too risky. DHCP can fit here, since it is not routable. DNS is, so that to me is not a good candidate. DHCP can be relayed, in which case the relay agent would be required to insert the location, or at least filter out any location it gets from upstream. Providing a wrong location is worse than providing none at all

Any L2 protocol would be

Any L2 protocol would be brand new. Once you're talking a brand new protocol, it's an entirely different class of problem.

No, providing a "wrong" location is not worse than none at all, if you indicate your confidence in the information. If it comes tagged with "I got this from my LAN, the exact location is unsure but the building is right" that's a great deal better than providing none at all.

Once you want to do a new protocol, you can do a lot, but it's a lot of work. Though SNMP might be the basis for what you need.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

His name is Brad Templeton. You figure it out.
Please make up a name if you do not wish to give your real one.
The content of this field is kept private and will not be shown publicly.
Personal home pages only. Posts with biz home pages get deleted and search engines ignore all links
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

More information about formatting options