doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc2671.txt b/doc/rfc/rfc2671.txt
new file mode 100644
index 0000000..ec05f80
--- /dev/null
+++ b/doc/rfc/rfc2671.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                            P. Vixie
+Request for Comments: 2671                                            ISC
+Category: Standards Track                                     August 1999
+
+
+                  Extension Mechanisms for DNS (EDNS0)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The Domain Name System's wire protocol includes a number of fixed
+   fields whose range has been or soon will be exhausted and does not
+   allow clients to advertise their capabilities to servers.  This
+   document describes backward compatible mechanisms for allowing the
+   protocol to grow.
+
+1 - Rationale and Scope
+
+1.1. DNS (see [RFC1035]) specifies a Message Format and within such
+     messages there are standard formats for encoding options, errors,
+     and name compression.  The maximum allowable size of a DNS Message
+     is fixed.  Many of DNS's protocol limits are too small for uses
+     which are or which are desired to become common.  There is no way
+     for implementations to advertise their capabilities.
+
+1.2. Existing clients will not know how to interpret the protocol
+     extensions detailed here.  In practice, these clients will be
+     upgraded when they have need of a new feature, and only new
+     features will make use of the extensions.  We must however take
+     account of client behaviour in the face of extra fields, and design
+     a fallback scheme for interoperability with these clients.
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 1]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+2 - Affected Protocol Elements
+
+2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
+     word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
+     1-bit flags.  The original reserved Z bits have been allocated to
+     various purposes, and most of the RCODE values are now in use.
+     More flags and more possible RCODEs are needed.
+
+2.2. The first two bits of a wire format domain label are used to denote
+     the type of the label.  [RFC1035 4.1.4] allocates two of the four
+     possible types and reserves the other two.  Proposals for use of
+     the remaining types far outnumber those available.  More label
+     types are needed.
+
+2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
+     While the minimum maximum reassembly buffer size still allows a
+     limit of 512 octets of UDP payload, most of the hosts now connected
+     to the Internet are able to reassemble larger datagrams.  Some
+     mechanism must be created to allow requestors to advertise larger
+     buffer sizes to responders.
+
+3 - Extended Label Types
+
+3.1. The "0 1" label type will now indicate an extended label type,
+     whose value is encoded in the lower six bits of the first octet of
+     a label.  All subsequently developed label types should be encoded
+     using an extended label type.
+
+3.2. The "1 1 1 1 1 1" extended label type will be reserved for future
+     expansion of the extended label type code space.
+
+4 - OPT pseudo-RR
+
+4.1. One OPT pseudo-RR can be added to the additional data section of
+     either a request or a response.  An OPT is called a pseudo-RR
+     because it pertains to a particular transport level message and not
+     to any actual DNS data.  OPT RRs shall never be cached, forwarded,
+     or stored in or loaded from master files.  The quantity of OPT
+     pseudo-RRs per message shall be either zero or one, but not
+     greater.
+
+4.2. An OPT RR has a fixed part and a variable set of options expressed
+     as {attribute, value} pairs.  The fixed part holds some DNS meta
+     data and also a small collection of new protocol elements which we
+     expect to be so popular that it would be a waste of wire space to
+     encode them as {attribute, value} pairs.
+
+
+
+
+
+Vixie                       Standards Track                     [Page 2]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+4.3. The fixed part of an OPT RR is structured as follows:
+
+     Field Name   Field Type     Description
+     ------------------------------------------------------
+     NAME         domain name    empty (root domain)
+     TYPE         u_int16_t      OPT
+     CLASS        u_int16_t      sender's UDP payload size
+     TTL          u_int32_t      extended RCODE and flags
+     RDLEN        u_int16_t      describes RDATA
+     RDATA        octet stream   {attribute,value} pairs
+
+4.4. The variable part of an OPT RR is encoded in its RDATA and is
+     structured as zero or more of the following:
+
+                +0 (MSB)                            +1 (LSB)
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+  0: |                          OPTION-CODE                          |
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+  2: |                         OPTION-LENGTH                         |
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+  4: |                                                               |
+     /                          OPTION-DATA                          /
+     /                                                               /
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   OPTION-CODE    (Assigned by IANA.)
+
+   OPTION-LENGTH  Size (in octets) of OPTION-DATA.
+
+   OPTION-DATA    Varies per OPTION-CODE.
+
+4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
+     field) is the number of octets of the largest UDP payload that can
+     be reassembled and delivered in the sender's network stack.  Note
+     that path MTU, with or without fragmentation, may be smaller than
+     this.
+
+4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
+       reassembly buffer.  Choosing 1280 on an Ethernet connected
+       requestor would be reasonable.  The consequence of choosing too
+       large a value may be an ICMP message from an intermediate
+       gateway, or even a silent drop of the response message.
+
+4.5.2. Both requestors and responders are advised to take account of the
+       path's discovered MTU (if already known) when considering message
+       sizes.
+
+
+
+
+
+Vixie                       Standards Track                     [Page 3]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+4.5.3. The requestor's maximum payload size can change over time, and
+       should therefore not be cached for use beyond the transaction in
+       which it is advertised.
+
+4.5.4. The responder's maximum payload size can change over time, but
+       can be reasonably expected to remain constant between two
+       sequential transactions; for example, a meaningless QUERY to
+       discover a responder's maximum UDP payload size, followed
+       immediately by an UPDATE which takes advantage of this size.
+       (This is considered preferrable to the outright use of TCP for
+       oversized requests, if there is any reason to suspect that the
+       responder implements EDNS, and if a request will not fit in the
+       default 512 payload size limit.)
+
+4.5.5. Due to transaction overhead, it is unwise to advertise an
+       architectural limit as a maximum UDP payload size.  Just because
+       your stack can reassemble 64KB datagrams, don't assume that you
+       want to spend more than about 4KB of state memory per ongoing
+       transaction.
+
+4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
+     are structured as follows:
+
+                 +0 (MSB)                            +1 (LSB)
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   0: |         EXTENDED-RCODE        |            VERSION            |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   2: |                               Z                               |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  Note
+                   that EXTENDED-RCODE value "0" indicates that an
+                   unextended RCODE is in use (values "0" through "15").
+
+   VERSION         Indicates the implementation level of whoever sets
+                   it.  Full conformance with this specification is
+                   indicated by version "0."  Requestors are encouraged
+                   to set this to the lowest implemented level capable
+                   of expressing a transaction, to minimize the
+                   responder and network load of discovering the
+                   greatest common implementation level between
+                   requestor and responder.  A requestor's version
+                   numbering strategy should ideally be a run time
+                   configuration option.
+
+                   If a responder does not implement the VERSION level
+                   of the request, then it answers with RCODE=BADVERS.
+                   All responses will be limited in format to the
+
+
+
+Vixie                       Standards Track                     [Page 4]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+                   VERSION level of the request, but the VERSION of each
+                   response will be the highest implementation level of
+                   the responder.  In this way a requestor will learn
+                   the implementation level of a responder as a side
+                   effect of every response, including error responses,
+                   including RCODE=BADVERS.
+
+   Z               Set to zero by senders and ignored by receivers,
+                   unless modified in a subsequent specification.
+
+5 - Transport Considerations
+
+5.1. The presence of an OPT pseudo-RR in a request should be taken as an
+     indication that the requestor fully implements the given version of
+     EDNS, and can correctly understand any response that conforms to
+     that feature's specification.
+
+5.2. Lack of use of these features in a request must be taken as an
+     indication that the requestor does not implement any part of this
+     specification and that the responder may make no use of any
+     protocol extension described here in its response.
+
+5.3. Responders who do not understand these protocol extensions are
+     expected to send a response with RCODE NOTIMPL, FORMERR, or
+     SERVFAIL.  Therefore use of extensions should be "probed" such that
+     a responder who isn't known to support them be allowed a retry with
+     no extensions if it responds with such an RCODE.  If a responder's
+     capability level is cached by a requestor, a new probe should be
+     sent periodically to test for changes to responder capability.
+
+6 - Security Considerations
+
+     Requestor-side specification of the maximum buffer size may open a
+     new DNS denial of service attack if responders can be made to send
+     messages which are too large for intermediate gateways to forward,
+     thus leading to potential ICMP storms between gateways and
+     responders.
+
+7 - IANA Considerations
+
+     The IANA has assigned RR type code 41 for OPT.
+
+     It is the recommendation of this document and its working group
+     that IANA create a registry for EDNS Extended Label Types, for EDNS
+     Option Codes, and for EDNS Version Numbers.
+
+     This document assigns label type 0b01xxxxxx as "EDNS Extended Label
+     Type."  We request that IANA record this assignment.
+
+
+
+Vixie                       Standards Track                     [Page 5]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+     This document assigns extended label type 0bxx111111 as "Reserved
+     for future extended label types."  We request that IANA record this
+     assignment.
+
+     This document assigns option code 65535 to "Reserved for future
+     expansion."
+
+     This document expands the RCODE space from 4 bits to 12 bits.  This
+     will allow IANA to assign more than the 16 distinct RCODE values
+     allowed in [RFC1035].
+
+     This document assigns EDNS Extended RCODE "16" to "BADVERS".
+
+     IESG approval should be required to create new entries in the EDNS
+     Extended Label Type or EDNS Version Number registries, while any
+     published RFC (including Informational, Experimental, or BCP)
+     should be grounds for allocation of an EDNS Option Code.
+
+8 - Acknowledgements
+
+     Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
+     Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
+     Narten were each instrumental in creating and refining this
+     specification.
+
+9 - References
+
+    [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+               Specification", STD 13, RFC 1035, November 1987.
+
+10 - Author's Address
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 779 7001
+   EMail: vixie@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 6]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+11 - Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 7]
+