Internet Draft Friedel van Megen Document: draft-vanmegen-ipv6-addr-00.txt Paul Muller Expires: March 2002 University of Kaiserslautern dep. of computer science October 2001 Mapping Universal Geographical Area Description (GAD) to IPv6 Geo Based Unicast Addresses Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document defines an IPv6 geo based global unicast address for- mat to use in the Internet. The address format is based on the 3GPP Universal Geographical Area Description. The address format defined in this document is consistent with the IPv6 protocol and the "IPv6 Addressing Architecture". It is designed to not only facilitate two dimensional data but also altitude information. This kind of information becomes necessary in areas where different users occupy floors (like in buildings) thus making plain geographical addressing ambiguous. In addition, provi- sion were made to extract valid location reference field data even in cases where accurarcy of location data was sacrified for a larg- er subnet field. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", in this document are to be interpreted as described in RFC-2119. vanmegen Expires March 2002 [Page 1] Internet-Draft University of Kaiserlautern October 2001 Mapping Universal Geographical Area Description (GAD) to IPv6 Geo Based Unicast Addresses Table of contents Status of this Memo.............................................1 Abstract........................................................1 Conventions used in this document...............................1 Introduction....................................................2 Overview of the IPv6 Address....................................2 Overview Universal Geographical Area Description (GAD)..........3 Proposed IPv6 Geo based Unicast Address Format..................4 Technical Motivation............................................7 Security Considerations.........................................7 References......................................................8 Author's Addresses..............................................9 Introduction This document defines a global unicast address format for IPv6 ad- dress assignments in the geo based unicast address space (100b) (see [6], although removed in [5]). The mechanism described here divides the geographic location of a site or (single) node down to its latitude, longitude, and altitude and combines this information (along with some marker bits) into a valid IPv6 address. Overview of the IPv6 Address IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces. There are three types of addresses: Unicast, Anycast, and Multicast. This document defines a specific type of Unicast ad- dress. In this document, fields in addresses are given specific names, for example "subnet". When this name is used with the term "ID" (for "identifier") after the name (e.g., "subnet ID"), it refers to the contents of the named field. When it is used with the term "prefix" (e.g. "subnet prefix") it refers to all of the addressing bits to the left of and including this field. When "field" is used on its own (e.g. "subnet field"), if refers to all bits comprising the referenced entity. IPv6 unicast addresses are designed assuming that the Internet routing system makes forwarding decisions based on a "longest pre- fix match" algorithm on arbitrary bit boundaries and does not have any knowledge of the internal structure of IPv6 addresses. The structure in IPv6 addresses is for assignment and allocation. The only exception to this is the distinction made between unicast and multicast addresses. The specific type of an IPv6 address is indicated by the leading bits in the address. The variable-length field comprising these leading bits is called the Format Prefix (FP). This document defines an address format for the 100 (binary) Format Prefix for Geo based Unicast addresses. The same address format vanmegen Expires March 2002 [Page 2] could Internet-Draft University of Kaiserlautern October 2001 be used for other Format Prefixes, as long as these Format Prefixes also identify IPv6 unicast addresses. Only the "100" Format Prefix is defined here (copied from [1] but changed FP to reflect geo based addresses). Current proposals for Geo based unicast addresses use a geographic reference derived from a bit interleave of the WGS84[2] based lati- tude and longitude of the demarcation point of the site or node but lack any altitude information [4]. Overview Universal Geographical Area Description (GAD) The Universal Geographical Area Description was first introduced in the GSM03.32 specs and transferred to the 3G area in April 1999. It describes locations on the earth's surface in various ways includ- ing locations with a notion of uncertainty. A GAD may be expressed in various ways. The following description was copied from the Ref- erence Document Version 4.0.0 [3]. Only those representations re- lated to this specification will be described. GAD's may be described as Ellipsoid Point, Ellipsoid point with un- certainty circle, Ellipsoid point with uncertainty ellipse, Poly- gon, Ellipsoid point with altitude, Ellipsoid point with altitude and uncertainty Ellipsoid, and Ellipsoid Arc. From this list, only Ellipsoid point, Polygon (with only one point), and Ellipsoid point with altitude may be used since this specification does not handle cases of uncertainty others than introduced by representation er- rors. One extension to the predefined shapes is a Polygon represen- tation including altitude information. It simply adds altitude in- formation of each polygon's point (16bits) to each polygon's point record. Coordinates are expressed in terms of longitude, latitude, and al- titude. The range of longitude is -180 to +180. The range of lati- tude is -90 to +90. 0 longitude corresponds to the Greenwich Merid- ian. Positive angles are to the East, while negative angles are to the West. 0 latitude corresponds to the equator. Positive angles are to the North, while negative angles are to the Sound. Altitudes are defined as the distance between the ellipsoid and the point, along a line orthogonal to the ellipsoid. Altitudes are measured in units of 1 meter. The latitude, expressed in the range -90, +90 is coded with 24bits: 1bit sign and 23bits representing the coded number. The relation between this number N and the range of absolute latitudes A (measured in degree) is: N <= (2^23)/90*A < N+1. The longitude, expressed in the range -180, +180, is coded as a number between -2^23 and 2^23-1. The relation between the coded number N and the range of longitude A (measured in degree) is: N <= (2^24)/360*A < N+1. Note: the proposed mapping changes this to units of 10cm, thus al- lowing a finer resolution for nodes in the mapped area. Another change is to represent latitude the same way as longitude is repre- sented. That is, both are represented by a 2 complement's number with 24bits. The relation between the coded number and the range of absolute latitudes A (measured in degree) is: N <= (2^24)/180*A < N+1. vanmegen Expires March 2002 [Page 3] Internet-Draft University of Kaiserlautern October 2001 Ellipsoid Point The description of an ellipsoid point is that of a point on the surface of the ellipsoid, and consists of a latitude and a longi- tude. In practice, such a description can be used to refer to a point of Earth's surface, or close the Earth's surface, with the same longitude and latitude. No provision is made in version 4.0.0. of the standard to give the height of a point. The S bit indi- cates, if latitude is measured from South (S=1) or North (S=0). RESV means reserved. All values are stored in network byte order. |4 |4 |1|23 |24 | +----+----+-+--------------+---------------+ |0000|RESV|S|23bit latitude|24bit longitude| +----+----+-+--------------+---------------+ Polygon A polygon is an arbitrary shape described by an ordered series of points. The minimum number of points allowed in the GAD specifica- tion is 3, and the maximum number of points allowed is 15. The points shall be connected in the order that they are given. A con- necting line is defined as the line over the ellipsoid joining the two points and of minimum distance (geodesic). The list of points shall respect this conditions: 1. a connecting line shall not cross another connecting line and 2. two successive points must not be diametrically opposed on the ellipsoid. While the definition above was originally copied from the 3GPP standard, some modifications are necessary in order to provide means to store a single point. The number of point allowed may be 1, in addition to the values allowed in the standard. This case must be interpreted by a client as a polygon having tree points all representing the same location. That way, a polygon having only 1 point is essentially the same as an ellipsoid point but with a dif- ferent format tag and record length. The length tag, LEN must be set to one. (Since the length is always one, it is omitted in the proposed IPv6 addresses' mapping) The S bit indicates, if latitude is measured from South (S=1) or North (S=0). RESV means reserved. All values are stored in network byte order. |4 |4 |1|23 |24 |16.extension.| +----+----+-+--------------+---------------+.............+ |0101|LEN |S|23bit latitude|24bit longitude|..altitude...| +----+----+-+--------------+---------------+.............+ Ellipsoid Point with Altitude The description of an ellipsoid point with altitude is that of a point at a specified distance above or below a point on the earth's surface. This is defined by an ellipsoid point with the given lon- gitude and latitude and the altitude above or below the ellipsoid point. The altitude is either above (D=0) or below (D=1) the point refer- enced by its latitude and longitude information. The S bit indi- cates, if latitude is measured from South (S=1) or North (S=0). RESV means reserved. All values are stored in network byte order. |4 |4 |1|23 |24 |1|16 | vanmegen Expires March 2002 [Page 4] Internet-Draft University of Kaiserlautern October 2001 +----+----+-+--------------+---------------+-+--------------+ |1000|RESV|S|23bit latitude|24bit longitude|D|15bit altitude| +----+----+-+--------------+---------------+-+--------------+ Most of the preceding definition were taken from the 3GPP stan- dard, version 4.0.0 [3], with descriptions added where needed to clarify modifications required by the proposed mapping. Proposed IPv6 Geo based Unicast Address Format Geo based Unicast address prefixes use a geographic reference de- rived from a bit interleave of the WGS84 based latitude and longi- tude of the demarcation point of a site plus the bit interleave of the location's altitude information. In addition, the original "type of shade" as defined by the 4bit field from [3] is copied to the resulting IPv6 address. Valied values for this field are 0000b: Ellipsoid point, altitude zero; 0101b: Polygon with one point, al- titude zero; and 1000b: Ellipsoid point with Altitude. The proposed mapping changes some of the original GAD specifica- tion's ranges: Altitude is mapped to units of 10cm (instead units of 1meter), thus allowing a finer resolution for nodes in the mapped area. Representation of coded latitude is changed, too. Both, longitude and latitude are represented by a 2 complement's coded number with 24bits. The relation between the coded number and the range of absolute latitudes A (measured in degree) changes to: N <= (2^24)/180*A < N+1. The resulting bitstream is complemented with information about the selected subnet, and information about the length of the subnet field. In order to allow sites flexible use of subnets, a variable subnet scheme is proposed. Subnets are at least 7bit large and may be increased by multiples of 4bit to a maximum size of 36bit (while at the same time decreasing the precision of the location data by 32bit). The initial overhead is only one bit (serving as marker for PREC), while larger subnets require an overhead of an additional 3bit field (namely, PREC no longer is available as subnet field). The use of explicit subnet sizes servers two purposes. First, it allows clients to determine the accuracy of the location information without knowing about the site's subnet policy. And second, this scheme allows prepared routers to route solely based on subnet information ignoring geographic location completely. The latter assumes that there are no other geographic based addresses in use for the complete network which will be the case in private or companies networks. The following field from a GAD are not transferred to an IPv6 ad- dress. First, all spare fields are simply dropped. There is not space reserverd in the proposed address format to store this addi- tional (yet actually undefined) information. And second, there is no prefix defined for the len field of an polygon description since this location information is per definition limited to only one point, thus this information would be redundant. |3 |1 |4 |64 |4 |3 |1 |48 | +--+--+----+---------------+-------+-----+--+--------------+ vanmegen Expires March 2002 [Page 5] Internet-Draft University of Kaiserlautern October 2001 |FP|R1|FT |Reference |SUBNET |PREC |PV|InterfaceID | +--+--+----+---------------+-------+-----+--+--------------+ FP is the format prefix for geo based unicast addresses (100b). Other values are possible (e.g., any 4bit prefix is possible if R1 is additionally used to represent the prefix) but this is beyond the scope of this specification. R1 is a reserved one bit field (always set to zero). It may be used as an additional bit for the format prefix if an other prefix than 100b is used. FT is a format tag, whose valid values are taken from [3]. Valid values include (0000b: Ellipsoid point, altitude zero; 0101b: Poly- gon with one point, altitude zero; 1000b: Ellipsoid point with Al- titude). An additional value may be defined to represent a polygon consisting of one point with altitude information but this should be synchronized with the standard body defining [3] to avoid unnec- essary collisions of values for this field. Reference contains the interleaved location information. It compro- mises longitude (24bits), latitude (24bits), and altitude (16bits). If no altitude information is known, all bits from altitude must be set to zero. Interleaving is done the following way: latitude and longitude are interleaved one by one. Altitude is mixed in starting with the 4th bit (counted from 0) up to (and including) bit 19). The remaining 4 bits are interleaved from only longitude and alti- tude: Longitude | 23 | .. | 21 | 20 | 19 | 18 | ...... | 05 | 04 | .. | 00 | +----+----+----+----+----+----+--------+----+----+----+----+ |O23 | |O21 |O20 |O19 |O18 | |O05 |O04 | |O00 | +----+----+----+----+----+----+--------+----+----+----+----+ Latitude | 23 | .. | 21 | 20 | 19 | 18 | ...... | 05 | 04 | .. | 00 | +----+----+----+----+----+----+--------+----+----+----+----+ |A23 | |A21 |A20 |A19 |A18 | |A05 |A04 | |A00 | +----+----+----+----+----+----+--------+----+----+----+----+ Altitude | 15 | 14 | ...... | 05 | 04 | .. | 00 | +----+----+--------+----+----+----+----+ |H15 |H14 | |H05 |H04 | |H00 | +----+----+--------+----+----+----+----+ The resulting reference will be: | 63 | 62 | .. | 57 | 56 | 55 | 54 | 53 | 52 | 51 | 50 | +----+----+----+----+----+----+----+----+----+----+----+ |O23 |A23 | .. |O20 |A20 |O19 |A19 |H15 |O18 |A18 |H18 | +----+----+----+----+----+----+----+----+----+----+----+ -> | 13 | 12 | 11 | 10 | 09 | 08 | 07 | 06 | .. | 01 | 00 | +----+----+----+----+----+----+----+----+----+----+----+ |O05 |A05 |H01 |O04 |A04 |H00 |O03 |A03 | .. |O00 |A00 | -> +----+----+----+----+----+----+----+----+----+----+----+ That way, subnetting does not degrade altitude information more than geographical information from longitude and latitude. In addi- vanmegen Expires March 2002 [Page 6] tion, Internet-Draft University of Kaiserlautern October 2001 bit interleaving from highest to lowest bit allows standard routers to keep their routing tables small since all data targeting the same destination are likely to have the same most significant bits. SUBNET is a variable length field comprising 7 bits, thus allowing for 128 subnets. There may be situations where only 128 subnets is not sufficient. In conjunction with PREC and PV, the field can be extended to 4+(8*4) = 36bits by reducing the precision of the loca- tion information. While degradation of location information is pos- sible, this is detectable by a client by simply inspecting the val- ue of PV. PV flags PREC as either valid or invalid. If PV=0, the 3bits from PREC may be used as additional SUBNET bits, extending the subnet range to 7bits. If PV=1, PREC contains information about the preci- sion of "Reference" and allows a system to extend it's SUBNET up to 36bit as described next. The actual meaning of PREC depends on the value of PV: If, PV is CLEARED, the PREC field is added to the initial SUBNET field, thus allowing for the described 2^(SUBNET(4)+PREC(3)) = 2^7 == 128 subnets. If PV is SET, PREC contains the number of bits taken from "Refer- ence" and added to SUBNET, thus allowing to reduce location pre- cision to gain more space for subnetting. Since no router is as- sumed to make any other assumptions than longest matching prefix, it's the end system implementers choice to sacrifice some loca- tion precision to allow a finer subnetting. Note, only additional nibbles can be assigned to the subnet field, thus a value of "0" for PREC means that SUBNET consists of the original 4 bits plus the least 4 bits of the reference field. (a value of 7 allows the system to use 8 additional nibbles, thus SUBNET comprises 4+(8*4)= 36bits in total) leaving only 32bits for the original reference. InterfaceID is used to identify an interface on a link. Therefore, it is only required to be unique on that link once the link can un- ambiguously determined from the prefix value. Normally, an inter- face's identifier can be used to construct the InterfaceID (e.g., in case, the interface card has a IEEE48bit MAC address). If this is not possible (e.g., serial links, dialup connections) uniqueness of this field has to be guaranteed by some other means. An Inter- face ID is always valid only for the local link, i.e., there is no need to require the construction of a global unique address [5]. In case an client wants to reach all nodes at specific location, the client must specify the any-address composed of an interface ID with all ones. Any node having an address with the specified prefix should forward the packet to any registered application as if it has been reached by unicast means. The application may base an an- swer on whether the request was sent with a specific Interface ID or the Any-Interface ID. Note, however, that this is a way to specify a range of servers to be contacted. A client may use an en- larged subnet field (filling it with all ones - just like an inter- face anycast address) while at the same time decreasing the accura- cy of the location information field. In combination with the all- ones interface ID locally constrainted distribution is possible. For example, a client in an urban area may wish to reach all servers within a range of m-meters. Since the client knows its cur- rent location (either by GPS or having access to a locally assigned vanmegen Expires March 2002 [Page 7] address), Internet-Draft University of Kaiserlautern October 2001 the client can construct an address having a limited accuracy (by sacrifying some location field bits for a larger subnet and coding this in the address). A packet sent to this address will be routed to any server withing the uncertainty range, thus reaching any server within the urban area. This allows for distance constrainted multicasts (rather than hop contrainted multicasts). This requires help from routers. Technical Motivation This specification was driven by two main reasons. First, already suggested mappings for geographic information into IPv6 addresses only add the longitude and latitude information to the address. While this is ok for many cases, there is one drawback. If more than one company shares the same building, network addresses will have the same prefix (since only based on "plain" location data) while assigned to different administrative entities. Therefore, need arises to base routing not only on surface information but in addition take the altitude information into account. And second, if routers and clients are to take advantage from the location data added to the IPv6 address, need arises to unambigu- ously identify the location data part. If the reference field was fixed, this would not be a problem. But since this mapping (as well as other mappings currently under discussion) allows to scarify precision of location data for subnet space, routers were not able to extract location data without knowing the size of the chosen subnet field. As a result, location data is rendered useless since no one can tell which the remaining location data from the part as- signed to the subnet field. Security Considerations The proposed scheme does not impose any new security considerations compared to geographic based addressing or any other global ad- dressing scheme. If privacy concerns about location privacy exist, these problems can either be solved by using "standard" addresses (e.g., provider based addresses) when connecting to clients not supposed to gain access to a node's geo-based address or by access- ing susceptible resources only through proxy nodes disguising the geo-based address. References [1] RFC2374, "An IPv6 Aggregatable Global Unicast Address Format", http://www.ietf.org/rfc/rfc2374.txt?number=2374 [2] World Geodetic System 1984, http://www.wgs84.com/files/wgsman24.pdf [3] 3rd Generation Partnership Project; Technical Specification Group Core Network; Universal Geographical Area Description (Release 4) (GAD), 3GPP TS 23.032 V4.0.0 (2001-04) [4] T. Hain, "An IPv6 Provider Independent Global Unicast Address Format", work-in-progress, draft-hain-ipv6-pi-addr-00.txt, June 2001 vanmegen Expires March 2002 [Page 8] Internet-Draft University of Kaiserlautern October 2001 [5] RFC2373, B. Hinden, S. Deering, "IP Version 6 Addressing Architecture", July 1998 [6] RFC1884, B. Hinden, S. Deering, "IP Version 6 Addressing Architecture", December 1995 Author's Addresses Paul M"uller University of Kaiserslautern Fachbereich Informatik, AG ICSY 67663 Kaiserslautern. Germany email: mueller@uni-kl.de http://www.icsy.de/ Friedel van Megen University of Kaiserslautern Fachbereich Informatik, AG ICSY 67663 Kaiserslautern. Germany email: vanmegen@informatik.uni-kl.de http://www.icsy.de/~vanmegen/ vanmegen Expires March 2002 [Page 9]