Internet DRAFT - draft-de-launois-dnsext-sloc-rr
draft-de-launois-dnsext-sloc-rr
Network Working Group C. de Launois
Internet-Draft UCL/INGI
Expires: January 8, 2006 July 7, 2005
Synthetic Location Information in the Domain Name System
draft-de-launois-dnsext-sloc-rr-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 documents 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.
This Internet-Draft will expire on January 8, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo defines a new Resource Record (RR) for the Domain Name
System (DNS), for experimental purposes. It describes a mechanism to
allow the DNS to carry synthetic coordinates about hosts, networks,
and subnets. The new resource record, called SLOC, can express
synthetic locations in different coordinate spaces.
This draft defines the format of the new SLOC RR for the DNS, and
reserves a corresponding DNS type mnemonic (SLOC) and numerical code
(TBD).
de Launois Expires January 8, 2006 [Page 1]
Internet-Draft Synthetic Locations in the DNS July 2005
This RFC assumes that the reader is familiar with the DNS [1] [2].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. RDATA Format . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 SLOC_ALG values . . . . . . . . . . . . . . . . . . . . . 5
2.2 SLOC_SPACE values . . . . . . . . . . . . . . . . . . . . 5
2.3 SLOC_DIM values . . . . . . . . . . . . . . . . . . . . . 6
2.4 SLOC RDATA Examples . . . . . . . . . . . . . . . . . . . 6
3. Master File Format . . . . . . . . . . . . . . . . . . . . . . 7
4. Examples of Master Files . . . . . . . . . . . . . . . . . . . 8
5. Application use of the SLOC RR . . . . . . . . . . . . . . . . 8
5.1 Suggested Uses . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Search Algorithms . . . . . . . . . . . . . . . . . . . . 9
5.2.1 Searching by Name . . . . . . . . . . . . . . . . . . 9
5.2.2 Searching by Address . . . . . . . . . . . . . . . . . 10
5.2.3 Searching by Network or Subnet . . . . . . . . . . . . 10
5.3 Applicability to non-IN Classes and non-IP Addresses . . . 11
6. Implementation of the SLOC RR for the Bind Name Server . . . . 12
6.1 The sloc.h file . . . . . . . . . . . . . . . . . . . . . 12
6.2 The sloc.c file . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . 23
de Launois Expires January 8, 2006 [Page 2]
Internet-Draft Synthetic Locations in the DNS July 2005
1. Introduction
Geographical location informations can be expressed using the LOC DNS
resource record defined in [3]. Geographical locations are useful to
generates maps of routers or to perform "visual" traceroutes. They
are however of little help for predicting round-trip times in the
Internet, since the round-trip times between two hosts are poorly
correlated with their geographical distances. Hence several
synthetic coordinates were developed so that the distance in the
synthetic coordinate space between hosts x and y actually reflects
the round-trip time between x and y. These synthetic coordinates are
usually not expressed in terms of latitude/longitude, and are
sometimes defined in other coordinate spaces than the traditional
two- or three-dimensional euclidean spaces.
This memo defines a new Resource Record (RR) for the Domain Name
System (DNS), for experimental purposes. It describes a mechanism to
allow the DNS to carry synthetic coordinates about hosts, networks,
and subnets. The new resource record, called SLOC, can express
synthetic locations for different coordinate spaces.
This draft defines the format of the new SLOC RR for the DNS, and
reserves a corresponding DNS type mnemonic (SLOC) and numerical code
(TBD).
2. RDATA 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLOC_CLASS | SLOC_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOCATION |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: LOCATION :
: : :
SLOC_CLASS An 8-bit value that specifies if the coordinate is
standard (1), vendor-specific (2), or private (3)
Standard identifications are destined for coordinates
that are supposed to be used by hosts in the global
Internet. For instance, a standard identification can
be used to express geographical coordinates.
Vendor-Specific identifications aim to be used by
vendors wishing to define their own proprietary
coordinates. They can also be used to experiment new
coordinates. Typically, vendor-specific coordinates
de Launois Expires January 8, 2006 [Page 3]
Internet-Draft Synthetic Locations in the DNS July 2005
are useful to only a fraction of hosts in the Internet.
Finally, private identifications can be used by anyone
who wants to express coordinates that do not have any
meaning outside the network where they are used.
SLOC_ID The format of the SLOC_ID field depends on the
SLOC_CLASS value, i.e. the format of the field is
different for standard, vendor-specific, and private
coordinates. The value of the SLOC_ID field specifies
both the nature of the coordinates, and the algorithm
that can interpret and possibly compute these
coordinates.
If the coordinate is standard (SLOC_CLASS=1), then this
field is divided into a a 8-bit value SLOC_ALG, a 8-bit
value SLOC_SPACE, and a 8-bit value SLOC_DIM:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SLOC_ALG | SLOC_SPACE | SLOC_DIM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The SLOC_ALG field specifies the algorithm that
interprets and computes the coordinates. The SLOC_SPACE
field uniquely identifies the nature of the space where
the coordinates are defined, for instance an Euclidean,
a spherical, or an hyperbolic space. Finally, the
SLOC_DIM defines the number of dimensions of the space.
When the identification is vendor-specific (SLOC_CLASS
= 2), the SLOC_ID field contains the vendor-specific ID
assigned by IANA (24-bit value encoded in network
standard byte order). If a vendor implements several
algorithms, or use several coordinate spaces, then the
SLOC_ID field may not suffice to uniquely identify a
couple (algorithm, coordinate space).
Therefore, it is suggested that the vendor uses the
first dimension(s) of its coordinates to identify the
type of coordinates. However, in any cases, this
implementation choice is left to the vendor.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VENDOR_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the coordinates are private (SLOC_CLASS = 3), then
the semantic and meaning of the SLOC_ID field depends
on the domain where it is found. Such coordinates
SHOULD NOT be transmitted to a hosts that is not inside
de Launois Expires January 8, 2006 [Page 4]
Internet-Draft Synthetic Locations in the DNS July 2005
the network where the coordinates are defined.
LOCATION A sequence of 1 or more 32-bit unsigned integers, most
significant octet first (network standard byte order).
These integers express the coordinates of a node.
The exact meaning of these integers depends on the
SLOC_CLASS and SLOC_ID fields.
The remaining of this document focus only on standard coordinates
(SLOC_CLASS=1)
2.1 SLOC_ALG values
For standard coordinates, the 8-bit SLOC_ALG value specifies the
algorithm that interprets and computes the coordinates. The
SLOC_SPACE field uniquely identifies the nature of the space where
the coordinates are defined, for instance an Euclidean, a spherical,
or an hyperbolic space. Finally, the SLOC_DIM defines the number of
dimensions of the space.
Some SLOC_ALG field values currently defined for some synthetic
coordinate algorithms are:
SLOC_ALG Description
--------------------------------------------------
0 Reserved
1 Geographical coordinates [3]
2 GNP synthetic coordinates [4]
3 Lighthouse synthetic coordinates [5]
4 Vivaldi synthetic coordinates [6]
5 SVivaldi synthetic coordinates [7]
6 BBS synthetic coordinates [8]
7 NPS synthetic coordinates [9]
8 PIC synthetic coordinates [10]
9 - 255 Unassigned
2.2 SLOC_SPACE values
Values currently defined for the SLOC_SPACE field are shown belown.
It assigns values to popular coordinate spaces. When the algorithm
does not make use of one these coordinate spaces, it may use the
"uninterpreted" coordinate space (SLOC_SPACE = 1), or use one of the
algorithm-specific values in the range [128..255].
de Launois Expires January 8, 2006 [Page 5]
Internet-Draft Synthetic Locations in the DNS July 2005
SLOC_SPACE Description
--------------------------------------------------
0 Reserved
1 Uninterpreted
2 Euclidean
3 Spherical
4 Cylindric
5 Hyperbolic
6 Height Vector
7-127 Unassigned
128-255 Algorithm-Specific
2.3 SLOC_DIM values
The table below shows the values for the SLOC_DIM field. Values in
the range [1..63] indicate the number of dimensions of the coordinate
space. Value 0 is reserved and MUST NOT be used.
SLOC_DIM Description Min Size of LOCATION field
-----------------------------------------------------------
0 Reserved Undefined
1 1 dimension 1
2 2 dimensions 2
3 3 dimensions 3
: : :
63 63 dimensions 63
64-254 Reserved
255 Variable 1
If SLOC_DIM equals 255, the LOCATION field contains a variable-length
sequence of one or more 32-bits numbers. This value is typically
used when SLOC_SPACE = 1, i.e. an uninterpreted coordinate space, or
when the size of the LOCATION field suffice to indicate the number of
dimensions used.
The third column defines the minimum number of 32-bit values required
in the LOCATION field for this type of dimensions. The LOCATION
field MAY contain more than this minimum number of 32-bit values. In
this case the meaning of the additional values is algorithm-specific.
The tuple (SLOC_ALG, SLOC_SPACE, SLOC_DIM), i.e. the whole SLOC_ID
field, uniquely defines a coordinate space and how to interpret it.
2.4 SLOC RDATA Examples
The table below shows some examples that illustrate the use of
standard coordinates (SLOC_CLASS = 1). It presents some meaningful
de Launois Expires January 8, 2006 [Page 6]
Internet-Draft Synthetic Locations in the DNS July 2005
combinations of SLOC_ALG, SLOC_SPACE and SLOC_DIM values. The
content of the LOCATION field is written here as a sequence of 32-bit
values separated by a colon ":".
SLOC_ALG SLOC_SPACE SLOC_DIM LOCATION Description
-----------------------------------------------------------
3 2 3 25:35:2 Lighthouse Euclidean 3-D
3 2 255 25:35:2 Same as above
4 6 3 5:3:1:100 Vivaldi 2D+H + error
4 2 3 5:3:1:100 Vivaldi 3D + error
5 6 3 5:3:1:100 SVivaldi 2D+H + error
1 3 3 0:0:0:1184274 Lat+Long+Alt+Extra field
In the table above, the examples that uses the Vivaldi network
coordinate system (3d and 4th lines) illustrate the need for the
SLOC_SPACE field. In these cases, the same algorithm (SLOC_ALG = 4)
and the same number of dimensions (SLOC_DIM = 3) are used, with an
identical number of 32-bit values in the LOCATION field. The meaning
of the coordinates is then given by the SLOC_SPACE field.
The 3rd and 5th examples illustrate the need for the SLOC_ALG field.
They both contain the same values in the SLOC_SPACE, SLOC_DIM and
LOCATION fields. However, the coordinates of the 3rd example are
computed by the Vivaldi algorithm, while the coordinates of the 5th
example are computed by the SVivaldi algorithm.
The 6th example illustrates the coding of geographical coordinates in
the SLOC RDATA. The extra field is used to encode the size and
precision values for the coordinates, as detailed in RFC 1876.
3. Master File Format
The SLOC record is expressed in a master file in the following
format:
<owner> <TTL> <class> SLOC
{1 sl_alg sl_space sl_dim | sl_class sl_id} coord
where:
sl_class: [1 .. 3] (unsigned 8-bit value)
sl_alg: [1 .. 255] (unsigned 8-bit value)
sl_space: [1 .. 255] (unsigned 8-bit value)
sl_dim: [1 .. 255] (unsigned 8-bit value)
sl_id: [0 .. 16777215] (unsigned 24-bit value)
coord = value [ ":" coord ]
value: [0 .. 4294967295] (unsigned 32-bit value)
de Launois Expires January 8, 2006 [Page 7]
Internet-Draft Synthetic Locations in the DNS July 2005
Numbers can be written in the decimal notation, or in the hexadecimal
notation, as illustrated by the examples in the next section.
4. Examples of Master Files
;; A SVivaldi 2D+H synthetic coordinate for domain example.net
example.net SLOC 1 5 6 3 5:3:1:100
;; Host A has a standard and a vendor-specific coordinates
A.example.net SLOC 1 3 2 3 0x11111111:0xABCDEF:9
A.example.net SLOC 2 0x00005E 10:20:30:40
;; Geographical coordinates can also be expressed with SLOC RR
A.south.pole.net SLOC ( 1 3 3
0:0:10:0x00121212 )
The first example illustrates SVivaldi coordinates assigned to the
domain "example.net". These coordinates use the standard SLOC
identification (SLOC_CLASS = 1), the SVivaldi algorithm (SLOC_ALG =
5), a Height Vector coordinate space (SLOC_SPACE = 6) with 2D+H = 3
dimensions (SLOC_DIM = 3). The coordinates for SVivaldi are (x = 5,
y = 3, h = 1). There is one extra value (e = 100), which stands for
an error estimation of the coordinates [4].
The second example illustrates the use of coordinates for an
individual host A inside the "example.net" network. This host has
two kinds of coordinates. The first one is a standard (SLOC_CLASS =
1) Lighthouse (SLOC_ALG = 3) Euclidean (SLOC_SPACE = 2) 3D (SLOC_DIM
= 3) coordinate. The second one is a vendor-specific (SLOC_CLASS =
2) coordinate with vendor ID = 0x5E.
The third and last example illustrates the coding of geographical
coordinates using the SLOC resource record format. The coordinate
values stand for the south pole. They respect RFC 1876 [3].
5. Application use of the SLOC RR
5.1 Suggested Uses
A suggested use is that an algorithm regularly computes the network
coordinates of a (sub)domain, and securely updates the SLOC resource
records in the DNS. Using synthetic network coordinates, it is
possible to evaluate the round-trip time that exists between two
distant domains by computing the distance in the coordinate space
between the coordinates of those domains.
de Launois Expires January 8, 2006 [Page 8]
Internet-Draft Synthetic Locations in the DNS July 2005
5.2 Search Algorithms
This section specifies how to use the DNS to translate domain names
and/or IP addresses into location information. This section is
similar to the section 5.2 of [3] describing the search algorithm for
the SLOC RR. The text is retranscribed here so that this memo is
self-contained.
As said earlier, the location information may refer to a host, or to
a network. When specifying the location of a network or subnet,
network administrators are not required to specify the SLOC RR data
for each individual host. For example, a computer lab with 24
workstations, all of which are on the same subnet and in basically
the same location, would only need a single SLOC RR for the subnet.
However, if the file server's location has been more precisely
measured, a separate SLOC RR for it can be placed in the DNS.
The default behaviour of an application is to query the DNS for the
location of an individual host. Sometimes, a host has no associated
SLOC RR data, while its network has one. In this case, the
application may have a {\it fallback} behaviour, and use the SLOC RR
data of the network to get a less precise or larger area. The
application MAY support the use of the algorithm in Section
Section 5.2.3, as noted in Section Section 5.2.1 and Section
Section 5.2.2. If fallback is desired, this behaviour is the
RECOMMENDED default, but in some cases it may need to be modified
based on the specific requirements of the application involved. This
search algorithm is designed to allow network administrators to
specify the location of a network or subnet without requiring SLOC RR
data for each individual hosst.
5.2.1 Searching by Name
If the application is beginning with a name, rather than an IP
address, it MUST check for a SLOC RR associated with that name.
(CNAME records should be followed as for any other RR type.)
If there is no SLOC RR for that name, all A records (if any)
associated with the name MAY be checked for network (or subnet) SLOC
RRs using the "Searching by Network or Subnet" algorithm
(Section 5.2.3). If multiple A records exist and have associated
network or subnet SLOC RRs, the application may choose to use any,
some, or all of the SLOC RRs found, possibly in combination. It is
suggested that multi-homed hosts have SLOC RRs for their name in the
DNS to avoid any ambiguity in these cases.
Note that domain names that do not have associated A records must
have a SLOC RR associated with their name in order for location
de Launois Expires January 8, 2006 [Page 9]
Internet-Draft Synthetic Locations in the DNS July 2005
information to be accessible.
5.2.2 Searching by Address
If the application is beginning with an IP address, it MUST first map
the address to a name using the IN-ADDR.ARPA namespace (see [1],
section 5.2.1), then check for a SLOC RR associated with that name.
If there is no SLOC RR for the name, the address MAY be checked for
network (or subnet) SLOC RRs using the "Searching by Network or
Subnet" algorithm (Section 5.2.3).
5.2.3 Searching by Network or Subnet
Even if the name of a host does not have any associated SLOC RRs, the
network(s) or subnet(s) it is on may. If the application wishes to
search for such less specific data, the following algorithm SHOULD be
followed to find a network or subnet SLOC RR associated with the IP
address. This algorithm is adapted slightly from that specified in
[5], sections 4.3 and 4.4.
Since subnet SLOC RRs are (if present) more specific than network
SLOC RRs, it is best to use them if available. In order to do so, we
build a stack of network and subnet names found while performing the
[5] search, then work our way down the stack until a SLOC RR is
found.
de Launois Expires January 8, 2006 [Page 10]
Internet-Draft Synthetic Locations in the DNS July 2005
1. create a host-zero address using the network portion of the IP
address (one, two, or three bytes for class A, B, or C networks,
respectively). For example, for the host 128.9.2.17, on the class
B network 128.9, this would result in the address "128.9.0.0".
2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A
records. Retrieve:
0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu.
A 255.255.255.0
Push the name "isi-net.isi.edu" onto the stack of names to be
searched for SLOC RRs later.
3. Since an A RR was found, repeat using mask from RR
(255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA.
Retrieve:
0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu.
A 255.255.255.240
Push the name "div2-subnet.isi.edu" onto the stack of names to be
searched for SLOC RRs later.
4. Since another A RR was found, repeat using mask 255.255.255.240
(x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA.
Retrieve:
16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu.
Push the name "inc-subsubnet.isi.edu" onto the stack of names to
be searched for SLOC RRs later.
5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no
more subnet levels to search. We now pop the top name from the
stack and check for an associated SLOC RR. Repeat until a SLOC RR
is found.
In this case, assume that inc-subsubnet.isi.edu does not have an
associated SLOC RR, but that div2-subnet.isi.edu does. We will
then use div2-subnet.isi.edu's SLOC RR as an approximation of this
host's location. (Note that even if isi-net.isi.edu has a SLOC
RR, it will not be used if a subnet also has a SLOC RR.)
5.3 Applicability to non-IN Classes and non-IP Addresses
Like for the LOC record, the SLOC record is defined for all RR
de Launois Expires January 8, 2006 [Page 11]
Internet-Draft Synthetic Locations in the DNS July 2005
classes, and may be used with non-IN classes such as HS and CH. The
semantics of such use are not defined by this memo.
6. Implementation of the SLOC RR for the Bind Name Server
This section proposes an implementation of the SLOC resource record
for the popular Internet Systems Consortium's BIND (Berkeley Internet
Name Domain) DNS server [6]. The RR type number chosen for
illustrative purposes is 51. The new SLOC RR is implemented in the C
language, in two files~: sloc51.h and sloc51.c, located in the /lib/
dns/rdata/generic/ subdirectory of the BIND source tree.
6.1 The sloc.h file
#ifndef GENERIC_SLOC_51_H
#define GENERIC_SLOC_51_H 1
/* Experimental SLOC RR DATA */
#define RRTYPE_SLOC_MAXLOC 64
typedef struct dns_rdata_sloc {
dns_rdatacommon_t common;
isc_mem_t *mctx;
isc_uint8_t class;
isc_uint8_t alg;
isc_uint8_t space;
isc_uint8_t dim;
isc_uint16_t len;
isc_uint32_t location[RRTYPE_SLOC_MAXLOC];
} dns_rdata_sloc_t;
#endif /* GENERIC_SLOC_51_H */
6.2 The sloc.c file
/* Experimental SLOC RR DATA */
#ifndef RDATA_GENERIC_SLOC_51_C
#define RDATA_GENERIC_SLOC_51_C
#define RRTYPE_SLOC_ATTRIBUTES (0)
static inline isc_result_t
fromtext_sloc(ARGS_FROMTEXT) {
isc_token_t token;
de Launois Expires January 8, 2006 [Page 12]
Internet-Draft Synthetic Locations in the DNS July 2005
char *e;
char *str;
int i;
unsigned char sloc_class;
unsigned long sloc_dim = 0;
unsigned int location;
unsigned int sloc_counter = 1;
REQUIRE(type == 51);
UNUSED(type);
UNUSED(rdclass);
UNUSED(origin);
UNUSED(options);
UNUSED(callbacks);
/*
* SLOC Class
*/
RETERR(isc_lex_getmastertoken(lexer, &token,
isc_tokentype_string,
ISC_FALSE));
str = DNS_AS_STR(token);
sloc_class = (unsigned char)strtol(str, &e, 0);
if (*e != 0)
RETTOK(ISC_R_UNEXPECTEDTOKEN);
if (sloc_class == 0 || sloc_class > 3)
RETTOK(ISC_R_RANGE);
RETERR(uint8_tobuffer(sloc_class, target));
/*
* SLOC ID.
*/
if (sloc_class == 1) {
/* Standard coordinates */
/* Read SLOC Alg, SLOC Space and */
/* SLOC Dim (8 bits each) */
for (i=0; i<3; i++) {
RETERR(isc_lex_getmastertoken(lexer, &token,
isc_tokentype_string, ISC_FALSE));
str = DNS_AS_STR(token);
sloc_dim = strtoul(str, &e, 0);
if (*e != 0)
RETTOK(ISC_R_UNEXPECTEDTOKEN);
if (sloc_dim == 0 || sloc_dim > 0xFFU)
RETTOK(ISC_R_RANGE);
RETERR(uint8_tobuffer(sloc_dim, target));
}
de Launois Expires January 8, 2006 [Page 13]
Internet-Draft Synthetic Locations in the DNS July 2005
} else {
/* Vendor-Specific or Private coordinates */
/* Read SLOC Id (24 bits) */
unsigned char sloc_vid_high;
unsigned short sloc_vid_low;
unsigned long sloc_tmp;
RETERR(isc_lex_getmastertoken(lexer, &token,
isc_tokentype_string,
ISC_FALSE));
str = DNS_AS_STR(token);
sloc_tmp = strtoul(str, &e, 0);
if (*e != 0)
RETTOK(ISC_R_UNEXPECTEDTOKEN);
if (sloc_tmp == 0 || sloc_tmp > 0xFFFFFFU)
RETTOK(ISC_R_RANGE);
sloc_vid_high = (unsigned char)(sloc_tmp >> 16);
RETERR(uint8_tobuffer(sloc_vid_high, target));
sloc_vid_low = (sloc_tmp & 0xFFFF);
RETERR(uint16_tobuffer(sloc_vid_low, target));
}
/*
* LOCATION.
*/
RETERR(isc_lex_getmastertoken(lexer, &token,
isc_tokentype_string,
ISC_FALSE));
str = DNS_AS_STR(token);
location = strtoul(str, &e, 0);
if (*e != 0 && *e != ':')
RETTOK(ISC_R_UNEXPECTEDTOKEN);
RETERR(uint32_tobuffer(location, target));
for (i=0; i<(RRTYPE_SLOC_MAXLOC-1) && *e == ':'; i++) {
str = e + 1;
location = strtoul(str, &e, 0);
RETERR(uint32_tobuffer(location, target));
sloc_counter++;
}
if (*e != 0)
RETTOK(ISC_R_UNEXPECTEDTOKEN);
if (sloc_class == 1 && sloc_counter < sloc_dim)
de Launois Expires January 8, 2006 [Page 14]
Internet-Draft Synthetic Locations in the DNS July 2005
RETTOK(ISC_R_UNEXPECTEDEND);
return (ISC_R_SUCCESS);
}
static inline isc_result_t
totext_sloc(ARGS_TOTEXT) {
isc_region_t sr;
unsigned char sl_class;
unsigned long n;
int i;
char buf[sizeof(":4294967295")];
UNUSED(tctx);
REQUIRE(rdata->type == 51);
REQUIRE(rdata->length != 0);
dns_rdata_toregion(rdata, &sr);
/* SLOC Class */
sl_class = sr.base[0];
sprintf(buf, "%i ", sl_class);
RETERR(str_totext(buf, target));
if (sl_class == 1) {
/* Convert SLOC Alg, SLOC Space and */
/* SLOC Dim (8 bits each) */
for (i = 1; i <= 3; i++) {
unsigned char sl_tmp = sr.base[i];
sprintf(buf, "%i ", sl_tmp);
RETERR(str_totext(buf, target));
}
} else {
/* Convert SLOC Id (24 bits) */
n = uint32_fromregion(&sr) & 0xFFFFFF;
sprintf(buf, "%lu ", n);
RETERR(str_totext(buf, target));
}
isc_region_consume(&sr, 4);
/* Convert LOCATION values */
n = uint32_fromregion(&sr);
isc_region_consume(&sr, 4);
sprintf(buf, "%lu", n);
de Launois Expires January 8, 2006 [Page 15]
Internet-Draft Synthetic Locations in the DNS July 2005
RETERR(str_totext(buf, target));
while (sr.length >= 4) {
n = uint32_fromregion(&sr);
isc_region_consume(&sr, 4);
sprintf(buf, ":%lu", n);
RETERR(str_totext(buf, target));
}
return (ISC_R_SUCCESS);
}
static inline isc_result_t
fromwire_sloc(ARGS_FROMWIRE) {
isc_region_t sr;
unsigned char sl_class;
unsigned char sl_alg;
unsigned char sl_space;
unsigned char sl_dim;
unsigned int sl_counter = 1;
REQUIRE(type == 51);
UNUSED(type);
UNUSED(rdclass);
UNUSED(dctx);
UNUSED(options);
isc_buffer_activeregion(source, &sr);
if (sr.length < 4)
return (ISC_R_UNEXPECTEDEND);
sl_class = sr.base[0];
sl_alg = sr.base[1];
sl_space = sr.base[2];
sl_dim = sr.base[3];
if (sl_class == 0 || sl_class > 3)
return (ISC_R_NOTIMPLEMENTED);
if (sl_class == 1) {
/* Check for Standard SLOC Class*/
if (sl_alg == 0 || sl_space == 0 || sl_dim == 0)
return (ISC_R_NOTIMPLEMENTED);
if (sl_dim > 63 && sl_dim < 255)
return (ISC_R_NOTIMPLEMENTED);
}
de Launois Expires January 8, 2006 [Page 16]
Internet-Draft Synthetic Locations in the DNS July 2005
RETERR(mem_tobuffer(target, sr.base, 4));
isc_region_consume(&sr, 4);
isc_buffer_forward(source, 4);
if (sr.length < 4) {
return (ISC_R_UNEXPECTEDEND);
}
RETERR(mem_tobuffer(target, sr.base, 4));
isc_region_consume(&sr, 4);
isc_buffer_forward(source, 4);
while (sr.length >= 4) {
RETERR(mem_tobuffer(target, sr.base, 4));
isc_region_consume(&sr, 4);
isc_buffer_forward(source, 4);
sl_counter++;
}
if (sl_class==1 && sl_dim!=255) {
/* Check number of coordinates */
if (sl_counter < sl_dim)
return (ISC_R_UNEXPECTEDEND);
}
return (ISC_R_SUCCESS);
}
static inline isc_result_t
towire_sloc(ARGS_TOWIRE) {
UNUSED(cctx);
REQUIRE(rdata->type == 51);
REQUIRE(rdata->length != 0);
return (mem_tobuffer(target, rdata->data, rdata->length));
}
static inline int
compare_sloc(ARGS_COMPARE) {
isc_region_t r1;
isc_region_t r2;
REQUIRE(rdata1->type == rdata2->type);
REQUIRE(rdata1->rdclass == rdata2->rdclass);
REQUIRE(rdata1->type == 51);
REQUIRE(rdata1->length != 0);
REQUIRE(rdata2->length != 0);
de Launois Expires January 8, 2006 [Page 17]
Internet-Draft Synthetic Locations in the DNS July 2005
dns_rdata_toregion(rdata1, &r1);
dns_rdata_toregion(rdata2, &r2);
return (isc_region_compare(&r1, &r2));
}
static inline isc_result_t
fromstruct_sloc(ARGS_FROMSTRUCT) {
dns_rdata_sloc_t *sloc = source;
int i;
REQUIRE(type == 51);
REQUIRE(source != NULL);
REQUIRE(sloc->common.rdtype == type);
REQUIRE(sloc->common.rdclass == rdclass);
UNUSED(type);
UNUSED(rdclass);
if (sloc->class == 0 || sloc->class > 3)
return (ISC_R_NOTIMPLEMENTED);
RETERR(uint8_tobuffer(sloc->class, target));
if (sloc->class == 1) {
/* Standard coordinates */
if (sloc->alg == 0
|| sloc->space == 0
|| sloc->dim == 0)
return (ISC_R_NOTIMPLEMENTED);
if (sloc->dim > 63 && sloc->space < 255)
return (ISC_R_NOTIMPLEMENTED);
if (sloc->len < sloc->dim)
return (ISC_R_UNEXPECTEDEND);
RETERR(uint8_tobuffer(sloc->dim, target));
} else {
/* Vendor-Specific or Private coordinates */
RETERR(uint8_tobuffer(sloc->alg, target));
RETERR(uint8_tobuffer(sloc->space, target));
RETERR(uint8_tobuffer(sloc->dim, target));
}
if (sloc->len < 1 || sloc->len > RRTYPE_SLOC_MAXLOC)
return (ISC_R_RANGE);
for (i = 0; i < sloc->len; i++) {
RETERR(uint32_tobuffer(sloc->location[i], target));
}
de Launois Expires January 8, 2006 [Page 18]
Internet-Draft Synthetic Locations in the DNS July 2005
return (ISC_R_SUCCESS);
}
static inline isc_result_t
tostruct_sloc(ARGS_TOSTRUCT) {
dns_rdata_sloc_t *sloc = target;
isc_region_t r;
REQUIRE(rdata->type == 51);
REQUIRE(target != NULL);
REQUIRE(rdata->length != 0);
UNUSED(mctx);
dns_rdata_toregion(rdata, &r);
sloc->common.rdclass = rdata->rdclass;
sloc->common.rdtype = rdata->type;
ISC_LINK_INIT(&sloc->common, link);
sloc->class = uint8_fromregion(&r);
isc_region_consume(&r, 1);
sloc->alg = uint8_fromregion(&r);
isc_region_consume(&r, 1);
sloc->space = uint8_fromregion(&r);
isc_region_consume(&r, 1);
sloc->dim = uint8_fromregion(&r);
isc_region_consume(&r, 1);
sloc->len = 1;
sloc->location[0] = uint32_fromregion(&r);
isc_region_consume(&r, 4);
while (r.length >= 4 && sloc->len < RRTYPE_SLOC_MAXLOC) {
sloc->location[sloc->len] = uint32_fromregion(&r);
sloc->len++;
}
return (ISC_R_SUCCESS);
}
static inline void
freestruct_sloc(ARGS_FREESTRUCT) {
dns_rdata_sloc_t *sloc = source;
REQUIRE(source != NULL);
REQUIRE(sloc->common.rdtype == 51);
UNUSED(source);
de Launois Expires January 8, 2006 [Page 19]
Internet-Draft Synthetic Locations in the DNS July 2005
UNUSED(sloc);
}
static inline isc_result_t
additionaldata_sloc(ARGS_ADDLDATA) {
REQUIRE(rdata->type == 51);
UNUSED(rdata);
UNUSED(add);
UNUSED(arg);
return (ISC_R_SUCCESS);
}
static inline isc_result_t
digest_sloc(ARGS_DIGEST) {
isc_region_t r;
REQUIRE(rdata->type == 51);
dns_rdata_toregion(rdata, &r);
return ((digest)(arg, &r));
}
static inline isc_boolean_t
checkowner_sloc(ARGS_CHECKOWNER) {
REQUIRE(type == 51);
UNUSED(name);
UNUSED(type);
UNUSED(rdclass);
UNUSED(wildcard);
return (ISC_TRUE);
}
static inline isc_boolean_t
checknames_sloc(ARGS_CHECKNAMES) {
REQUIRE(rdata->type == 51);
UNUSED(rdata);
UNUSED(owner);
UNUSED(bad);
return (ISC_TRUE);
de Launois Expires January 8, 2006 [Page 20]
Internet-Draft Synthetic Locations in the DNS July 2005
}
#endif /* RDATA_GENERIC_SLOC_51_C */
7. IANA Considerations
IANA is requested to allocate an RR type number for the SLOC record
type.
8. Security Considerations
This memo describes a new resource record for the Domain Name System.
As such, it does not introduce any new vulnerability. However, care
should be taken so that the algorithms used to compute the
coordinates are tolerant to abuses.
9. References
[1] Mockapetris, P., "Domain Names - Concepts and Facilities",
RFC 1034, November 1987.
[2] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987.
[3] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means
for Expressing Location Information in the Domain Name System",
RFC 1876, January 1996.
[4] de Launois, C., Uhlig, S., and O. Bonaventure, "Scalable Route
Selection for IPv6 Multihomed Sites", Proc. Networking'05,
May 2005.
[5] Mockapetris, P., "DNS Encoding of Network Names and Other
Types", RFC 1101, April 1989.
[6] Internet Systems Consortium, Inc., "ISC BIND",
URL http://www.isc.org/sw/bind/, May 2005.
[7] Ng, T. and H. Zhang, "Predicting Internet Network Distance with
Coordinates-Based Approaches", Proc. IEEE INFOCOM'02,
June 2002.
[8] Pias, M., Crowcroft, J., Wilbur, S., Bhatti, S., and T. Harris,
"Lighthouses for scalable distributed location",
Proc. IPTPS'03, Feburary 2003.
[9] Dabek, F., Kaashoek, F., and R. Morris, "Vivaldi: A
de Launois Expires January 8, 2006 [Page 21]
Internet-Draft Synthetic Locations in the DNS July 2005
Decentralized Network Coordinate System", Proc. ACM SIGCOMM'04,
August 2004.
[10] Shavitt, Y. and T. Tankel, "Big-Bang Simulation for embedding
network distances in Euclidean space", Proc. IEEE INFOCOM'03,
April 2003.
[11] Ng, T. and H. Zhang, "A network positioning system for the
Internet", Proc. USENIX Conference, June 2004.
[12] Costa, M., Castro, M., Rowstron, A., and P. Key, "PIC:
Practical Internet Coordinates for Distance Estimation",
Proc. International Conference on Distributed Systems,
March 2004.
Author's Address
Cedric de Launois
UCL/INGI
Place Ste-Barbe 2
B-1348 Louvain-la-Neuve
Belgium
Email: delaunois@info.ucl.ac.be
URI: http://www.info.ucl.ac.be/people/delaunoi/
de Launois Expires January 8, 2006 [Page 22]
Internet-Draft Synthetic Locations in the DNS July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
de Launois Expires January 8, 2006 [Page 23]
