idnits 2.17.1 draft-eastlake-dnsop-expressing-qos-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (6 March 2022) is 782 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee754' ** Downref: Normative reference to an Experimental RFC: RFC 5820 -- Obsolete informational reference (is this intentional?): RFC 1349 (Obsoleted by RFC 2474) -- Obsolete informational reference (is this intentional?): RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP D. Eastlake 3 Internet-Draft H. Song 4 Intended status: Standards Track Futurewei Technologies 5 Expires: 7 September 2022 6 March 2022 7 Expressing Quality of Service Requirements (QoS) in Domain Name System 8 (DNS) Queries 9 draft-eastlake-dnsop-expressing-qos-requirements-00 11 Abstract 13 A method of encoding communication service quality requirements in a 14 Domain Name System (DNS) query is specified through inclusion of the 15 requirements in one or more label of the name being queried. This 16 enables DNS responses that are dependent on such requirements without 17 changes in the format of DNS protocol messages or DNS application 18 program interfaces (APIs). 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 7 September 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology and Acronyms . . . . . . . . . . . . . . . . 3 55 2. Including Service Requirements in DNS Queries . . . . . . . . 4 56 2.1. Including Information in DNS Queries . . . . . . . . . . 4 57 2.2. Encoding Service Requirements in DNS Names . . . . . . . 5 58 2.2.1. Requirement TLV Encoding . . . . . . . . . . . . . . 5 59 2.2.2. Requirements Types and Value Encoding . . . . . . . . 6 60 2.2.3. Complete QoS DNS Names . . . . . . . . . . . . . . . 7 61 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 4.1. Requirements Label Type Codes . . . . . . . . . . . . . . 8 64 4.2. Restricted LDH Label Prefixes . . . . . . . . . . . . . . 8 65 4.2.1. R-LDH Registry . . . . . . . . . . . . . . . . . . . 9 66 4.2.2. R-LDH Expert Guidance . . . . . . . . . . . . . . . . 9 67 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 6.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 The Domain Name System (DNS) is a distributed database that stores 76 data under hierarchical domain names and supports redundant servers, 77 data caching, and security features. The data is formatted into 78 resource records (RRs) whose content type and structure are indicated 79 by the RR Type field. A typical use of DNS is that, by running the 80 DNS protocol, a host gets the IP addresses stored at a domain name 81 from DNS servers through a DNS resolver. Many other types of data 82 besides IP addresses can be stored in and returned by the DNS. 84 There are instances where different DNS answers are desired depending 85 on the type of destination service to be connected to and/or the 86 communication protocol to be used for that communication. This can 87 be signaled in a query through the use of designated initial labels 88 beginning with the underscore codepoint ("_", 0x5F). This was 89 initially specified for the SRV RR Type [RFC2782]. It has been 90 extended with additional types of leading-underscore labels for use 91 with the TLSA, URI, TXT, and other RR Types [RFC8552]. 93 Similarly, there is a need to encode different communication service 94 quality requirements in DNS queries. Then different DNS answers can 95 be returned depending, for example, on whether high bandwidth or low 96 delay is the most important factor in the communication. Different 97 answers could cause packets to be differently handled, constructed, 98 or addressed which in turn could affect the path taken and/or the 99 behavior of network switches along the communications path so as to 100 make the communications more likely to satisfy the desired 101 communication service requirements. 103 Such encoding into the name being queried ensures that requirements 104 will be forwarded by any recursive DNS servers between the querying 105 application and the responding authoritative server. It also avoids 106 any change in DNS protocol messages or application program interfaces 107 (APIs). 109 This document specifies how service requirements may be encoded in 110 DNS queries through inclusion of the requirements in one or more 111 labels of the name being queried enabling an authoritative server to 112 take such requirements into account in determining its answers. 114 1.1. Terminology and Acronyms 116 The following terminology and acronyms are used in this document. 117 General familiarity with DNS terminology [RFC8499] is assumed. 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119][RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 ABNF - Augmented Backus-Naur Form [RFC5234]. 127 API - Application Program Interface 129 DNS - Domain Name System 131 LDH - Letters, Digits, and Hyphen (DNS label) [RFC5820] 132 R-LDH - Restricted LDH (DNS label) [RFC5820] 134 RR - Resource Record [RFC8499]. Ths unit of data stored in the DNS. 136 TLV - Type, Length, Value. 138 2. Including Service Requirements in DNS Queries 140 This section specifies how to encode communication services quality 141 requirements in one or more domain name labels and discusses why some 142 alternatives methods of including requirements in a DNS query were 143 rejected. 145 2.1. Including Information in DNS Queries 147 There exist methods to include information in a DNS request that are 148 conveyed only from a resolver to a server, that is one hop. These 149 are primarily through the inclusion of "meta-RRs" in the Additional 150 Information section of a DNS request [RFC1035] including the OPT 151 meta-RR [RFC6891] which can carry an extensible set of options. 152 These methods are generally not suitable to use for the inclusion of 153 QoS requirements for two reasons: 155 * Typical APIs do not provide for meta-RRs to be specified on a 156 query or retrieved from a response. 158 * Because meta-RRs designate transient data associated with a 159 particular DNS message. Thus, if a query is forwarded by a 160 recursive DNS server, such requirements will be lost. 162 Other methods of including information in a DNS query that are 163 preserved when a query is forwarded are the Name, Class, and RR Type. 165 Class is an additional dimension of DNS data besides Name and RR 166 Type. However, only the "IN" or Internet Class has significant 167 deployment or utilization and DNS messages specifying other Classes 168 are frequently blocked by middle-boxes. Thus this dimension is not 169 useful in practice. 171 RR Type is only 16-bits and is already used to indicate the type of 172 RRs being requests. 174 This leaves only the name being queried for the encoding of service 175 requirement as specified below. 177 2.2. Encoding Service Requirements in DNS Names 179 Domain names consist of a sequence of labels, with labels further to 180 the right being a higher level in the name hierarchy and labels to 181 the left of a particular label identifying nodes in the hierarchical 182 tree of nodes below that particular label. Each label is limited to 183 63 octets in length and the zero length null label is reserved to 184 identify the root node. In a complete valid domain name, the sum of 185 the length of each label in the name plus one octet of overhead per 186 label (including the terminating null label) may not exceed 255 187 octets. 189 Communication service requirements are encoded into names being 190 queried. This is done by including a service label, constructed as 191 described below, in the name usually as the first label. A service 192 label consist of a special prefix followed by a sequence of one or 193 more encoded TLVs indicating the service requirements. The use of 194 such a special prefix which affects the interpretation of the 195 remainder of the label is similar to the "xn--" prefix to indicate 196 internationalized domain names [RFC5890]. 198 2.2.1. Requirement TLV Encoding 200 Each TLV expressing a service requirement can be thought of as being 201 binarily encoded as shown in Figure 1. 203 0 1 2 3 4 5 6 7 204 +---+---+---+---+---+---+---+---+ 205 | Type | Length | 206 +---+---+---+---+---+---+---+---+ 207 | Value, Length Bytes Long . 208 . . 209 . . 210 ................................. 212 Figure 1: Service Requirement TLV Structure 214 * Type: 4-bit unsigned integer indicating the type of service 215 requirement. 217 Length: 4-bit unsigned integer indicating the length of the value 218 associated with the service requirement in bytes. The presence 219 of an explicit length makes it possible to skip unknown/ 220 unimplemented service requirements. 222 Value: The value associated with the service requirement. 224 Although the DNS does not constraint the octet values within a label, 225 for ease in use and due to user interface restrictions label octets 226 are commonly limited to a subset of printing ASCII [RFC0020] 227 character values. Furthermore, for name matching purposes, the DNS 228 does not distinguish between octets having the upper case and lower 229 case codes for an ASCII letter and in some cases the storage of a 230 label in the DNS and/or its later retrieval may change the value of 231 an octet in that label between the values for upper and lower case 232 version of an ASCII letter [RFC4343]. To avoid possible problems 233 with this DNS case insensitivity or possibly problematic byte values 234 such as zero, the TLV or sequence of TLVs is included in the DNS name 235 label in hexadecimal notation. There are more compact encoding that 236 avoid these problems, such as a customization of Bootstring similar 237 to Punycode [RFC3492] or Base32 [RFC4648] but for simplicity and to 238 make the encoding into names more easily readable for debugging and 239 other purpose hexdecimal was chosen. 241 2.2.2. Requirements Types and Value Encoding 243 The following types of service requirement are initially defined: 245 Coarse: A general indication of the most important service being 246 sought encoded as a one byte integer patterned after the IPv4 ToS 247 (Type of Service) value specified in [RFC1349]. (This is "coarse" 248 in contrast with the more precise service requirements defined 249 below.) The following values are defined: 251 0x00 Normal service. 253 0x01 Minimize cost. 255 0x02 Maximize reliability. 257 0x04 Maximize throughput. 259 0x08 Minimize delay. 261 0x10 Minimize jitter. 263 Bandwidth: The bandwidth requirement is encoded as a float32 (32-bit 264 IEEE floating point format [ieee754] number). The unit is bits 265 per second. If more than one TLV of this type occurs in a DNS 266 name, all but the first (leftmost) are ignored. 268 Delay: The delay requirement is encoded in 24-bit integer format. 269 The unit is microseconds. If more than one TLV of this type 270 occurs in a DNS name, all but the first (leftmost) are ignored. 272 Jitter: The jitter (i.e., delay variation) is encoded in 24-bit 273 integer format. The unit is microsecond. If more than one TLV of 274 this type occurs in a DNS name, all but the first (leftmost) are 275 ignored. 277 Loss Rate: This lost rate (i.e., the percentage of packet loss) is 278 encoded in 24-bit integer format. The basic unit is 0.0000001% 279 (i.e., one packet drop per 1 billion packets), where (2^24 - 2) = 280 1.6777214% is the largest possible loss rate defined, 2^24-1 means 281 no loss rate requirement, and 0 means the drop rate should be 282 smaller than 0.0000001%. If more than one TLV of this type occurs 283 in a DNS name, all but the first (leftmost) are ignored. 285 Using IEEE 32-bit floating point for the values when appropriate 286 provides a compact notation that can encode up to approximately 10^38 287 and down to approximately 10^-38 with 6 to 9 significant digits of 288 precision [ieee754]. 290 2.2.3. Complete QoS DNS Names 292 The on-the-wire encoding of a domain name beginning with a service 293 requirement label would be as shown in Figure 2 below. (In the DNS 294 wire encoding, each label is preceded by a length.) 296 +-------+-------+-----+ +-----+--------------------------------+ 297 |length |prefix |TLV1 |...|TLVn |Encoded Remainder of Domain Name| 298 +-------+-------+-----+ +-----+--------------------------------+ 300 Figure 2: Name Wire Encoding Style 1 302 Alternatively, service requirements could split among a sequence of 303 two or more labels in a DNS name to be queried, as shown in Figure 3. 305 +-------+------+----+ +-------+------+----+-----------------+ 306 |length |prefix|TLV1|...|length |prefix|TLVn|Remainder of Name| 307 +-------+------+----+ +-------+------+----+-----------------+ 309 Figure 3: Name Encoding Style 2 311 The display presentation of a DNS name requesting a coarse QoS 312 requirement for minimum delay for communication with example.com 313 would be as shown in Figure 4 314 qs-- Prefix 315 1 TLV Type 316 1 TLV Length 317 08 TLV Value 318 example.com Remainder of domain name 320 qs--1108.example.com. Complete domain name 322 Figure 4: Example DNS Name 324 3. Security Considerations 326 TBD 328 4. IANA Considerations 330 This section conforms to [RFC8126]. 332 IANA is requested to create the following registries. 334 4.1. Requirements Label Type Codes 336 IANA is requested to create a registry on the Domain Name System 337 (DNS) Parameters webpage as follows: 339 Name: DNS QoS Requirements Label Type Codes 340 Registration Procedure: IETF review. 341 Reference: [this document] 343 Code Description Reference 344 ------ ------------- ----------------- 345 0 reserved 346 1 Coarse QoS [this document] 347 2 Bandwidth [this document] 348 3 Delay [this document] 349 4 Jitter [this document] 350 5 Loss Rate [this document] 351 6-14 unassigned 352 15 extended 354 4.2. Restricted LDH Label Prefixes 356 LDH labels are specified in [RFC5890] as consisting of letters, 357 digits, and hyphen but not beginning or ending with a hyphen. That 358 is, strings of length from 1 through 63 that match the ABNF 359 (Augmented Backus-Naur Form [RFC5234]) expression for LDH below. 361 * LD = ( a-z / 0-9 ) ;letter or digit (case insensitive) 362 * HYPH = %x2D ;hyphen / minus 364 * LDH = LD / HYPH 366 * LDH-LABEL = LD / LD 0*61LDH LD 368 R-LDH (Restricted LDH) labels are specified in [RFC5890] as the 369 subset of LDH-LABELs that begin with two letters/digits followed by 370 two hyphens. That is, they are LDH-LABELs that match the ABNF 371 regular expression [RFC5234] below. 373 * R-LDH-LABEL = 2LD HYPH HYPH 0*58LDH LD 375 4.2.1. R-LDH Registry 377 IANA is requested to create a registry on the Domain Name System 378 (DNS) Parameters webpage as follows: 380 Name: DNS Restricted LDH (R-LDH) Label Prefixes 381 Registration Procedure: Expert review. 382 Reference: [this document] 384 Prefix Description Reference 385 ------ --------------------- ----------- 386 qs-- QoS Requirements [this document] 387 xn-- Internationalization [RFC5820] 389 4.2.2. R-LDH Expert Guidance 391 In reviewing applications for the assignment of an R-LDH prefix, the 392 Expert should keep in mind the following guidance: 394 * The use of labels with the requested prefix must meet the 395 following criteria: 397 - be documented in an Internet Draft, 399 - not significantly duplicate the use of any other R-LDH prefix, 400 and 402 - not require any changes to DNS protocol messages or DNS 403 mechanisms such as the handling of CNAME or DNAME RRs or 404 wildcards. 406 * Assignment of more than one R-LDH for a purpose is prohibited. If 407 it is necessary to distinguish sub-uses under an R-LDH prefix, 408 this should be done by encoding within the R-LDH label after the 409 prefix or by a further label or labels before the R-LDH label, 410 such as a label beginning with underscore ("_"). 412 * Prefixes where the first or second character is any of the digits 413 "0", "1", and "5"or the letters "O", "I", "L", and "S" should not 414 be assigned, due to the possibilities of confusion, unless there 415 are strong reasons to use these characters. 417 5. Acknowledgments 419 The suggestions of the following are gratefully acknowledged: 421 * TBD 423 6. References 425 6.1. Normative References 427 [ieee754] IEEE 754 WG, IEEE., "IEEE 754-2019 - IEEE Standard for 428 Floating-Point Arithmetic", 2019, 429 . 431 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 432 RFC 20, DOI 10.17487/RFC0020, October 1969, 433 . 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, 437 DOI 10.17487/RFC2119, March 1997, 438 . 440 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case 441 Insensitivity Clarification", RFC 4343, 442 DOI 10.17487/RFC4343, January 2006, 443 . 445 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 446 Specifications: ABNF", STD 68, RFC 5234, 447 DOI 10.17487/RFC5234, January 2008, 448 . 450 [RFC5820] Roy, A., Ed. and M. Chandra, Ed., "Extensions to OSPF to 451 Support Mobile Ad Hoc Networking", RFC 5820, 452 DOI 10.17487/RFC5820, March 2010, 453 . 455 [RFC5890] Klensin, J., "Internationalized Domain Names for 456 Applications (IDNA): Definitions and Document Framework", 457 RFC 5890, DOI 10.17487/RFC5890, August 2010, 458 . 460 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 461 Writing an IANA Considerations Section in RFCs", BCP 26, 462 RFC 8126, DOI 10.17487/RFC8126, June 2017, 463 . 465 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 466 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 467 May 2017, . 469 6.2. Informative References 471 [RFC1035] Mockapetris, P., "Domain names - implementation and 472 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 473 November 1987, . 475 [RFC1349] Almquist, P., "Type of Service in the Internet Protocol 476 Suite", RFC 1349, DOI 10.17487/RFC1349, July 1992, 477 . 479 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 480 specifying the location of services (DNS SRV)", RFC 2782, 481 DOI 10.17487/RFC2782, February 2000, 482 . 484 [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode 485 for Internationalized Domain Names in Applications 486 (IDNA)", RFC 3492, DOI 10.17487/RFC3492, March 2003, 487 . 489 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 490 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 491 . 493 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 494 for DNS (EDNS(0))", STD 75, RFC 6891, 495 DOI 10.17487/RFC6891, April 2013, 496 . 498 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 499 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 500 January 2019, . 502 [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource 503 Records through "Underscored" Naming of Attribute Leaves", 504 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 505 . 507 Authors' Addresses 509 Donald Eastlake 510 Futurewei Technologies 511 2386 Panoramic Circle 512 Apopka, FL 32703 513 United States of America 514 Phone: +1-508-333-2270 515 Email: donald.eastlake@futurewei.com 517 Haoyu Song 518 Futurewei Technologies 519 2220 Central Expressway 520 Santa Clara, CA 95050 521 United States of America 522 Email: haoyu.song@futurewei.com