idnits 2.17.00 (12 Aug 2021) /tmp/idnits63607/draft-woodworth-npn-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The draft header indicates that this document updates RFC4034, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4035, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4033, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2308, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2308, updated by this document, for RFC5378 checks: 1997-01-17) -- 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 21, 2019) is 1028 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: '0-255' is mentioned on line 445, but not defined == Missing Reference: '0-10' is mentioned on line 403, but not defined == Missing Reference: '0-3' is mentioned on line 445, but not defined == Unused Reference: 'RFC3597' is defined on line 373, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP Working Group J. Woodworth 3 Internet-Draft D. Ballew 4 Updates: 2308, 4033, 4034, 4035 (if CenturyLink, Inc. 5 approved) S. Bindinganaveli Raghavan 6 Intended status: Standards Track Hughes Network Systems 7 Expires: January 22, 2020 D. Lawrence 8 Oracle 9 July 21, 2019 11 Numeric Pattern Normalization (NPN) 12 draft-woodworth-npn-00 14 Abstract 16 The Numeric Pattern Normalization (NPN) resource record provides pre- 17 processing information to reduce the number of possible variants 18 which can be generated by pattern-based RR's into a single signable 19 record. 21 Ed note 23 Text inside square brackets ([]) is additional background 24 information, answers to frequently asked questions, general musings, 25 etc. They will be removed before publication. This document is 26 being collaborated on in GitHub at . 27 The most recent version of the document, open issues, etc should all 28 be available here. The authors gratefully accept pull requests. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 22, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 1.1. Background and Terminology . . . . . . . . . . . . . . . 3 66 2. The NPN Resource Record . . . . . . . . . . . . . . . . . . . 3 67 2.1. NPN RDATA Wire Format . . . . . . . . . . . . . . . . . . 3 68 2.2. The NPN RR Presentation Format . . . . . . . . . . . . . 5 69 2.3. Use and Normalization Processing of NPN RRs . . . . . . . 5 70 2.3.1. Pseudocode for NPN Normalization Processing . . . . . 6 71 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 3.1. Normalized (NPN-Based) Signatures . . . . . . . . . . . . 7 73 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 75 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 7.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Appendix A. NPN Examples . . . . . . . . . . . . . . . . . . . . 9 80 A.1. EXAMPLE 1 . . . . . . . . . . . . . . . . . . . . . . . . 9 81 A.2. EXAMPLE 2 . . . . . . . . . . . . . . . . . . . . . . . . 10 82 A.3. EXAMPLE 3 . . . . . . . . . . . . . . . . . . . . . . . . 11 83 A.4. EXAMPLE 4 . . . . . . . . . . . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 The Numeric Pattern Normalization (NPN) resource record provides 89 methods to generate DNSSEC signatures for pattern-based "synthesized" 90 RR's, and validation of such signatures. It does this by introducing 91 a pre-processing step of pattern substitution into both the signing 92 and validating processes. 94 1.1. Background and Terminology 96 The reader is assumed to be familiar with the basic DNS and DNSSEC 97 concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], and 98 [RFC4035]; subsequent RFCs that update them in [RFC2181] and 99 [RFC2308]; and DNS terms in [RFC7719]. 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. The NPN Resource Record 107 The Numeric Pattern Normalization (NPN) resource record provides pre- 108 processing information to reduce the number of possible variants that 109 can be generated by a pattern-based RR into one signable record. By 110 identifying parts of the dynamic resource record which should be 111 ignored or represented as a static value, one exemplar record and 112 signature is used to validate all other records that match the 113 pattern. 115 For example, a pattern replacement like pool-A-${1}-${2}.example.com 116 that generates PTR records for pool-A-0-0.example.com through pool- 117 A-255-255.example.com would have an NPN record that signals a 118 validating resolver to verify all pool-A-#-#.example.com names 119 against a record for pool-A-9-9.example.com. 121 Though it is conceivable that forged records could be validated as 122 legitimate, such forged records must meet strict criteria and match 123 patterns which define and are considered legitimate. The added 124 measure is a notable improvement in security over being hosted in 125 insecure zones. 127 The Type value for the NPN RR type is TBD. 129 The NPN RR is class independent and has no special TTL requirements. 131 2.1. NPN RDATA Wire Format 133 The RDATA for an NPN RR consists of a 2 octet Match Type field, a 1 134 octet Flags field, a 1 octet Owner Ignore field, a 1 octet Left 135 Ignore field and a 1 octet Right Ignore field. 137 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Match Type | Flags | Owner Ignore | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Left Ignore | Right Ignore | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Match Type indicates the type of the RRset with which this record is 146 associated. 148 Flags defines additional processing parameters for data 149 normalization. This document defines only the Period-As-Number flag 150 "." (position 5), the Hyphen-As-Number "-" (position 6) and the 151 hexadecimal flag "X" (position 7). All other flags are reserved for 152 future use. 154 0 1 2 3 4 5 6 7 155 +-+-+-+-+-+-+-+-+ 156 |Reserved |.|-|X| 157 +-+-+-+-+-+-+-+-+ 159 Bits 0-4: Reserved for future 161 Bit 5: Period As Number (.) Flag 162 If 0, periods are treated as non-digits. 163 If 1, periods will be processed as digits. 165 Bit 6: Hyphen As Number (-) Flag 166 If 0, hyphens are treated as non-digits. 167 If 1, hyphens will be processed as digits. 169 Bit 7: Hexadecimal (X) Flag 170 If 0, numeric digits include only 0-9. 171 If 1, numeric digits include a-f in addition to 0-9. 173 Owner Ignore defines the number of octets in the owner name, as 174 counted from the left, which MUST be ignored by the normalization 175 process. This field offers additional security to pattern based 176 signatures which may not be immediately apparent. By restricting the 177 leftmost characters defined by this value, ultimately the length of 178 the generated portion of the accompanying synthesized RR will be 179 confined accordingly. 181 Left Ignore defines the number of octets of the generated RDATA, as 182 counted from the left, which MUST be ignored by the normalization 183 process. 185 Right Ignore defines the number of octets of the generated RDATA, as 186 counted from the right, which MUST be ignored by the normalization 187 process. 189 2.2. The NPN RR Presentation Format 191 Match Type is represented as an RR type mnemonic or with [RFC3597]'s 192 generic TYPE mechanism. 194 Flags is a string of characters indicating the status of each bit as 195 per the following table. The characters can appear in any order. 197 +------------------+-----------+-----------+ 198 | Flag | Unset | Set | 199 +------------------+-----------+-----------+ 200 | Period As Number | | . | 201 +------------------+-----------+-----------+ 202 | Hyphen As Number | | - | 203 +------------------+-----------+-----------+ 204 | Hexadecimal | 9 | f | 205 +------------------+-----------+-----------+ 207 Owner Ignore, Left Ignore, and Right Ignore are displayed as unsigned 208 decimal integers, ranging from 0 through 255. 210 2.3. Use and Normalization Processing of NPN RRs 212 This document provides a minor yet significant modification to DNSSEC 213 regarding how RRsets will be signed or verified. Specifically the 214 Signature Field of [RFC4034], Section 3.1.8. Prior to processing 215 into canonical form, signed zones may contain associated RRs where; 216 owner, class and type of a non NPN RR directly corresponds with an 217 NPN RR matching owner, class and Match Type. If this condition 218 exists the NPN RR's RDATA defines details for processing the 219 associated RDATA into a "Normalized" format. Normalized data is 220 based on pre-canonical formatting and zero padded for "A" and "AAAA" 221 RR types for acceptable precision during the process. This concept 222 will become clearer in the NPN pseudocode and examples provided in 223 the sections to follow. 225 The rules for this transformation are simple: 227 o For RR's Owner field, characters from the beginning to the index 228 of the Owner Ignore value or the final string of characters 229 belonging to the zone's ORIGIN MUST NOT be modified by this 230 algorithm. This value is intended to provide additional 231 limitations on the query portion further minimizing the risk of 232 spoofed RR's matching NPN-based signatures. 234 o For RR's RDATA field, character from beginning to the index of 235 Left Ignore value or characters with index of Right Ignore value 236 to the end MUST NOT be modified by this algorithm. 238 o In the remaining portion of both Owner and RDATA strings of 239 numeric data, defined as character "0" through "f" or "0" through 240 "9" depending on whether or not the Hexadecimal flag is set or 241 not, MUST be consolidated to a single character and set to the 242 highest value defined by the Hexadecimal flag. Examples may be 243 found in the following section. If period-as-number or hyphen-as- 244 number flags are set whichever are used ("." or "-") would be 245 treated as part of the number and consolidated where appropriate. 247 Once the normalization has been performed the signature will continue 248 processing into canonical form using the normalized RRs in the place 249 of original ones. 251 If multiple NPN RR's resolve to the same owner and type, it MUST be 252 assumed either multiple overlapping pattern-based generation RR's 253 coexist for the same owner. In this scenario, the validation 254 algorithm SHOULD be attempted against all NPN RR's until a successful 255 validation is found or no NPN's for this owner and type remain. 256 While multiple overlapping pattern-based generation SHOULD be 257 discouraged, future pattern-based RR's may necessitate this condition 258 so it must be accounted for. 260 NPN RRs MAY be included in the "Additional" section to provide a hint 261 of the NPN processing required for the verification path. 263 It is important to note, properly sizing the Ignore fields is 264 critical to minimizing the risk of spoofed signatures. Never 265 intentionally set all Ignore values to zero in order to make 266 validation easier as it places the validity of zone data at risk. 267 Only accompany RRs which are pattern derived (such as BULK) with NPN 268 records as doing so may unnecessarily reduce the confidence level of 269 generated signatures. 271 2.3.1. Pseudocode for NPN Normalization Processing 273 This section provides a simple demonstration of process flow for NPN 274 rdata normalization and DNSSEC signatures. 276 The pseudocode provided below assumes all associated RRs are valid 277 members of a DNSSEC-compatible RRset, including pattern-generated 278 ones. 280 for rr in rrset 281 if (has_NPN) 282 rr.rdata_normal = NPN_normalize 283 add_to_sigrrset 285 next 286 else 287 add_to_sigrrset 288 next 290 process_canonical_form 292 dnssec_sign 294 Similar logic MUST be used for determining DNSSEC validity of RRsets 295 in validating nameservers for signatures generated based on NPN 296 normalization. 298 3. Security Considerations 300 The NPN RR is intended to be used only with the offline-signing of 301 pattern-based RR's where there is an expected minimal security 302 impact. Use of NPN RR's for other purposes is strongly discouraged 303 and falls outside the scope of this document. 305 3.1. Normalized (NPN-Based) Signatures 307 This solution provides a flexible solution as nameservers without on- 308 the-fly signing capabilities can still support signatures for 309 pattern-based records. The down side to this solution is it requires 310 NPN resolver support for validation. 312 It has been pointed out that due to this limitation, creation of 313 DNSSEC-signed pattern-based RRs requiring NPN support SHOULD be 314 formally discouraged until such time a respectable percentage (>80%) 315 of validating resolvers in-the-wild possess NPN processing 316 capabilities. Until that time, on-the-fly signing and unsigned 317 records offer the intended capabilities for pattern-based RR's, while 318 requiring zero new features to support their resolution. Given 319 enough time, enough nameservers will be patched and upgraded for 320 unrelated reasons and by means of simple attrition can supply a level 321 of inertia and eventually widespread adoption can be assumed. 323 4. Privacy Considerations 325 NPN records do not introduce any new privacy concerns to DNS data. 327 5. IANA Considerations 329 IANA is requested to assign numbers for the NPN DNS resource record 330 type identified in this document. 332 6. Acknowledgments 334 This document was created as an extension to the DNS infrastructure. 335 As such, many people over the years have contributed to its creation 336 and the authors are appreciative to each of them even if not thanked 337 or identified individually. 339 A special thanks is extended for the kindness, wisdom and technical 340 advice of Robert Whelton (CenturyLink, Inc.) and Gary O'Brien 341 (Secure64). 343 7. References 345 7.1. Normative References 347 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 348 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 349 . 351 [RFC1035] Mockapetris, P., "Domain names - implementation and 352 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 353 November 1987, . 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, 357 DOI 10.17487/RFC2119, March 1997, 358 . 360 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 361 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 362 . 364 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 365 NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998, 366 . 368 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 369 ADDR.ARPA delegation", BCP 20, RFC 2317, 370 DOI 10.17487/RFC2317, March 1998, 371 . 373 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 374 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 375 2003, . 377 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 378 Rose, "DNS Security Introduction and Requirements", 379 RFC 4033, DOI 10.17487/RFC4033, March 2005, 380 . 382 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 383 Rose, "Resource Records for the DNS Security Extensions", 384 RFC 4034, DOI 10.17487/RFC4034, March 2005, 385 . 387 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 388 Rose, "Protocol Modifications for the DNS Security 389 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 390 . 392 7.2. Informative References 394 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 395 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 396 2015, . 398 Appendix A. NPN Examples 400 A.1. EXAMPLE 1 402 2.10.in-addr.arpa. 86400 IN BULK PTR ( 403 [0-255].[0-10].2.10.in-addr.arpa. 404 pool-A-${1}-${2}.example.com. 405 ) 406 2.10.in-addr.arpa. 86400 IN NPN PTR 9 0 7 13 408 For the BULK RR used in this example, a query for the PTR of address 409 10.2.3.44 would match the for the query name 44.3.2.10.in-addr.arpa, 410 resulting in the generation of a PTR to pool-A-3-44.example.com as 411 the response. 413 By protecting the "Ignore" characters from the generated RR's RDATA 414 the focus for normalization becomes "3-44" as illustrated below. 416 0 1 2 3 4 5 6 7 417 v--------- 418 p o o l - A - 3 - 4 4 . e x a m p l e . c o m . 419 ---------^ 420 1 1 1 1 421 3 2 1 0 9 8 7 6 5 4 3 2 1 0 423 Everything to the left of "3-44" will remain intact, as will 424 everything to its right. The remaining characters will be processed 425 for digits between 0 and 9 as indicated by the NPN record's 426 hexadecimal flag 9, and each run of digits replaced by the single 427 character "9". The final Normalized RDATA for *.2.10.in-addr.arpa 428 would therefore become pool-A-9-9.example.com., and its signature 429 would be based on this value to cover all possible permutations of 430 the pool-A-${1}-${2}.example.com replacement pattern. 432 Since the validating nameserver would use the identical NPN record 433 for processing and comparison, all RRs generated by the BULK record 434 can now be verified with a single signature. 436 A.2. EXAMPLE 2 438 This example contains a classless IPv4 delegation on the /22 CIDR 439 boundary as defined by [RFC2317]. The network for this example is 440 "10.2.0/22" delegated to a nameserver "ns1.sub.example.com.". RRs 441 for this example are defined as: 443 $ORIGIN 2.10.in-addr.arpa. 444 0-3 86400 IN NS ns1.sub.example.com. 445 86400 IN BULK CNAME [0-255].[0-3] ${*|.}.0-3 446 86400 IN NPN CNAME 9 0 0 23 448 For this example, a query of "10.2.2.65" would enter the nameserver 449 as "65.2.2.10.in-addr.arpa." and a "CNAME" RR with the RDATA of 450 "65.2.0-3.2.10.in-addr.arpa." would be generated. 452 By protecting the "Ignore" characters from the generated RR's RDATA 453 the focus for normalization becomes "65.2" as illustrated below. 455 0 456 v--------- 457 6 5 . 2 . 0 - 3 . 2 . 1 0 . i n - a d d r . a r p a . 458 ---------^ 459 2 2 2 2 1 1 1 1 1 1 1 1 1 1 460 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 462 Everything to the left of "65.2" will remain intact as will 463 everything to its right. The remaining characters will be processed 464 for digits from 0 through 9 as indicated by the NPN record's 465 hexadecimal flag "9", with each run replaced by the single character 466 "9". The final normalized RDATA would therefore become 9.9.0- 467 3.2.10.in-addr.arpa and its signature would be based on this 468 normalized RDATA field. This new normalized string would be used as 469 an RDATA for the wildcard label of 2.10.in-addr.arpa now encompassing 470 all possible permutations of the ${*|.}.0-3.2.10.in-addr.arpa. 471 pattern. 473 As in example 1, the validatating resolver would use the same NPN 474 record for comparison. 476 A.3. EXAMPLE 3 478 This example provides reverse logic for example 1 by providing an 479 IPv4 address record for a requested hostname. For this example the 480 query is defined as an A record for pool-A-3-44.example.com, with an 481 origin of example.com. RRs for this example are defined as: 483 example.com. 86400 IN BULK A ( 484 pool-A-[0-10]-[0-255] 485 10.2.${*} 486 ) 487 example.com. 86400 IN NPN A 9 0 8 0 489 By protecting the "Ignore" characters from the generated RR's RDATA 490 the focus for normalization becomes "003.044" as illustrated below. 492 0 1 2 3 4 5 6 7 8 493 v-------------- 494 0 1 0 . 0 0 2 . 0 0 3 . 0 4 4 495 ---------------^ 496 0 498 This example illustrates a key point about NPN records; since they 499 are pre-canonical they MUST operate on a strict subset of WIRE 500 formatted data. For A and AAAA records this means the "Ignore" 501 fields are based on zero padded data. In this example our generated 502 record MUST be converted into "010.002.003.044" (shown above) prior 503 to processing. After processing, wire format would become 504 "0x0A02032C" (shown in hexadecimal). This format would be too 505 imprecise for normalization so padded decimal is used. 507 Everything to the left of "003.044" will remain intact as will 508 everything to its right. The remaining characters will be processed 509 for digits between 0 and 9 as indicated by the NPN record's 510 hexadecimal flag "9" and each run replaced by the single character 511 "9". The final Normalized RDATA would therefore become 10.2.9.9 and 512 its signature would be based on this normalized RDATA field. This 513 new normalized A RR would be used as an RDATA for the wildcard label 514 of "*.example.com." now encompassing all possible permutations of the 515 10.2.${*} pattern. 517 A.4. EXAMPLE 4 519 This example provides similar logic for an IPv6 AAAA record. For 520 this example the query is defined as an AAAA record for pool-A-ff- 521 aa.example.com with an origin of example.com.. RRs for this example 522 are defined as: 524 example.com. 86400 IN BULK AAAA ( 525 pool-A-[0-ffff]-[0-ffff] 526 fc00::${1}:${2} 527 ) 528 example.com. 86400 IN NPN AAAA X 0 30 0 530 By protecting the "Ignore" characters from the generated RR's RDATA 531 the focus for normalization becomes "00ff:00aa" as illustrated below. 533 1 1 1 1 1 1 1 1 1 1 2 2 534 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 536 f c 0 0 : 0 0 0 0 : 0 0 0 0 : 0 0 0 0 : -/-/ 538 4 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 1 539 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 540 /-/-/- . . . . . . . . . . . . . . . . . . . . . . . . -/-/-/ 541 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4 542 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 543 v------------------ 544 /-/- 0 0 0 0 : 0 0 0 0 : 0 0 f f : 0 0 a a 545 -------------------^ 546 2 1 1 1 1 1 1 1 1 1 1 547 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 549 This example reinforces the point on pre-canonical processing of NPN 550 records; they MUST operate on a strict subset of WIRE formatted data. 551 For A and AAAA records this means the "Ignore" fields are based on 552 zero padded data. In this example our generated record MUST be 553 converted into "fc00:0000:0000:0000:0000:0000:00ff:00aa" (shown 554 above) prior to processing. After processing, wire format would 555 become "0xFC000000000000000000000000FF00AA" (shown in hexadecimal). 556 This format is slightly misleading as it is truly only 16 bytes of 557 WIRE data and would be too imprecise for normalization so padded 558 hexadecimal is used. 560 Everything to the left of "00ff:00aa" will remain intact as will 561 everything to its right. The remaining characters will be processed 562 for numbers between "0" and "f" as indicated by the NPN record's 563 hexadecimal flag "X" and each run replaced by the single character 564 "f". The final Normalized RDATA would therefore become "fc00::f:f" 565 and its signature would be based on this "normalized" RDATA field. 566 This new "normalized" "AAAA" RR would be used as an RDATA for the 567 wildcard label of *.example.com now encompassing all possible 568 permutations of the "fc00::${1}:${2}" pattern. 570 Authors' Addresses 572 John Woodworth 573 CenturyLink, Inc. 574 4250 N Fairfax Dr 575 Arlington VA 22203 576 USA 578 Email: John.Woodworth@CenturyLink.com 580 Dean Ballew 581 CenturyLink, Inc. 582 2355 Dulles Corner Blvd, Ste 200 300 583 Herndon VA 20171 584 USA 586 Email: Dean.Ballew@CenturyLink.com 588 Shashwath Bindinganaveli Raghavan 589 Hughes Network Systems 590 11717 Exploration Lane 591 Germantown MD 20876 592 USA 594 Email: shashwath.bindinganaveliraghavan@hughes.com 596 David C Lawrence 597 Oracle 599 Email: tale@dd.org