RFC 4676
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information
RFC 4676: Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information 📍💖
- Network Working Group 🌐
- Request for Comments: 4676
- Author: H. Schulzrinne, Columbia U. 🎓
- Category: Standards Track 🦋
- Date: October 2006 🗓️
- Obsoletes and updates: the title block doesn't list anything this one obsoletes or updates ✨
Status of This Memo 📜
Okay bestie, this one is an Internet standards track protocol for the whole Internet community 🌍. The author is also asking everyone to talk about it and send suggestions for making it better 💬. If you want the official standardization state and status, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. And distribution of this memo is unlimited, so share it with whoever you want 🫶.
Copyright Notice ©️
Copyright (C) The Internet Society (2006). 🌸
Abstract 🌸
So this document specifies a DHCP option for both DHCPv4 and DHCPv6 🎀. The option carries the civic location of either the client or the DHCP server 📮. The Location Configuration Information (LCI) is the juicy part: it covers the country, administrative units like states, provinces, and cities 🏙️, plus street addresses, postal community names, and building information 🏢. And here's the iconic bit: the option lets you have several renditions of the same address in different scripts and languages 🌏✨.
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 .............................................6
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 ..................................................171. Introduction ✨
Okay so, lots of end system services can level up when they know roughly where the device is 📍. IP telephony devices are the big ones here, because they need their location to reach the right emergency response agency 🚨 and so emergency responders can actually find them 🙏. Main character energy, but make it safety 😭.
There are two common ways to pin down where something is: geospatial coordinates or civic addresses 🗺️. Geospatial coordinates give you longitude, latitude, and altitude 🛰️. Civic addresses give you a street address 🏡.
Civic addresses are usually, but not always, closely tied to the postal address that the local postal service uses to deliver mail 📬. Not every postal address is a street address though 🙈. Like, the author's own address isn't on any street or building sign at all 💀. And obviously PO boxes are a no-go for this stuff 🙅♀️. People also sometimes call a civic address a 'civil address' or 'jurisdictional address' 🎀. This document mainly supports civic addresses, but it lets you include the postal community name too, in case that's different from the civic name 💅.
A related document [15] describes a DHCPv4 [2] option for sending geospatial information to a device 🛰️. This document is the civic and postal version, showing how DHCPv4 and DHCPv6 [6] can carry that address info to devices 🏘️. You can use geospatial and civic formats at the same time, which boosts the chance that emergency responders get accurate, timely location info 🚑✨. And the reader should also know the concepts in [11], because a bunch of the protocol elements here were designed to dovetail with PIDF-LO elements 🧩.
This document only covers delivering location info from the DHCP server to the client 📤. The reason is security: using DHCP to update the database is a whole can of worms 🪱. Within the GEOPRIV architecture from RFC 3693 [9], the mechanism here for sending the initial location info is called a "sighting" function 👀. Sighting functions don't have to have security capabilities, and they're only meant to be set up in trusted, controlled environments 🔒. (The classic example of a sighting function is a Global Positioning System wired straight into a network node 🛰️.) For the protections that have to be provided according to RFC 3694 [10], check out the Security Considerations (Section 6) 🛡️.
End systems that get location info through this mechanism then use other protocol mechanisms to send it to an emergency call center or to share it as part of presence information 📞.
Civic info is so useful because it often gives extra, human-readable details, especially inside buildings 🏢. It's also way easier to get for most occupied structures than geospatial info, and you can often still make sense of it even when it's incomplete 🧩. For example, big university or corporate campuses often don't have geocoding down to building and room level readily available 🏫.
Here's the tea ☕: unlike geospatial info, the format for civic and postal info is different from country to country 🌍. The first set of data fields comes from standards published by the United States National Emergency Number Association (NENA) [18], and it takes into account addressing conventions for a bunch of countries across different regions 🗾. Other countries can reuse many of the data elements 🔁, but this document also sets up an IANA registry so people can define extra civic location data fields 📋.
The same civic and postal address can often be shown in multiple languages and scripts 🈶. Korean addresses, for example, are often written in Hangul, Latin, and Kanji 🇰🇷. Some older cities also have multiple language variants, like Munich, Muenchen, and Monaco 🏰. DHCPv4 and DHCPv6 don't currently have a way to ask for a specific script or language 🙃. So the DHCP server SHOULD provide all common renderings to the client 📝, and it MUST provide at least the rendering in the language and script that's right for the location 🫶. For presence info, the target might be visiting from a foreign country and want to share the info in a format their home-country watchers understand ✈️. For emergency services, the local-language rendering is probably the most useful 🚨. To provide multiple renderings, the server repeats sequences of address elements, and each one gets a 'language' and/or 'script' element in front of it (see Section 3.3) 🧾. The language and script stay in effect for the following elements until another language or script element overrides them 🔄. The DHCP client is unlikely to be the final consumer of the location info 📱, so the DHCP server has to provide all the appropriate language and script versions, which the client then passes along through some other GEOPRIV using protocol 📨. That's typically encoded in a presence-based GEOPRIV location object format [16] 🎁.
The DHCP server MAY provide location info for multiple locations related to the target 🧭. For example, you could get both the network element and the network jack itself 🔌. That's likely to help with debugging network problems 🐛.
This document leaves a bunch of operational decisions up to you 🧠. For example, an administrator has to decide when to provide the location of the DHCP server or other network elements, even if those might be pretty far from the client 🗺️. The administrator also has to think about whether to include both civic and geospatial info if they might differ ⚖️. The document doesn't spell out the criteria for these choices 🤷♀️. That's because they depend heavily on local circumstances and need local, human knowledge 🧑🤝🧑.
A system that works with location info configured by DHCP depends on the DHCP admins being careful about a few things 🧐, like:
- 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 Section 3.1, is the administrator certain that this configuration is geographically valid?
There are tons of other things to think about so location info is handled safely and quickly for an emergency service in particular 🚨. Those belong to the applications that use the configured location info, and they're outside the scope of this document 📱. DHCP configuration SHOULD NOT be used for emergency services without guidelines covering these things 🛑. Work on those guidelines was underway in the IETF ECRIT working group when this document was published 🛠️.
Also, if a network gives civic location info through both DHCPv4 and DHCPv6, the info carried by the two protocols MUST be the same 👯♀️. No mismatches, periodt 💅.
As discussed in the Security Considerations (Section 6), 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 🎟️.
The DHCPv4 long-options mechanism described in RFC 3396 [8] MUST be used if the civic address option is bigger than the maximum DHCPv4 option size of 255 octets 📏. Big address? Big energy, big mechanism 🧚.
2. Terminology 🎀
Okay, so in this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in RFC 2119 [1] 📖. They tell you the requirement levels for compliant implementations 💜. Read those carefully, they're the rules of the game 🎮.
3. Format of the DHCP Civic Location Option 🦋
3.1. Overall Format for DHCPv4 📡
okay bestie, let's look at the DHCPv4 layout first 💖 Here's the whole thing:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GEOCONF_CIVIC | N | what | country |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| code | civic address elements ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The option code for GEOCONF_CIVIC is 99 🎀
The N field is the length of the option, and it's variable ✨ The minimum length is 3 octets.
The what field says which location the DHCP entry is about 🗺️ There are three options right now:
0means the location of the DHCP server.1means the location of the network element that's believed to be closest to the client.2means the location of the client.
Option (2) SHOULD be used 💅 but it might not be known. Options (0) and (1) SHOULD NOT be used unless it's known that the DHCP client is in close physical proximity to the server or network element. Literally the logic is so clean 😭
The country code is the two-letter ISO 3166 country code in capital ASCII letters, like DE or US 🌍 Civic addresses always include a country, so this is a fixed-format field, which saves space. Iconic 🧚
The civic address elements are zero or more elements that make up the civic and/or postal address. The format is described below (Section 3.3) 🦋
3.2. Overall Format for DHCPv6 🌸
The DHCPv6 [6] civic address option is about the client as a whole, not one specific place 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_GEOCONF_CIVIC | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| what | country code | .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. civic address elements .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The option-code is OPTION_GEOCONF_CIVIC, which is 37 ✨
The option-len is the length of the country code, what, and civic address elements, in octets 🧮
what, country code, and civic address elements work the same way they do above (Section 3.1) 🫶
3.3. Element Format 🧩
For both DHCPv4 and DHCPv6, every civic address element looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CAtype | CAlength | CAvalue ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+CAtype is a one-octet descriptor of the data in the civic address value 💅
CAlength is the length of the CAvalue, in octets. It doesn't include the CAlength field itself 🙈
CAvalue is the civic address value, which gets described in detail below 🎀
3.4. Civic Address Components 🗺️✨
Every country has different administrative hierarchies, and they often use the same (English) names, so this spec uses one simple hierarchical notation that gets filled in for each country 💖 We assume that five levels are enough for sub-national divisions above the street level.
All elements are OPTIONAL and can show up in any order 🦋
Component values MUST be encoded as UTF-8 [7]. They SHOULD be written in mixed case, following the customary spelling. The script indication (CAtype 128) MUST be written in mixed case, with the first letter a capital letter 👑
Abbreviations MUST NOT be used unless they're indicated for each element. Abbreviations don't need a trailing period 🙅♀️
It is RECOMMENDED that all elements in a particular script (CAtype 128) and language (CAtype 0) get grouped together, because that means fewer script and language identifiers are needed 🧚
For each script and language, elements SHOULD be included in numeric order, from lowest to highest of their CAtype. In general, an element is labeled in its language and script by the most recent 'language tag' (CAtype ) element before it. Not all elements depend on the script and language, so a client collects the elements by CAtype and then picks the most desirable language and script rendition when there are multiple elements for the same CAtype 🌈
+--------+-------+--------------------------------------------------+
| CAtype | label | description |
+--------+-------+--------------------------------------------------+
| 1 | A1 | national subdivisions (state, canton, region, |
| | | province, prefecture) |
| | | |
| 2 | A2 | county, parish, gun (JP), district (IN) |
| | | |
| 3 | A3 | city, township, shi (JP) |
| | | |
| 4 | A4 | city division, borough, city district, ward, |
| | | chou (JP) |
| | | |
| 5 | A5 | neighborhood, block |
| | | |
| 6 | A6 | group of streets below the neighborhood level |
+--------+-------+--------------------------------------------------+
Table 1For specific countries, the administrative sub-divisions are described below 🌏
CA (Canada): The mapping to NENA designations is shown in parentheses. A1 designates the province (STA), A2 the county (CNA), and A3 the city, town, or MSAG community name (MCN) 🍁
DE (Germany): A1 represents the state (Bundesstaat), A2 the county (Regierungsbezirk), A3 the city (Stadt, Gemeinde), and A4 the district (Bezirk). Street suffixes (STS) are only used for designations that are a separate word (e.g., Marienthaler Strasse) 🥨
JP (Japan): A1 represents the metropolis (To, Fu) or prefecture (Ken, Do), A2 the city (Shi) or rural area (Gun), A3 the ward (Ku) or village (Mura), A4 the town (Chou or Machi), A5 the city district (Choume), and A6 the block (Banchi or Ban) 🍣
KR (Korea): A1 represents the province (Do), A2 the county (gun), A3 the city or village (ri), A4 the urban district (gu), and A5 the neighborhood (dong) 🇰🇷
US (United States): The mapping to NENA designations is shown in parentheses. A1 designates the state (STA), using the two-letter state and possession abbreviations recommended by the United States Postal Service Publication 28 [17], Appendix B. A2 designates the county, parish (Louisiana), or borough (Alaska) (CNA). A3 designates the civic community name, e.g., city or town. It's also known as the municipal jurisdiction or MSAG community name (MCN). The civic community name (A3) reflects the political boundaries, which may differ from postal delivery assignments, the postal community name (PCN), for historical or practical reasons. The optional element A4 contains the community place name, such as "New Hope Community" or "Urbanizacion" in Puerto Rico 🇺🇸
Mappings and considerations from additional countries may be informally gathered from time to time in independent documents published by the IETF. These should be titled "Civic Address Considerations for [Country]" and should contain similar information to the examples given here. As published by the IETF, they will be non-normative and purely descriptive, like the examples here, and will not purport to speak with authority for any country, but rather be offered for information. If authors choose to label the document with a country code, this does not preclude its use for labeling a future coexisting document 📚
Additional CA types appear in many countries and are simply omitted where they are not needed or known:
Okay so bestie, this is the whole civic address menu 🗺️✨ The big table comes first, and then I'll break down what each piece means 💅
+--------+------+------+---------------------------+----------------+
| CAtype | NENA | PIDF | Description | Examples |
+--------+------+------+---------------------------+----------------+
| 0 | | | language | i-default [3] |
| | | | | |
| 16 | PRD | PRD | leading street direction | N |
| | | | | |
| 17 | POD | POD | trailing street suffix | SW |
| | | | | |
| 18 | STS | STS | street suffix or type | Ave, Platz |
| | | | | |
| 19 | HNO | HNO | house number | 123 |
| | | | | |
| 20 | HNS | HNS | house number suffix | A, 1/2 |
| | | | | |
| 21 | LMK | LMK | landmark or vanity | Columbia |
| | | | address | University |
| | | | | |
| 22 | LOC | LOC | additional location | South Wing |
| | | | information | |
| | | | | |
| 23 | NAM | NAM | name (residence and | Joe's |
| | | | office occupant) | Barbershop |
| 24 | ZIP | PC | postal/zip code | 10027-1234 |
| | | | | |
| 25 | | | building (structure) | Low Library |
| | | | | |
| 26 | | | unit (apartment, suite) | Apt 42 |
| | | | | |
| 27 | | FLR | floor | 4 |
| | | | | |
| 28 | | | room | 450F |
| | | | | |
| 29 | | | type of place | office |
| | | | | |
| 30 | PCN | | postal community name | Leonia |
| | | | | |
| 31 | | | post office box (P.O. | 12345 |
| | | | Box) | |
| | | | | |
| 32 | | | additional code | 13203000003 |
| | | | | |
| 33 | | SEAT | seat (desk, cubicle, | WS 181 |
| | | | workstation) | |
| | | | | |
| 34 | | | primary road name | Broadway |
+--------+------+------+---------------------------+----------------+
+--------+------+------+---------------------------+----------------+
| CAtype | NENA | PIDF | Description | Examples |
+--------+------+------+---------------------------+----------------+
| 35 | | | road section | 14 |
| | | | | |
| 36 | | | branch road name | Lane 7 |
| | | | | |
| 37 | | | sub-branch road name | Alley 8 |
| | | | | |
| 38 | | | street name pre-modifier | Old |
| | | | | |
| 39 | | | street name post-modifier | Service |
| | | | | |
| 128 | | | script | Latn |
| | | | | |
| 255 | | | reserved | |
+--------+------+------+---------------------------+----------------+The CA types in the NENA column line up with items from the NENA "Recommended Formats and Protocols For ALI Data Exchange, ALI Response and GIS Mapping" [18], but they work for most countries 🌍 The NENA column points at the data dictionary name in Exhibit 18 of [18].
The PIDF column gives the element name from [16]. (Some elements got added after the PIDF location object definition was already finished, so those don't have a PIDF-LO equivalent yet 🙈)
Language: The "language" item (CAtype 0) is optional and says which language the address is presented in, pulling tags from [4], as discussed in [13]. If you leave it out, the default is "i-default" [3] 🌸
Script: The "script" item (CAtype 128) is optional and says which script the address is presented in, using tags from [12] and expanded on in Section 2.2.3 of [13]. If it's left out, it defaults to "Latn" ✨
POD, PRD: The abbreviations N, E, S, W, and NE, NW, SE, SW SHOULD be used for POD (trailing street suffix) and PRD (leading street direction) in English-speaking countries 🧭
STS: STS is the street suffix or type. In the United States (US), the abbreviations from the United States Postal Service Publication 28 [17], Appendix C, SHOULD be used 🇺🇸
HNS: HNS ("house number suffix") modifies a street address. It doesn't identify any part of the street address on its own 🔢
building: A landmark (LMK, CAtype 21) can point to a whole complex of buildings, but 'building' (CAtype 25) gives the name of one single building if the street address has more than one building, or if the building name is helpful in identifying the location 🏢
LOC: LOC ("location", CAtype 22) is an unstructured string with extra info about the location, like which part of a building you're in or other unstructured details 📍
PCN: The postal community name (CAtype 30) and the post office box (CAtype 31) let the recipient construct a postal address 📬 The post office box field should contain the words "P.O. Box" or other locally appropriate postal designation.
NAM: The NAM object helps with user location ("Joe Miller", "Alice's Dry Cleaning") 💇♀️ It doesn't identify the person using a communications device. It identifies the person or organization associated with the address.
LMK: A landmark (LMK, CAtype 21) can indicate a complex of buildings, while '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. (Like on university campuses, where the house number often isn't shown on buildings but the building name is printed right there, so it's the thing people actually look for 🎓)
Unit: The "unit" object (CAtype 26) holds the name or number of a part of a structure with separate administrative units, owners, or tenants, like separate companies or families living in the same building. Common examples are suite or apartment designations 🚪
Room: A "room" (CAtype 28) is the smallest identifiable subdivision of a structure 🛋️
Type of place: The "type of place" item (CAtype 29) describes the kind of place the civic coordinates point to, like whether it's a home, office, street, or other public space 🏡 The values come from the items in the location types registry [11]. This makes it easy for the DHCP client to fill in the presence information. Since this is an IANA-registered token, the language and script designations don't apply to this element.
Additional code: The "additional code" item (CAtype 32) gives an extra, country-specific code for the location. For example, in Japan it holds the Japan Industry Standard (JIS) address code, which pins down a unique address inside Japan, all the way to the floor of the building 🇯🇵
SEAT: The "seat" item (CAtype 33) marks a place where a person might sit, like a seat in a stadium or theater, a cubicle in an open-plan office, or a booth at a trade show 💺
Primary road name: The "primary road" item (CAtype 34) is the road or street name tied to the address. If CAtypes 35 through 37 aren't specified, the building or designated location is found on that street. If some of CAtypes 35 through 37 are specified, that means the main road is the one the smaller streets branch off from, and it's where the structure or building is actually located 🛣️
Road section: The "road section" item (CAtype 35) designates a specific section or stretch of a primary road. This is a new thoroughfare element, and it's super useful where a primary road is split into sections that reuse the same street number ranges 🔁
Branch road name: The "branch road name" item (CAtype 36) is the name or identifier of a road or street that intersects with or is associated with a primary road. It's only used in countries where side streets don't have unique names within a municipality or other administrative unit, and instead have to be qualified by the name of the primary road they branch off of 🌿
Sub-Branch road name: The "sub-branch road name" (CAtype 37) item is the name of a street that branches off a branch road (CAtype 36). It's only used in countries where those streets are named relative to the primary road name and the branch road they connect with 🌱
Street name pre-modifier: The "street name pre-modifier" (CAtype 38) is an optional part of the complete street name. It's a word or phrase that comes before all the other parts of the street name and modifies it, but it's separated from the street name by a street name pre-directional. An example is "Old" in "Old North First Street" 🪄
Street name post-modifier: The "street name post-modifier" (CAtype 39) is an optional part of the complete street name. It's a word or phrase that comes after all the other parts of the street name and modifies it, but it's separated from the street name by a street name post-directional and/or street suffix. An example is "Extended" in "East End Avenue Extended" 🦋
4. Postal Addresses 📬✨
Okay so, a recipient can usually build a postal address from every language-appropriate element, and that includes the postal code (ZIP, CAtype 24) 💌. But a few elements get to overrule the civic address components when it's time to make a postal address 👑. If a post office box (CAtype 31) is included, the street address parts (CAtype 34, PRD, POD, STS, HNO, HNS) get swapped out for the PO box element 📮. If a postal community name is given, the civic community name (typically, A3) gets replaced by the postal community name (PCN, CAtype 30) 🏘️. Formatting these addresses properly takes country-specific knowledge, and that's beyond the scope of this document 🙈.
5. Example 🗼
Instead of showing the exact byte layout of a DHCP option, we're going to look at a symbolic example 🥨. It's the civic address of the Munich city hall in Bavaria, Germany 🇩🇪. The city and state names are also given in English and Italian, along with German. The other items are assumed to be the same in every language, and every language uses the latin script 🌸.
+--------+---------------------+
| CAtype | CAvalue |
+--------+---------------------+
| 0 | de |
| | |
| 128 | Latn |
| | |
| 1 | Bayern |
| | |
| 2 | Oberbayern |
| | |
| 3 | M=U+00FCnchen |
| | |
| 6 | Marienplatz |
| | |
| 19 | 8 |
| | |
| 21 | Rathaus |
| | |
| 24 | 80331 |
| | |
| 29 | government-building |
| | |
| 31 | Postfach 1000 |
| | |
| 0 | en |
| | |
| 1 | Bavaria |
| | |
| 3 | Munich |
| | |
| 0 | it |
| | |
| 1 | Baviera |
| | |
| 3 | Monaco |
+--------+---------------------+6. Security Considerations 🔐😭
Okay, this part is seriously important, bestie, so read it carefully 🫶. All the security considerations from the GEOPRIV architecture in RFC 3693 [9] apply here too 💜.
If critical decisions might depend on the value of this GEOCONF_CIVIC option, then DHCPv4 authentication in RFC 3118 [5] SHOULD be used to protect the integrity of the DHCP options 🛡️.
DHCP messages have no privacy protection at all 💀. So an eavesdropper who can watch the link between the DHCP server and the requesting client can find out what this option contains. That means using this option on networks without access restrictions, or without network-layer or link-layer privacy mechanisms, is NOT RECOMMENDED 🚫.
To keep location information from leaking by accident, DHCPv4 servers SHOULD return the GEOCONF_CIVIC option only when the DHCPv4 client has included it in its 'parameter request list' (RFC 2131 [2], Section 3.5) 🎀. In the same way, DHCPv6 servers SHOULD return the OPTION_GEOCONF_CIVIC option only when the DHCPv6 client has included it in its OPTION_ORO 🦋.
Once location information has been introduced, it MUST be given the protections defined in RFC 3694 [10] 👑. That's why location information SHOULD NOT be sent from a DHCP client to a DHCP server 🙅♀️. If a client does decide to send location information to the server, it's implicitly giving that server unlimited retention and distribution permissions 🥹.
Sending location data to a server is basically handing over a blank cheque for how long it's kept and who gets it. Think very hard before you do it 💅.
7. IANA Considerations 🧚
IANA has registered new DHCPv4 and DHCPv6 option codes for the Civic Address, GEOCONF_CIVIC and OPTION_GEOCONF_CIVIC respectively 🌈.
This document sets up a brand-new IANA registry for CAtypes, which name civic address components 🗂️. Following RFC 2434 [14], this registry runs 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 🫡.
Each registration uses this template:
CAtype: Numeric identifier, assigned by IANA.
Brief description: Short description identifying the meaning of the
element.
Reference to published specification: A stable reference to an RFC
or other permanent and readily available reference, in sufficient
detail so that interoperability between independent
implementations is possible.
Country-specific considerations: If applicable, notes whether the
element is only applicable or defined for certain countries.The initial list of registrations is in Section 3.4 ✨.
Updates to country-specific considerations for CAtypes that are already defined don't go through IANA registrations, since they're purely descriptive and don't register identifiers 🌸. As mentioned earlier, country-specific conventions may optionally be written up in documents titled "Civic Addresses for [Country]" 📄.
8. References 📚
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. (the bible of the BCP 14 key words, bestie 📖)
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[3] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[4] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[8] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[10] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[11] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", RFC 4589, July 2006.
[12] International Organization for Standardization, ISO., "ISO 15924:2004. Information and documentation - Codes for the representation of names of scripts", January 2004.
8.2. Informative References
[13] Phillips, A. and M. Davis, "Tags for Identifying Languages", Work in Progress, October 2005.
[14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[15] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.
[16] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[17] United States Postal Service, "Postal Addressing Standards", November 2000.
[18] National Emergency Number Assocation, "NENA Recommended Formats and Protocols For ALI Data Exchange, ALI Response and GIS Mapping", NENA NENA-02-010, January 2002.
Acknowledgements 🫶🌷
Big thank-yous to Harald Alvestrand, Stefan Berger, Peter Blatherwick, Joel M. Halpern, David Kessens, Cheng-Hong Li, Rohan Mahy, James Polk, Martin Thomson and Hannes Tschofenig for their helpful comments 💖. Examples and inspiration came from the Street Address Data Standard of the Federal Geographic Data Committee 🗺️.
Author's Address 🖊️
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
EMail: hgs+geopriv@cs.columbia.edu
URI: http://www.cs.columbia.eduFull Copyright Statement ©️
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🧾
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify any such rights. Information on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use such proprietary rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Please send that information to the IETF at ietf-ipr@ietf.org 📬.
Acknowledgement 💜
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) 🌈✨
📦 where this page comes from
- ietf: rfc4676 2006-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms