diff options
Diffstat (limited to 'doc/rfc/rfc4776.txt')
| -rw-r--r-- | doc/rfc/rfc4776.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc4776.txt b/doc/rfc/rfc4776.txt new file mode 100644 index 0000000..34d52a5 --- /dev/null +++ b/doc/rfc/rfc4776.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group H. Schulzrinne +Request for Comments: 4776 Columbia U. +Obsoletes: 4676 November 2006 +Category: Standards Track + + + Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option + for Civic Addresses Configuration Information + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The IETF Trust (2006). + +RFC Editor Note + + RFC 4776 is being published to correct an error in the assignment of + the numeric value of the DHCPv6 option-code in RFC 4676 (Section + 3.2). This document obsoletes RFC 4676. + +Abstract + + 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. + + + + + + + + + + + + + + + +Schulzrinne Standards Track [Page 1] + +RFC 4776 DHCP Civic November 2006 + + +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 ..................................................17 + +1. Introduction + + Many end system services can benefit by knowing the approximate + location of the end device. In particular, IP telephony devices need + to know their location to contact the appropriate emergency response + agency and to be found by emergency responders. + + There are two common ways to identify the location of an object, + either through geospatial coordinates or by so-called civic + addresses. Geospatial coordinates indicate longitude, latitude, and + altitude, while civic addresses indicate a street address. + + The civic address is commonly, but not necessarily, closely related + to the postal address, used by the local postal service to deliver + mail. However, not all postal addresses correspond to street + addresses. For example, the author's address is a postal address + that does not appear on any street or building sign. Naturally, post + office boxes would be unsuitable for the purposes described here. + The term 'civil address' or 'jurisdictional address' is also + sometimes used instead of civic address. This document mainly + supports civic addresses, but allows the postal community name to be + indicated if it differs from the civic name. + + A related document [15] describes a DHCPv4 [2] option for conveying + geospatial information to a device. This document describes how + DHCPv4 and DHCPv6 [6] can be used to convey the civic and postal + address to devices. Both geospatial and civic formats can be used + simultaneously, increasing the chance to deliver accurate and timely + + + + + +Schulzrinne Standards Track [Page 2] + +RFC 4776 DHCP Civic November 2006 + + + location information to emergency responders. The reader should also + be familiar with the concepts in [11], as many of the protocol + elements below are designed to dovetail with PIDF-LO elements. + + This document only defines the delivery of location information from + the DHCP server to the client, due to security concerns related to + using DHCP to update the database. Within the GEOPRIV architecture + as defined by RFC 3693 [9], the defined mechanism in this document + for conveying initial location information is known as a "sighting" + function. Sighting functions are not required to have security + capabilities and are only intended to be configured in trusted and + controlled environments. (A classic example of the sighting function + is a Global Positioning System wired directly to a network node.) + Further discussion of the protections that must be provided according + to RFC 3694 [10] are in the Security Considerations (Section 6). + + End systems that obtain location information via the mechanism + described here then use other protocol mechanisms to communicate this + information to an emergency call center or to convey it as part of + presence information. + + Civic information is useful since it often provides additional, + human-usable information, particularly within buildings. Also, + compared to geospatial information, it is readily obtained for most + occupied structures and can often be interpreted even if incomplete. + For example, for many large university or corporate campuses, + geocoding information to building and room granularity may not be + readily available. + + Unlike geospatial information, the format for civic and postal + information differs from country to country. The initial set of data + fields is derived from standards published by the United States + National Emergency Number Association (NENA) [18] and takes into + account addressing conventions for a number of countries in different + areas of the world. It is anticipated that other countries can reuse + many of the data elements, but the document also establishes an IANA + registry for defining additional civic location data fields. + + The same civic and postal address information can often be rendered + in multiple languages and scripts. For example, Korean addresses are + often shown in Hangul, Latin, and Kanji, while some older cities have + multiple language variants (e.g., Munich, Muenchen, and Monaco). + Since DHCPv4 and DHCPv6 do not currently support a mechanism to query + 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 location + indicated. For example, for use in presence information, the target + may be visiting from a foreign country and want to convey the + + + +Schulzrinne Standards Track [Page 3] + +RFC 4776 DHCP Civic November 2006 + + + information in a format suitable for watchers in its home country. + For emergency services, the rendering in the local language is likely + to be most appropriate. To provide multiple renderings, the server + repeats sequences of address elements, prefixing each with a + 'language' and/or 'script' element (see Section 3.3). The language + and script remain in effect for subsequent elements until overridden + by another language or script element. Since the DHCP client is + unlikely to be the final consumer of the location information, the + DHCP server has to provide all appropriate language and script + versions, which the client then passes on via some other GEOPRIV + using protocol, typically encoded in a presence-based GEOPRIV + location object format [16]. + + The DHCP server MAY provide location information for multiple + locations related to the target, for example, both the network + element and the network jack itself. This is likely to help in + debugging network problems, for example. + + 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 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 + + + +Schulzrinne Standards Track [Page 4] + +RFC 4776 DHCP Civic November 2006 + + + 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. + + In addition, if a network provides civic location information via + both DHCPv4 and DHCPv6, the information conveyed by the two protocols + MUST be the same. + + 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 exceeds the maximum DHCPv4 option + size of 255 octets. + +2. Terminology + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and + indicate requirement levels for compliant implementations. + +3. Format of the DHCP Civic Location Option + +3.1. Overall Format for DHCPv4 + + 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. + + + + + + + +Schulzrinne Standards Track [Page 5] + +RFC 4776 DHCP Civic November 2006 + + + what: The 'what' element describes to which location the DHCP entry + refers. Currently, three options are defined: the location of the + DHCP server (a value of 0), the location of the network element + believed to be closest to the client (a value of 1), or the + location of the client (a value of 2). Option (2) SHOULD be used, + but 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. + + country code: The two-letter ISO 3166 country code in capital ASCII + letters, e.g., DE or US. (Civic addresses always contain country + designations, suggesting the use of a fixed-format field to save + space.) + + civic address elements: Zero or more elements comprising the civic + and/or postal address, with the format described below + (Section 3.3). + +3.2. Overall Format for DHCPv6 + + 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: Length of the Countrycode, 'what' and 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). + + + + + + + +Schulzrinne Standards Track [Page 6] + +RFC 4776 DHCP Civic November 2006 + + +3.3. Element Format + + For both DHCPv4 and DHCPv6, each civic address element has the + following format: + + 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 + + Since each country has different administrative hierarchies, with + often the same (English) names, this specification adopts a simple + hierarchical notation that is then instantiated for each country. We + assume that five levels are sufficient for sub-national divisions + above the street level. + + 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. + + 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. + + 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. + + + + +Schulzrinne Standards Track [Page 7] + +RFC 4776 DHCP Civic November 2006 + + + +--------+-------+--------------------------------------------------+ + | 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 1 + + For 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), 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 + + + +Schulzrinne Standards Track [Page 8] + +RFC 4776 DHCP Civic November 2006 + + + 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: + + +--------+------+------+---------------------------+----------------+ + | 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 | + | | | | | | + +--------+------+------+---------------------------+----------------+ + + + +Schulzrinne Standards Track [Page 9] + +RFC 4776 DHCP Civic November 2006 + + + +--------+------+------+---------------------------+----------------+ + | 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 labeled in the second column correspond to items from + the NENA "Recommended Formats and Protocols For ALI Data Exchange, + ALI Response and GIS Mapping" [18], but are applicable to most + countries. The "NENA" column refers to the data dictionary name in + Exhibit 18 of [18]. + + The column labeled PIDF indicates the element name from [16]. (Some + elements were added to this document after the PIDF location object + definition had been completed. These elements currently do not have + a PIDF-LO equivalent.) + + + +Schulzrinne Standards Track [Page 10] + +RFC 4776 DHCP Civic November 2006 + + + Language: The "language" item (CAtype 0) optionally identifies the + language used for presenting the address information, drawing from + the tags for identifying languages in [4], as discussed in [13]. + If omitted, the default value for this tag is "i-default" [3]. + + Script: The "script" item (CAtype 128) optionally identifies the + script used for presenting the address information, drawing from + the tags for identifying scripts described in [12] and elaborated + on in Section 2.2.3 of [13]. If omitted, the default value for + this tag is "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 designates a street suffix or type. In the United States + (US), the abbreviations recommended by the United States Postal + Service Publication 28 [17], Appendix C, SHOULD be used. + + HNS: HNS ("house number suffix") is a modifier to a street address; + it does not identify parts of a street address. + + 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. + + LOC: LOC ("location", CAtype 22) is an unstructured string + specifying additional information about the location, such as the + part of a building or other unstructured information. + + PCN: The postal community name (CAtype 30) and the post office box + (CAtype 31) allow the recipient to 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 is used to aid user location ("Joe Miller", + "Alice's Dry Cleaning"). It does not identify the person using a + communications device, but rather the person or organization + associated with the address. + + 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. (For + example, on university campuses, the house number is often not + displayed on buildings, whereas the building name is prominently + shown.) + + + +Schulzrinne Standards Track [Page 11] + +RFC 4776 DHCP Civic November 2006 + + + Unit: The "unit" object (CAtype 26) contains the name or number of a + part of a structure where there are separate administrative units, + owners, or tenants, such as separate companies or families that + occupy that structure. Common examples include 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 + type of place described by the civic coordinates. For example, it + describes whether it is a home, office, street, or other public + space. The values are drawn from the items in the location types + registry [11]. This information makes it easy, for example, for + the DHCP client to then populate the presence information. Since + this is an IANA-registered token, the language and script + designations do not apply for this element. + + Additional code: The "additional code" item (CAtype 32) provides an + additional, country-specific code identifying the location. For + example, for Japan, it contains the Japan Industry Standard (JIS) + address code. The JIS address code provides a unique address + inside of Japan, down to the level of indicating the floor of the + building. + + SEAT: The "seat" item (CAtype 33) designates a place where a person + might sit, such as a seat in a stadium or theater, or a cubicle in + an open-plan office or a booth in a trade show. + + Primary road name: The "primary road" item (CAtype 34) is given to + the road or street name associated with the address. If CAtypes + 35 through 37 are not specified, the building or designated + location is found on that street. If some of CAtypes 35 through + 37 are specified, this designates the main road, off of which the + smaller streets branch off and 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 is useful where a primary road is divided + into sections that re-use the same street number ranges. + + Branch road name: The "branch road name" item (CAtype 36) represents + the name or identifier of a road or street that intersects or is + associated with a primary road. The branch road name is used only + in countries where side streets do not have unique names within a + municipality or other administrative unit, but rather must be + + + + +Schulzrinne Standards Track [Page 12] + +RFC 4776 DHCP Civic November 2006 + + + qualified by the name of the primary road name that they branch + off of. + + Sub-Branch road name: The "sub-branch road name" (CAtype 37) item + represents the name of a street that branches off a branch road + (CAtype 36). The sub-branch road name is used only in countries + where such streets are named relative to the primary road name and + branch road that they connect with. + + Street name pre-modifier: The "street name pre-modifier" (CAtype 38) + is an optional element of the complete street name. It is a word + or phrase that precedes all other elements of the street name and + modifies it, but is 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 element of the complete street name. It is a + word or phrase that follows all other elements of the street name + and modifies it, but is 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 + + In general, a recipient can construct a postal address by using all + language-appropriate elements, including the postal code (ZIP, CAtype + 24). However, certain elements override the civic address components + to create a postal address. If the elements include a post office + box (CAtype 31), the street address components (CAtype 34, PRD, POD, + STS, HNO, HNS) are replaced with the post office box element. If a + postal community name is specified, the civic community name + (typically, A3) is replaced by the postal community name (PCN, CAtype + 30). Country-specific knowledge is required to create a valid postal + address. The formating of such addresses is beyond the scope of this + document. + + + + + + + + + + + + + + + +Schulzrinne Standards Track [Page 13] + +RFC 4776 DHCP Civic November 2006 + + +5. Example + + Rather than showing the precise byte layout of a DHCP option, we show + a symbolic example below, representing the civic address of the + Munich city hall in Bavaria, Germany. The city and state name are + also conveyed in English and Italian in addition to German; the other + items are assumed to be common across all languages. All 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 | + +--------+---------------------+ + + + + + +Schulzrinne Standards Track [Page 14] + +RFC 4776 DHCP Civic November 2006 + + +6. Security Considerations + + The security considerations discussed in the GEOPRIV architecture + defined by RFC 3693 [9] apply. + + 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. + + Since there is no privacy protection for DHCP messages, an + eavesdropper who can monitor the link between the DHCP server and + requesting client can discover the information contained in this + option. Thus, usage of this option on networks without access + restrictions or network-layer or link-layer privacy mechanisms is NOT + RECOMMENDED. + + 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 [10]. 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. + +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 establishes a new IANA registry for CAtypes designating + civic address components. Referring to RFC 2434 [14], 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. + + CAtype: Numeric identifier, assigned by IANA. + + Brief description: Short description identifying the meaning of the + element. + + + + + + +Schulzrinne Standards Track [Page 15] + +RFC 4776 DHCP Civic November 2006 + + + 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 contained in Section 3.4. + + Updates to country-specific considerations for previously-defined + CAtypes are not defined by IANA registrations since they are purely + descriptive, 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. + + + +Schulzrinne Standards Track [Page 16] + +RFC 4776 DHCP Civic November 2006 + + + [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 + + Harald Alvestrand, Stefan Berger, Peter Blatherwick, Joel M. Halpern, + David Kessens, Cheng-Hong Li, Rohan Mahy, James Polk, Martin Thomson + and Hannes Tschofenig provided helpful comments. Examples and + inspiration were drawn from the Street Address Data Standard of the + Federal Geographic Data Committee. + + + + + + + + + + + +Schulzrinne Standards Track [Page 17] + +RFC 4776 DHCP Civic November 2006 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Schulzrinne Standards Track [Page 18] + +RFC 4776 DHCP Civic November 2006 + + +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; nor does it 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 and 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. + + + + + + +Schulzrinne Standards Track [Page 19] + |