RFC 4776
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information
Network Working Group RFC 4776 ✨
Okay bestie, this one is the RFC for stuffing a civic street address into DHCP 💖 It was written by H. Schulzrinne of Columbia U. 🎀 and published in November 2006 🌸. It's a Standards Track doc 👑, and it obsoletes RFC 4676 💅 because the DHCPv6 option-code number got assigned wrong over there 🙈. This one fixes it.
The title is Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information 🦋.
Status of This Memo
This doc specifies an Internet standards track protocol for the Internet community, and it wants discussion and suggestions for improvements 🫶. For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.
Copyright Notice
Copyright (C) The IETF Trust (2006). 💜
RFC Editor Note
RFC 4776 is out to fix a mistake: the DHCPv6 option-code number in RFC 4676 (Section 3.2) was assigned incorrectly 😭. This document obsoletes RFC 4676 💀.
Abstract
This doc defines a DHCP option (for both DHCPv4 and DHCPv6) that carries the civic location of the client or the DHCP server 🗺️✨. The Location Configuration Information (LCI) can include the country, admin units like states, provinces and cities, street addresses, postal community names, and building info 🏙️. The option also lets you have several versions 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 .............................................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 ..................................................171. Introduction 🧚
Lots of end system services can use knowing roughly where the device is 📍. IP phones especially need to know their location so they can reach the right emergency response agency and so responders can find them 🚨.
There are two common ways to pin down where something is: geospatial coordinates (longitude, latitude, and altitude) or civic addresses (a street address) 🌎.
A civic address is often, but not always, the same as the postal address the local post office uses to deliver mail 📬. Not every postal address maps to a street address though. The author's own mailing address, for example, doesn't show up on any street or building sign 😂. PO boxes are a no-go for this stuff 🙅♀️. You might also hear "civil address" or "jurisdictional address" for the same idea 🎀. This doc mainly supports civic addresses, but it does let you add a postal community name when it's different from the civic name 💖.
There's a related doc [15] that describes a DHCPv4 [2] option for sending geospatial info to a device 🛰️. This doc explains how DHCPv4 and DHCPv6 [6] can carry civic and postal addresses to devices 📮. You can use geospatial and civic info together, which gives emergency responders a better shot at accurate, timely location info 🚑✨. Also, the reader should know the ideas in [11], because lots of the protocol elements here are built to line up with PIDF-LO elements 🤓.
This doc only covers delivering location info from the DHCP server to the client, because using DHCP to update the database raises security concerns 🔒. In the GEOPRIV architecture from RFC 3693 [9], the mechanism here for handing over the first location info is called a "sighting" function 👀. Sighting functions don't have to have security features and are only meant for trusted, controlled environments 🏠. (A classic sighting function is a GPS wired right into a network node 🛰️.) Protections that MUST be provided per RFC 3694 [10] are discussed further in the Security Considerations (Section 6) 🔐.
End systems that get location info through this mechanism then use other protocol mechanisms to pass it along to an emergency call center or include it in presence information 📞.
Civic info is handy because it often gives extra, human-friendly details, especially inside buildings 🏢. It's also easy to get for most occupied structures and can often still be understood even when it's incomplete 🥰. For example, big university or corporate campuses might not have geocoding down to the building and room level 🏫.
Unlike geospatial info, the format for civic and postal info changes 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 around the world 🗾. Other countries can reuse a lot of these data elements, and the doc also sets up an IANA registry for adding new civic location data fields 📋.
The same civic and postal address info can often be shown in several languages and scripts 🈶. For example, Korean addresses are often written in Hangul, Latin, and Kanji, and some older cities have multiple language versions (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 MUST provide at least the rendering in the language and script that fits the location 🙌. For presence info, the target might be visiting from abroad and want to share the info in a format its watchers back home can read ✈️. For emergency services, the local-language rendering is probably the best fit 🚨. To give multiple renderings, the server repeats sequences of address elements, and each one gets a 'language' and/or 'script' element in front (see Section 3.3) 🔁. The language and script stick around for later elements until another language or script element overrides them 💅. The DHCP client usually isn't the final consumer of the location info, so the DHCP server has to supply every appropriate language and script version, and the client then passes them on through some other GEOPRIV using protocol, usually encoded as a presence-based GEOPRIV location object format [16] 🦋.
The DHCP server MAY provide location info for multiple locations related to the target, like both the network element and the network jack itself 🔌. This can be super useful for debugging network problems 🐛.
This doc calls for various operational decisions 🧐. For example, an admin has to decide when to give out the location of the DHCP server or other network elements, even if they're far from the client 🗺️. The admin must also think about whether to include both civic and geospatial info when they might differ 🤔. The doc doesn't set the criteria for those choices, because they depend heavily on local circumstances and need local, human knowledge 🧠.
A system that uses location info configured by DHCP depends on the DHCP admins being careful about a few things, like:
- if info about one location is given in multiple forms (e.g., in multiple languages), is it consistent? 🌸
- is the admin sure location info is only configured for systems it applies to (e.g., not for systems that are topologically close but geographically far)? 🧭
- if the configured location is not the target's but that of a 'nearby' network node or the DHCP server, despite the recommendation against this practice in Section 3.1, is the admin sure that configuration is geographically valid? 🙈
There are a lot of other things to think about to make sure location info is handled safely and quickly for emergency services in particular 🚨. Those belong to the applications that use the configured location info, and they're outside this doc's scope 🙅♀️. DHCP configuration SHOULD NOT be used for emergency services without guidelines on these things 🚫. Work on those guidelines was happening in the IETF ECRIT working group when this doc was published 🛠️.
Also, if a network provides civic location info through both DHCPv4 and DHCPv6, the info both protocols carry MUST be the same 💯.
As covered in the Security Considerations (Section 6), DHCPv4 servers SHOULD return the GEOCONF_CIVIC option only when the DHCPv4 client has included this option in its 'parameter request list' (RFC 2131 [2], Section 3.5) 📝. Likewise, DHCPv6 servers SHOULD return the OPTION_GEOCONF_CIVIC option only when the DHCPv6 client has included it in its OPTION_ORO 🎀.
The DHCPv4 long-options mechanism from RFC 3396 [8] MUST be used if the civic address option is bigger than the maximum DHCPv4 option size of 255 octets 📏.
2. Terminology 📖
In this doc, 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] and show requirement levels for compliant implementations 🎯.
3. Format of the DHCP Civic Location Option 🎀
Part 1 is done, bestie! Part 2 is coming up next 💖🧚
3.1. Overall Format for DHCPv4 ✨
okay so, here's the DHCPv4 layout 🎀 bestie look at how the bits are stacked 👀
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Code GEOCONF_CIVIC 🧚: the code for this DHCP option is
99. - N 🌸: the length of this option is variable. The minimum length is 3 octets.
- what 🔥: this tells you which location the DHCP entry is talking about. Right now there are three options:
0means the location of the DHCP server1means the location of the network element believed to be closest to the client2means the location of the client
Option (2) SHOULD be used, but it may not be known. Options (0) and (1) SHOULD NOT be used unless it is known that the DHCP client is in close physical proximity to the server or network element. the vibes are very "use the right one, bestie" 💅
- country code 🌈: the two-letter ISO 3166 country code in capital ASCII letters, like
DEorUS. Civic addresses always contain a country designation, so this is a fixed-format field to save space ✨ - civic address elements 🦋: zero or more elements that make up the civic and/or postal address, with the format described below (Section 3.3).
3.2. Overall Format for DHCPv6
ngl this one is giving "the whole client" energy 💜 The DHCPv6 [6] civic address option refers generally to the client as a whole.
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 .
. ... .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- option-code 🎀:
OPTION_GEOCONF_CIVIC(36) - option-len 💖: the length of the Countrycode,
whatand civic address elements in octets. - what ✨: see above (Section 3.1).
- country code 🫶: see above (Section 3.1).
- civic address elements 🍓: see above (Section 3.1).
3.3. Element Format
For both DHCPv4 and DHCPv6, every civic address element has the same little layout, so it's giving consistency 🧚
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 🦋: a one-octet descriptor of the data civic address value.
- CAlength 🌈: the length, in octets, of the CAvalue, not including the CAlength field itself.
- CAvalue 💜: the civic address value, as described in detail below.
3.4. Civic Address Components
okay this section is the good stuff 😭 Each country has its own administrative hierarchy, and they often use the same (English) names, so this spec uses a simple hierarchical notation that gets instantiated for each country. We assume that five levels are sufficient for sub-national divisions above the street level. main character energy for a clean structure 👑
All elements are OPTIONAL and can appear 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. no cap, this is the kind of rule that keeps everyone's data looking clean ✨
Abbreviations MUST NOT be used unless indicated for each element. Abbreviations do not need a trailing period. 💀
It is RECOMMENDED that all elements in a particular script (CAtype 128) and language (CAtype 0) be grouped together, as that reduces the number of script and language identifiers needed. so efficient, it's lowkey iconic 🫶
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 preceding it. Since not all elements depend on the script and language, a client accumulates the elements by CAtype and then selects the most desirable language and script rendition if there are multiple elements for the same CAtype. the way that this is organised is just chef's kiss 💅
+--------+-------+--------------------------------------------------+
| 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. Let's go country by country 🌍
- CA (Canada) 🍁: the mapping to NENA designations is shown in parentheses. A1 designates the province (STA), A2 the county (CNA), 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), A4 the district (Bezirk). Street suffixes (STS) are used only 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), 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 is also known as the municipal jurisdiction or MSAG community name (MCN). The civic community name (A3) reflects the political boundaries. These boundaries 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 here's the CAtype table, bestie 🎀 Every row is one little piece of an address, and the columns tell you which registry or PIDF name it lines up with. 💅
+--------+------+------+---------------------------+----------------+
| 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 |
| | | | | |
+--------+------+------+---------------------------+----------------+
+--------+------+------+---------------------------+----------------+
| CAtype | NENA | PIDF | Description | Examples |
+--------+------+------+---------------------------+----------------+
| 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 |
| | | | | |
| 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 in most countries too 🌍 The NENA column points at the data dictionary name in Exhibit 18 of [18].
The PIDF column gives the element name from [16]. ngl, some elements got added after the PIDF location object was already done, so those don't have a PIDF-LO equivalent yet 🥺
Language: The "language" item (CAtype 0) is optional and tells you which language the address info is presented in. It draws its tags from [4], as discussed in [13]. If it's left out, the default is "i-default" [3] ✨
Script: The "script" item (CAtype 128) is optional too 🧚 It tells you which script the address uses. Its tags come from [12] and get elaborated on in Section 2.2.3 of [13]. If it's omitted, the default value is "Latn" 💜
POD, PRD: For POD (trailing street suffix) and PRD (leading street direction) in English-speaking countries, the abbreviations N, E, S, W, and NE, NW, SE, SW SHOULD be used 🧭
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. It's giving official post office energy 📮
HNS: HNS ("house number suffix") is a modifier to the street address. It doesn't identify any part of the street address on its own 🙈
building: A landmark (LMK, CAtype 21) can point at a whole complex of buildings, but 'building' (CAtype 25) gives the name of a single building. You'd use it if the street address covers more than one building or if the building name helps pinpoint the location 🏛️
LOC: LOC ("location", CAtype 22) is an unstructured string with extra info about the spot, like which part of a building you're in or other freeform stuff 🍓
PCN: The postal community name (CAtype 30) and the post office box (CAtype 31) let the recipient build a postal address. The post office box field should contain the words "P.O. Box" or another locally appropriate postal designation 📬
NAM: The NAM object helps people find a location, like "Joe Miller" or "Alice's Dry Cleaning" 💖 It doesn't say who's using a communications device. It says who or what organization is connected to the address. Not me mixing those up 💅
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 is often not displayed on buildings but the building name is prominently shown 🎓
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. Suite and apartment designations are the most common examples 🏢
Room: A "room" (CAtype 28) is the smallest identifiable subdivision of a structure 🚪
Type of place: The "type of place" item (CAtype 29) describes what kind of place the civic coordinates point to. For example, whether it's a home, an office, a street, or some other public space 🏡 The values come from the items in the location types registry [11]. This makes life easy for the DHCP client when it populates 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 Japan, that's the Japan Industry Standard (JIS) address code. It gives a unique address inside Japan, all the way down 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, the primary road is the main road that the smaller streets branch off of, 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. It's a brand-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 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. Instead, they 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 also an optional part of the complete street name. It's a word or phrase that comes after all the other parts 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 certain elements totally override the civic address components to make a postal address 💅. If the elements include a post office box (CAtype 31), then the street address components (CAtype 34, PRD, POD, STS, HNO, HNS) get replaced by the post office box element 📦. If a postal community name is specified, the civic community name (typically, A3) gets swapped out for the postal community name (PCN, CAtype 30) 🌸. Country-specific knowledge is needed to make a valid postal address, and how to format these addresses is out of scope for this document 🙈.
5. Example
ok this one is so cute 🎀. Rather than showing the precise byte layout of a DHCP option, we show a symbolic example of the civic address of the Munich city hall in Bavaria, Germany 🥨. The city and state name are also given in English and Italian as well as German 🇩🇪🇮🇹. Everything else is assumed to be shared across all languages 💜. All of the languages use 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 🔐
this section is SERIOUS bestie, so pay attention 😤. The security considerations from the GEOPRIV architecture defined by RFC 3693 [9] apply here 📜.
Where critical decisions might be based on the value of this GEOCONF_CIVIC option, DHCPv4 authentication in RFC 3118 [5] SHOULD be used to protect the integrity of the DHCP options 🛡️.
Okay, the big one: DHCP messages have zero privacy protection 💀. An eavesdropper who can watch the link between the DHCP server and the requesting client can find out the information in this option 👀. So using this option on networks without access restrictions, or without network-layer or link-layer privacy mechanisms, is NOT RECOMMENDED 🚫.
To keep location info from leaking out by accident, the GEOCONF_CIVIC option SHOULD only be returned by DHCPv4 servers when the DHCPv4 client has put this option in its 'parameter request list' (RFC 2131 [2], Section 3.5) 🙈. Same vibe for DHCPv6: the OPTION_GEOCONF_CIVIC option SHOULD only be returned by DHCPv6 servers when the DHCPv6 client has included it in its OPTION_ORO 🫶.
🚨 Once initial location information has been introduced, it MUST be afforded the protections defined in RFC 3694 [10]. So 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 😭.
7. IANA Considerations 🦋
the 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 the civic address components ✨. Referring to 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 CAtype entry has these fields:
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 were already defined are not handled by IANA registrations, because they are purely descriptive and not a registration of identifiers 🧚. As noted 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.
- [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 🫶
Huge thanks to Harald Alvestrand, Stefan Berger, Peter Blatherwick, Joel M. Halpern, David Kessens, Cheng-Hong Li, Rohan Mahy, James Polk, Martin Thomson and Hannes Tschofenig, who all gave 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.edu
Full Copyright Statement ⚖️
Copyright (C) The IETF Trust (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, THE IETF TRUST, 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 regarding 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 the extent to which any license under such rights might or might not be available, and it does not represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to 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 result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line 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 that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org 💌.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society 🌸.
📦 where this page comes from
- ietf: rfc4776 2006-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms