Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information
obsoleted by
- rfc-4776 — Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information
Extracted elements (30)
The country code is given a fixed-format 2-octet field (ISO 3166) rather than a TLV element because civic addresses always contain country designations, and a fixed field saves space compared to a repeated TLV.
The DHCP mechanism is classified as a GEOPRIV 'sighting' function — it conveys initial location information and is not required to have security capabilities, but is only intended for trusted and controlled environments. It does not support client-to-server location updates due to security concerns.
The initial CA type set is derived from NENA standards and designed to accommodate addressing conventions for multiple countries. An IANA registry is established so that additional country-specific or future civic address fields can be defined without revising the RFC.
POD (trailing street suffix) and PRD (leading street direction) SHOULD use the abbreviations N, E, S, W, NE, NW, SE, SW in English-speaking countries. For STS in the US, abbreviations from USPS Publication 28 Appendix C SHOULD be used.
The PIDF column in the CA type table maps CA types to PIDF-LO element names (RFC 4119). Some CA types (e.g., CAtypes 35–39) were added after PIDF-LO was completed and currently have no PIDF-LO equivalent, requiring careful handling when converting between formats.
Abbreviations MUST NOT be used in civic address elements unless specifically indicated for that element. Abbreviations do not need a trailing period.
Component values MUST be encoded as UTF-8. They SHOULD be written in mixed case following customary spelling. The script indication (CAtype 128) MUST be written in mixed case with the first letter capitalized.
DHCP configuration SHOULD NOT be used for emergency services without guidelines on operational considerations such as consistency, correct geographic assignment, and proximity validity.
For each script and language, elements SHOULD be included in numeric order from lowest to highest CAtype value.
If a network provides civic location information via both DHCPv4 and DHCPv6, the information conveyed by both 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.
The DHCP server SHOULD provide all common language/script renderings of the civic address 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 (RFC 3396) MUST be used if the civic address option exceeds the maximum DHCPv4 option size of 255 octets.
The 'what' field value of 2 (location of the client) SHOULD be used. Values 0 (DHCP server) and 1 (nearest network element) SHOULD NOT be used unless it is known that the client is in close physical proximity to that device.
Administrative hierarchy CAtypes 1–6 represent national subdivisions (A1=state/province, A2=county, A3=city, A4=city district/borough, A5=neighborhood/block, A6=group of streets below neighborhood). All elements are OPTIONAL and may appear in any order.
Building/interior CAtypes include: 21 (LMK, landmark/vanity address), 22 (LOC, additional location info), 23 (NAM, occupant name), 24 (ZIP, postal/zip code), 25 (building), 26 (unit/apartment), 27 (FLR, floor), 28 (room), 29 (type of place), 33 (SEAT, seat/workstation).
CAtype 0 is the language tag (default 'i-default'), CAtype 128 is the script tag (default 'Latn'). These elements control the language and script interpretation of all subsequent CA elements until overridden.
CAtype 30 (PCN, postal community name) and CAtype 31 (post office box) allow construction of a postal address. If a P.O. Box is present, street address components (CAtypes 34, PRD, POD, STS, HNO, HNS) are replaced with the P.O. Box element when constructing a postal address.
CAtype 32 ('additional code') provides a country-specific additional location code, e.g., the Japan Industry Standard (JIS) address code for Japan. CAtype 255 is reserved.
Street-level CAtypes include: 16 (PRD, leading street direction), 17 (POD, trailing street suffix), 18 (STS, street suffix/type), 19 (HNO, house number), 20 (HNS, house number suffix), 34 (primary road name), 35 (road section), 36 (branch road name), 37 (sub-branch road name), 38 (street name pre-modifier), 39 (street name post-modifier).
The DHCPv4 GEOCONF_CIVIC option (code 99) carries civic location information. It begins with a 1-octet option code (99), 1-octet length N (minimum 3), a 1-octet 'what' field, a 2-octet ISO 3166 country code, followed by variable-length civic address elements.
The DHCPv6 OPTION_GEOCONF_CIVIC option (code 37) carries civic location information with a 2-octet option code, 2-octet option-len, 1-octet 'what', 2-octet country code, and variable-length civic address elements.
IANA registered DHCPv4 option code 99 (GEOCONF_CIVIC) and DHCPv6 option code 37 (OPTION_GEOCONF_CIVIC) for the civic address location option.
This document establishes an IANA registry for CAtypes (civic address component type codes). Registration requires Expert Review and Specification Required. Each entry must include: numeric CAtype, brief description, reference to published specification, and optionally country-specific considerations.
After initial location information has been introduced via DHCP, it MUST be afforded the protections defined in RFC 3694. Location information SHOULD NOT be sent from a DHCP client to a DHCP server, as doing so implicitly grants unlimited retention and distribution permissions.
There is no privacy protection for DHCP messages; an eavesdropper monitoring the link between the DHCP server and client can discover civic location information. Usage of this option on networks without access restrictions or link/network-layer privacy mechanisms is NOT RECOMMENDED.
To minimize unintended exposure of location information, GEOCONF_CIVIC SHOULD be returned by DHCPv4/v6 servers only when the client has explicitly requested it via the parameter request list or OPTION_ORO.
Where critical decisions may be based on the GEOCONF_CIVIC option value, DHCPv4 authentication (RFC 3118) SHOULD be used to protect the integrity of DHCP options.
Each civic address element (CA element) is encoded as a TLV: 1-octet CAtype, 1-octet CAlength (length of CAvalue in octets, not including CAlength itself), followed by a variable-length CAvalue.
The DHCPv4 GEOCONF_CIVIC option wire format: 1-octet code (99), 1-octet length N, 1-octet 'what' (0=server, 1=nearest network element, 2=client), 2-octet ASCII country code, followed by zero or more TLV civic address elements.