idnits 2.17.1 draft-ietf-dnsind-binary-labels-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 an Abstract section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 5, 1999) is 9123 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) == Missing Reference: 'DNSSEC' is mentioned on line 224, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- No information found for draft-dnsind-edns0 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'EDNS0' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSIND Working Group Matt Crawford 2 Internet Draft Fermilab 3 May 5, 1999 5 Binary Labels in the Domain Name System 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet- Drafts as 19 reference material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 1. Introduction and Terminology 29 This document defines a ``Bit-String Label'' which may appear within 30 domain names. This new label type compactly represents a sequence 31 of ``One-Bit Labels'' and enables resource records to be stored at 32 any bit-boundary in a binary-named section of the domain name tree. 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in [KWORD]. 38 2. Motivation 40 Binary labels are intended to efficiently solve the problem of 41 storing data and delegating authority on arbitrary boundaries when 42 the structure of underlying name space is most naturally represented 43 in binary. 45 3. Label Format 47 Up to 256 One-Bit Labels can be grouped into a single Bit-String 48 Label. Within a Bit-String Label the most significant or "highest 49 level" bit appears first. This is unlike the ordering of DNS labels 50 themselves, which has the least significant or "lowest level" label 51 first. Nonetheless, this ordering seems to be the most natural and 52 efficient for representing binary labels. 54 Among consecutive Bit-String Labels, the bits in the first-appearing 55 label are less significant or "at a lower level" than the bits in 56 subsequent Bit-String Labels, just as ASCII labels are ordered. 58 3.1. Encoding 60 0 1 2 61 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . . 62 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+ 63 |0 1| ELT | Count | Label ... | 64 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+ 66 (Each tic mark represents one bit.) 68 ELT 000001 binary, the six-bit extended label type [EDNS0] 69 assigned to the Bit-String Label. 71 Count The number of significant bits in the Label field. A 72 Count value of zero indicates that 256 bits are 73 significant. (Thus the null label representing the DNS 74 root cannot be represented as a Bit String Label.) 76 Label The bit string representing a sequence of One-Bit Labels, 77 with the most significant bit first. That is, the One-Bit 78 Label in position 17 in the diagram above represents a 79 subdomain of the domain represented by the One-Bit Label 80 in position 16, and so on. 82 The Label field is padded on the right with zero to seven 83 pad bits to make the entire field occupy an integral 84 number of octets. These pad bits MUST be zero on 85 transmission and ignored on reception. 87 A sequence of bits may be split into two or more Bit-String Labels, 88 but the division points have no significance and need not be 89 preserved. An excessively clever server implementation might split 90 Bit-String Labels so as to maximize the effectiveness of message 91 compression [DNSIS]. A simpler server might divide Bit-String 92 Labels at zone boundaries, if any zone boundaries happen to fall 93 between One-Bit Labels. 95 3.2. Textual Representation 97 A Bit-String Label is represented in text -- in a zone file, for 98 example -- as a surrounded by the delimiters "\[" and 99 "]". The is either a dotted quad or a base indicator and 100 a sequence of digits appropriate to that base, optionally followed 101 by a slash and a length. The base indicators are "b", "o" and "x", 102 denoting base 2, 8 and 16 respectively. The length counts the 103 significant bits and MUST be between 1 and 32, inclusive, after a 104 dotted quad, or between 1 and 256, inclusive, after one of the other 105 forms. If the length is omitted, the implicit length is 32 for a 106 dotted quad or 1, 3 or 4 times the number of binary, octal or 107 hexadecimal digits supplied, respectively, for the other forms. 109 In augmented Backus-Naur form [ABNF], 111 bit-string-label = "\[" bit-spec "]" 113 bit-spec = bit-data [ "/" length ] 114 / dotted-quad [ "/" slength ] 116 bit-data = "x" 1*64HEXDIG 117 / "o" 1*86OCTDIG 118 / "b" 1*256BIT 120 dotted-quad = decbyte "." decbyte "." decbyte "." decbyte 122 decbyte = 1*3DIGIT 124 length = NZDIGIT *2DIGIT 126 slength = NZDIGIT [ DIGIT ] 128 OCTDIG = %x30-37 130 NZDIGIT = %x31-39 132 If a is present, the number of digits in the 133 MUST be just sufficient to contain the number of bits specified by 134 the . If there are insignificant bits in a final 135 hexadecimal or octal digit, they MUST be zero. A 136 always has all four parts even if the associated is less 137 than 24, but, like the other forms, insignificant bits MUST be zero. 139 Each number represented by a must be between 0 and 255, 140 inclusive. 142 The number represented by must be between 1 and 256 143 inclusive. 145 The number represented by must be between 1 and 32 146 inclusive. 148 When the textual form of a Bit-String Label is generated by machine, 149 the length SHOULD be explicit, not implicit. 151 3.2.1. Examples 153 The following four textual forms represent the same Bit-String 154 Label. 156 \[b11010000011101] 157 \[o64072/14] 158 \[xd074/14] 159 \[208.116.0.0/14] 161 The following represents two consecutive Bit-String Labels which 162 denote the same relative point in the DNS tree as any of the above 163 single Bit-String Labels. 165 \[b11101].\[o640] 167 3.3. Canonical Representation and Sort Order 169 Both the wire form and the text form of binary labels have a degree 170 of flexibility in their grouping into multiple consecutive Bit- 171 String Labels. For generating and checking DNS signature records 172 [DNSSEC] binary labels must be in a predictable form. This 173 canonical form is defined as the form which has the fewest possible 174 Bit-String Labels and in which all except possibly the first (least 175 significant) label in any sequence of consecutive Bit-String Labels 176 is of maximum length. 178 For example, the canonical form of any sequence of up to 256 One-Bit 179 Labels has a single Bit-String Label, and the canonical form of a 180 sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of 181 which the second and third contain 256 label bits. 183 The canonical sort order of domain names [DNSSEC] is extended to 184 encompass binary labels as follows. Sorting is still label-by- 185 label, from most to least significant, where a label may now be a 186 One-Bit Label or a standard (code 00) label. Any One-Bit Label 187 sorts before any standard label, and a 0 bit sorts before a 1 bit. 188 The absence of a label sorts before any label, as specified in 189 [DNSSEC]. 191 For example, the following domain names are correctly sorted. 193 foo.example 194 \[b1].foo.example 195 \[b100].foo.example 196 \[b101].foo.example 197 bravo.\[b10].foo.example 198 alpha.foo.example 200 4. Processing Rules 202 A One-Bit Label never matches any other kind of label. In 203 particular, the DNS labels represented by the single ASCII 204 characters "0" and "1" do not match One-Bit Labels represented by 205 the bit values 0 and 1. 207 5. Discussion 209 A Count of zero in the wire-form represents a 256-bit sequence, not 210 to optimize that particular case, but to make it completely 211 impossible to have a zero-bit label. 213 6. IANA Considerations 215 This document defines one Extended Label Type, termed the Bit-String 216 Label, and requests registration of the code point 000001 binary in 217 the space defined by [EDNS0]. 219 7. Security Considerations 221 All security considerations which apply to traditional ASCII DNS 222 labels apply equally to binary labels. he canonicalization and 223 sorting rules of section 3.3 allow these to be addressed by DNS 224 Security [DNSSEC]. 226 8. References 228 [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 229 Specifications: ABNF", RFC 2234. 231 [DNSIS] P.V. Mockapetris, "Domain names - implementation and 232 specification", RFC 1035. 234 [DNSSEC]D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security 235 Extensions", RFC 2065. 237 [EDNS0] P. Vixie, "Extension mechanisms for DNS (EDNS0)", Currently 238 draft-dnsind-edns0-01.txt. 240 [KWORD] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels," RFC 2119. 243 9. Author's Address 245 Matt Crawford 246 Fermilab MS 368 247 PO Box 500 248 Batavia, IL 60510 249 USA 251 Phone: +1 630 840-3461 253 EMail: crawdad@fnal.gov