[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

DNSOP Working Group                                         J. Woodworth
Internet-Draft                                                 D. Ballew
Updates: 2308, 4033, 4034, 4035 (if                    CenturyLink, Inc.
         approved)                            S. Bindinganaveli Raghavan
Intended status: Standards Track                  Hughes Network Systems
Expires: January 22, 2020                                    D. Lawrence
                                                                  Oracle
                                                           July 21, 2019


                  Numeric Pattern Normalization (NPN)
                         draft-woodworth-npn-00

Abstract

   The Numeric Pattern Normalization (NPN) resource record provides pre-
   processing information to reduce the number of possible variants
   which can be generated by pattern-based RR's into a single signable
   record.

Ed note

   Text inside square brackets ([]) is additional background
   information, answers to frequently asked questions, general musings,
   etc.  They will be removed before publication.  This document is
   being collaborated on in GitHub at <https://github.com/ioneyez/npn>.
   The most recent version of the document, open issues, etc should all
   be available here.  The authors gratefully accept pull requests.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 22, 2020.






Woodworth, et al.       Expires January 22, 2020                [Page 1]


Internet-Draft                     NPN                         July 2019


Copyright Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Background and Terminology  . . . . . . . . . . . . . . .   3
   2.  The NPN Resource Record . . . . . . . . . . . . . . . . . . .   3
     2.1.  NPN RDATA Wire Format . . . . . . . . . . . . . . . . . .   3
     2.2.  The NPN RR Presentation Format  . . . . . . . . . . . . .   5
     2.3.  Use and Normalization Processing of NPN RRs . . . . . . .   5
       2.3.1.  Pseudocode for NPN Normalization Processing . . . . .   6
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     3.1.  Normalized (NPN-Based) Signatures . . . . . . . . . . . .   7
   4.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  NPN Examples . . . . . . . . . . . . . . . . . . . .   9
     A.1.  EXAMPLE 1 . . . . . . . . . . . . . . . . . . . . . . . .   9
     A.2.  EXAMPLE 2 . . . . . . . . . . . . . . . . . . . . . . . .  10
     A.3.  EXAMPLE 3 . . . . . . . . . . . . . . . . . . . . . . . .  11
     A.4.  EXAMPLE 4 . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   The Numeric Pattern Normalization (NPN) resource record provides
   methods to generate DNSSEC signatures for pattern-based "synthesized"
   RR's, and validation of such signatures.  It does this by introducing
   a pre-processing step of pattern substitution into both the signing
   and validating processes.





Woodworth, et al.       Expires January 22, 2020                [Page 2]


Internet-Draft                     NPN                         July 2019


1.1.  Background and Terminology

   The reader is assumed to be familiar with the basic DNS and DNSSEC
   concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034], and
   [RFC4035]; subsequent RFCs that update them in [RFC2181] and
   [RFC2308]; and DNS terms in [RFC7719].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  The NPN Resource Record

   The Numeric Pattern Normalization (NPN) resource record provides pre-
   processing information to reduce the number of possible variants that
   can be generated by a pattern-based RR into one signable record.  By
   identifying parts of the dynamic resource record which should be
   ignored or represented as a static value, one exemplar record and
   signature is used to validate all other records that match the
   pattern.

   For example, a pattern replacement like pool-A-${1}-${2}.example.com
   that generates PTR records for pool-A-0-0.example.com through pool-
   A-255-255.example.com would have an NPN record that signals a
   validating resolver to verify all pool-A-#-#.example.com names
   against a record for pool-A-9-9.example.com.

   Though it is conceivable that forged records could be validated as
   legitimate, such forged records must meet strict criteria and match
   patterns which define and are considered legitimate.  The added
   measure is a notable improvement in security over being hosted in
   insecure zones.

   The Type value for the NPN RR type is TBD.

   The NPN RR is class independent and has no special TTL requirements.

2.1.  NPN RDATA Wire Format

   The RDATA for an NPN RR consists of a 2 octet Match Type field, a 1
   octet Flags field, a 1 octet Owner Ignore field, a 1 octet Left
   Ignore field and a 1 octet Right Ignore field.









Woodworth, et al.       Expires January 22, 2020                [Page 3]


Internet-Draft                     NPN                         July 2019


                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Match Type          |     Flags     |  Owner Ignore |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Left Ignore  |  Right Ignore |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Match Type indicates the type of the RRset with which this record is
   associated.

   Flags defines additional processing parameters for data
   normalization.  This document defines only the Period-As-Number flag
   "." (position 5), the Hyphen-As-Number "-" (position 6) and the
   hexadecimal flag "X" (position 7).  All other flags are reserved for
   future use.

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |Reserved |.|-|X|
   +-+-+-+-+-+-+-+-+

   Bits 0-4: Reserved for future

   Bit    5: Period As Number (.) Flag
      If 0, periods are treated as non-digits.
      If 1, periods will be processed as digits.

   Bit    6: Hyphen As Number (-) Flag
      If 0, hyphens are treated as non-digits.
      If 1, hyphens will be processed as digits.

   Bit    7: Hexadecimal (X) Flag
      If 0, numeric digits include only 0-9.
      If 1, numeric digits include a-f in addition to 0-9.

   Owner Ignore defines the number of octets in the owner name, as
   counted from the left, which MUST be ignored by the normalization
   process.  This field offers additional security to pattern based
   signatures which may not be immediately apparent.  By restricting the
   leftmost characters defined by this value, ultimately the length of
   the generated portion of the accompanying synthesized RR will be
   confined accordingly.

   Left Ignore defines the number of octets of the generated RDATA, as
   counted from the left, which MUST be ignored by the normalization
   process.




Woodworth, et al.       Expires January 22, 2020                [Page 4]


Internet-Draft                     NPN                         July 2019


   Right Ignore defines the number of octets of the generated RDATA, as
   counted from the right, which MUST be ignored by the normalization
   process.

2.2.  The NPN RR Presentation Format

   Match Type is represented as an RR type mnemonic or with [RFC3597]'s
   generic TYPE mechanism.

   Flags is a string of characters indicating the status of each bit as
   per the following table.  The characters can appear in any order.

   +------------------+-----------+-----------+
   |       Flag       |   Unset   |    Set    |
   +------------------+-----------+-----------+
   | Period As Number |           |     .     |
   +------------------+-----------+-----------+
   | Hyphen As Number |           |     -     |
   +------------------+-----------+-----------+
   |   Hexadecimal    |     9     |     f     |
   +------------------+-----------+-----------+

   Owner Ignore, Left Ignore, and Right Ignore are displayed as unsigned
   decimal integers, ranging from 0 through 255.

2.3.  Use and Normalization Processing of NPN RRs

   This document provides a minor yet significant modification to DNSSEC
   regarding how RRsets will be signed or verified.  Specifically the
   Signature Field of [RFC4034], Section 3.1.8.  Prior to processing
   into canonical form, signed zones may contain associated RRs where;
   owner, class and type of a non NPN RR directly corresponds with an
   NPN RR matching owner, class and Match Type.  If this condition
   exists the NPN RR's RDATA defines details for processing the
   associated RDATA into a "Normalized" format.  Normalized data is
   based on pre-canonical formatting and zero padded for "A" and "AAAA"
   RR types for acceptable precision during the process.  This concept
   will become clearer in the NPN pseudocode and examples provided in
   the sections to follow.

   The rules for this transformation are simple:

   o  For RR's Owner field, characters from the beginning to the index
      of the Owner Ignore value or the final string of characters
      belonging to the zone's ORIGIN MUST NOT be modified by this
      algorithm.  This value is intended to provide additional
      limitations on the query portion further minimizing the risk of
      spoofed RR's matching NPN-based signatures.



Woodworth, et al.       Expires January 22, 2020                [Page 5]


Internet-Draft                     NPN                         July 2019


   o  For RR's RDATA field, character from beginning to the index of
      Left Ignore value or characters with index of Right Ignore value
      to the end MUST NOT be modified by this algorithm.

   o  In the remaining portion of both Owner and RDATA strings of
      numeric data, defined as character "0" through "f" or "0" through
      "9" depending on whether or not the Hexadecimal flag is set or
      not, MUST be consolidated to a single character and set to the
      highest value defined by the Hexadecimal flag.  Examples may be
      found in the following section.  If period-as-number or hyphen-as-
      number flags are set whichever are used ("." or "-") would be
      treated as part of the number and consolidated where appropriate.

   Once the normalization has been performed the signature will continue
   processing into canonical form using the normalized RRs in the place
   of original ones.

   If multiple NPN RR's resolve to the same owner and type, it MUST be
   assumed either multiple overlapping pattern-based generation RR's
   coexist for the same owner.  In this scenario, the validation
   algorithm SHOULD be attempted against all NPN RR's until a successful
   validation is found or no NPN's for this owner and type remain.
   While multiple overlapping pattern-based generation SHOULD be
   discouraged, future pattern-based RR's may necessitate this condition
   so it must be accounted for.

   NPN RRs MAY be included in the "Additional" section to provide a hint
   of the NPN processing required for the verification path.

   It is important to note, properly sizing the Ignore fields is
   critical to minimizing the risk of spoofed signatures.  Never
   intentionally set all Ignore values to zero in order to make
   validation easier as it places the validity of zone data at risk.
   Only accompany RRs which are pattern derived (such as BULK) with NPN
   records as doing so may unnecessarily reduce the confidence level of
   generated signatures.

