Technical Summary
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.
Geolocation data is carried in another option, specified in RFC 3825.
Working Group Summary
The working group came to consensus on this document. There was
a Last Call comment raised asking for clarification of whether this
option would ever be sent from host to server; this was discussed
at the GEOPRIV interim meeting and this document reflect the agreed
resolution.
Protocol Quality
This document was reviewed according to the PROTO process and
the write-up submitted by Andy Newton; it was reviewed for the IESG by Ted
Hardie.
RFC Editor Note
In Section 2.
OLD
A related document [18] describes a DHCPv4 [2] option for conveying
geospatial information to a device. This draft describes how DHCPv4
and DHCPv6 [6] can be used to convey the civic and postal address to
devices. Both geospatial and civic formats be used simultaneously,
increasing the chance to deliver accurate and timely location
information to emergency responders.
NEW
A related document [18] describes a DHCPv4 [2] option for conveying
geospatial information to a device. This draft describes how DHCPv4
and DHCPv6 [6] can be used to convey the civic and postal address to
devices. Both geospatial and civic formats be used simultaneously,
increasing the chance to deliver accurate and timely location
information to emergency responders. The reader should also be familiar
with the concepts in [14], as many of the protocol elements below are
designed to dovetail with PIDF-LO elements.
In Section 2
OLD:
After initial location information has been introduced, it MUST be
afforded the protections defined in RFC 3694 [12]. Therefore,
location information SHOULD NOT be sent from a DHCP client to a DHCP
server. If a client decides to send location information to the
server, it is implicitly granting that server unlimited retention and
distribution permissions.
NEW:
Further discussion of the protections which must be provided according
to RFC 3694 [12] are in the Security Considerations (Section 6).
In Section 3.4
OLD:
STS: STS designates a street suffix or type. In the United States
(US), the abbreviations recommended by the United States Postal
Service Publication 28 [20], Appendix C, SHOULD be used.
HNS: HNS ("house number") is a modifier to a street address; it does
not identify parts of a street address.
NEW:
STS: STS designates a street suffix or type. In the United States
(US), the abbreviations recommended by the United States Postal
Service Publication 28 [20], Appendix C, SHOULD be used.
OLD:
LMK: While a landmark (LMK, CAtype 21) can indicate a complex of
buildings, 'building' (CAtype 25) conveys the name of a single
building if the street address includes more than one building or
the building name is helpful in identifying the location.
NEW:
building: While a landmark (LMK, CAtype 21) can indicate a complex of
buildings, 'building' (CAtype 25) conveys the name of a single
building if the street address includes more than one building or
if the building name is helpful in identifying the location.
In Section 6
OLD:
To minimize the unintended exposure of location information, the
GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when
the DHCPv4 client has included this option in its 'parameter request
list' (RFC 2131 [2], Section 3.5). Similarly, the
OPTION_GEOCONF_CIVIC option SHOULD be returned by DHCPv6 servers only
when the DHCPv6 client has included this option in its OPTION_ORO.
NEW:
To minimize the unintended exposure of location information, the
GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when
the DHCPv4 client has included this option in its 'parameter request
list' (RFC 2131 [2], Section 3.5). Similarly, the
OPTION_GEOCONF_CIVIC option SHOULD be returned by DHCPv6 servers only
when the DHCPv6 client has included this option in its OPTION_ORO.
After initial location information has been introduced, it MUST be
afforded the protections defined in RFC 3694 [12]. Therefore,
location information SHOULD NOT be sent from a DHCP client to a DHCP
server. If a client decides to send location information to the
server, it is implicitly granting that server unlimited retention and
distribution permissions.
In Section 3.1
OLD
N: The length of this option is variable. The minimum length is 3.
NEW
N: The length of this option is variable. The minimum length is 3 octets.
In Section 3.2
OLD
option-len: Length of the Countrycode, 'what' and civic address
elements.
option-len: Length of the Countrycode, 'what' and civic address
elements in octets
In Section 7.
OLD
The initial list of registrations is contained in.
NEW
The initial list of registrations is contained in Section 3.4.
OLD :
This document calls for various operational decisions. For example,
an administrator has to decide when to provide the location of the
DHCP server or other network elements even if these may be a good
distance away from the client. The administrator must also consider
whether to include both civic and geospatial information if these may
differ. The document does not specify the criteria to be used in
making these choices, as these choices are likely to depend strongly
on local circumstances and need to be based on local, human
knowledge
NEW:
This document calls for various operational decisions. For example,
an administrator has to decide when to provide the location of the
DHCP server or other network elements even if these may be a good
distance away from the client. The administrator must also consider
whether to include both civic and geospatial information if these may
differ. The document does not specify the criteria to be used in
making these choices, as these choices are likely to depend strongly
on local circumstances and need to be based on local, human
knowledge
A system that works with location information configured by DHCP is
dependent that the administrators of the DHCP systems are careful
enough on a number of fronts, such as:
- if information about one location is provided in multiple
forms (e.g. in multiple languages), is it consistent?
- is the administrator certain that location information
is configured only to systems to which it applies (e.g.
not to systems topologically near, but geographically far)?
- if the location configured is not that of the target
but that of a 'nearby' network node or the DHCP server,
despite the recommendation against this practice in
in Section 3.1, is the administrator certain that this
configuration is geographically valid?
There are many other considerations in ensuring that location
information is handled safely and promptly for an emergency service in
particular. Those are in the province of the applications which make
use of the configured location information, and they are beyond the
scope of this document. DHCP configuration SHOULD NOT be used for
emergency services without guidelines on these considerations. Work on
these is under way in the IETF ECRIT working group at the time of
publication of this document.
OLD:
If a network provides civic location information via both DHCPv4 and
DHCPv6, the information conveyed by two protocols MUST be the same.
NEW:
In addition, if a network provides civic location information via both DHCPv4
and
DHCPv6, the information conveyed by two protocols MUST be the same.
Section 7
OLD:
This document establishes a new IANA registry for CAtypes designating
civic address components. According to RFC 2434 [17], this registry
operates under the "Specification Required" rules.
NEW:
This document establishes a new IANA registry for CAtypes
designating civic address components. Referring to RFC 2434 [17],
this registry operates under both "Expert Review" and
"Specification Required" rules. The IESG will appoint an Expert
Reviewer who will advise IANA promptly on each request for a new or
updated CAtype.
3.
Section 3.4 Civic Address Components
OLD:
Mappings and considerations for additional countries should be
written up in documents titled "Civic Addresses for [Country] (XY)",
where "XY" represents the two-letter country code, e.g., "Civic
Address Considerations for France (FR)".
NEW:
Mappings and considerations for additional countries may be
informally gathered from time to time by independent documents
which the IETF publishes which will have similar information to
the examples given here. These are non-normative, purely
descriptive, and do not purport to speak with authority for
a country, but rather are offered as an informational base
which may provide others with benefit. The use of a
country code to label a collection does not preclude its
reuse in a future collection.