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]