2.3.1.  Pseudocode for NPN Normalization Processing

   This section provides a simple demonstration of process flow for NPN
   rdata normalization and DNSSEC signatures.

   The pseudocode provided below assumes all associated RRs are valid
   members of a DNSSEC-compatible RRset, including pattern-generated
   ones.






Woodworth, et al.       Expires January 22, 2020                [Page 6]


Internet-Draft                     NPN                         July 2019


      for rr in rrset
          if (has_NPN<rr.owner, rr.class, rr.type>)
              rr.rdata_normal = NPN_normalize<rr.rdata>
              add_to_sigrrset<NPN.owner, rr.class, rr.type,
                  rr.rdata_normal>
              next
          else
              add_to_sigrrset<rr.owner, rr.class, rr.type, rr.rdata>
              next

      process_canonical_form<sigrrset>

      dnssec_sign<sigrrset>

   Similar logic MUST be used for determining DNSSEC validity of RRsets
   in validating nameservers for signatures generated based on NPN
   normalization.

3.  Security Considerations

   The NPN RR is intended to be used only with the offline-signing of
   pattern-based RR's where there is an expected minimal security
   impact.  Use of NPN RR's for other purposes is strongly discouraged
   and falls outside the scope of this document.

3.1.  Normalized (NPN-Based) Signatures

   This solution provides a flexible solution as nameservers without on-
   the-fly signing capabilities can still support signatures for
   pattern-based records.  The down side to this solution is it requires
   NPN resolver support for validation.

   It has been pointed out that due to this limitation, creation of
   DNSSEC-signed pattern-based RRs requiring NPN support SHOULD be
   formally discouraged until such time a respectable percentage (>80%)
   of validating resolvers in-the-wild possess NPN processing
   capabilities.  Until that time, on-the-fly signing and unsigned
   records offer the intended capabilities for pattern-based RR's, while
   requiring zero new features to support their resolution.  Given
   enough time, enough nameservers will be patched and upgraded for
   unrelated reasons and by means of simple attrition can supply a level
   of inertia and eventually widespread adoption can be assumed.

4.  Privacy Considerations

   NPN records do not introduce any new privacy concerns to DNS data.





Woodworth, et al.       Expires January 22, 2020                [Page 7]


Internet-Draft                     NPN                         July 2019


5.  IANA Considerations

   IANA is requested to assign numbers for the NPN DNS resource record
   type identified in this document.

6.  Acknowledgments

   This document was created as an extension to the DNS infrastructure.
   As such, many people over the years have contributed to its creation
   and the authors are appreciative to each of them even if not thanked
   or identified individually.

   A special thanks is extended for the kindness, wisdom and technical
   advice of Robert Whelton (CenturyLink, Inc.) and Gary O'Brien
   (Secure64).

7.  References

7.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
              <https://www.rfc-editor.org/info/rfc2181>.

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
              <https://www.rfc-editor.org/info/rfc2308>.

   [RFC2317]  Eidnes, H., de Groot, G., and P. Vixie, "Classless IN-
              ADDR.ARPA delegation", BCP 20, RFC 2317,
              DOI 10.17487/RFC2317, March 1998,
              <https://www.rfc-editor.org/info/rfc2317>.






Woodworth, et al.       Expires January 22, 2020                [Page 8]


