Network Working Group H. Schulzrinne
Request for Comments: 4776 Columbia U.
Obsoletes: 4676 November 2006
Category: Standards Track
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option
for Civic Addresses Configuration Information
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2006).
RFC Editor Note
RFC 4776 is being published to correct an error in the assignment of
the numeric value of the DHCPv6 option-code in RFC 4676 (Section
3.2). This document obsoletes RFC 4676.
Abstract
This document specifies a Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) option containing the civic location of the client or the
DHCP server. The Location Configuration Information (LCI) includes
information about the country, administrative units such as states,
provinces, and cities, as well as street addresses, postal community
names, and building information. The option allows multiple
renditions of the same address in different scripts and languages.
Schulzrinne Standards Track [Page 1]
RFC 4776 DHCP Civic November 2006
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................5
3. Format of the DHCP Civic Location Option ........................5
3.1. Overall Format for DHCPv4 ..................................5
3.2. Overall Format for DHCPv6 ..................................6
3.3. Element Format .............................................7
3.4. Civic Address Components ...................................7
4. Postal Addresses ...............................................13
5. Example ........................................................14
6. Security Considerations ........................................15
7. IANA Considerations ............................................15
8. References .....................................................16
8.1. Normative References ......................................16
8.2. Informative References ....................................17
Acknowledgements ..................................................17
1. Introduction
Many end system services can benefit by knowing the approximate
location of the end device. In particular, IP telephony devices need
to know their location to contact the appropriate emergency response
agency and to be found by emergency responders.
There are two common ways to identify the location of an object,
either through geospatial coordinates or by so-called civic
addresses. Geospatial coordinates indicate longitude, latitude, and
altitude, while civic addresses indicate a street address.
The civic address is commonly, but not necessarily, closely related
to the postal address, used by the local postal service to deliver
mail. However, not all postal addresses correspond to street
addresses. For example, the author's address is a postal address
that does not appear on any street or building sign. Naturally, post
office boxes would be unsuitable for the purposes described here.
The term 'civil address' or 'jurisdictional address' is also
sometimes used instead of civic address. This document mainly
supports civic addresses, but allows the postal community name to be
indicated if it differs from the civic name.
A related document [15] describes a DHCPv4 [2] option for conveying
geospatial information to a device. This document describes how
DHCPv4 and DHCPv6 [6] can be used to convey the civic and postal
address to devices. Both geospatial and civic formats can be used
simultaneously, increasing the chance to deliver accurate and timely
Schulzrinne Standards Track [Page 2]
RFC 4776 DHCP Civic November 2006
location information to emergency responders. The reader should also
be familiar with the concepts in [11], as many of the protocol
elements below are designed to dovetail with PIDF-LO elements.
This document only defines the delivery of location information from