Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information
obsoletes
- rfc-4676 — Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information
updated by
Extracted elements (28)
Multiple renderings of the same address in different languages and scripts are supported by repeating sequences of address elements prefixed with language (CAtype 0) and/or script (CAtype 128) elements, because DHCPv4/v6 lack a mechanism for the client to request a specific language or script.
The CAtype namespace is extensible via IANA registry rather than being fixed, because civic address conventions differ substantially by country, and the initial set derived from NENA standards was not expected to cover all global addressing needs.
The country code is encoded as a fixed-format two-octet field rather than a TLV element because civic addresses always contain a country designation, and the fixed format saves space compared to repeating a CAtype/CAlength header for a universally present field.
The DHCP server may provide location information for multiple locations (e.g., both network element and network jack), expressed via multiple 'what' field values, because knowing the location of infrastructure elements (not just the client) aids network debugging.
The option delivers location only from DHCP server to client (not the reverse) because of security concerns related to using DHCP to update a location database. The GEOPRIV architecture classifies this as a 'sighting function', which requires no security capabilities and is only for trusted environments.
RFC 4776 obsoletes RFC 4676 to correct an error in the assignment of the numeric value of the DHCPv6 option-code for the civic location option. Implementations of RFC 4676 that used the erroneous code must be updated to use option code 36.
After initial location information has been introduced, it MUST be afforded the protections defined in RFC 3694. Location information SHOULD NOT be sent from a DHCP client to a DHCP server; a client that does so implicitly grants the server unlimited retention and distribution permissions.
All civic address component values MUST be encoded as UTF-8. They SHOULD be written in mixed case following customary spelling. Abbreviations MUST NOT be used unless explicitly indicated for each element.
DHCP configuration SHOULD NOT be used for emergency services without guidelines on operational considerations such as consistency of multi-language renderings, geographic applicability, and proximity assumptions.
If a network provides civic location information via both DHCPv4 and DHCPv6, the information conveyed by the two protocols MUST be the same.
It is RECOMMENDED that all elements in a particular script (CAtype 128) and language (CAtype 0) be grouped together to reduce the number of script and language identifiers needed. Elements SHOULD be included in numeric order by CAtype within each script/language group.
Since DHCPv4 and DHCPv6 do not support querying for a specific script or language, the DHCP server SHOULD provide all common renderings to the client and MUST provide at least the rendering in the language and script appropriate to the indicated location.
The DHCPv4 long-options mechanism described in RFC 3396 MUST be used if the civic address option exceeds the maximum DHCPv4 option size of 255 octets.
The GEOCONF_CIVIC option SHOULD be returned by DHCPv4 servers only when the DHCPv4 client has included this option in its 'parameter request list'. Similarly, OPTION_GEOCONF_CIVIC SHOULD be returned by DHCPv6 servers only when included in the client's OPTION_ORO.
Additional CA types (16–39, 128, 255) cover street addressing and building details: PRD (16, leading direction), POD (17, trailing suffix), STS (18, street type), HNO (19, house number), HNS (20, house number suffix), LMK (21, landmark), LOC (22, additional location), NAM (23, name), ZIP/PC (24, postal code), building (25), unit (26), floor (27), room (28), type of place (29), PCN (30, postal community name), P.O. Box (31), additional code (32), SEAT (33), primary road (34), road section (35), branch road (36), sub-branch road (37), pre-modifier (38), post-modifier (39), script (128), reserved (255).
CAtype 0 (language) identifies the language for address elements, drawing from RFC 3066 language tags; default is 'i-default'. CAtype 128 (script) identifies the script using ISO 15924 codes; default is 'Latn'. Language and script remain in effect for subsequent elements until overridden.
Civic Address (CA) types 1–6 represent a five-level administrative hierarchy: A1=national subdivision (state/province), A2=county/parish, A3=city/township, A4=city division/borough/ward, A5=neighborhood/block, A6=group of streets. Country-specific instantiations are provided for CA, DE, JP, KR, and US.
The country code field is a two-letter ISO 3166 country code in capital ASCII letters (e.g., DE or US), encoded as a fixed-format field. Civic addresses always contain country designations, motivating use of a fixed field to save space.
The DHCPv4 civic location option is identified by option code 99 (GEOCONF_CIVIC). Its format includes a one-octet option code, one-octet length N (minimum 3), a one-octet 'what' field, a two-octet ISO 3166 country code, and zero or more civic address elements.
The DHCPv6 civic location option is identified by option code 36 (OPTION_GEOCONF_CIVIC). Its format includes a two-octet option-code, two-octet option-len, one-octet 'what' field, two-octet country code, and zero or more civic address elements.
The 'what' field specifies the entity whose location is being described: value 0 = DHCP server location, value 1 = network element closest to client, value 2 = client location. Value 2 SHOULD be used; values 0 and 1 SHOULD NOT be used unless the client is known to be in close physical proximity.
IANA registered DHCPv4 option code 99 (GEOCONF_CIVIC) and DHCPv6 option code 36 (OPTION_GEOCONF_CIVIC) for the civic address options. This document corrects an error in RFC 4676, which had assigned an incorrect numeric value to the DHCPv6 option-code.
This document establishes a new IANA registry for CAtypes (civic address component type identifiers), operating under 'Expert Review' and 'Specification Required' rules per RFC 2434. Each registration requires a numeric identifier, brief description, stable specification reference, and any country-specific considerations.
DHCP messages have no privacy protection; an eavesdropper monitoring the link between server and client can discover location information. Usage of this option on networks without access restrictions or without network-layer or link-layer privacy mechanisms is NOT RECOMMENDED.
The mechanism defined here is a GEOPRIV 'sighting function' (RFC 3693): it conveys location only from server to client, not in the reverse direction, due to security concerns about using DHCP to update location databases. Sighting functions are intended only for trusted, controlled environments.
Where critical decisions might be based on the GEOCONF_CIVIC option value (e.g., emergency services), DHCPv4 authentication per RFC 3118 SHOULD be used to protect the integrity of DHCP options against tampering.
Each civic address element uses a TLV encoding: CAtype (1 octet, descriptor of the civic address component), CAlength (1 octet, length of CAvalue not including itself), and CAvalue (variable, the civic address value in UTF-8).
The DHCPv4 GEOCONF_CIVIC option wire format is: option code 99 (1 octet), length N (1 octet, minimum 3), 'what' (1 octet), country code (2 octets ASCII), followed by civic address elements. The DHCPv6 OPTION_GEOCONF_CIVIC uses a 2-octet option-code of 36 and 2-octet option-len.