idnits 2.17.1 draft-de-launois-dnsext-sloc-rr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1026. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1003. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1010. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1016. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 10 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 182: '... SHOULD NOT be transmitt...' RFC 2119 keyword, line 243: '...ue 0 is reserved and MUST NOT be used....' RFC 2119 keyword, line 264: '... field MAY contain more than this mi...' RFC 2119 keyword, line 391: '... application MAY support the use of ...' RFC 2119 keyword, line 394: '... RECOMMENDED default, but in some ca...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 7, 2005) is 6867 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0' is mentioned on line 853, but not defined == Unused Reference: '11' is defined on line 975, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 978, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 1876 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Unknown state RFC: RFC 1101 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. de Launois 3 Internet-Draft UCL/INGI 4 Expires: January 8, 2006 July 7, 2005 6 Synthetic Location Information in the Domain Name System 7 draft-de-launois-dnsext-sloc-rr-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 8, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This memo defines a new Resource Record (RR) for the Domain Name 41 System (DNS), for experimental purposes. It describes a mechanism to 42 allow the DNS to carry synthetic coordinates about hosts, networks, 43 and subnets. The new resource record, called SLOC, can express 44 synthetic locations in different coordinate spaces. 46 This draft defines the format of the new SLOC RR for the DNS, and 47 reserves a corresponding DNS type mnemonic (SLOC) and numerical code 48 (TBD). 50 This RFC assumes that the reader is familiar with the DNS [1] [2]. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. RDATA Format . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1 SLOC_ALG values . . . . . . . . . . . . . . . . . . . . . 5 58 2.2 SLOC_SPACE values . . . . . . . . . . . . . . . . . . . . 5 59 2.3 SLOC_DIM values . . . . . . . . . . . . . . . . . . . . . 6 60 2.4 SLOC RDATA Examples . . . . . . . . . . . . . . . . . . . 6 62 3. Master File Format . . . . . . . . . . . . . . . . . . . . . . 7 64 4. Examples of Master Files . . . . . . . . . . . . . . . . . . . 8 66 5. Application use of the SLOC RR . . . . . . . . . . . . . . . . 8 67 5.1 Suggested Uses . . . . . . . . . . . . . . . . . . . . . . 8 68 5.2 Search Algorithms . . . . . . . . . . . . . . . . . . . . 9 69 5.2.1 Searching by Name . . . . . . . . . . . . . . . . . . 9 70 5.2.2 Searching by Address . . . . . . . . . . . . . . . . . 10 71 5.2.3 Searching by Network or Subnet . . . . . . . . . . . . 10 72 5.3 Applicability to non-IN Classes and non-IP Addresses . . . 11 74 6. Implementation of the SLOC RR for the Bind Name Server . . . . 12 75 6.1 The sloc.h file . . . . . . . . . . . . . . . . . . . . . 12 76 6.2 The sloc.c file . . . . . . . . . . . . . . . . . . . . . 12 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 22 86 Intellectual Property and Copyright Statements . . . . . . . . 23 88 1. Introduction 90 Geographical location informations can be expressed using the LOC DNS 91 resource record defined in [3]. Geographical locations are useful to 92 generates maps of routers or to perform "visual" traceroutes. They 93 are however of little help for predicting round-trip times in the 94 Internet, since the round-trip times between two hosts are poorly 95 correlated with their geographical distances. Hence several 96 synthetic coordinates were developed so that the distance in the 97 synthetic coordinate space between hosts x and y actually reflects 98 the round-trip time between x and y. These synthetic coordinates are 99 usually not expressed in terms of latitude/longitude, and are 100 sometimes defined in other coordinate spaces than the traditional 101 two- or three-dimensional euclidean spaces. 103 This memo defines a new Resource Record (RR) for the Domain Name 104 System (DNS), for experimental purposes. It describes a mechanism to 105 allow the DNS to carry synthetic coordinates about hosts, networks, 106 and subnets. The new resource record, called SLOC, can express 107 synthetic locations for different coordinate spaces. 109 This draft defines the format of the new SLOC RR for the DNS, and 110 reserves a corresponding DNS type mnemonic (SLOC) and numerical code 111 (TBD). 113 2. RDATA Format 115 0 1 2 3 116 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 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | SLOC_CLASS | SLOC_ID | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | LOCATION | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 : LOCATION : 123 : : : 125 SLOC_CLASS An 8-bit value that specifies if the coordinate is 126 standard (1), vendor-specific (2), or private (3) 127 Standard identifications are destined for coordinates 128 that are supposed to be used by hosts in the global 129 Internet. For instance, a standard identification can 130 be used to express geographical coordinates. 131 Vendor-Specific identifications aim to be used by 132 vendors wishing to define their own proprietary 133 coordinates. They can also be used to experiment new 134 coordinates. Typically, vendor-specific coordinates 135 are useful to only a fraction of hosts in the Internet. 136 Finally, private identifications can be used by anyone 137 who wants to express coordinates that do not have any 138 meaning outside the network where they are used. 140 SLOC_ID The format of the SLOC_ID field depends on the 141 SLOC_CLASS value, i.e. the format of the field is 142 different for standard, vendor-specific, and private 143 coordinates. The value of the SLOC_ID field specifies 144 both the nature of the coordinates, and the algorithm 145 that can interpret and possibly compute these 146 coordinates. 148 If the coordinate is standard (SLOC_CLASS=1), then this 149 field is divided into a a 8-bit value SLOC_ALG, a 8-bit 150 value SLOC_SPACE, and a 8-bit value SLOC_DIM: 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | SLOC_ALG | SLOC_SPACE | SLOC_DIM | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 The SLOC_ALG field specifies the algorithm that 157 interprets and computes the coordinates. The SLOC_SPACE 158 field uniquely identifies the nature of the space where 159 the coordinates are defined, for instance an Euclidean, 160 a spherical, or an hyperbolic space. Finally, the 161 SLOC_DIM defines the number of dimensions of the space. 163 When the identification is vendor-specific (SLOC_CLASS 164 = 2), the SLOC_ID field contains the vendor-specific ID 165 assigned by IANA (24-bit value encoded in network 166 standard byte order). If a vendor implements several 167 algorithms, or use several coordinate spaces, then the 168 SLOC_ID field may not suffice to uniquely identify a 169 couple (algorithm, coordinate space). 170 Therefore, it is suggested that the vendor uses the 171 first dimension(s) of its coordinates to identify the 172 type of coordinates. However, in any cases, this 173 implementation choice is left to the vendor. 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | VENDOR_ID | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 If the coordinates are private (SLOC_CLASS = 3), then 180 the semantic and meaning of the SLOC_ID field depends 181 on the domain where it is found. Such coordinates 182 SHOULD NOT be transmitted to a hosts that is not inside 183 the network where the coordinates are defined. 185 LOCATION A sequence of 1 or more 32-bit unsigned integers, most 186 significant octet first (network standard byte order). 187 These integers express the coordinates of a node. 188 The exact meaning of these integers depends on the 189 SLOC_CLASS and SLOC_ID fields. 191 The remaining of this document focus only on standard coordinates 192 (SLOC_CLASS=1) 194 2.1 SLOC_ALG values 196 For standard coordinates, the 8-bit SLOC_ALG value specifies the 197 algorithm that interprets and computes the coordinates. The 198 SLOC_SPACE field uniquely identifies the nature of the space where 199 the coordinates are defined, for instance an Euclidean, a spherical, 200 or an hyperbolic space. Finally, the SLOC_DIM defines the number of 201 dimensions of the space. 203 Some SLOC_ALG field values currently defined for some synthetic 204 coordinate algorithms are: 206 SLOC_ALG Description 207 -------------------------------------------------- 208 0 Reserved 209 1 Geographical coordinates [3] 210 2 GNP synthetic coordinates [4] 211 3 Lighthouse synthetic coordinates [5] 212 4 Vivaldi synthetic coordinates [6] 213 5 SVivaldi synthetic coordinates [7] 214 6 BBS synthetic coordinates [8] 215 7 NPS synthetic coordinates [9] 216 8 PIC synthetic coordinates [10] 217 9 - 255 Unassigned 219 2.2 SLOC_SPACE values 221 Values currently defined for the SLOC_SPACE field are shown belown. 222 It assigns values to popular coordinate spaces. When the algorithm 223 does not make use of one these coordinate spaces, it may use the 224 "uninterpreted" coordinate space (SLOC_SPACE = 1), or use one of the 225 algorithm-specific values in the range [128..255]. 227 SLOC_SPACE Description 228 -------------------------------------------------- 229 0 Reserved 230 1 Uninterpreted 231 2 Euclidean 232 3 Spherical 233 4 Cylindric 234 5 Hyperbolic 235 6 Height Vector 236 7-127 Unassigned 237 128-255 Algorithm-Specific 239 2.3 SLOC_DIM values 241 The table below shows the values for the SLOC_DIM field. Values in 242 the range [1..63] indicate the number of dimensions of the coordinate 243 space. Value 0 is reserved and MUST NOT be used. 245 SLOC_DIM Description Min Size of LOCATION field 246 ----------------------------------------------------------- 247 0 Reserved Undefined 248 1 1 dimension 1 249 2 2 dimensions 2 250 3 3 dimensions 3 251 : : : 252 63 63 dimensions 63 253 64-254 Reserved 254 255 Variable 1 256 If SLOC_DIM equals 255, the LOCATION field contains a variable-length 257 sequence of one or more 32-bits numbers. This value is typically 258 used when SLOC_SPACE = 1, i.e. an uninterpreted coordinate space, or 259 when the size of the LOCATION field suffice to indicate the number of 260 dimensions used. 262 The third column defines the minimum number of 32-bit values required 263 in the LOCATION field for this type of dimensions. The LOCATION 264 field MAY contain more than this minimum number of 32-bit values. In 265 this case the meaning of the additional values is algorithm-specific. 267 The tuple (SLOC_ALG, SLOC_SPACE, SLOC_DIM), i.e. the whole SLOC_ID 268 field, uniquely defines a coordinate space and how to interpret it. 270 2.4 SLOC RDATA Examples 272 The table below shows some examples that illustrate the use of 273 standard coordinates (SLOC_CLASS = 1). It presents some meaningful 274 combinations of SLOC_ALG, SLOC_SPACE and SLOC_DIM values. The 275 content of the LOCATION field is written here as a sequence of 32-bit 276 values separated by a colon ":". 278 SLOC_ALG SLOC_SPACE SLOC_DIM LOCATION Description 279 ----------------------------------------------------------- 280 3 2 3 25:35:2 Lighthouse Euclidean 3-D 281 3 2 255 25:35:2 Same as above 282 4 6 3 5:3:1:100 Vivaldi 2D+H + error 283 4 2 3 5:3:1:100 Vivaldi 3D + error 284 5 6 3 5:3:1:100 SVivaldi 2D+H + error 285 1 3 3 0:0:0:1184274 Lat+Long+Alt+Extra field 287 In the table above, the examples that uses the Vivaldi network 288 coordinate system (3d and 4th lines) illustrate the need for the 289 SLOC_SPACE field. In these cases, the same algorithm (SLOC_ALG = 4) 290 and the same number of dimensions (SLOC_DIM = 3) are used, with an 291 identical number of 32-bit values in the LOCATION field. The meaning 292 of the coordinates is then given by the SLOC_SPACE field. 294 The 3rd and 5th examples illustrate the need for the SLOC_ALG field. 295 They both contain the same values in the SLOC_SPACE, SLOC_DIM and 296 LOCATION fields. However, the coordinates of the 3rd example are 297 computed by the Vivaldi algorithm, while the coordinates of the 5th 298 example are computed by the SVivaldi algorithm. 300 The 6th example illustrates the coding of geographical coordinates in 301 the SLOC RDATA. The extra field is used to encode the size and 302 precision values for the coordinates, as detailed in RFC 1876. 304 3. Master File Format 306 The SLOC record is expressed in a master file in the following 307 format: 309 SLOC 310 {1 sl_alg sl_space sl_dim | sl_class sl_id} coord 312 where: 314 sl_class: [1 .. 3] (unsigned 8-bit value) 315 sl_alg: [1 .. 255] (unsigned 8-bit value) 316 sl_space: [1 .. 255] (unsigned 8-bit value) 317 sl_dim: [1 .. 255] (unsigned 8-bit value) 318 sl_id: [0 .. 16777215] (unsigned 24-bit value) 320 coord = value [ ":" coord ] 321 value: [0 .. 4294967295] (unsigned 32-bit value) 323 Numbers can be written in the decimal notation, or in the hexadecimal 324 notation, as illustrated by the examples in the next section. 326 4. Examples of Master Files 328 ;; A SVivaldi 2D+H synthetic coordinate for domain example.net 329 example.net SLOC 1 5 6 3 5:3:1:100 331 ;; Host A has a standard and a vendor-specific coordinates 332 A.example.net SLOC 1 3 2 3 0x11111111:0xABCDEF:9 333 A.example.net SLOC 2 0x00005E 10:20:30:40 335 ;; Geographical coordinates can also be expressed with SLOC RR 336 A.south.pole.net SLOC ( 1 3 3 337 0:0:10:0x00121212 ) 339 The first example illustrates SVivaldi coordinates assigned to the 340 domain "example.net". These coordinates use the standard SLOC 341 identification (SLOC_CLASS = 1), the SVivaldi algorithm (SLOC_ALG = 342 5), a Height Vector coordinate space (SLOC_SPACE = 6) with 2D+H = 3 343 dimensions (SLOC_DIM = 3). The coordinates for SVivaldi are (x = 5, 344 y = 3, h = 1). There is one extra value (e = 100), which stands for 345 an error estimation of the coordinates [4]. 347 The second example illustrates the use of coordinates for an 348 individual host A inside the "example.net" network. This host has 349 two kinds of coordinates. The first one is a standard (SLOC_CLASS = 350 1) Lighthouse (SLOC_ALG = 3) Euclidean (SLOC_SPACE = 2) 3D (SLOC_DIM 351 = 3) coordinate. The second one is a vendor-specific (SLOC_CLASS = 352 2) coordinate with vendor ID = 0x5E. 354 The third and last example illustrates the coding of geographical 355 coordinates using the SLOC resource record format. The coordinate 356 values stand for the south pole. They respect RFC 1876 [3]. 358 5. Application use of the SLOC RR 360 5.1 Suggested Uses 362 A suggested use is that an algorithm regularly computes the network 363 coordinates of a (sub)domain, and securely updates the SLOC resource 364 records in the DNS. Using synthetic network coordinates, it is 365 possible to evaluate the round-trip time that exists between two 366 distant domains by computing the distance in the coordinate space 367 between the coordinates of those domains. 369 5.2 Search Algorithms 371 This section specifies how to use the DNS to translate domain names 372 and/or IP addresses into location information. This section is 373 similar to the section 5.2 of [3] describing the search algorithm for 374 the SLOC RR. The text is retranscribed here so that this memo is 375 self-contained. 377 As said earlier, the location information may refer to a host, or to 378 a network. When specifying the location of a network or subnet, 379 network administrators are not required to specify the SLOC RR data 380 for each individual host. For example, a computer lab with 24 381 workstations, all of which are on the same subnet and in basically 382 the same location, would only need a single SLOC RR for the subnet. 383 However, if the file server's location has been more precisely 384 measured, a separate SLOC RR for it can be placed in the DNS. 386 The default behaviour of an application is to query the DNS for the 387 location of an individual host. Sometimes, a host has no associated 388 SLOC RR data, while its network has one. In this case, the 389 application may have a {\it fallback} behaviour, and use the SLOC RR 390 data of the network to get a less precise or larger area. The 391 application MAY support the use of the algorithm in Section 392 Section 5.2.3, as noted in Section Section 5.2.1 and Section 393 Section 5.2.2. If fallback is desired, this behaviour is the 394 RECOMMENDED default, but in some cases it may need to be modified 395 based on the specific requirements of the application involved. This 396 search algorithm is designed to allow network administrators to 397 specify the location of a network or subnet without requiring SLOC RR 398 data for each individual hosst. 400 5.2.1 Searching by Name 402 If the application is beginning with a name, rather than an IP 403 address, it MUST check for a SLOC RR associated with that name. 404 (CNAME records should be followed as for any other RR type.) 406 If there is no SLOC RR for that name, all A records (if any) 407 associated with the name MAY be checked for network (or subnet) SLOC 408 RRs using the "Searching by Network or Subnet" algorithm 409 (Section 5.2.3). If multiple A records exist and have associated 410 network or subnet SLOC RRs, the application may choose to use any, 411 some, or all of the SLOC RRs found, possibly in combination. It is 412 suggested that multi-homed hosts have SLOC RRs for their name in the 413 DNS to avoid any ambiguity in these cases. 415 Note that domain names that do not have associated A records must 416 have a SLOC RR associated with their name in order for location 417 information to be accessible. 419 5.2.2 Searching by Address 421 If the application is beginning with an IP address, it MUST first map 422 the address to a name using the IN-ADDR.ARPA namespace (see [1], 423 section 5.2.1), then check for a SLOC RR associated with that name. 425 If there is no SLOC RR for the name, the address MAY be checked for 426 network (or subnet) SLOC RRs using the "Searching by Network or 427 Subnet" algorithm (Section 5.2.3). 429 5.2.3 Searching by Network or Subnet 431 Even if the name of a host does not have any associated SLOC RRs, the 432 network(s) or subnet(s) it is on may. If the application wishes to 433 search for such less specific data, the following algorithm SHOULD be 434 followed to find a network or subnet SLOC RR associated with the IP 435 address. This algorithm is adapted slightly from that specified in 436 [5], sections 4.3 and 4.4. 438 Since subnet SLOC RRs are (if present) more specific than network 439 SLOC RRs, it is best to use them if available. In order to do so, we 440 build a stack of network and subnet names found while performing the 441 [5] search, then work our way down the stack until a SLOC RR is 442 found. 444 1. create a host-zero address using the network portion of the IP 445 address (one, two, or three bytes for class A, B, or C networks, 446 respectively). For example, for the host 128.9.2.17, on the class 447 B network 128.9, this would result in the address "128.9.0.0". 449 2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A 450 records. Retrieve: 452 0.0.9.128.IN-ADDR.ARPA. PTR isi-net.isi.edu. 453 A 255.255.255.0 455 Push the name "isi-net.isi.edu" onto the stack of names to be 456 searched for SLOC RRs later. 458 3. Since an A RR was found, repeat using mask from RR 459 (255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA. 460 Retrieve: 462 0.2.9.128.IN-ADDR.ARPA. PTR div2-subnet.isi.edu. 463 A 255.255.255.240 465 Push the name "div2-subnet.isi.edu" onto the stack of names to be 466 searched for SLOC RRs later. 468 4. Since another A RR was found, repeat using mask 255.255.255.240 469 (x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA. 470 Retrieve: 472 16.2.9.128.IN-ADDR.ARPA. PTR inc-subsubnet.isi.edu. 474 Push the name "inc-subsubnet.isi.edu" onto the stack of names to 475 be searched for SLOC RRs later. 477 5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no 478 more subnet levels to search. We now pop the top name from the 479 stack and check for an associated SLOC RR. Repeat until a SLOC RR 480 is found. 482 In this case, assume that inc-subsubnet.isi.edu does not have an 483 associated SLOC RR, but that div2-subnet.isi.edu does. We will 484 then use div2-subnet.isi.edu's SLOC RR as an approximation of this 485 host's location. (Note that even if isi-net.isi.edu has a SLOC 486 RR, it will not be used if a subnet also has a SLOC RR.) 488 5.3 Applicability to non-IN Classes and non-IP Addresses 490 Like for the LOC record, the SLOC record is defined for all RR 491 classes, and may be used with non-IN classes such as HS and CH. The 492 semantics of such use are not defined by this memo. 494 6. Implementation of the SLOC RR for the Bind Name Server 496 This section proposes an implementation of the SLOC resource record 497 for the popular Internet Systems Consortium's BIND (Berkeley Internet 498 Name Domain) DNS server [6]. The RR type number chosen for 499 illustrative purposes is 51. The new SLOC RR is implemented in the C 500 language, in two files~: sloc51.h and sloc51.c, located in the /lib/ 501 dns/rdata/generic/ subdirectory of the BIND source tree. 503 6.1 The sloc.h file 505 #ifndef GENERIC_SLOC_51_H 506 #define GENERIC_SLOC_51_H 1 508 /* Experimental SLOC RR DATA */ 510 #define RRTYPE_SLOC_MAXLOC 64 512 typedef struct dns_rdata_sloc { 513 dns_rdatacommon_t common; 514 isc_mem_t *mctx; 515 isc_uint8_t class; 516 isc_uint8_t alg; 517 isc_uint8_t space; 518 isc_uint8_t dim; 519 isc_uint16_t len; 520 isc_uint32_t location[RRTYPE_SLOC_MAXLOC]; 521 } dns_rdata_sloc_t; 523 #endif /* GENERIC_SLOC_51_H */ 525 6.2 The sloc.c file 527 /* Experimental SLOC RR DATA */ 529 #ifndef RDATA_GENERIC_SLOC_51_C 530 #define RDATA_GENERIC_SLOC_51_C 532 #define RRTYPE_SLOC_ATTRIBUTES (0) 534 static inline isc_result_t 535 fromtext_sloc(ARGS_FROMTEXT) { 536 isc_token_t token; 537 char *e; 538 char *str; 539 int i; 540 unsigned char sloc_class; 541 unsigned long sloc_dim = 0; 542 unsigned int location; 543 unsigned int sloc_counter = 1; 545 REQUIRE(type == 51); 547 UNUSED(type); 548 UNUSED(rdclass); 549 UNUSED(origin); 550 UNUSED(options); 551 UNUSED(callbacks); 553 /* 554 * SLOC Class 555 */ 556 RETERR(isc_lex_getmastertoken(lexer, &token, 557 isc_tokentype_string, 558 ISC_FALSE)); 559 str = DNS_AS_STR(token); 560 sloc_class = (unsigned char)strtol(str, &e, 0); 561 if (*e != 0) 562 RETTOK(ISC_R_UNEXPECTEDTOKEN); 563 if (sloc_class == 0 || sloc_class > 3) 564 RETTOK(ISC_R_RANGE); 565 RETERR(uint8_tobuffer(sloc_class, target)); 567 /* 568 * SLOC ID. 569 */ 570 if (sloc_class == 1) { 571 /* Standard coordinates */ 572 /* Read SLOC Alg, SLOC Space and */ 573 /* SLOC Dim (8 bits each) */ 574 for (i=0; i<3; i++) { 575 RETERR(isc_lex_getmastertoken(lexer, &token, 576 isc_tokentype_string, ISC_FALSE)); 577 str = DNS_AS_STR(token); 578 sloc_dim = strtoul(str, &e, 0); 579 if (*e != 0) 580 RETTOK(ISC_R_UNEXPECTEDTOKEN); 581 if (sloc_dim == 0 || sloc_dim > 0xFFU) 582 RETTOK(ISC_R_RANGE); 583 RETERR(uint8_tobuffer(sloc_dim, target)); 584 } 586 } else { 587 /* Vendor-Specific or Private coordinates */ 588 /* Read SLOC Id (24 bits) */ 590 unsigned char sloc_vid_high; 591 unsigned short sloc_vid_low; 592 unsigned long sloc_tmp; 594 RETERR(isc_lex_getmastertoken(lexer, &token, 595 isc_tokentype_string, 596 ISC_FALSE)); 597 str = DNS_AS_STR(token); 598 sloc_tmp = strtoul(str, &e, 0); 599 if (*e != 0) 600 RETTOK(ISC_R_UNEXPECTEDTOKEN); 601 if (sloc_tmp == 0 || sloc_tmp > 0xFFFFFFU) 602 RETTOK(ISC_R_RANGE); 604 sloc_vid_high = (unsigned char)(sloc_tmp >> 16); 605 RETERR(uint8_tobuffer(sloc_vid_high, target)); 606 sloc_vid_low = (sloc_tmp & 0xFFFF); 607 RETERR(uint16_tobuffer(sloc_vid_low, target)); 608 } 610 /* 611 * LOCATION. 612 */ 613 RETERR(isc_lex_getmastertoken(lexer, &token, 614 isc_tokentype_string, 615 ISC_FALSE)); 617 str = DNS_AS_STR(token); 618 location = strtoul(str, &e, 0); 619 if (*e != 0 && *e != ':') 620 RETTOK(ISC_R_UNEXPECTEDTOKEN); 621 RETERR(uint32_tobuffer(location, target)); 623 for (i=0; i<(RRTYPE_SLOC_MAXLOC-1) && *e == ':'; i++) { 624 str = e + 1; 625 location = strtoul(str, &e, 0); 626 RETERR(uint32_tobuffer(location, target)); 627 sloc_counter++; 628 } 630 if (*e != 0) 631 RETTOK(ISC_R_UNEXPECTEDTOKEN); 633 if (sloc_class == 1 && sloc_counter < sloc_dim) 634 RETTOK(ISC_R_UNEXPECTEDEND); 636 return (ISC_R_SUCCESS); 637 } 639 static inline isc_result_t 640 totext_sloc(ARGS_TOTEXT) { 641 isc_region_t sr; 642 unsigned char sl_class; 643 unsigned long n; 644 int i; 646 char buf[sizeof(":4294967295")]; 648 UNUSED(tctx); 650 REQUIRE(rdata->type == 51); 651 REQUIRE(rdata->length != 0); 653 dns_rdata_toregion(rdata, &sr); 655 /* SLOC Class */ 656 sl_class = sr.base[0]; 657 sprintf(buf, "%i ", sl_class); 658 RETERR(str_totext(buf, target)); 660 if (sl_class == 1) { 661 /* Convert SLOC Alg, SLOC Space and */ 662 /* SLOC Dim (8 bits each) */ 663 for (i = 1; i <= 3; i++) { 664 unsigned char sl_tmp = sr.base[i]; 665 sprintf(buf, "%i ", sl_tmp); 666 RETERR(str_totext(buf, target)); 667 } 669 } else { 670 /* Convert SLOC Id (24 bits) */ 671 n = uint32_fromregion(&sr) & 0xFFFFFF; 672 sprintf(buf, "%lu ", n); 673 RETERR(str_totext(buf, target)); 674 } 676 isc_region_consume(&sr, 4); 678 /* Convert LOCATION values */ 679 n = uint32_fromregion(&sr); 680 isc_region_consume(&sr, 4); 681 sprintf(buf, "%lu", n); 682 RETERR(str_totext(buf, target)); 684 while (sr.length >= 4) { 685 n = uint32_fromregion(&sr); 686 isc_region_consume(&sr, 4); 687 sprintf(buf, ":%lu", n); 688 RETERR(str_totext(buf, target)); 689 } 691 return (ISC_R_SUCCESS); 692 } 694 static inline isc_result_t 695 fromwire_sloc(ARGS_FROMWIRE) { 696 isc_region_t sr; 697 unsigned char sl_class; 698 unsigned char sl_alg; 699 unsigned char sl_space; 700 unsigned char sl_dim; 701 unsigned int sl_counter = 1; 703 REQUIRE(type == 51); 705 UNUSED(type); 706 UNUSED(rdclass); 707 UNUSED(dctx); 708 UNUSED(options); 710 isc_buffer_activeregion(source, &sr); 711 if (sr.length < 4) 712 return (ISC_R_UNEXPECTEDEND); 714 sl_class = sr.base[0]; 715 sl_alg = sr.base[1]; 716 sl_space = sr.base[2]; 717 sl_dim = sr.base[3]; 719 if (sl_class == 0 || sl_class > 3) 720 return (ISC_R_NOTIMPLEMENTED); 722 if (sl_class == 1) { 723 /* Check for Standard SLOC Class*/ 724 if (sl_alg == 0 || sl_space == 0 || sl_dim == 0) 725 return (ISC_R_NOTIMPLEMENTED); 726 if (sl_dim > 63 && sl_dim < 255) 727 return (ISC_R_NOTIMPLEMENTED); 728 } 729 RETERR(mem_tobuffer(target, sr.base, 4)); 730 isc_region_consume(&sr, 4); 731 isc_buffer_forward(source, 4); 733 if (sr.length < 4) { 734 return (ISC_R_UNEXPECTEDEND); 735 } 737 RETERR(mem_tobuffer(target, sr.base, 4)); 738 isc_region_consume(&sr, 4); 739 isc_buffer_forward(source, 4); 741 while (sr.length >= 4) { 742 RETERR(mem_tobuffer(target, sr.base, 4)); 743 isc_region_consume(&sr, 4); 744 isc_buffer_forward(source, 4); 745 sl_counter++; 746 } 748 if (sl_class==1 && sl_dim!=255) { 749 /* Check number of coordinates */ 750 if (sl_counter < sl_dim) 751 return (ISC_R_UNEXPECTEDEND); 752 } 754 return (ISC_R_SUCCESS); 755 } 757 static inline isc_result_t 758 towire_sloc(ARGS_TOWIRE) { 759 UNUSED(cctx); 761 REQUIRE(rdata->type == 51); 762 REQUIRE(rdata->length != 0); 764 return (mem_tobuffer(target, rdata->data, rdata->length)); 765 } 767 static inline int 768 compare_sloc(ARGS_COMPARE) { 769 isc_region_t r1; 770 isc_region_t r2; 772 REQUIRE(rdata1->type == rdata2->type); 773 REQUIRE(rdata1->rdclass == rdata2->rdclass); 774 REQUIRE(rdata1->type == 51); 775 REQUIRE(rdata1->length != 0); 776 REQUIRE(rdata2->length != 0); 777 dns_rdata_toregion(rdata1, &r1); 778 dns_rdata_toregion(rdata2, &r2); 779 return (isc_region_compare(&r1, &r2)); 780 } 782 static inline isc_result_t 783 fromstruct_sloc(ARGS_FROMSTRUCT) { 784 dns_rdata_sloc_t *sloc = source; 785 int i; 787 REQUIRE(type == 51); 788 REQUIRE(source != NULL); 789 REQUIRE(sloc->common.rdtype == type); 790 REQUIRE(sloc->common.rdclass == rdclass); 792 UNUSED(type); 793 UNUSED(rdclass); 795 if (sloc->class == 0 || sloc->class > 3) 796 return (ISC_R_NOTIMPLEMENTED); 797 RETERR(uint8_tobuffer(sloc->class, target)); 799 if (sloc->class == 1) { 800 /* Standard coordinates */ 801 if (sloc->alg == 0 802 || sloc->space == 0 803 || sloc->dim == 0) 804 return (ISC_R_NOTIMPLEMENTED); 805 if (sloc->dim > 63 && sloc->space < 255) 806 return (ISC_R_NOTIMPLEMENTED); 807 if (sloc->len < sloc->dim) 808 return (ISC_R_UNEXPECTEDEND); 809 RETERR(uint8_tobuffer(sloc->dim, target)); 811 } else { 812 /* Vendor-Specific or Private coordinates */ 813 RETERR(uint8_tobuffer(sloc->alg, target)); 814 RETERR(uint8_tobuffer(sloc->space, target)); 815 RETERR(uint8_tobuffer(sloc->dim, target)); 816 } 818 if (sloc->len < 1 || sloc->len > RRTYPE_SLOC_MAXLOC) 819 return (ISC_R_RANGE); 821 for (i = 0; i < sloc->len; i++) { 822 RETERR(uint32_tobuffer(sloc->location[i], target)); 823 } 824 return (ISC_R_SUCCESS); 825 } 827 static inline isc_result_t 828 tostruct_sloc(ARGS_TOSTRUCT) { 829 dns_rdata_sloc_t *sloc = target; 830 isc_region_t r; 832 REQUIRE(rdata->type == 51); 833 REQUIRE(target != NULL); 834 REQUIRE(rdata->length != 0); 836 UNUSED(mctx); 838 dns_rdata_toregion(rdata, &r); 840 sloc->common.rdclass = rdata->rdclass; 841 sloc->common.rdtype = rdata->type; 842 ISC_LINK_INIT(&sloc->common, link); 844 sloc->class = uint8_fromregion(&r); 845 isc_region_consume(&r, 1); 846 sloc->alg = uint8_fromregion(&r); 847 isc_region_consume(&r, 1); 848 sloc->space = uint8_fromregion(&r); 849 isc_region_consume(&r, 1); 850 sloc->dim = uint8_fromregion(&r); 851 isc_region_consume(&r, 1); 852 sloc->len = 1; 853 sloc->location[0] = uint32_fromregion(&r); 854 isc_region_consume(&r, 4); 856 while (r.length >= 4 && sloc->len < RRTYPE_SLOC_MAXLOC) { 857 sloc->location[sloc->len] = uint32_fromregion(&r); 858 sloc->len++; 859 } 861 return (ISC_R_SUCCESS); 862 } 864 static inline void 865 freestruct_sloc(ARGS_FREESTRUCT) { 866 dns_rdata_sloc_t *sloc = source; 868 REQUIRE(source != NULL); 869 REQUIRE(sloc->common.rdtype == 51); 871 UNUSED(source); 872 UNUSED(sloc); 873 } 875 static inline isc_result_t 876 additionaldata_sloc(ARGS_ADDLDATA) { 877 REQUIRE(rdata->type == 51); 879 UNUSED(rdata); 880 UNUSED(add); 881 UNUSED(arg); 883 return (ISC_R_SUCCESS); 884 } 886 static inline isc_result_t 887 digest_sloc(ARGS_DIGEST) { 888 isc_region_t r; 890 REQUIRE(rdata->type == 51); 892 dns_rdata_toregion(rdata, &r); 894 return ((digest)(arg, &r)); 895 } 897 static inline isc_boolean_t 898 checkowner_sloc(ARGS_CHECKOWNER) { 900 REQUIRE(type == 51); 902 UNUSED(name); 903 UNUSED(type); 904 UNUSED(rdclass); 905 UNUSED(wildcard); 907 return (ISC_TRUE); 908 } 910 static inline isc_boolean_t 911 checknames_sloc(ARGS_CHECKNAMES) { 913 REQUIRE(rdata->type == 51); 915 UNUSED(rdata); 916 UNUSED(owner); 917 UNUSED(bad); 919 return (ISC_TRUE); 921 } 923 #endif /* RDATA_GENERIC_SLOC_51_C */ 925 7. IANA Considerations 927 IANA is requested to allocate an RR type number for the SLOC record 928 type. 930 8. Security Considerations 932 This memo describes a new resource record for the Domain Name System. 933 As such, it does not introduce any new vulnerability. However, care 934 should be taken so that the algorithms used to compute the 935 coordinates are tolerant to abuses. 937 9. References 939 [1] Mockapetris, P., "Domain Names - Concepts and Facilities", 940 RFC 1034, November 1987. 942 [2] Mockapetris, P., "Domain Names - Implementation and 943 Specification", RFC 1035, November 1987. 945 [3] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means 946 for Expressing Location Information in the Domain Name System", 947 RFC 1876, January 1996. 949 [4] de Launois, C., Uhlig, S., and O. Bonaventure, "Scalable Route 950 Selection for IPv6 Multihomed Sites", Proc. Networking'05, 951 May 2005. 953 [5] Mockapetris, P., "DNS Encoding of Network Names and Other 954 Types", RFC 1101, April 1989. 956 [6] Internet Systems Consortium, Inc., "ISC BIND", 957 URL http://www.isc.org/sw/bind/, May 2005. 959 [7] Ng, T. and H. Zhang, "Predicting Internet Network Distance with 960 Coordinates-Based Approaches", Proc. IEEE INFOCOM'02, 961 June 2002. 963 [8] Pias, M., Crowcroft, J., Wilbur, S., Bhatti, S., and T. Harris, 964 "Lighthouses for scalable distributed location", 965 Proc. IPTPS'03, Feburary 2003. 967 [9] Dabek, F., Kaashoek, F., and R. Morris, "Vivaldi: A 968 Decentralized Network Coordinate System", Proc. ACM SIGCOMM'04, 969 August 2004. 971 [10] Shavitt, Y. and T. Tankel, "Big-Bang Simulation for embedding 972 network distances in Euclidean space", Proc. IEEE INFOCOM'03, 973 April 2003. 975 [11] Ng, T. and H. Zhang, "A network positioning system for the 976 Internet", Proc. USENIX Conference, June 2004. 978 [12] Costa, M., Castro, M., Rowstron, A., and P. Key, "PIC: 979 Practical Internet Coordinates for Distance Estimation", 980 Proc. International Conference on Distributed Systems, 981 March 2004. 983 Author's Address 985 Cedric de Launois 986 UCL/INGI 987 Place Ste-Barbe 2 988 B-1348 Louvain-la-Neuve 989 Belgium 991 Email: delaunois@info.ucl.ac.be 992 URI: http://www.info.ucl.ac.be/people/delaunoi/ 994 Intellectual Property Statement 996 The IETF takes no position regarding the validity or scope of any 997 Intellectual Property Rights or other rights that might be claimed to 998 pertain to the implementation or use of the technology described in 999 this document or the extent to which any license under such rights 1000 might or might not be available; nor does it represent that it has 1001 made any independent effort to identify any such rights. Information 1002 on the procedures with respect to rights in RFC documents can be 1003 found in BCP 78 and BCP 79. 1005 Copies of IPR disclosures made to the IETF Secretariat and any 1006 assurances of licenses to be made available, or the result of an 1007 attempt made to obtain a general license or permission for the use of 1008 such proprietary rights by implementers or users of this 1009 specification can be obtained from the IETF on-line IPR repository at 1010 http://www.ietf.org/ipr. 1012 The IETF invites any interested party to bring to its attention any 1013 copyrights, patents or patent applications, or other proprietary 1014 rights that may cover technology that may be required to implement 1015 this standard. Please address the information to the IETF at 1016 ietf-ipr@ietf.org. 1018 Disclaimer of Validity 1020 This document and the information contained herein are provided on an 1021 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1022 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1023 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1024 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1025 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1026 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1028 Copyright Statement 1030 Copyright (C) The Internet Society (2005). This document is subject 1031 to the rights, licenses and restrictions contained in BCP 78, and 1032 except as set forth therein, the authors retain all their rights. 1034 Acknowledgment 1036 Funding for the RFC Editor function is currently provided by the 1037 Internet Society.