Internet-Draft                     NPN                         July 2019


   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
              (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September
              2003, <https://www.rfc-editor.org/info/rfc3597>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/info/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/info/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/info/rfc4035>.

7.2.  Informative References

   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
              2015, <https://www.rfc-editor.org/info/rfc7719>.

Appendix A.  NPN Examples

A.1.  EXAMPLE 1

   2.10.in-addr.arpa. 86400 IN BULK PTR (
                                    [0-255].[0-10].2.10.in-addr.arpa.
                                    pool-A-${1}-${2}.example.com.
                               )
   2.10.in-addr.arpa. 86400 IN NPN  PTR 9 0 7 13

   For the BULK RR used in this example, a query for the PTR of address
   10.2.3.44 would match the for the query name 44.3.2.10.in-addr.arpa,
   resulting in the generation of a PTR to pool-A-3-44.example.com as
   the response.

   By protecting the "Ignore" characters from the generated RR's RDATA
   the focus for normalization becomes "3-44" as illustrated below.









Woodworth, et al.       Expires January 22, 2020                [Page 9]


Internet-Draft                     NPN                         July 2019


     0 1 2 3 4 5 6 7
                   v---------
       p o o l - A - 3 - 4 4 . e x a m p l e . c o m .
                    ---------^
                             1 1 1 1
                             3 2 1 0 9 8 7 6 5 4 3 2 1 0

   Everything to the left of "3-44" will remain intact, as will
   everything to its right.  The remaining characters will be processed
   for digits between 0 and 9 as indicated by the NPN record's
   hexadecimal flag 9, and each run of digits replaced by the single
   character "9".  The final Normalized RDATA for *.2.10.in-addr.arpa
   would therefore become pool-A-9-9.example.com., and its signature
   would be based on this value to cover all possible permutations of
   the pool-A-${1}-${2}.example.com replacement pattern.

   Since the validating nameserver would use the identical NPN record
   for processing and comparison, all RRs generated by the BULK record
   can now be verified with a single signature.

A.2.  EXAMPLE 2

   This example contains a classless IPv4 delegation on the /22 CIDR
   boundary as defined by [RFC2317].  The network for this example is
   "10.2.0/22" delegated to a nameserver "ns1.sub.example.com.".  RRs
   for this example are defined as:

   $ORIGIN 2.10.in-addr.arpa.
   0-3 86400 IN      NS    ns1.sub.example.com.
       86400 IN BULK CNAME [0-255].[0-3] ${*|.}.0-3
       86400 IN NPN  CNAME 9 0 0 23

   For this example, a query of "10.2.2.65" would enter the nameserver
   as "65.2.2.10.in-addr.arpa." and a "CNAME" RR with the RDATA of
   "65.2.0-3.2.10.in-addr.arpa." would be generated.

   By protecting the "Ignore" characters from the generated RR's RDATA
   the focus for normalization becomes "65.2" as illustrated below.

          0
          v---------
            6 5 . 2 . 0 - 3 . 2 . 1 0 . i n - a d d r . a r p a .
           ---------^
                    2 2 2 2 1 1 1 1 1 1 1 1 1 1
                    3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0

   Everything to the left of "65.2" will remain intact as will
   everything to its right.  The remaining characters will be processed



Woodworth, et al.       Expires January 22, 2020               [Page 10]


Internet-Draft                     NPN                         July 2019


   for digits from 0 through 9 as indicated by the NPN record's
   hexadecimal flag "9", with each run replaced by the single character
   "9".  The final normalized RDATA would therefore become 9.9.0-
   3.2.10.in-addr.arpa and its signature would be based on this
   normalized RDATA field.  This new normalized string would be used as
   an RDATA for the wildcard label of 2.10.in-addr.arpa now encompassing
   all possible permutations of the ${*|.}.0-3.2.10.in-addr.arpa.
   pattern.

   As in example 1, the validatating resolver would use the same NPN
   record for comparison.

A.3.  EXAMPLE 3

   This example provides reverse logic for example 1 by providing an
   IPv4 address record for a requested hostname.  For this example the
   query is defined as an A record for pool-A-3-44.example.com, with an
   origin of example.com.  RRs for this example are defined as:

   example.com. 86400 IN BULK A (
                                      pool-A-[0-10]-[0-255]
                                      10.2.${*}
                                     )
   example.com. 86400 IN NPN  A 9 0 8 0

   By protecting the "Ignore" characters from the generated RR's RDATA
   the focus for normalization becomes "003.044" as illustrated below.

                   0 1 2 3 4 5 6 7 8
                                   v--------------
                     0 1 0 . 0 0 2 . 0 0 3 . 0 4 4
                                    ---------------^
                                                   0

   This example illustrates a key point about NPN records; since they
   are pre-canonical they MUST operate on a strict subset of WIRE
   formatted data.  For A and AAAA records this means the "Ignore"
   fields are based on zero padded data.  In this example our generated
   record MUST be converted into "010.002.003.044" (shown above) prior
   to processing.  After processing, wire format would become
   "0x0A02032C" (shown in hexadecimal).  This format would be too
   imprecise for normalization so padded decimal is used.

   Everything to the left of "003.044" will remain intact as will
   everything to its right.  The remaining characters will be processed
   for digits between 0 and 9 as indicated by the NPN record's
   hexadecimal flag "9" and each run replaced by the single character
   "9".  The final Normalized RDATA would therefore become 10.2.9.9 and



Woodworth, et al.       Expires January 22, 2020               [Page 11]


Internet-Draft                     NPN                         July 2019


   its signature would be based on this normalized RDATA field.  This
   new normalized A RR would be used as an RDATA for the wildcard label
   of "*.example.com." now encompassing all possible permutations of the
   10.2.${*} pattern.

A.4.  EXAMPLE 4

   This example provides similar logic for an IPv6 AAAA record.  For
   this example the query is defined as an AAAA record for pool-A-ff-
   aa.example.com with an origin of example.com..  RRs for this example
   are defined as:

   example.com. 86400 IN BULK AAAA (
                                      pool-A-[0-ffff]-[0-ffff]
                                      fc00::${1}:${2}
                                   )
   example.com. 86400 IN NPN  AAAA X 0 30 0

   By protecting the "Ignore" characters from the generated RR's RDATA
   the focus for normalization becomes "00ff:00aa" as illustrated below.

                         1 1 1 1 1 1 1 1 1 1 2 2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

       f c 0 0 : 0 0 0 0 : 0 0 0 0 : 0 0 0 0 : -/-/

     4 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 1
     0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9
      /-/-/- . . . . . . . . . . . . . . . . . . . . . . . . -/-/-/
                             2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4
                             1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
                                               v------------------
                        /-/- 0 0 0 0 : 0 0 0 0 : 0 0 f f : 0 0 a a
                                                -------------------^
                           2 1 1 1 1 1 1 1 1 1 1
                           0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0

   This example reinforces the point on pre-canonical processing of NPN
   records; they MUST operate on a strict subset of WIRE formatted data.
   For A and AAAA records this means the "Ignore" fields are based on
   zero padded data.  In this example our generated record MUST be
   converted into "fc00:0000:0000:0000:0000:0000:00ff:00aa" (shown
   above) prior to processing.  After processing, wire format would
   become "0xFC000000000000000000000000FF00AA" (shown in hexadecimal).
   This format is slightly misleading as it is truly only 16 bytes of
   WIRE data and would be too imprecise for normalization so padded
   hexadecimal is used.




Woodworth, et al.       Expires January 22, 2020               [Page 12]


Internet-Draft                     NPN                         July 2019


   Everything to the left of "00ff:00aa" will remain intact as will
   everything to its right.  The remaining characters will be processed
   for numbers between "0" and "f" as indicated by the NPN record's
   hexadecimal flag "X" and each run replaced by the single character
   "f".  The final Normalized RDATA would therefore become "fc00::f:f"
   and its signature would be based on this "normalized" RDATA field.
   This new "normalized" "AAAA" RR would be used as an RDATA for the
   wildcard label of *.example.com now encompassing all possible
   permutations of the "fc00::${1}:${2}" pattern.

Authors' Addresses

   John Woodworth
   CenturyLink, Inc.
   4250 N Fairfax Dr
   Arlington  VA 22203
   USA

   Email: John.Woodworth@CenturyLink.com


   Dean Ballew
   CenturyLink, Inc.
   2355 Dulles Corner Blvd, Ste 200 300
   Herndon  VA 20171
   USA

   Email: Dean.Ballew@CenturyLink.com


   Shashwath Bindinganaveli Raghavan
   Hughes Network Systems
   11717 Exploration Lane
   Germantown  MD 20876
   USA

   Email: shashwath.bindinganaveliraghavan@hughes.com


   David C Lawrence
   Oracle

   Email: tale@dd.org








Woodworth, et al.       Expires January 22, 2020               [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/