diff --git a/doc/expired/draft-duerst-dns-i18n-02.txt b/doc/expired/draft-duerst-dns-i18n-02.txt new file mode 100644 index 0000000000..a42981634b --- /dev/null +++ b/doc/expired/draft-duerst-dns-i18n-02.txt @@ -0,0 +1,905 @@ + + + + + + +Internet Draft M. Duerst + Keio University +Expires in six months July 1998 + + + Internationalization of Domain Names + + +Status of this Memo + + This document is an Internet-Draft. Internet-Drafts are working doc- + uments of the Internet Engineering Task Force (IETF), its areas, and + its working groups. Note that other groups may also distribute work- + ing documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a "working + draft" or "work in progress". + + To learn the current status of any Internet-Draft, please check the + 1id-abstracts.txt listing contained in the Internet-Drafts Shadow + Directories on ftp.ietf.org (US East Coast), nic.nordu.net + (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific + Rim). + + Distribution of this document is unlimited. Please send comments to + the author at . + + +Abstract + + Internet domain names are currently limited to a very restricted + character set. This document proposes the introduction of a new + "zero-level" domain (ZLD) to allow the use of arbitrary characters + from the Universal Character Set (ISO 10646/Unicode) in domain names. + The proposal is fully backwards compatible and does not need any + changes to DNS. Version 02 is reissued without changes just to + keep this draft available. + +Table of contents + + 0. Change History ................................................. 2 + 0.8 Changes Made from Version 01 to Version 02 .................. 2 + 0.9 Changes Made from Version 00 to Version 01 .................. 2 + 1. Introduction ................................................... 3 + 1.1 Motivation .................................................. 3 + + + + Expires End of January 1998 [Page 1] + +Internet Draft Internationalization of Domain Names July 1997 + + + 1.2 Notational Conventions ...................................... 4 + 2. The Hidden Zero Level Domain ................................... 4 + 3. Encoding International Characters .............................. 5 + 3.1 Encoding Requirements ....................................... 5 + 3.2 Encoding Definition ......................................... 5 + 3.3 Encoding Example ............................................ 7 + 3.4 Length Considerations ....................................... 8 + 4. Usage Considerations ........................................... 8 + 4.1 General Usage ............................................... 8 + 4.2 Usage Restrictions .......................................... 9 + 4.3 Domain Name Creation ....................................... 10 + 4.4 Usage in URLs .............................................. 12 + 5. Alternate Proposals ........................................... 13 + 5.1 The Dillon Proposal ........................................ 13 + 5.2 Using a Separate Lookup Service ............................ 13 + 6. Generic Considerations ........................................ 14 + 5.1 Security Considerations .................................... 14 + 5.2 Internationalization Considerations ........................ 14 + Acknowledgements ................................................. 14 + Bibliography ..................................................... 15 + Author's Address .................................................= + 16 + + + + +0. Change History + + + +0.8 Changes Made from Version 01 to Version 02 + + No significant changes; reissued to make it available officially. + Changed author's address. + + Changes deferred to future versions (if ever): + - Decide on ZLD name (.i or .i18n.int or something else) + - Decide on casing solution + - Decide on exact syntax + - Proposals for experimental setup + + + + +0.9 Changes Made from Version 00 to Version 01 + + + + + + + + Expires End of January 1998 [Page 2] + +Internet Draft Internationalization of Domain Names July 1997 + + + - Minor rewrites and clarifications + + - Added the following references: [RFC1730], [Kle96], [ISO3166], + [iNORM] + + - Slightly expanded discussion about casing + + - Added some variant proposals for syntax + + - Added some explanations about different kinds of name parallelism + + - Added some explanation about independent addition of internation- + alized names in subdomains without bothering higher-level domains + + - Added some explanations about tools needed for support, and the + MX/CNAME problem + + - Change to RFC1123 (numbers allowed at beginning of labels) + + + + +1. Introduction + + +1.1 Motivation + + + The lower layers of the Internet do not discriminate any language or + script. On the application level, however, the historical dominance + of the US and the ASCII character set [ASCII] as a lowest common + denominator have led to limitations. The process of removing these + limitations is called internationalization (abbreviated i18n). One + example of the abovementioned limitations are domain names [RFC1034, + RFC1035], where only the letters of the basic Latin alphabet (case- + insensitive), the decimal digits, and the hyphen are allowed. + + While such restrictions are convenient if a domain name is intended + to be used by arbitrary people around the globe, there may be very + good reasons for using aliases that are more easy to remember or type + in a local context. This is similar to traditional mail addresses, + where both local scripts and conventions and the Latin script can be + used. + + There are many good reasons for domain name i18n, and some arguments + that are brought forward against such an extension. This document, + however, does not discuss the pros and cons of domain name i18n. It + proposes and discusses a solution and therefore eliminates one of the + + + + Expires End of January 1998 [Page 3] + +Internet Draft Internationalization of Domain Names July 1997 + + + most often heard arguments agains, namely "it cannot be done". + + The solution proposed in this document consists of the introduction + of a new "zero-level" domain building the root of a new domain + branch, and an encoding of the Universal Character Set (UCS) + [ISO10646] into the limited character set of domain names. + + + +1.2 Notational Conventions + + In the domain name examples in this document, characters of the basic + Latin alphabet (expressible in ASCII) are denoted with lower case + letters. Upper case letters are used to represent characters outside + ASCII, such as accented characters of the Latin alphabet, characters + of other alphabets and syllabaries, ideographic characters, and vari- + ous signs. + + +2. The Hidden Zero Level Domain + + The domain name system uses the domain "in-addr.arpa" to convert + internet addresses back to domain names. One way to view this is to + say that in-addr.arpa forms the root of a separate hierarchy. This + hierarchy has been made part of the main domain name hierarchy just + for implementation convenience. While syntactically, in-addr.arpa is + a second level domain (SLD), functionally it is a zero level domain + (ZLD) in the same way as "." is a ZLD. A similar example of a ZLD is + the domain tpc.int, which provides a hierarchy of the global phone + numbering system [RFC1530] for services such as paging and printing + to fax machines. + + For domain name i18n to work inside the tight restrictions of domain + name syntax, one has to define an encoding that maps strings of UCS + characters to strings of characters allowable in domain names, and a + means to distinguish domain names that are the result of such an + encoding from ordinary domain names. + + This document proposes to create a new ZLD to distinguish encoded + i18n domain names from traditional domain names. This domain would + be hidden from the user in the same way as a user does not see in- + addr.arpa. This domain could be called "i18n.arpa" (although the use + of arpa in this context is definitely not appropriate), simply + "i18n", or even just "i". Below, we are using "i" for shortness, + while we leave the decision on the actual name to further= + discussion. + + + + + + + Expires End of January 1998 [Page 4] + +Internet Draft Internationalization of Domain Names July= + 1997 + + +3. Encoding International Characters + + + + +3.1 Encoding Requirements + + + Until quite recently, the thought of going beyond ASCII for something + such as domain names failed because of the lack of a single encom- + passing character set for the scripts and languages of the world. + Tagging techniques such as those used in MIME headers [RFC1522] would + be much too clumsy for domain names. + + The definition of ISO 10646 [ISO10646], codepoint by codepoint iden- + tical with Unicode [Unicode], provides a single Universal Character + Set (UCS). A recent report [RFCIAB] clearly recommends to base the + i18n of the Internet on these standards. + + An encoding for i18n domain names therefore has to take the charac- + ters of ISO 10646/Unicode as a starting point. The full four-byte + (31 bit) form of UCS, called UCS4, should be used. A limitation to + the two-byte form (UCS2), which allows only for the encoding of the + Base Multilingual Plane, is too restricting. + + For the mapping between UCS4 and the strongly limited character set + of domain names, the following constraints have to be considered: + + - The structure of domain names, and therefore the "dot", have to be + conserved. Encoding is done for individual labels. + + - Individual labels in domain names allow the basic Latin alphabet + (monocase, 26 letters), decimal digits, and the "-" inside the + label. The capacity per octet is therefore limited to somewhat + above 5 bits. + + - There is no need nor possibility to preserve any characters. + + - Frequent characters (i.e. ASCII, alphabetic, UCS2, in that order) + should be encoded relatively compactly. A variable-length encoding + (similar to UTF-8) seems desirable. + + + +3.2 Encoding Definition + + + Several encodings for UCS, so called UCS Transform Formats, exist + + + + Expires End of January 1998 [Page 5] + +Internet Draft Internationalization of Domain Names July 1997 + + + already, namely UTF-8 [RFC2044], UTF-7 [RFC1642], and UTF-16 [Uni- + code]. Unfortunately, none of them is suitable for our purposes. We + therefore use the following encoding: + + - To accommodate the slanted probability distribution of characters + in UCS4, a variable-length encoding is used. + + - Each target letter encodes 5 bits of information. Four bits of + information encode character data, the fifth bit is used to indi- + cate continuation of the variable-length encoding. + + - Continuation is indicated by distinguishing the initial letter + from the subsequent letter. + + - Leading four-bit groups of binary value 0000 of UCS4 characters + are discarded, except for the last TWO groups (i.e. the last + octet). This means that ASCII and Latin-1 characters need two + target letters, the main alphabets up to and including Tibetan + need three target letters, the rest of the characters in the BMP + need four target letters, all except the last (private) plane in + the UTF-16/Surrogates area [Unicode] need five target letters, and + so on. + + - The letters representing the various bit groups in the various + positions are chosen according to the following table: + + + Nibble Value Initial Subsequent + Hex Binary + 0 0000 G 0 + 1 0001 H 1 + 2 0010 I 2 + 3 0011 J 3 + 4 0100 K 4 + 5 0101 L 5 + 6 0110 M 6 + 7 0111 N 7 + 8 1000 O 8 + 9 1001 P 9 + A 1010 Q A + B 1011 R B + C 1100 S C + D 1101 T D + E 1110 U E + F 1111 V F + + + [Should we try to eliminate "I" and "O" from initial? "I" might be + + + + Expires End of January 1998 [Page 6] + +Internet Draft Internationalization of Domain Names July 1997 + + + eliminated because then an algorithm can more easily detect ".i". "O" + could lead to some confusion with "0". What other protocols are + there that might be able to use a similar solution, but that might + have other restrictions for the initial letters? Proposal to run ini- + tial range from H to X. Extracting the initial bits then becomes ^ + 'H'. Proposal to have a special convention for all-ASCII labels + (start label with one of the letters not used above).] + + Please note that this solution has the following interesting proper- + ties: + + - For subsequent positions, there is an equivalence between the hex- + adecimal value of the character code and the target letter used. + This assures easy conversion and checking. + + - The absence of digits from the "initial" column, and the fact that + the hyphen is not used, assures that the resulting string conforms + to domain name syntax. + + - Raw sorting of encoded and unencoded domain names is equivalent. + + - The boundaries of characters can always be detected easily. + (While this is important for representations that are used inter- + nally for text editing, it is actually not very important here, + because tools for editing can be assumed to use a more straight- + forward representation internally.) + + - Unless control characters are allowed, the target string will + never actually contain a G. + + + +3.3 Encoding Example + + + As an example, the current domain + + is.s.u-tokyo.ac.jp + + with the components standing for information science, science, the + University of Tokyo, academic, and Japan, might in future be repre- + sented by + + JOUHOU.RI.TOUDAI.GAKU.NIHON + + (a transliteration of the kanji that might probably be chosen to rep- + resent the same domain). Writing each character in U+HHHH notation as + in [Unicode], this results in the following (given for reference + + + + Expires End of January 1998 [Page 7] + +Internet Draft Internationalization of Domain Names July 1997 + + + only, not the actual encoding or something being typed in by the + user): + + U+60c5U+5831.U+7406.U+6771U+5927.U+5b66.U+65e5U+672c + + The software handling internationalized domain names will translate + this, according to the above specifications, before submitting it to + the DNS resolver, to: + + M0C5L831.N406.M771L927.LB66.M5E5M72C.i + + + +3.4 Length Considerations + + + DNS allows for a maximum of 63 positions in each part, and for 255 + positions for the overall domain name including dots. This allows up + to 15 ideographs, or up to 21 letters e.g. from the Hebrew or Arabic + alphabet, in a label. While this does not allow for the same margin + as in the case of ASCII domain names, it should still be quite suffi- + cient. [Problems could only surface for languages that use very long + words or terms and don't know any kind of abbreviations or similar + shortening devices. Do these exist? Islandic expert asserted + Islandic is not a problem.] DNS contains a compression scheme that + avoids sending the same trailing portion of a domain name twice in + the same transmission. Long domain names are therefore not that much + of a concern. + + +4. Usage Considerations + + + +4.1 General Usage + + + To implement this proposal, neither DNS servers nor resolvers need + changes. These programs will only deal with the encoded form of the + domain name with the .i suffix. Software that wants to offer an + internationalized user interface (for example a web browser) is + responsible for the necessary conversions. It will analyze the domain + name, call the resolver directly if the domain name conforms to the + domain name syntax restrictions, and otherwise encode the name + according to the specifications of Section 3.2 and append the .i suf- + fix before calling the resolver. New implementations of resolvers + will of course offer a companion function to gethostbyname accepting + a ISO10646/Unicode string as input. + + + + Expires End of January 1998 [Page 8] + +Internet Draft Internationalization of Domain Names July 1997 + + + For domain name administrators, them main tool that will be needed is + a program to compile files configuring zones from an UTF-8 notation + (or any other suitable encoding) to the encoding described in Section + 3.3. Utility tools will include a corresponding decompiler, checkers + for various kinds of internationalization-related errors, and tools + for managing syntactic parallelism (see Section 4.3). + + +4.2 Usage Restrictions + + + While this proposal in theory allows to have control characters such + as BEL or NUL or symbols such as arrows and smilies in domain names, + such characters should clearly be excluded from domain names. Whether + this has to be explicitly specified or whether the difficulty to type + these characters on any keyboard of the world will limit their use + has to be discussed. One approach is to start with a very restricted + subset and gradually relax it; the other is to allow almost anything + and to rely on common sense. Anyway, such specifications should go + into a separate document to allow easy updates. + + A related point is the question of equivalence. For historical rea- + sons, ISO 10646/Unicode contain considerable number of compatibility + characters and allow more than one representation for characters with + diacritics. To guarantee smooth interoperability in these and related + cases, additional restrictions or the definition of some form of nor- + malization seem necessary. However, this is a general problem + affecting all areas where ISO 10646/Unicode is used in identifiers, + and should therefore be addressed in a generic way. See [iNORM] for + an initial proposal. + + Equally related is the problem of case equivalence. Users can very + well distinguish between upper case and lower case. Also, casing in + an i18n context is not as straightforward as for ASCII, so that case + equivalence is best avoided. Problems therefore result not from the + fact that case is distinguished for i18n domain names, but from the + fact that existing domain names do not distinguish case. Where it is + impossible to distinguish between next.com and NeXT.com, the same two + subdomains would easily be distinguishable if subordinate to a i18n + domain. There are several possible solutions. One is to try to grad- + ually migrate from a case-insensitive solution to a case-sensitive + solution even for ASCII. Another is to allow case-sensitivity only + beyond ASCII. Another is to restrict anything beyond ASCII to lower- + case only (lowercase distinguishes better than uppercase, and is also + generally used for ASCII domain names). + + A problem that also has to be discussed and solved is bidirectional- + ity. Arabic and Hebrew characters are written right-to-left, and the + + + + Expires End of January 1998 [Page 9] + +Internet Draft Internationalization of Domain Names July 1997 + + + mixture with other characters results in a divergence between logical + and graphical sequence. See [HTML-I18N] for more explanations. The + proposal of [Yer96] for dealing with bidirectionality in URLs could + probably be applied to domain names. Anyway, there should be a gen- + eral solution for identifiers, not a DNS-specific solution. + + +4.3 Domain Name Creation + + + The ".i" ZLD should be created as such to allow the internationaliza- + tion of domain names. Rules for creating subdomains inside ".i" + should follow the established rules for the creation of functionally + equivalent domains in the existing domain hierarchy, and should + evolve in parallel. + + For the actual domain hierarchy, the amount of parallelism between + the current ASCII-oriented hierarchy and some internationalized hier- + archy depends on various factors. In some cases, two fully parallel + hierarchies may emerge. In other cases, if more than one script or + language is used locally, more than two parallel hierarchies may + emerge. Some nodes, e.g. in intranets, may only appear in an i18n + hierarchy, whereas others may only appear in the current hierarchy. + In some cases, the pecularities of scripts, languages, cultures, and + the local marketplace may lead to completely different hierarchies. + + Also, one has to be aware that there may be several kinds of paral- + lelisms. The first one is called syntactic parallelism. If there is + a domain XXXX.yy.zz and a domain vvvv.yy.zz, then the domain yy.zz + will have to exist both in the traditional DNS hierarchy as well as + within the hierarchy starting at the .i ZLD, with appropriate encod- + ing. + + The second type of parallelism is called transcription parallelism. + It results by transcribing or transliterating relations between ASCII + domain names and domain names in other scripts. + + The third type of parallelism is called semantic parallelism. It + results from translating elements of a domain name from one language + to another, possibly also changing the script or set of used charac- + ters. + + On the host level, parallelism means that there are two names for the + same host. Conventions should exist to decide whether the parallel + names should have separate IP addresses or not (A record or CNAME + record). With separate IP addresses, address to name lookup is easy, + otherwise it needs special precautions to be able to find all names + corresponding to a given host address. Another detail entering this + + + + Expires End of January 1998 [Page 10] + +Internet Draft Internationalization of Domain Names July 1997 + + + consideration is that MX records only work for hostnames/domains, + not for CNAME aliases. This at least has the consequence that alias + resolution for internationalized mail addresses has to occur before + MX record lookup. + + When discussing and applying the rules for creating domain names, + some peculiarities of i18n domain names should be carefully consid- + ered: + + - Depending on the script, reasonable lengths for domain name parts + may differ greatly. For ideographic scripts, a part may often be + only a one-letter code. Established rules for lengths may need + adaptation. For example, a rule for country TLDs could read: one + ideographic character or two other characters. + + - If the number of generic TLDs (.com, .edu, .org, .net) is kept + low, then it may be feasible to restrict i18n TLDs to country + TLDs. + + - There are no ISO 3166 [ISO3166] two-letter codes in scripts other + than Latin. I18n domain names for countries will have to be + designed from scratch. + + - The names of some countries or regions may pose greater political + problems when expressed in the native script than when expressed + in 2-letter ISO 3166 codes. + + - I18n country domain names should in principle only be created in + those scripts that are used locally. There is probably little use + in creating an Arabic domain name for China, for example. + + - In those cases where domain names are open to a wide range of + applicants, a special procedure for accepting applications should + be used so that a reasonable-quality fit between ASCII domain + names and i18n domain names results where desired. This would + probably be done by establishing a period of about a month for + applications inside a i18n domain newly created as a parallel for + an existing domain, and resolving the detected conflicts. For + syntactically parallel domain names, the owners should always be + the same. Administration may be split in some cases to account for + the necessary linguistic knowledge. For domain names with tran- + scription parallelism and semantic parallelism, the question of + owner identity should depend on the real-life situation (trade- + marks,...). + + - It will be desirable to have internationalized subdomains in non- + internationalized TLDs. As an example, many companies in France + may want to register an accented version of their company name, + + + + Expires End of January 1998 [Page 11] + +Internet Draft Internationalization of Domain Names July 1997 + + + while remaining under the .fr TLD. For this, .fr would have to be + reregistered as .M6N2.i. Accented and other internationalized sub- + domains would go below .M6N2.i, whereas unaccented ones would go + below .fr in its plain form. + + - To generalize the above case, one may need to create a requirement + that any domain name registry would have to register and manage + syntactically parallel domain names below the .i ZLD upon request + to allow registration of i18n domain names in arbitrary subdo- + mains. An alternative to this is to organize domain name search + so that e.g. in a search for XXXXXX.fr, if M6N2.i is not found in + .i, the name server for .fr is queried for XXXXXX.M6N2.i (with + XXXXXX appropriately encoded). This convention would allow lower- + level domains to introduce internationalized subdomains without + depending on higher-level domains. + + + +4.4 Usage in URLs + + According to current definitions, URLs encode sequences of octets + into a sequence of characters from a character set that is almost as + limited as the character set of domain names [RFC1738]. This is + clearly not satisfying for i18n. + + Internationalizing URLs, i.e. assigning character semantics to the + encoded octets, can either be done separately for each part and/or + scheme, or in an uniform way. Doing it separately has the serious + disadvantage that software providing user interfaces for URLs in gen- + eral would have to know about all the different i18n solutions of the + different parts and schemes. Many of these solutions may not even be + known yet. + + It is therefore definitely more advantageous to decide on a single + and consistent solution for URL internationalization. The most valu- + able candidate [Yer96], for many reasons, is UTF-8 [RFC2044], an + ASCII-compatible encoding of UCS4. + + Therefore, an URL containing the domain name of the example of Sec- + tion 3.3 should not be written as: + + ftp://M0C5L831.N406.M771L927.LB66.M5E5M72C.i + + (although this will also work) but rather + + ftp://%e6%83%85%e5%a0%b1.%e7%90%86.%e6%9d%b1%e5%a4%a7. + %e5%ad%a6.%e6%97%a5%e6%9c%ac + + + + + Expires End of January 1998 [Page 12] + +Internet Draft Internationalization of Domain Names July 1997 + + + In this canonical form, the trailing .i is absent, and the octets can + be reconstructed from the %HH-encoding and interpreted as UTF-8 by + generic URL software. The software part dealing with domain names + will carry out the conversion to the .i form. + + +5. Alternate Proposals + + + +5.1 The Dillon Proposal + + The proposal of Michael Dillon [Dillon96] is also based on encoding + Unicode into the limited character set of domain names. Distinction + is done for each part, using the hyphen in initial position. Because + this does not fully conform to the syntax of existing domain names, + it is questionable whether it is backwards-compatible. On the other + hand, this has the advantage that local i18n domain names can be + installed easily without cooperation by the manager of the superdo- + main. + + A variable-length scheme with base 36 is used that can encode up to + 1610 characters, absolutely insufficient for Chinese or Japanese. + Characters assumed not to be used in i18n domain names are excluded, + i.e. only one case is allowed for basic Latin characters. This means + that large tables have to be worked out carefully to convert between + ISO 10646/Unicode and the actual number that is encoded with base= + 36. + + +5.2 Using a Separate Lookup Service + + Instead of using a special encoding and burdening DNS with i18n, one + could build and use a separate lookup service for i18n domain names. + Instead of converting to UCS4 and encoding according to Section 3.2, + and then calling the DNS resolver, a program would contact this new + service when seeing a domain name with characters outside the allowed + range. + + Such solutions have various problems. There are many directory ser- + vices and proposals for how to use them in a way similar to DNS. For + an overview and a specific proposal, see [Kle96]. However, while + there are many proposals, a real service containing the necessary + data and providing the wide installed base and distributed updating + is in DNS does not exist. + + Most directory service proposals also do not offer uniqueness. + Defining unique names again for a separate service will duplicate + much of the work done for DNS. If uniqueness is not guaranteed, the + + + + Expires End of January 1998 [Page 13] + +Internet Draft Internationalization of Domain Names July 1997 + + + user is bundened with additional selection steps. + + Using a separate lookup service for the internationalization of + domain names also results in more complex implementations than the + proposal made in this draft. Contrary to what some people might + expect, the use of a separate lookup service also does not solve a + capacity problem with DNS, because there is no such problem, nor will + one be created with the introduction of i18n domain names. + + +6. Generic Considerations + + + +6.1 Security Considerations + + This proposal is believed not to raise any other security considera- + tions than the current use of the domain name system. + + +6.2 Internationalization Considerations + + This proposal addresses internationalization as such. The main addi- + tional consideration with respect to internationalization may be the + indication of language. However, for concise identifiers such as + domain names, language tagging would be too much of a burden and + would create complex dependencies with semantics. + + + NOTE -- This section is introduced based on a recommenda- + tion in [RFCIAB]. A similar section addressing internation- + alization should be included in all application level + internet drafts and RFCs. + + + + + +Acknowledgements + + I am grateful in particular to the following persons for their advice + or criticism: Bert Bos, Lori Brownell, Michael Dillon, Donald E. + Eastlake 3rd, David Goldsmith, Larry Masinter, Ryan Moats, Keith + Moore, Thorvardur Kari Olafson, Erik van der Poel, Jurgen Schwertl, + Paul A. Vixie, Francois Yergeau, and others. + + + + + + + Expires End of January 1998 [Page 14] + +Internet Draft Internationalization of Domain Names July= + 1997 + + +Bibliography + + [ASCII] Coded Character Set -- 7-Bit American Standard Code + for Information Interchange, ANSI X3.4-1986. + + [Dillon96] M. Dillon, "Multilingual Domain Names", Memra Software + Inc., November 1996 (circulated Dec. 6, 1996 on iahc- + discuss@iahc.org). + + [HTML-I18N] F. Yergeau, G. Nicol, G. Adams, and M. Duerst, "Inter- + nationalization of the Hypertext Markup Language", + Work in progress (draft-ietf-html-i18n-05.txt), August + 1996. + + [iNORM] M. Duerst, "Normalization of Internationalized Identi- + fiers", draft-duerst-i18n-norm-00.txt, July 1997. + + [ISO3166] ISO 3166, "Code for the representation of names of + countries", ISO 3166:1993. + + [ISO10646] ISO/IEC 10646-1:1993. International standard -- Infor- + mation technology -- Universal multiple-octet coded + character Set (UCS) -- Part 1: Architecture and basic + multilingual plane. + + [Kle96] J. Klensin and T. Wolf, Jr., "Domain Names and Company + Name Retrieval", Work in progress (draft-klensin-tld- + whois-01.txt), November 1996. + + [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facili- + ties", ISI, Nov. 1987. + + [RFC1035] P. Mockapetris, "Domain Names - Implementation and + Specification", ISI, Nov. 1987. + + [RFC1522] K. Moore, "MIME (Multipurpose Internet Mail Exten- + sions) Part Two: Message Header Extensions for Non- + ASCII Text", University of Tennessee, September 1993. + + [RFC1642] D. Goldsmith, M. Davis, "UTF-7: A Mail-safe Transfor- + mation Format of Unicode", Taligent Inc., July 1994. + + [RFC1730] C. Malamud and M. Rose, "Principles of Operation for + the TPC.INT Subdomain: General Principles and Policy", + Internet Multicasting Service, October 1993. + + [RFC1738] T. Berners-Lee, L. Masinter, and M. McCahill, + "Uniform Resource Locators (URL)", CERN, Dec. 1994. + + + + Expires End of January 1998 [Page 15] + +Internet Draft Internationalization of Domain Names July 1997 + + + [RFC2044] F. Yergeau, "UTF-8, A Transformation Format of Unicode + and ISO 10646", Alis Technologies, October 1996. + + [RFCIAB] C. Weider, C. Preston, K. Simonsen, H. Alvestrand, R. + Atkinson, M. Crispin, P. Svanberg, "Report from the + IAB Character Set Workshop", October 1996 (currently + available as draft-weider-iab-char-wrkshop-00.txt). + + [Unicode] The Unicode Consortium, "The Unicode Standard, Version + 2.0", Addison-Wesley, Reading, MA, 1996. + + [Yer96] F. Yergeau, "Internationalization of URLs", Alis Tech- + nologies, + = + . + + + +Author's Address + + Martin J. Duerst + World Wide Web Consortium + Keio Research Institute at SFC + Keio University + 5322 Endo + Fujisawa + 252-8520 Japan + + Tel: +81 466 49 11 70 + E-mail: mduerst@w3.org + + + NOTE -- Please write the author's name with u-Umlaut wherever + possible, e.g. in HTML as Dürst. + + + + + + + + + + + + + + + + + + + Expires End of January 1998 [Page 16] + diff --git a/doc/expired/draft-dunlap-dns-duxfr-00.txt b/doc/expired/draft-dunlap-dns-duxfr-00.txt new file mode 100644 index 0000000000..d299ac282b --- /dev/null +++ b/doc/expired/draft-dunlap-dns-duxfr-00.txt @@ -0,0 +1,336 @@ + DNSIND Working Group K. Dunlap + INTERNET-DRAFT Check Point Software + P. Vixie + ISC + September 1999 + + Dynamic Update Zone Transfer + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + Status of This Memo + + This draft, file name draft-dunlap-dns-duxfr-00.txt, is intended to + become a Proposed Standard RFC. Distribution of this document is unlim- + ited. Comments should be sent to or to the + authors. + + This document is an Internet-Draft and is in full conformance with all + provisions of Section 10 of RFC2026. Internet-Drafts are working docu- + ments of the Internet Engineering Task Force (IETF), its areas, and its + working groups. Note that other groups may also distribute working + documents as Internet-Drafts. + + 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 not appropriate to use Internet-Drafts as reference + material or to cite them other than as ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + To view the list Internet-Draft Shadow Directories, see + http://www.ietf.org/shadow.html. + + Abstract + + This document proposes an alternative extension to the DNS protocol for + Incremental zone transfer (IXFR) [RFC1995]. This extension uses the + mechanisms for adding and deleting Resource Records specified in + [RFC2136] to transmit the changes between authoritative servers of a + zone. + + Expires March 2000 [Page 1] + + INTERNET-DRAFT DNS DUXFR September 1999 + + 1 - Introduction + + For rapid propagation of changes to a DNS database [STD13], it is neces- + sary to reduce latency by actively notifying servers of the change. + This is accomplished by the DNS NOTIFY Mechanism [RFC1996]. + + The simple method described for Incremental transfer (IXFR), in + [RFC1995], does not adequately address the complexity of the problem. + + Dynamic Update Zone Transfer (DUXFR), as proposed, is a mechanism to + transmit the complexity of changes in the zone and still have the effi- + ciency of IXFR means to propagate changed portions of a zone. + + In this document, a slave name server which requests DUXFR is called a + DUXFR client and a master or slave name server which responds to the + request is called a DUXFR server. + + 2 - Brief Description of the Protocol + + If a DUXFR client, which likely has an older version of a zone, thinks + it needs a newer version of the zone (typically through SOA refresh + timeout or the NOTIFY mechanism), it sends a DUXFR message containing + the SOA serial number of its (presumably outdated) copy of the zone. + + A DUXFR server should keep record of the newest version of the zone and + the differences between that copy and several older versions. When a + DUXFR request with an older version number is received, the DUXFR server + needs to send only the differences required to make that version + current. These differences are sent using the DNS UPDATE format packets + for deletes and add specified in [RFC2136 2.5]. + + When a zone has been updated, it should be saved in stable storage + before the new version is used to respond to DUXFR (or AXFR) queries. + Otherwise, if the server crashes, data which is no longer available may + have been distributed to slave servers, which can cause persistent data- + base inconsistencies. + + If a DUXFR query with the same or newer version number than that of the + server is received, it is replied to with a single SOA record of the + server's current version, just as in IXFR. + + The Transport protocol for DUXFR queries is TCP/IP. + + Expires March 2000 [Page 2] + + INTERNET-DRAFT DNS DUXFR September 1999 + + 3 - Query Format + + The DUXFR Query format is based on the standard DNS UPDATE Message For- + mat. In the DNS Packet Header the Opcode is set to UPDATE and the Zone + Type (ZTYPE) being set to AXFR. The Additional section containing the + SOA record of the client's version of the zone. + + 4 - Response Format + + The response packets to the DUXFR query are in the standard DNS UPDATE + Message Format. The records in the Update Section are formatted using + the four sets of semantics for adding and deleting Resource Records + specified in the ``Update Section'' in [RFC2136 2.5]. The client will + process these changes using the prerequisite for the transaction as the + existence of the SOA serial number specified in the Additional section + of the DUXFR query. + + The response to a DUXFR query, when the server no longer has all the + previous history from the version the client requests, will be a + Response code (RCODE) of "Refused". It is recommended that the client + retry with an AXFR query described in [RFC1034 4.3.5]. + + It is recommended that the Prerequisite sections of the DNS message be + empty on transmission and ignored on reception. The Additional section + may contain necessary data such as signatures as specified by other + extensions to [RFC 2136]. + + 5 - Version Overhead + + A DUXFR server can not be required to hold all previous versions forever + and may delete them anytime. In general, there is a trade-off between + the size of storage space and the possibility of using DUXFR. + + Information about older versions should be purged if the total length of + a DUXFR response would be longer than that of an AXFR response. Given + that the purpose of DUXFR is to reduce AXFR overhead, this strategy is + quite reasonable. The strategy assures that the amount of storage + required is at most twice that of the current zone information. + + Information older than the SOA expire period may also be purged. + + 6 - IANA Considerations + + No IANA services are required by this document. + + Expires March 2000 [Page 3] + + INTERNET-DRAFT DNS DUXFR September 1999 + + 7 - Security Considerations + + DNS is related to several security problems, no attempt is made to fix + them in this document. + + The authors believe that this document does not introduce any additional + security problems to the current DNS protocol. + + 8 - Examples + + Given the following three generations of data with the current serial + number of 3. + + Example.Com. IN SOA NS.Example.Com. admin.Example.Com. +( + 1 600 600 3600000 604800 ) + IN NS NS.Example.Com. + NS.Example.Com. IN A 192.168.1.5 + Vangogh.Example.Com. IN A 192.168.1.21 + + Vangogh.Example.Com. is removed and Monet.Example.Com. is added. + + Example.Com. IN SOA NS.Example.Com. admin.Example.Com. ( + 2 600 600 3600000 604800 ) + IN NS NS.Example.Com. + NS.Example.Com. IN A 192.168.1.5 + Monet.Example.Com. IN A 192.168.6.27 + IN A 192.168.3.128 + + One of the IP address of Monet.Example.Com. is changed. + + Example.Com. IN SOA NS.Example.Com. admin.Example.Com. ( + 3 600 600 3600000 604800 ) + IN NS NS.Example.Com. + NS.Example.Com. IN A 192.168.1.5 + Monet.Example.Com. IN A 192.168.6.42 + IN A 192.168.3.128 + + Expires March 2000 [Page 4] + + INTERNET-DRAFT DNS DUXFR September 1999 + + The following DUXFR query: + + +--------------------------------------------------+ + Header | OPCODE=QUERY, QR=Request | + +--------------------------------------------------+ + Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR | + +--------------------------------------------------+ + Prerequisite | | + +--------------------------------------------------+ + Update | | + +--------------------------------------------------+ + Additional | Example.Com. IN SOA serial=1 | + +--------------------------------------------------+ + + The reply could be with the following DUXFR response with Update packets + in the Answer Section: + + +--------------------------------------------------+ + Header | OPCODE=QUERY, QR=Response | + +--------------------------------------------------+ + Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR | + +--------------------------------------------------+ + Prerequisite | Example.Com. IN SOA serial=1 | + +--------------------------------------------------+ + Update | Vangogh.Example.Com. 0 ANY A 192.168.1.21 | + | Monet.Example.Com. IN A 192.168.6.42 | + | Monet.Example.Com. IN A 192.168.3.128 | + | Example.Com. 0 IN SOA serial=1 | + | Example.Com. IN SOA serial=2 | + | Monet.Example.Com. 0 ANY A 192.168.6.42 | + | Example.Com. 0 ANY SOA serial=2 | + | Example.Com. IN SOA serial=3 | + +--------------------------------------------------+ + Additional | | + +--------------------------------------------------+ + + or with the following Compressed DUXFR response with Update packets in + the Answer Section: + + Expires March 2000 [Page 5] + + INTERNET-DRAFT DNS DUXFR September 1999 + + +--------------------------------------------------+ + Header | OPCODE=QUERY, QR=Response | + +--------------------------------------------------+ + Zone | QNAME=Example.Com., QCLASS=IN, QTYPE=AXFR | + +--------------------------------------------------+ + Prerequisite | Example.Com. IN SOA serial=1 | + +--------------------------------------------------+ + Update | Vangogh.Example.Com. 0 ANY A 192.168.1.21 | + | Monet.Example.Com. IN A 192.168.6.42 | + | Monet.Example.Com. IN A 192.168.3.128 | + | Example.Com. 0 ANY SOA serial=1 | + | Example.Com. IN SOA serial=3 | + +--------------------------------------------------+ + Additional | | + +--------------------------------------------------+ + + References + + [RFC1034]] + P. Mockapetris, ``Domain Names - Concepts and Facilities'' STD + 13, RFC 1034, USC/Information Sciences Institute, November 1987. + + [RFC1035] + P. Mockapetris, ``Domain Names - Implementation and Specifica- + tion'' RFC 1035, USC/Information Sciences Institute, November + 1987. + + [RFC1996] + P. Vixie, ``A Mechanism for Prompt Notification of Zone Changes + (DNS Notify)'' RFC 1996, August 1996 + + [RFC1995] + M. Ohta, ``Incremental Zone Transfer in DNS'' RFC 1995, August + 1996. + + [RFC2026] + S. Bradner, ``the Internet Standards Process -- Revision 3'' RFC + 2026, Harvard University, October 1996. + + [RFC2136] + P. Vixie, S. Thomson, Y. Rekhter and J. Bound, ``Dynamic + Updates in the Domain Name System (DNS UPDATE)'' RFC 2136, + April 1997 + + Expires March 2000 [Page 6] + + INTERNET-DRAFT DNS DUXFR September 1999 + + Author's Address + + Kevin J. Dunlap + Check Point Software Technologies, Inc. + The Meta IP Group + 119 South Main Street, Suite 200 + Seattle, WA 98033 + +1 206 674 3700 + + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063 + +1 650 779 7001 + + + Expires March 2000 [Page 7] + + INTERNET-DRAFT DNS DUXFR September 1999 + + 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. + + Expires March 2000 [Page 8] diff --git a/doc/expired/draft-ietf-dnsind-binary-labels-05.txt b/doc/expired/draft-ietf-dnsind-binary-labels-05.txt new file mode 100644 index 0000000000..b95dfb6244 --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-binary-labels-05.txt @@ -0,0 +1,337 @@ +DNSIND Working Group Matt Crawford +Internet Draft Fermilab + May 5, 1999 + + Binary Labels in the Domain Name System + + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + 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." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + +1. Introduction and Terminology + + This document defines a ``Bit-String Label'' which may appear within + domain names. This new label type compactly represents a sequence + of ``One-Bit Labels'' and enables resource records to be stored at + any bit-boundary in a binary-named section of the domain name tree. + + 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 [KWORD]. + + +2. Motivation + + Binary labels are intended to efficiently solve the problem of + storing data and delegating authority on arbitrary boundaries when + the structure of underlying name space is most naturally represented + in binary. + + + + + + + +Expires November 10, 1999 Crawford [Page 1] + +Internet Draft Binary DNS Labels May 5, 1999 + + +3. Label Format + + Up to 256 One-Bit Labels can be grouped into a single Bit-String + Label. Within a Bit-String Label the most significant or "highest + level" bit appears first. This is unlike the ordering of DNS labels + themselves, which has the least significant or "lowest level" label + first. Nonetheless, this ordering seems to be the most natural and + efficient for representing binary labels. + + Among consecutive Bit-String Labels, the bits in the first-appearing + label are less significant or "at a lower level" than the bits in + subsequent Bit-String Labels, just as ASCII labels are ordered. + + +3.1. Encoding + + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+ + |0 1| ELT | Count | Label ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+ + + (Each tic mark represents one bit.) + + + ELT 000001 binary, the six-bit extended label type [EDNS0] + assigned to the Bit-String Label. + + Count The number of significant bits in the Label field. A + Count value of zero indicates that 256 bits are + significant. (Thus the null label representing the DNS + root cannot be represented as a Bit String Label.) + + Label The bit string representing a sequence of One-Bit Labels, + with the most significant bit first. That is, the One-Bit + Label in position 17 in the diagram above represents a + subdomain of the domain represented by the One-Bit Label + in position 16, and so on. + + The Label field is padded on the right with zero to seven + pad bits to make the entire field occupy an integral + number of octets. These pad bits MUST be zero on + transmission and ignored on reception. + + A sequence of bits may be split into two or more Bit-String Labels, + but the division points have no significance and need not be + preserved. An excessively clever server implementation might split + + + +Expires November 10, 1999 Crawford [Page 2] + +Internet Draft Binary DNS Labels May 5, 1999 + + + Bit-String Labels so as to maximize the effectiveness of message + compression [DNSIS]. A simpler server might divide Bit-String + Labels at zone boundaries, if any zone boundaries happen to fall + between One-Bit Labels. + + +3.2. Textual Representation + + A Bit-String Label is represented in text -- in a zone file, for + example -- as a surrounded by the delimiters "\[" and + "]". The is either a dotted quad or a base indicator and + a sequence of digits appropriate to that base, optionally followed + by a slash and a length. The base indicators are "b", "o" and "x", + denoting base 2, 8 and 16 respectively. The length counts the + significant bits and MUST be between 1 and 32, inclusive, after a + dotted quad, or between 1 and 256, inclusive, after one of the other + forms. If the length is omitted, the implicit length is 32 for a + dotted quad or 1, 3 or 4 times the number of binary, octal or + hexadecimal digits supplied, respectively, for the other forms. + + In augmented Backus-Naur form [ABNF], + + bit-string-label = "\[" bit-spec "]" + + bit-spec = bit-data [ "/" length ] + / dotted-quad [ "/" slength ] + + bit-data = "x" 1*64HEXDIG + / "o" 1*86OCTDIG + / "b" 1*256BIT + + dotted-quad = decbyte "." decbyte "." decbyte "." decbyte + + decbyte = 1*3DIGIT + + length = NZDIGIT *2DIGIT + + slength = NZDIGIT [ DIGIT ] + + OCTDIG = %x30-37 + + NZDIGIT = %x31-39 + + If a is present, the number of digits in the + MUST be just sufficient to contain the number of bits specified by + the . If there are insignificant bits in a final + hexadecimal or octal digit, they MUST be zero. A + always has all four parts even if the associated is less + + + +Expires November 10, 1999 Crawford [Page 3] + +Internet Draft Binary DNS Labels May 5, 1999 + + + than 24, but, like the other forms, insignificant bits MUST be zero. + + Each number represented by a must be between 0 and 255, + inclusive. + + The number represented by must be between 1 and 256 + inclusive. + + The number represented by must be between 1 and 32 + inclusive. + + When the textual form of a Bit-String Label is generated by machine, + the length SHOULD be explicit, not implicit. + + +3.2.1. Examples + + The following four textual forms represent the same Bit-String + Label. + + \[b11010000011101] + \[o64072/14] + \[xd074/14] + \[208.116.0.0/14] + + The following represents two consecutive Bit-String Labels which + denote the same relative point in the DNS tree as any of the above + single Bit-String Labels. + + \[b11101].\[o640] + + + +3.3. Canonical Representation and Sort Order + + Both the wire form and the text form of binary labels have a degree + of flexibility in their grouping into multiple consecutive Bit- + String Labels. For generating and checking DNS signature records + [DNSSEC] binary labels must be in a predictable form. This + canonical form is defined as the form which has the fewest possible + Bit-String Labels and in which all except possibly the first (least + significant) label in any sequence of consecutive Bit-String Labels + is of maximum length. + + For example, the canonical form of any sequence of up to 256 One-Bit + Labels has a single Bit-String Label, and the canonical form of a + sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of + which the second and third contain 256 label bits. + + + +Expires November 10, 1999 Crawford [Page 4] + +Internet Draft Binary DNS Labels May 5, 1999 + + + The canonical sort order of domain names [DNSSEC] is extended to + encompass binary labels as follows. Sorting is still label-by- + label, from most to least significant, where a label may now be a + One-Bit Label or a standard (code 00) label. Any One-Bit Label + sorts before any standard label, and a 0 bit sorts before a 1 bit. + The absence of a label sorts before any label, as specified in + [DNSSEC]. + + For example, the following domain names are correctly sorted. + + foo.example + \[b1].foo.example + \[b100].foo.example + \[b101].foo.example + bravo.\[b10].foo.example + alpha.foo.example + + +4. Processing Rules + + A One-Bit Label never matches any other kind of label. In + particular, the DNS labels represented by the single ASCII + characters "0" and "1" do not match One-Bit Labels represented by + the bit values 0 and 1. + + +5. Discussion + + A Count of zero in the wire-form represents a 256-bit sequence, not + to optimize that particular case, but to make it completely + impossible to have a zero-bit label. + + +6. IANA Considerations + + This document defines one Extended Label Type, termed the Bit-String + Label, and requests registration of the code point 000001 binary in + the space defined by [EDNS0]. + + +7. Security Considerations + + All security considerations which apply to traditional ASCII DNS + labels apply equally to binary labels. he canonicalization and + sorting rules of section 3.3 allow these to be addressed by DNS + Security [DNSSEC]. + + + + + +Expires November 10, 1999 Crawford [Page 5] + +Internet Draft Binary DNS Labels May 5, 1999 + + +8. References + + [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234. + + [DNSIS] P.V. Mockapetris, "Domain names - implementation and + specification", RFC 1035. + + [DNSSEC]D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security + Extensions", RFC 2065. + + [EDNS0] P. Vixie, "Extension mechanisms for DNS (EDNS0)", Currently + draft-dnsind-edns0-01.txt. + + [KWORD] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels," RFC 2119. + + +9. Author's Address + + Matt Crawford + Fermilab MS 368 + PO Box 500 + Batavia, IL 60510 + USA + + Phone: +1 630 840-3461 + + EMail: crawdad@fnal.gov + + + + + + + + + + + + + + + + + + + + + + +Expires November 10, 1999 Crawford [Page 6] + diff --git a/doc/expired/draft-ietf-dnsind-dddd-01.txt b/doc/expired/draft-ietf-dnsind-dddd-01.txt new file mode 100644 index 0000000000..0d3b429c54 --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-dddd-01.txt @@ -0,0 +1,334 @@ + +DNSIND Working Group Brian Wellington (TISLabs) +INTERNET-DRAFT Olafur Gudmundsson (TISLabs) + April 1999 + + + +Updates: RFC 2136 + + + + Deferred Dynamic Domain Name System (DNS) Delete Operations + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + 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.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + This document proposes a mechanism for notifying a dynamic DNS server + that a delete operation should be performed at a certain point in the + future. This works within the framework of the current DNS dynamic + update protocol, and provides needed functionality for clients with + leased dynamic addresses. + + + + + + + + + +Expires October 1999 [Page 1] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + +1 - Introduction + +Dynamic update operations for the Domain Name System [RFC1034, RFC1035] +are defined in [RFC2136], but there is no automated method of specifying +that records should have a fixed lifetime, or lease. + +1.1 - Overview of DNS Dynamic Update + +DNS dynamic update defines a new DNS opcode and a new interpretation of +the DNS message if that opcode is used. An update can specify +insertions or deletions of data, along with prerequisites necessary for +the updates to occur. All tests and changes for a DNS update request +are restricted to a single zone, and are performed at the primary server +for the zone. The primary server for a dynamic zone must increment the +zone SOA serial number when an update occurs or before the next +retrieval of the SOA. + +1.2 - Overview of DHCP leases + +DHCP [RFC2131] provides a means for a host to obtain a network address +from a DHCP server. The server may ``lease'' this address to the host, +meaning that it is valid only for the period of time specified in the +lease. The host may may extend its lease with subsequent requests, or +may issue a message to release the address back to the server when it is +no longer needed. + +2 - Background + +When a host receives dynamic addresses with associated dynamic DNS +records, the records can be updated by either the host or the DHCP +server. In many cases, update by the server is recommended, since the +server maintains lease information for each address. In some cases, +though, the server cannot update some or all of the DNS records. This +happens when the DNS and DHCP server are under different administration, +for example. + +A host can easily update its own DNS records when receiving information +from the DHCP server. It can also delete its records when shutting +down. If the host unexpectedly goes down, though, it cannot delete the +records. When the DHCP lease on the address expires and is not renewed, +the DHCP server may reassign the address. The DNS records now point to +an assigned address, but not the correct address. Until the host +updates its records again, DNS will contain bad information. + +Since the DHCP and DNS servers are often not co-located with the +clients, the possibility of a host unexpectedly going down and not +communicating with the servers is non-trivial. + + + + +Expires October 1999 [Page 2] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + +If the host could set a lease on the DNS records similar to that on its +address, the DNS records would lose validity at the same time as the +address. This would prevent bad information from remaining in DNS. DNS +has no such provision for leases, though, since this would require +storing a lease time along with each record (or each record in a dynamic +zone). + +An alternative method is suggested. A ``delete'' update is sent along +with the ``add'' update, but the delete is marked in such a way that it +will not be exectuted immediately. Instead, it will be stored for the +specified amount of time before being applied. If the host wishes to +extend or shorten the lifetime of the DNS record(s), it can replace the +``deferred delete'' record, which will reset the lease time of the +record(s). The ``deferred delete'' record would, of course, also be +removed if a normal delete update was received. + +3 - Protocol changes + +When doing a delete update operation as defined in [RFC2136] (deleting +an RR, an RRset, or all RRset from a name), the TTL field MUST be +specified as 0. An [RFC2136] compliant server will silently ignore (*) +an update record with a non-zero TTL. This document overloads the TTL +field. If TTL is non-zero, the value represents the number of seconds +(a 32 bit unsigned integer) before which the delete will be applied to +the zone. Thus, the delete operation will be deferred for that number +of seconds, where the number of seconds indicates the lease time. A 32 +bit integer provides for a lease time of over 136 years, which should be +long enough for most uses. + +3.1 - Storage and execution + +Deferred delete records are stored, persistently, by the name server. +The name server SHOULD attempt to evaluate the deletes in a timely +manner. If multiple deferred deletes are sent in the same DNS message +with the same TTL value, they MUST be processed atomically if processed +as planned (that is, none of the deferred deletes are updated or +cancelled). + +3.2 - Processing of deferred deletes + +When a deferred delete is received, the server must check to see if it +matches an existing deferred delete records, where matching indicates +the same name, type, class, and rdata. If a match is found, the new +deferred delete MUST replace the old one. If the deferred delete does +not refer to any record in the server, it should fail as a normal delete +would. + + + + + +Expires October 1999 [Page 3] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + +3.3 - Processing of normal deletes + +When a normal delete is received and accepted, the server SHOULD purge +any matching deferred delete records. + +3.4 - Processing of cancellations + +The value 0xFFFFFFFF (the largest unsigned 32 bit integer) in the TTL +field has a special meaning. If a delete containing this lease time is +received, the server will unconditionally remove any matching deferred +deletes. If no deferred delete matches, this request will be silently +ignored. + +3.5 - Processing of adds + +When data is added through a dynamic update which matches a deferred +delete, there is no additional processing done. + +4 - TTL handling + +Any record that may be deleted SHOULD have a short TTL compared to its +lease time, to prevent deleted data from being cached past its +expiration. + +When the time until an RR is deleted becomes low enough, the server MAY +modify the TTL of the RRset. Whenever the TTL is automatically reduced +by this process, the zone will be considered ``changed'' for the purpose +of automatic SOA SERIAL increment (as in [RFC2136]) and real time zone +slave notification [RFC1996]. As these operations can potentially be +expensive (more so if DNSSEC [RFC2535] signatures must be regenerated), +the specific limits and effects are left to the implementation. + +If the TTL is modified by the server, it is not reset if the lease is +renewed. Therefore, the original RR SHOULD be sent with the lease +renewal if the client expects that the server has modified the TTL. + + + + + + + + + + + + + + + + +Expires October 1999 [Page 4] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + +5 - Usage + +Normally, a deferred delete update will initially be sent along with an +add, although this is not required. Further updates to the deferred +delete may be sent independently, although the add should be sent again. +If the deferred delete is associated with a leased address, the lease +time of the update SHOULD be approximately equal to the lease time of +the address. + +6 - Protocol robustness + +This protocol has no inherent protection against replayed messages, +which can either originate from an attack or faulty hardware. To +prevent this problem, prerequisites should be used in the update +message, such as a test for the existence of a TXT record describing the +lease, which would be added along with the other records (see [RFC2136], +section 5). + +7 - Security considerations + +This addition to the dynamic DNS protocol does not affect the security +of the protocol. If security is desired, TSIG [TSIG] and/or DNSSEC +[RFC2535] authentication should be used, as specified in [simple-update] +or [RFC2137, update2]. The authors strongly recommend using security +along with this protocol. + +If a DNSSEC signed-zone is modified with deferred deletes, the server +must resign any affected records when the delete is executed. No +special processing is required when the delete is received. + +8 - IANA Considerations + +None. + +9 - References + +[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' + RFC 1034, ISI, November 1987. + +[RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification,'' RFC 1035, ISI, November 1987. + +[RFC1996] P. Vixie ``A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY),'' RFC 1996, ISC, August 1996. + +[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic + Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore + & Cisco & DEC, April 1997. + + + +Expires October 1999 [Page 5] + +INTERNET-DRAFT Deferred Dynamic DNS Deletes February 1999 + + +[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC + 2137, CyberCash, April 1997. + +[RFC2535] D. Eastlake ``Domain Name System Security Extensions,'' RFC + 2535, IBM, March 1999. + +[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington + ``Secret Key Transaction Signatures for DNS (TSIG),'' draft- + ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs, + February 1999. + +[simple-update] + B. Wellington ``Simple Secure Domain Name System (DNS) + Dynamic Update,'' draft-ietf-dnssec-simple-update-00.txt, + TISLabs, November 1998. + +[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic + Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite + Systems Company, August 1998. + +8 - Author's Address + + + Brian Wellington Olafur Gudmundsson + TISLabs at Network Associates TISLabs at Network Associates + 3060 Washington Road, Route 97 3060 Washington Road, Route 97 + Glenwood, MD 21738 Glenwood, MD 21738 + +1 443 259 2369 +1 443 259 2389 + + + + + + + + + + + + + + + + + + + + + + + +Expires October 1999 [Page 6] + diff --git a/doc/expired/draft-ietf-dnsind-dhcp-rr-00.txt b/doc/expired/draft-ietf-dnsind-dhcp-rr-00.txt new file mode 100644 index 0000000000..6d729e2938 --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-dhcp-rr-00.txt @@ -0,0 +1,167 @@ +INTERNET-DRAFT Andreas Gustafsson +draft-ietf-dnsind-dhcp-rr-00.txt Internet Engines, Inc. + October 1999 + + A DNS RR for encoding DHCP information + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + 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." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Abstract + + This document describes a DNS RR for use by DHCP servers that need to + store state information in the DNS. + +Introduction + + A set of procedures to allow DHCP servers [RFC2131] to automatically + update the DNS [RFC1034, RFC1035] is proposed in [DHCPDNS]. + + A situation can arise where multiple DHCP clients request the same + DNS name from their (possibly distinct) DHCP servers. To resolve + such conflicts, [DHCPDNS] proposes storing client identifiers in the + DNS to unambiguously associate domain names with the DHCP clients + "owning" them. Early versions of [DHCPDNS] proposed using TXT + records for encoding this information; the current version specifies + the use of KEY records. + + In the interest of clarity, it would be preferable for this DHCP + +Expires April 2000 [Page 1] + +draft-ietf-dnsind-dhcp-rr-00.txt October 1999 + + information to use a distinct RR type rather than the existing KEY + type. A separate RR type can also improve efficiency by avoiding the + unnecessary transmission of unrelated KEY records. + + This memo defines a distinct RR type for use by DHCP servers, the + "DHCP" RR. + +The DHCP RR + + The DHCP RR is defined with mnemonic DHCP and type code . + +DHCP RDATA format + + The RDATA section of a DHCP RR in transmission contains RDLENGTH + bytes of binary data. The format of this data and its interpretation + by DHCP servers and clients, including the interpretation of multiple + DHCP RRs at the same domain name, are TBD. [This part of the + specification should be driven by the needs of, and written in + cooperation with, the DHCP Working Group and the authors of + [DHCPDNS]]. + + DNS software should consider the RDATA section to be opaque. In DNS + master files, the RDATA is represented as a hexadecimal string with + an optional "0x" or "0X" prefix. Periods (".") may be inserted + anywhere after the "0x" for readability. This format is identical to + that of the NSAP RR [RFC1706]. The number of hexadecimal digits MUST + be even. + +Example + + A DHCP server allocating the IPv4 address 10.0.0.1 to a client + "client.org.nil" might associate eight bytes of housekeeping + information with the client as follows: + + client.org.nil. A 10.0.0.1 + client.org.nil. DHCP 01.23.45.67.89.ab.cd.ef + +Security Considerations + + The DHCP record as such does not introduce any new security problems + into the DNS. However, care should be taken not to store sensitive + information in DHCP records, since they are published along with + other DNS data. Note that even the hardware addresses of DHCP + clients may be considered sensitive information. + +IANA Considerations + + The IANA is requested to allocate an RR type number for the DHCP + +Expires April 2000 [Page 2] + +draft-ietf-dnsind-dhcp-rr-00.txt October 1999 + + record type from the regular RR type number range. + +References + + [RFC1035] - Domain Names - Implementation and Specifications, P. + Mockapetris, November 1987. + + [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, + November 1987. + + [RFC1706] - DNS NSAP Resource Records, B. Manning, R. Colella, + October 1994. + + [RFC2131] - Dynamic Host Configuration Protocol, R. Droms, March + 1997. + + [DHCPDNS] - draft-ietf-dhc-dhcp-dns-*.txt + +Author's Address + + Andreas Gustafsson + Internet Engines, Inc. + 950 Charter Street + Redwood City, CA 94063 + USA + + Phone: +1 650 779 6004 + + Email: gson@iengines.net + +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 implmentation 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. + +Expires April 2000 [Page 3] + +draft-ietf-dnsind-dhcp-rr-00.txt October 1999 + + 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." + +Expires April 2000 [Page 4] diff --git a/doc/expired/draft-ietf-dnsind-dname-03.txt b/doc/expired/draft-ietf-dnsind-dname-03.txt new file mode 100644 index 0000000000..f28cd1b3ea --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-dname-03.txt @@ -0,0 +1,502 @@ + +DNSIND Working Group Matt Crawford +Internet Draft Fermilab + March 21, 1999 + + Non-Terminal DNS Name Redirection + + + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + 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." + + To view the list Internet-Draft Shadow Directories, see + http://www.ietf.org/shadow.html. + + +1. Introduction + + This document defines a new DNS Resource Record called ``DNAME'', + which provides the capability to map an entire subtree of the DNS + name space to another domain. It differs from the CNAME record + which maps a single node of the name space. + + 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 [KWORD]. + + +2. Motivation + + This Resource Record and its processing rules were conceived as a + solution to the problem of maintaining address-to-name mappings in a + context of network renumbering. Without the DNAME mechanism, an + authoritative DNS server for the address-to-name mappings of some + network must be reconfigured when that network is renumbered. With + DNAME, the zone can be constructed so that it needs no modification + when renumbered. DNAME can also be useful in other situations, such + as when an organizational unit is renamed. + + + +Expires September 26, 1999 Crawford [Page 1] + +Internet Draft Non-Terminal Nicknames March 21, 1999 + + +3. The DNAME Resource Record + + The DNAME RR has mnemonic DNAME and type code 39 (decimal). + + DNAME has the following format: + + DNAME + + The format is not class-sensitive. All fields are required. The + RDATA field is a [DNSIS]. + + The DNAME RR causes type NS additional section processing. + + The effect of the DNAME record is the substitution of the record's + for its as a suffix of a domain name. A "no- + descendants" limitation governs the use of DNAMEs in a zone file: + + If a DNAME RR is present at a node N, there may be other data at + N (except a CNAME or another DNAME), but there MUST be no data + at any descendant of N. This restriction applies only to + records of the same class as the DNAME record. + + This rule assures predictable results when a DNAME record is cached + by a server which is not authoritative for the record's zone. It + MUST be enforced when authoritative zone data is loaded. Together + with the rules for DNS zone authority [DNSCLR] it implies that DNAME + and NS records can only coexist at the top of a zone which has only + one node. + + The compression scheme of [DNSIS] MUST NOT be applied to the RDATA + portion of a DNAME record unless the sending server has some way of + knowing that the receiver understands the DNAME record format. + Signalling such understanding is expected to be the subject of + future DNS Extensions. + + Naming loops can be created with DNAME records or a combination of + DNAME and CNAME records, just as they can with CNAME records alone. + Resolvers, including resolvers embedded in DNS servers, MUST limit + the resources they devote to any query. Implementors should note, + however, that fairly lengthy chains of DNAME records may be valid. + + +4. Query Processing + + To exploit the DNAME mechanism the name resolution algorithms + [DNSCF] must be modified slightly for both servers and resolvers. + + Both modified algorithms incorporate the operation of making a + + + +Expires September 26, 1999 Crawford [Page 2] + +Internet Draft Non-Terminal Nicknames March 21, 1999 + + + substitution on a name (either QNAME or SNAME) under control of a + DNAME record. This operation will be referred to as "the DNAME + substitution". + + +4.1. Processing by Servers + + For a server performing non-recursive service steps 3.c and 4 of + section 4.3.2 [DNSCF] are changed to check for a DNAME record before + checking for a wildcard ("*") label, and to return certain DNAME + records from zone data and the cache. + + DNS clients sending Extended DNS [EDNS0] queries with Version 0 or + non-extended queries are presumed not to understand the semantics of + the DNAME record, so a server which implements this specification, + when answering a non-extended query, SHOULD synthesize a CNAME + record for each DNAME record encountered during query processing to + help the client reach the correct DNS data. The behavior of clients + and servers under Extended DNS versions greater than 0 will be + specified when those versions are defined. + + The synthesized CNAME RR, if provided, MUST have + + The same CLASS as the QCLASS of the query, + + TTL equal to zero, + + An equal to the QNAME in effect at the moment the DNAME + RR was encountered, and + + An RDATA field containing the new QNAME formed by the action of + the DNAME substitution. + + If the server has the appropriate key on-line [DNSSEC, SECDYN], it + MAY generate and return a SIG RR for the synthesized CNAME RR. + + The revised server algorithm is: + + 1. Set or clear the value of recursion available in the response + depending on whether the name server is willing to provide + recursive service. If recursive service is available and + requested via the RD bit in the query, go to step 5, otherwise + step 2. + + 2. Search the available zones for the zone which is the nearest + ancestor to QNAME. If such a zone is found, go to step 3, + otherwise step 4. + + + + +Expires September 26, 1999 Crawford [Page 3] + +Internet Draft Non-Terminal Nicknames March 21, 1999 + + + 3. Start matching down, label by label, in the zone. The matching + process can terminate several ways: + + a. If the whole of QNAME is matched, we have found the node. + + If the data at the node is a CNAME, and QTYPE doesn't match + CNAME, copy the CNAME RR into the answer section of the + response, change QNAME to the canonical name in the CNAME + RR, and go back to step 1. + + Otherwise, copy all RRs which match QTYPE into the answer + section and go to step 6. + + b. If a match would take us out of the authoritative data, we + have a referral. This happens when we encounter a node with + NS RRs marking cuts along the bottom of a zone. + + Copy the NS RRs for the subzone into the authority section + of the reply. Put whatever addresses are available into the + additional section, using glue RRs if the addresses are not + available from authoritative data or the cache. Go to step + 4. + + c. If at some label, a match is impossible (i.e., the + corresponding label does not exist), look to see whether the + last label matched has a DNAME record. + + If a DNAME record exists at that point, copy that record + into the answer section. If substitution of its + for its in QNAME would overflow the legal size for a + , set RCODE to YXDOMAIN [DNSUPD] and exit; + otherwise perform the substitution and continue. If the + query was not extended [EDNS0] with a Version indicating + understanding of the DNAME record, the server SHOULD + synthesize a CNAME record as described above and include it + in the answer section. Go back to step 1. + + If there was no DNAME record, look to see if the "*" label + exists. + + If the "*" label does not exist, check whether the name we + are looking for is the original QNAME in the query or a name + we have followed due to a CNAME. If the name is original, + set an authoritative name error in the response and exit. + Otherwise just exit. + + If the "*" label does exist, match RRs at that node against + QTYPE. If any match, copy them into the answer section, but + + + +Expires September 26, 1999 Crawford [Page 4] + +Internet Draft Non-Terminal Nicknames March 21, 1999 + + + set the owner of the RR to be QNAME, and not the node with + the "*" label. Go to step 6. + + 4. Start matching down in the cache. If QNAME is found in the + cache, copy all RRs attached to it that match QTYPE into the + answer section. If QNAME is not found in the cache but a DNAME + record is present at an ancestor of QNAME, copy that DNAME + record into the answer section. If there was no delegation from + authoritative data, look for the best one from the cache, and + put it in the authority section. Go to step 6. + + 5. Use the local resolver or a copy of its algorithm (see resolver + section of this memo) to answer the query. Store the results, + including any intermediate CNAMEs and DNAMEs, in the answer + section of the response. + + 6. Using local data only, attempt to add other RRs which may be + useful to the additional section of the query. Exit. + + Note that there will be at most one ancestor with a DNAME as + described in step 4 unless some zone's data is in violation of the + no-descendants limitation in section 3. An implementation might + take advantage of this limitation by stopping the search of step 3c + or step 4 when a DNAME record is encountered. + + +4.2. Processing by Resolvers + + A resolver or a server providing recursive service must be modified + to treat a DNAME as somewhat analogous to a CNAME. The resolver + algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d + as 4.e and insert a new 4.d. The complete algorithm becomes: + + 1. See if the answer is in local information, and if so return it + to the client. + + 2. Find the best servers to ask. + + 3. Send them queries until one returns a response. + + 4. Analyze the response, either: + + a. if the response answers the question or contains a name + error, cache the data as well as returning it back to the + client. + + b. if the response contains a better delegation to other + servers, cache the delegation information, and go to step 2. + + + +Expires September 26, 1999 Crawford [Page 5] + +Internet Draft Non-Terminal Nicknames March 21, 1999 + + + c. if the response shows a CNAME and that is not the answer + itself, cache the CNAME, change the SNAME to the canonical + name in the CNAME RR and go to step 1. + + d. if the response shows a DNAME and that is not the answer + itself, cache the DNAME. If substitution of the DNAME's + for its in the SNAME would overflow the + legal size for a , return an implementation- + dependent error to the application; otherwise perform the + substitution and go to step 1. + + e. if the response shows a server failure or other bizarre + contents, delete the server from the SLIST and go back to + step 3. + + A resolver or recursive server which understands DNAME records but + sends non-extended queries MUST augment step 4.c by deleting from + the reply any CNAME records which have an which is a + subdomain of the of any DNAME record in the response. + + +5. Examples of Use + +5.1. Organizational Renaming + + If an organization with domain name FROBOZZ.EXAMPLE became part of + an organization with domain name ACME.EXAMPLE, it might ease + transition by placing information such as this in its old zone. + + frobozz.example. DNAME frobozz-division.acme.example. + MX 10 mailhub.acme.example. + + The response to an extended recursive query for www.frobozz.example + would contain, in the answer section, the DNAME record shown above + and the relevant RRs for www.frobozz-division.acme.example. + + +5.2. Classless Delegation of Shorter Prefixes + + The classless scheme for in-addr.arpa delegation [INADDR] can be + extended to prefixes shorter than 24 bits by use of the DNAME + record. For example, the prefix 192.0.8.0/22 can be delegated by + the following records. + + + + + + + + +Expires September 26, 1999 Crawford [Page 6] + +Internet Draft Non-Terminal Nicknames March 21, 1999 + + + + $ORIGIN 0.192.in-addr.arpa. + 8/22 NS ns.slash-22-holder.example. + 8 DNAME 8.8/22 + 9 DNAME 9.8/22 + 10 DNAME 10.8/22 + 11 DNAME 11.8/22 + + A typical entry in the resulting reverse zone for some host with + address 192.0.9.33 might be + + $ORIGIN 8/22.0.192.in-addr.arpa. + 33.9 PTR somehost.slash-22-holder.example. + + + The same advisory remarks concerning the choice of the "/" character + apply here as in [INADDR]. + + +5.3. Network Renumbering Support + + If IPv4 network renumbering were common, maintenance of address + space delegation could be simplified by using DNAME records instead + of NS records to delegate. + + $ORIGIN new-style.in-addr.arpa. + 189.190 DNAME in-addr.example.net. + + $ORIGIN in-addr.example.net. + 188 DNAME in-addr.customer.example. + + $ORIGIN in-addr.customer.example. + 1 PTR www.customer.example. + 2 PTR mailhub.customer.example. + ; etc ... + + This would allow the address space 190.189.0.0/16 assigned to the + ISP "example.net" to be changed without the necessity of altering + the zone files describing the use of that space by the ISP and its + customers. + + Renumbering IPv4 networks is currently so arduous a task that + updating the DNS is only a small part of the labor, so this scheme + may have a low value. But it is hoped that in IPv6 the renumbering + task will be quite different and the DNAME mechanism may play a + useful part. + + + + + +Expires September 26, 1999 Crawford [Page 7] + +Internet Draft Non-Terminal Nicknames March 21, 1999 + + +6. IANA Considerations + + This document defines a new DNS Resource Record type with the + mnemonic DNAME and type code 39 (decimal). The naming/numbering + space is defined in [DNSIS]. This name and number have already been + registered with the IANA. + + +7. Security Considerations + + The DNAME record is similar to the CNAME record with regard to the + consequences of insertion of a spoofed record into a DNS server or + resolver, differing in that the DNAME's effect covers a whole + subtree of the name space. The facilities of [DNSSEC] are available + to authenticate this record type. + + +8. References + + [DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities", + RFC 1034. + + [DNSCLR] R. Elz, R. Bush, "Clarifications to the DNS Specification", + RFC 2181. + + [DNSIS] P.V. Mockapetris, "Domain names - implementation and + specification", RFC 1035. + + [DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security + Extensions", RFC 2065. + + [DNSUPD] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic + Updates in the Domain Name System", RFC 2136. + + [EDNS0] P. Vixie, "Extensions mechanisms for DNS (EDNS0)", Currently + draft-dnsind-edns0-01.txt. + + [INADDR] H. Eidnes, G. de Groot, P. Vixie, "Classless IN-ADDR.ARPA + delegation", RFC 2317. + + [KWORD] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels," RFC 2119. + + [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic + Update", RFC 2137. + + + + + + +Expires September 26, 1999 Crawford [Page 8] + +Internet Draft Non-Terminal Nicknames March 21, 1999 + + +9. Author's Address + + Matt Crawford + Fermilab MS 368 + PO Box 500 + Batavia, IL 60510 + USA + + Phone: +1 630 840-3461 + + EMail: crawdad@fnal.gov + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires September 26, 1999 Crawford [Page 9] + diff --git a/doc/expired/draft-ietf-dnsind-edns0-01.txt b/doc/expired/draft-ietf-dnsind-edns0-01.txt new file mode 100644 index 0000000000..8aefeaf902 --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-edns0-01.txt @@ -0,0 +1,319 @@ + + + + + DNSIND Working Group Paul Vixie + INTERNET-DRAFT ISC + January, 1999 + + + Extension mechanisms for DNS (EDNS0) + + + Status of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + 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.'' + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + + + 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. + + + + + + Expires July 1999 [Page 1] + + INTERNET-DRAFT EDNS0 January 1999 + + + 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. + + 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. The 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. + + + + Expires July 1999 [Page 2] + + INTERNET-DRAFT EDNS0 January 1999 + + + 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. + + 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 buffer 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. + + + + + + Expires July 1999 [Page 3] + + INTERNET-DRAFT EDNS0 January 1999 + + + 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. Requestors are advised to retry in such cases. + + 4.5.2. Both requestors and responders are advised to take account of the + path's already discovered MTU (if known) when considering message sizes. + + 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.'' Note that both requestors and responders + should set this to the highest level they implement, + that responders should send back RCODE=BADVERS and that + requestors should be prepared to probe using lower + version numbers if they receive an 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 + + + + Expires July 1999 [Page 4] + + INTERNET-DRAFT EDNS0 January 1999 + + + 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 + + IANA is hereby requested to assign an RR type code 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. + + 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. + + + + Expires July 1999 [Page 5] + + INTERNET-DRAFT EDNS0 January 1999 + + + 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] P. Mockapetris, ``Domain Names - Implementation and + Specification,'' RFC 1035, USC/Information Sciences + Institute, November 1987. + + 10 - Author's Address + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063 + +1 650 779 7001 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Expires July 1999 [Page 6] + diff --git a/doc/expired/draft-ietf-dnsind-edns1-03.txt b/doc/expired/draft-ietf-dnsind-edns1-03.txt new file mode 100644 index 0000000000..b300eed20c --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-edns1-03.txt @@ -0,0 +1,249 @@ + DNSIND Working Group Paul Vixie + INTERNET-DRAFT ISC + June, 1999 + + Extensions to DNS (EDNS1) + + Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + 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." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Abstract + + This document specifies a number of extensions within the Extended + DNS framework defined by [EDNS0], including several new extended + label types and the ability to ask multiple questions in a single + request. + + 1 - Rationale and Scope + + 1.1. EDNS (see [EDNS0]) specifies an extension mechanism to DNS (see + [RFC1035]) which provides for larger message sizes, additional label + types, and new message flags. + + 1.2. This document makes use of the EDNS extension mechanisms to add + several new extended label types and message options, and the ability to + ask multiple questions in a single request. + + Expires December 1999 [Page 1] + + INTERNET-DRAFT EDNS1 June 1999 + + 2 - Affected Protocol Elements + + 2.1. Compression pointers are 14 bits in size and are relative to the + start of the DNS Message, which can be 64KB in length. 14 bits restrict + pointers to the first 16KB of the message, which makes labels introduced + in the last 48KB of the message unreachable by compression pointers. A + longer pointer format is needed. + + 2.2. DNS Messages are limited to 65535 octets in size when sent over + TCP. This acts as an effective maximum on RRset size, since multiple + TCP messages are only possible in the case of zone transfers. Some + mechanism must be created to allow normal DNS responses (other than zone + transfers) to span multiple DNS Messages when TCP is used. + + 2.3. Multiple queries in a question section have not been supported in + DNS due the applicability of some DNS Message Header flags (such as AA) + and of the RCODE field only to a single QNAME, QTYPE, and QCLASS. + Multiple questions per request are desirable, and some way of asking + them must be made available. + + 3 - Extended Label Types + + 3.1. In [EDNS0], the ``0 1'' label type was specified to denote an + extended label type, whose value is encoded in the lower six bits of the + first octet of a label, and an extended label type of ``1 1 1 1 1 1'' + was further reserved for use in future multibyte extended label types. + + 3.2. The ``0 0 0 0 0 0'' extended label type will indicate an extended + compression pointer, such that the following two octets comprise a + 16-bit compression pointer in network byte order. Like the normal + compression pointer, this pointer is relative to the start of the DNS + Message. + + 3.3. The ``0 0 0 0 0 1'' extended label type will indicate a counted bit + string label as described in [CRAW98]. + + 3.4. The ``0 0 0 0 1 0'' extended label type will indicate a ``long + local compression pointer'' as described in [KOCH98]. + + Expires December 1999 [Page 2] + + INTERNET-DRAFT EDNS1 June 1999 + + 4 - OPT pseudo-RR Flags and Options 4.1. The extended RCODE and flags + are structured as follows: + + +0 (MSB) +1 (LSB) + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 0: | EXTENDED-RCODE | VERSION | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + 2: |MD |FM |RRD|LM | Z | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. (As + defined by [EDNS0].) + + VERSION Indicates the implementation level of whoever sets it. + Full conformance with the draft standard version of this + specification is version ``1.'' Note that both + requestors and responders should set this to the highest + level they implement, that responders should send back + RCODE=BADVERS and that requestors should be prepared to + probe using lower version numbers if they receive an + RCODE=BADVERS. + + MD ``More data'' flag. Valid only in TCP streams where + message ordering and reliability are guaranteed. This + flag indicates that the current message is not the + complete request or response, and should be aggregated + with the following message(s) before being considered + complete. Such messages are called ``segmented.'' It + is an error for the RCODE (including the EXTENDED- + RCODE), AA flag, or DNS Message ID to differ among + segments of a segmented message. It is an error for TC + to be set on any message of a segmented message. Any + given RR must fit completely within a message, and all + messages will both begin and end on RR boundaries. Each + section in a multipart message must appear in normal + message order, and each section must be complete before + later sections are added. All segments of a message + must be transmitted contiguously, without interleaving + of other messages. + + FM ``First match'' flag. Notable only when multiple + questions are present. If set in a request, questions + will be processed in wire order and the first question + whose answer would have NOERROR AND ANCOUNT>0 is treated + + Expires December 1999 [Page 3] + + INTERNET-DRAFT EDNS1 June 1999 + + as if it were the only question in the query message. + Otherwise, questions can be processed in any order and + all possible answer records will be included in the + response. Response FM should be ignored by requestors. + + RRD ``Recursion really desired'' flag. Notable only when a + request is processed by an intermediate name server + (``forwarder'') who is not authoritative for the zone + containing QNAME, and where QTYPE=ANY or QDCOUNT>1. If + set in a request, the intermediate name server can only + answer using unexpired cached answers (either positive + or negative) which were atomically acquired using (a) + the same QTYPE or set of QTYPEs present in the current + question and whose TTLs were each minimized to the + smallest among them when first cached, and (b) the same + FM and LM settings present in the current question. + + LM ``Longest match'' flag. If this flag is present in a + query message, then for any question whose QNAME is not + fully matched by zone or cache data, the longest + trailing label-bounded suffix of the QNAME for which + zone or cache data is present will be eligible for use + as an answer. Note that an intervening wildcard name + shall supercede this behaviour and the rules described + in [RFC1034 4.3.2, 4.3.3] shall apply, except that the + owner name of the answer will be the wildcard name + rather than the QNAME. Any of: QTYPE=ANY, or + QCLASS=ANY, or QCOUNT>1, shall be considered an error if + the LM flag is set. + + If LM is set in a request, then LM has meaning in the + response as follows: If the content of the response + would have been different without the LM flag being set + on the request, then the response LM will be set; If the + content of the response was not determined or affected + by the request LM, then the response LM will be cleared. + If the request LM was not set, then the response LM is + not meaningful and should be set to zero by responders + and ignored by requestors. + + Z Set to zero by senders and ignored by receivers, unless + modified in a subsequent specification. + + Expires December 1999 [Page 4] + + INTERNET-DRAFT EDNS1 June 1999 + + 5 - Multiple Questions for QUERY + + 5.1. If QDCOUNT>1, multiple questions are present. All questions must + be for the same QNAME and QCLASS; only the QTYPE is allowed to vary. It + is an error for QDCOUNT>1 and any QTYPE=ANY or QCLASS=ANY. + + 5.2. RCODE and AA apply to all RRs in the answer section having the + QNAME that is shared by all questions in the question section. AA + applies to all matching answers, and will not be set unless the exact + original request was processed by an authoritative server and the + response forwarded in its entirety. + + 5.3. If a multiple question request is processed by an intermediate + server and the authority server does not support multiple questions, the + intermediate server must generate an answer iteratively by making + multiple requests of the authority server. In this case, AA must never + be set in the final answer due to lack of atomicity of the contributing + authoritative responses. + + 5.4. If iteratively processing a multiple question request using an + authority server which can only process single question requests, if any + contributing request generates a SERVFAIL response, then the final + response's RCODE should be SERVFAIL. + + 6 - Acknowledgements + + Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, + Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, Michael Patton, + and Michael Graff were each instrumental in creating this specification. + + 7 - References + + [RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification,'' RFC 1035, USC/Information Sciences + Institute, November 1987. + + [EDNS0] P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' Draft + draft-ietf-dnsind-edns0-XX, IETF DNSIND, September 1998 + + [CRAW98] M. Crawford, ``Binary Labels in the Domain Name System,'' + Draft draft-ietf-dnsind-binary-labels-XX, IETF DNSIND, March + 1998. + + [KOCH98] P. Koch, ``A New Scheme for the Compression of Domain + Names,'' Draft draft-ietf-dnsind-local-compression-XX.txt. + + Expires December 1999 [Page 5] + + INTERNET-DRAFT EDNS1 June 1999 + + IETF DNSIND, March 1998. + + 8 - Author's Address + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063 + +1 650 779 7001 + + + Expires December 1999 [Page 6] diff --git a/doc/expired/draft-ietf-dnsind-indirect-key-00.txt b/doc/expired/draft-ietf-dnsind-indirect-key-00.txt new file mode 100644 index 0000000000..7857081ee9 --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-indirect-key-00.txt @@ -0,0 +1,470 @@ +DNSIND Working Group D. Eastlake +INTERNET-DRAFT IBM +Expires October 1999 + April 1999 +draft-ietf-dnsind-indirect-key-00.txt + + + Indirect KEY RRs in the Domain Name System (DNS) + -------- --- --- -- --- ------ ---- ------ ----- + + Donald E. Eastlake 3rd + + + +Status of This Document + + This draft, file name draft-ietf-dnsind-indirect-key-00.txt, is + intended to be become a Proposed Standard RFC. Distribution of this + document is unlimited. Comments should be sent to the DNSSEC mailing + list or to the author. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + + + +Abstract + + [RFC 2535] defines a means for storing cryptographic public keys in + the Domain Name System. An additional code point is defined for the + algorithm field of the KEY resource record (RR) to indicate that the + key is not stored in the KEY RR but is pointed to by the KEY RR. + Encodings to indicate different types of key and pointer formats are + specified. + + [This draft is moved from the DNSSEC WG as part of that WG's merger + into me DNSIND WG. It would have been draft-ietf-dnssec-indirect- + key-02.txt in the DNSSEC WG.] + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT Indirect KEY RRs + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. The Indirect KEY RR Algorithm...........................3 + 2.1 The Target Type Field..................................4 + 2.2 The Target Algorithm Field.............................5 + 2.3 The Hash Fields........................................5 + 3. Performance Considerations..............................6 + 4. IANA Considerations.....................................6 + 5. Security Considerations.................................6 + References.................................................7 + Author's Address...........................................7 + Expiration and File Name...................................8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT Indirect KEY RRs + + +1. Introduction + + The Domain Name System (DNS) security extensions [RFC 2535] provide + for the general storage of public keys in the domain name system via + the KEY resource record (RR). These KEY RRs are used in support of + DNS security and may be used to support other security protocols. + KEY RRs can be associated with users, zones, and hosts or other end + entities named in the DNS. + + For reasons given below, it will sometimes be desireable to store a + key or keys elsewhere and merely point to it from the KEY RR. + Indirect key storage makes it possible to point to a key service via + a URL, to have a compact pointer to a larger key or set of keys, to + point to a certificate either inside DNS [RFC 2538] or outside the + DNS, and where appropriate, to store a key or key set applicable to + many DNS entries in some place and point to it from those entries. + + However, to simplify DNSSEC implementation, this technique MUST NOT + be used for KEY RRs used in for verification in DNSSEC, i.e., the + value of the "protocol" field of an indirect KEY RR MUST NOT be 3. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", + "RECOMMENDED", and "MAY" in this document are to be interpreted as + described in [RFC 2119]. + + + +2. The Indirect KEY RR Algorithm + + Domain Name System (DNS) KEY Resource Record (RR) [RFC 2535] + algorithm number 252 is defined as the indirect key algorithm. This + algorithm MAY NOT be used for zone keys in support of DNS security. + All KEYs used in DNSSEC validation MUST be stored directly in the + DNS. + + When the algorithm byte of a KEY RR has the value 252, the "public + key" portion of the RR is formated as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | target type | target alg. | hash type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | hash size | hash (variable size) / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ + | / + / pointer (variable size) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT Indirect KEY RRs + + +2.1 The Target Type Field + + Target type specifies the type of the key containing data being + pointed at. + + Target type + ----------- + + 0 - reserved, see section 4 + + 1 - indicates that the pointer is a domain name from which KEY RRs + [RFC 2535] should be retrieved. Name compression in the pointer + field is prohibited. + + 2 - indicates that the pointer is a null terminated character string + which is a URL [RFC 1738]. For exisiting data transfer URL + schemes, such as ftp, http, shttp, etc., the data is the same as + the public key portion of a KEY RR. (New URL schemes may be + defined which return multiple keys.) + + 3 - indicates that the pointer is a domain name from which CERT RRs + [RFC 2538] should be retrieved. Name compression in the pointer + field is prohibited. + + 4 - indicates that the pointer is a null terminated character string + which is a URL [RFC 1738]. For exisiting data transfer URL + schemes, such as ftp, http, shttp, etc., the data is the same as + the entire RDATA portion of a CERT RR [RFC 2538]. (New URL + schemes may be defined which return multiple such data blocks.) + + 5 - indicates that the pointer is a null terminated character string + which is a URL [RFC 1738]. For exisiting data transfer URL + schemes, such as ftp, http, shttp, etc., the data is a PKCS#1 [RFC + 2437] format key. (New URL schemes may be defined which return + multiple keys.) + + 6 through 255 - available for assignment, see section 4. + + 256 through 511 (i.e., 256 + n) - indicate that the pointer is a null + terminated character string which is a URL [RFC 1738]. For + exisiting data transfer URL schemes, such as ftp, http, shttp, + etc., the data is a certificate of the type indicated by a CERT RR + [RFC 2538] certificate type of n. That is, target types 257, 258, + and 259 are PKIX, SPKI, and PGP certificates and target types 509 + and 510 are URL and OID private certificate types. (New URL + schemes may be defined which return multiple such certificates.) + + 512 through 65534 - available for assignment, see section 4. + + 65535 reserved, see section 4. + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT Indirect KEY RRs + + +2.2 The Target Algorithm Field + + The algorithm field is as defined in [RFC 2535]. If non-zero, it + specifies the algorithm type of the target key or keys pointed. If + zero, it does not specify what algorithm the target key or keys apply + to. + + + +2.3 The Hash Fields + + If the indirecting KEY RRset [RFC 2181, 2535] is retrieved from an + appropriately secure DNS zone with a resolver implementing DNS + security, then there would be a high level of confidence in the + entire value of the KEY RRset including any direct keys. This may or + may not be true of any indirect key pointed to. If an indirect key + is embodied in a certificate or retrieved via a secure protocol such + as SHTTP, it may also be secure. But an indirecting KEY RR could, + for example, simply have an FTP URL pointing to a binary key stored + elsewhere, the retrieval of which would not be secure. + + The hash option in algorithm 252 KEY RRs provides a means of + extending the security of the indirecting KEY RR to the actual key + material pointed at. By including a hash in a secure indirecting RR, + this secure hash can be checked against the hash of the actual keying + material + + Type Hash Algorithm + ---- -------------- + 0 indicates no hash present + 1 MD5 [RFC 1321] + 2 SHA-1 + 3 RIPEMD + 4-252 available, see section 4 + 253 private, domain name (see below) + 254 private, OID (see below) + 255 reserved + + Codes 253 and 254 indicate that a private, proprietary, local, or + experimental hash algorithm is used. For code 253, the hash field + begins with a wire encoded domain name (with compression prohibited) + that indicates the algorithm to use. For code 254, the hash field + begins with a one byte unsigned OID length followed by a BER encoded + OID which indicates the algorithm to use. + + The hash size field is an unsigned octet count of the hash field size + less the length of any code 253 or 254 prefix. For some hash + algorithms it may be fixed by the algorithm choice but this will not + always be the case. For example, hash size is used to distinguish + between RIPEMD-128 (16 octets) and RIPEMD-160 (20 octets). If the + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT Indirect KEY RRs + + + hash algorithm field is 0, the hash size MUST be zero and no hash + octets are present. + + The hash field itself is variable size with its length specified by + the hash size field and any code 253 or 254 prefix. + + + +3. Performance Considerations + + With current public key technology, an indirect key will sometimes be + shorter than the keying material it points at. In addition, there + can be cases where a single indirect KEY RR points to multiple keys + elsewhere. This may improve DNS performance in the retrieval of the + initial KEY RR. However, an additional retrieval step then needs to + be done to get the actually keying material which must be added to + the overall time to get the public key. + + + +4. IANA Considerations + + IETF consensus, standards action, and similar terms in this section + are as define in [RFC 2434]. + + KEY RR algorithm number 252 was already reserved for indirect keys in + RFC 2535. + + An IETF standards action is required to allocate target type codes + hex x0000, x0006 through x00FF, x0200 through x0FFF, and xFFFF. + Codes in the range x1000 through x7FFF can be allocated by an IETF + consensus. Codes x8000 through xFEFF are available on a first come + first serve basis. Codes xFF00 through xFFFE are available for + experimentation or private local use without allocation. Use of + codes in this block may result in conflicts outside such experiment + or locality. + + An IETF consensus is required to allocate an indirect KEY RR hash + algorithm code in the range 4-252 and a standards action is required + to allocate hash algorithm code 255. Codes 253 and 254 should cover + requirements for local, private, or proprietary algorithms. + + + +5. Security Considerations + + The indirecting step of using an indirect KEY RR adds complexity and + additional steps where security could go wrong. If the indirect key + RR was retrieved from a zone that was insecure for the resolver, you + have no security. If the indirect key RR, although secure itself, + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT Indirect KEY RRs + + + point to a key which can not be securely retrieved and is not + validateted by a secure hash in the indirect key RR, you have no + security. + + + +References + + RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", + STD 13, November 1987. + + RFC 1035 - P. Mockapetris, "Domain Names - Implementation and + Specifications", STD 13, November 1987. + + RFC 1321 - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992. + + RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform + Resource Locators (URL)", December 1994. + + RFC 2119 - "Key words for use in RFCs to Indicate Requirement + Levels", S. Bradner. March 1997. + + RFC 2181 - R. Elz, R. Bush, "Clarifications to the DNS + Specification", July 1997. + + RFC 2434 - T. Narten, H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", October 1998. + + RFC 2437 - B. Kaliski, J. Staddon, "PKCS #1: RSA Cryptography + Specifications Version 2.0", October 1998. + + RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", + March 1999. + + RFC 2538 - D. Eastlake, O. Gudmundsson, "Storing Certificates in the + Domain Name System (DNS)", March 1999. + + + +Author's Address + + Donald E. Eastlake 3rd + IBM + 65 shindegan Hill Road, RR #1 + Carmel, NY 10512 USA + + Telephone: +1-914-784-7913 (w) + +1-914-276-2668 (h) + FAX: +1-914-784-3833 (w) + EMail: dee3@us.ibm.com + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT Indirect KEY RRs + + +Expiration and File Name + + This draft expires October 1999. + + Its file name is draft-ietf-dnsind-indirect-key-00.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 8] + diff --git a/doc/expired/draft-ietf-dnsind-keyreferral-00.txt b/doc/expired/draft-ietf-dnsind-keyreferral-00.txt new file mode 100644 index 0000000000..7670b4c66e --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-keyreferral-00.txt @@ -0,0 +1,440 @@ + +DNSIND WG Edward Lewis +INTERNET DRAFT TIS Labs +May Update: RFC 2535 Jerry Scharf +Catagory: I-D ISC + April 1, 1999 + + The Zone Key Referral + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + 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." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments should be sent to the authors or the DNSIND WG mailing list + . + + This draft expires on October 1, 1999 + +Copyright Notice + + Copyright (C) The Internet Society (1999). All rights + reserved. + +Notes on this document + +This section will only appear in the -00.txt edition of this draft. + +This document originated in the DNSSEC working group in June 1998. The +discussion of the issues in this draft were tabled until the publication +of the then current DNSSEC drafts as RFCs. + +The first version of this document lists a third author, John Gilmore. +He is listed as an author because he was one of the initiators of what is +proposed. In this and following versions he is only listed in the +Acknowledgements (as opposed to being an author) as he has not been +involved in the writing/editing of the draft. This has been done to +avoid assigning his name to a document he may not have a chance to read, +this is not intended as a slight on his efforts. + +When commenting on this draft, please be aware that some terms used here +are up for negotiation before progressing - such as "thief" and "road +block" appearing later in the draft. Comments which are left justified +were added during the re-issuing of the draft, they add context that +may have been lost over time. + + Abstract + + A new type of key is defined to address the problems of + performance in large delegeted zones and issues of liability of + registrars with regards to the storing of public keys belonging + to zone cuts. This new key type also brings DNSSEC more in line + with the DNS treatment of zone cuts and speeds recovery in + handling privatekey exposure. + + The new type of key is a referral record that is stored, signed, + at the parent zone's place for the delegation point. A resolver + receiving this record is being informed that there are genuine + public keys at the child's authoritative name servers. The + parent no longer needs to store the child's public keys locally. + +1 Introduction + + There are a number of different reasons for the proposal of this + new key type. Reasons include: + o the performance impact that RFC 2535 has on name servers + o the problem of updating a widely delegated parent zone on demand + o statements in RFC 2181 on authoritative data at delegations + o perceived liability of the operator of a name server or registry + + To address these issues, which are expanded upon below, a new + key type is proposed - a "zone key referral" - to join the user + key, host key, and zone key types defined in RFC 2535. + +1.1 Performance Issues + + A sample zone will be used to illustrate the problem. The + example will part from reality mostly in the length of zone + names, which changes the size of the owner and resource record + data fields. + + # $ORIGIN test. + # @ IN SOA + # IN SIG SOA + # IN KEY <1024 bit zone key> + # IN SIG KEY + # IN SIG KEY + # IN NS ns.test. + # IN SIG NS + # IN NXT my-org.test. NS SOA SIG KEY NXT + # IN SIG NXT + # + # my-org IN KEY <1024 bit zone key> + # IN KEY <1024 bit zone key> + # IN SIG KEY + # IN NS ns1.my-org.test. + # IN NS ns2.my-org.test. + # IN NXT them.test. NS SIG KEY NXT + # IN SIG NXT + # + # them IN KEY 0xC100 3 1 + # IN SIG KEY + # IN NS ns1.them.test. + # IN NS ns2.them.test. + # IN NXT test. NS SIG KEY NXT + # IN SIG NXT + + In this zone file fragment, "my-org" is a delegation point of + interest with two registered public keys. Presumably, one key + is for signatures generated currently and the other is for still + living and valid but older signatures. "them" is another + delegation point, with a NULL key. This signifies that this zone + is unsecured. + + To analyze the performance impact of the storing of keys, the + number of bytes used to represent the RRs in the procotol format + is used. The actual number of bytes stored will likely be + higher, accounting for data structure overhead and alignment. + The actual number of bytes transferred will be lower due to DNS + name compression. + + The number of bytes for my-org's two 1024-bit keys, two NS + records, NXT and the associated signatures is 526. The bytes + needed for them (with the NULL key) is 346. Currently, there + are close to 2 million entries in com., so if we take my-org as + a typical domain, over 1GB on memory will be needed for com. + + The zone keys used in the example are set to 1024 bits. This + number may range from as low as 512 bits upwards to over 3000 + bits. To scale the above numbers to a different key size, + multiply the difference in key sizes by 4 for my-org and by 2 + for them, and adjust the numbers accordingly. + + The increased size of the data held for the zone cuts will have + two impacts at the transport and below layers. Bandwidth beyond + that currently needed will be used to carry the KEY records. + The inclusion of all of the child's keys will also push DNS over + the UDP size limit and start using TCP - which could cause + critical problems for current heavily used name servers, like + the roots. + + Another impact, not illustrated by the example, is the frequency + of updates. If each time a public key for my-org is added or + deleted, the SOA serial number will have to increase, and the + SOA signed again. If an average zone changes its keys(s) once + per month, there will be on average 45 updates per minute in a + zone of 2 million delegations. + +(The multiple algorithms issue is an extension of multiple keys. The +example should be updated to show at least a DSS key as well as an RSA +key.) + +1.2 Security Incident Recovery (w/ respect to keys only) + + Once a zone administrator is alerted that any key's private + counterpart has been discovered (exposed), the first action to + be taken is to stop advertising the public key in DNS. This + doesn't end the availability of the key - it will be residing in + caches - but is the closest action resembling revokation + available in DNS. + + Stopping the advertisement in the zone's name servers is as + quick as altering the master file and restarting the name + server. Having to do this in two places will will only delay + the time until the recovery is complete. + + For example, a registrar of a top level domain has decided to + update its zone only on Mondays and Fridays due to the size of + the zone. A customer/delegatee is the victim of a break in, in + which one of the items taken is the file of private keys used to + sign DNS data. If this occurs on a Tuesday, the thief has until + Friday to use the keys before they disappear from the DNS, even + if the child stops publishing them immediately. + + If the public key set is in the parent zone, and the parent zone + is not able to make the change quickly, the public key cannot be + revoked quickly. If the parent only refers to there being a key + at the child zone, then the child has the agility to change the + keys - even issue a NULL key, which will force all signatures in + the zone to become suspect. + +1.3 DNS Clarifications + + RFC 2181, section 6, clarifies the status of data appearing at a + zone cut. Data at a zone cut is served authoritatively from the + servers listed in the NS set present at the zone cut. The data + is not (necessarily) served authoritatively from the parent. + (The exception is in servers handling both the parent and child + zone.) + + Section 6 also mentions that there are two exceptions created by + DNSSEC, the NXT single record set and the KEY set. This + proposal addresses the exception relating to the KEY set, + limiting its severity (but falling short of removing it + altogether). By limiting the exception, we will be simplifying + DNS. + +1.4 Liability + + Liability is a legal concept, so it is not wise to attempt an + engineering solution to it. However, the perceived liability + incurred in using DNSSEC by registrars may prevent the adoption + of DNSSEC. Hence DNSSEC should be engineered in such a away to + address the concern. + + One source of liability is the notion that by advertising a + public key for a child zone, a parent zone is providing a + service of security. With that comes responsibility. By having + the parent merely indicate that a child has a key (or has no + key), the parent is providing less in the way of security. If + the parent is wrong, the potential loss is less. Instead of + falsely authenticated data, configuration errors will be + apparent to the resolving client. + +2 The Proposal + + The proposal is to introduce a new key type which indicates + whether the delegated zone is running secured or not. Running + secured is either a zone signed with at least one key, an + experimental zone, or a zone with only NULL keys published. + + The Zone Referral Key will resemble the NULL key in syntax. + There will be a flags field, an algorithm field, and a protocol + field, but no public key material. The Referral Key is signed + by the parent zone, as was the public key set in RFC 2065. + There is only one Referral Key RR present. + + The Referral Key flags field will have the following values: + Field Bit(s) Value Meaning + + A/C 0- 1 0b01 indicates a key will be found + 0b11 indicates a key will not be found + 0b?0 error (referral cannot encrypt) + XT 2 0 no extended flags are needed + Z 4- 5 0 must be zero for all keys + NAMTYP 6- 7 0b11 this is a referral to a zone key + Z 8-11 0 must be zero for all keys + SIG 12-15 0 must be zero for a referral key + + The legal values of the flags field are (in summary): + + Hex Value Indicates + 0x4300 The delegation has a key record set + 0xC300 The delegation has no key record + + Other values are not valid for Referral Keys (but may be valid + for other keys). + + The Protocol field must be set to 3, the DNSSEC protocol value. + + The Algorithm field must be 0. + +The algorithm is not important at this point. So long as the searcher +knows to expect a key set at the delegated zone's apex, a secure chain +is possible. One the key set is retrieved and verified, then the +algorithms used in the delegated zone are known. (The issue is that a +zone may be signed in algorithm 1 and not 3, 3 and not 1, both, etc., +and a secure resolver must know this in order to set signature arrival +expectations. + +2.1 Example + + The Referral key for my-org.test. and them.test. would appear as + the following in the zone master file: + + my-org.test. IN KEY 0x4300 3 0 + them.test. IN KEY 0xC300 3 0 + + In the example introduced earlier, the master file would change + to the following. + + # $ORIGIN test. + # @ IN SOA + # IN SIG SOA + # IN KEY <1024 bit zone key> + # IN SIG KEY + # IN SIG KEY + # IN NS ns.test. + # IN SIG NS + # IN NXT my-org.test. NS SOA SIG KEY NXT + # IN SIG NXT + # + # my-org IN KEY 0x4300 3 0 + # IN SIG KEY + # IN NS ns1.my-org.test. + # IN NS ns2.my-org.test. + # IN NXT them.test. NS SIG KEY NXT + # IN SIG NXT + # + # them IN KEY 0xC300 3 1 + # IN SIG KEY + # IN NS ns1.them.test. + # IN NS ns2.them.test. + # IN NXT test. NS SIG KEY NXT + # IN SIG NXT + +3 Analysis + + By removing the public keys from the parent's master file, the + parent is no longer a road block during an emergency removal of + keys. A parent zone is unchanged as a zone changes from NULL + keys to experimental keys to fully signed. The parent is also + not providing a security service, other than to authentically + claim the existence of a KEY record set - akin to the "hints" of + the name servers. + + The change also improves the prospect for performance. The need + for multiple KEY RR's, each one on the order of 100 bytes, is + removed and replaced by a single KEY RR of the order of 25 + bytes. Saving bytes reduces the need to use TCP to avoid + truncated responses. Also, the need for updating the zone drops + - no longer will there be updates for each key change. + + As far as the statements by RFC 2181 conerning authority levels, + the Referral Key is not authortative and would be superseeded by + a verified set of the real zone keys. The only caveat is that + once the verified set of keys expire (assuming the parent has to + learn the keys from another server), the Referal Key must + reappear. This is an example of what has been labelled "mount- + like semantics." + + [No reference for mount-like semantics has yet been found.] + + The last point is important. This requires the "mount-like + semantics" that have been discussed for the BIND name servers. + Once hints are overridden by learned, authorititative and + verified data, the hints are not discarded. Hints in this state + are stored and become visible when the learned data expires. + +4 IANA Considerations + + Other than using a new value in the flags field of the KEY RR, + no new number assignments are needed. The flags field is not + under the control of IANA as of yet. There are no requirements + placed on IANA by this draft. + +5 Security Considerations + + There has been some debate about whether the Referral key should + be treated as a hint - just like the NS records. If so, then + there is no need to sign the Referral Key, and an unsigned + (hence non-authenticated) security record is of little value. + So, is the Referral Key even needed? + + Authentication in DNSSEC is done from the data "back" towards a + trusted point - e.g., "up" to the root. Since the + authentication is done by going repeatedly from child to parent, + why bother having the parent indicate the status of the child? + + The answer is in the scenario in which a resolver somewhere has + obtained data which fails the verification process. Perhaps the + signature is wrong, a key in the chain of trust is unavailable, + the set should have had a signature, but none is found (or vice + versa), or the trail of signed-by names is not acceptable. In + this case, the resolver needs to find the authoritative zone, + its status and its name server set. + + If a zone is being attacked by a masquerader, and parents do not + make any statements about the security of child zones, then an + easy and successfull attack may occur. An attacker only needs + to supply either fake name server records or glue records to + redirect queries. + + While this attack will not be stopped as far as denial of + service, the masquerader can be stopped from being accepted as + an authoritative source if the parent of the zone claims the + child is secure and signs the public keys of the true child and + not the masquerader. + + The masquerader cannot successfully claim that the zone is + unsigned, because it must have a zone key signed by the parent. + NULL or not, the key would not be trusted by the resolver, + assuming the parent has not also been duped. The resolver, + sensing this, should report an error or security incident, and + not accept data. + +6 Acknowledgements + + John Gilmore originally raised the issues that have led to this + document. + +7 Author's addresses + +Edward Lewis Jerry Scharf + +3060 Washinton Rd (Rte 97) +Glenwood, MD 21738 ++1(443)259-2352 + +8 References + +RFC 2181 "Clarifications to the DNS Specification", Elz and Bush +RFC 2535 "Domain Name System Security Extensions", Eastlake + +9 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 implmentation 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." + +This draft expires on October 1, 1999 diff --git a/doc/expired/draft-ietf-dnsind-kitchen-sink-02.txt b/doc/expired/draft-ietf-dnsind-kitchen-sink-02.txt new file mode 100644 index 0000000000..9a35062c52 --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-kitchen-sink-02.txt @@ -0,0 +1,697 @@ +INTERNET-DRAFT Donald E. Eastlake, 3rd + IBM +Expires March 2000 September 1999 +draft-ietf-dnsind-kitchen-sink-02.txt + + + + The Kitchen Sink DNS Resource Record + --- ------- ---- --- -------- ------ + + Donald E. Eastlake 3rd + + + +Status of This Document + + This draft, file name draft-ietf-dnsind-kitchen-sink-02.txt, is + intended to be become an Experimental RFC. Distribution of this + document is unlimited. Comments should be sent to + or to the author. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved + + + +Abstract + + Periodically people desire to put proprietary, complex, and/or + obscure data into the Domain Name System (DNS). This draft defines a + kitchen sink Resource Record that will satisfy this desire for the + storage of miscellaneous structured information. + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT The Kitchen Sink Resource Record + + +Acknowledgements + + The suggestions or information provided by the following persons have + improved this document and they are gratefully acknowledged: + + Rob Austein + Matt Crawford + Johnny Eriksson + Phillip H. Griffin + Michael A. Patton + David Singer + + + +Table of Contents + + Status of This Document....................................1 + Copyright Notice...........................................1 + Abstract...................................................1 + + Acknowledgements...........................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Kitchen Sink Resource Record............................3 + 2.1 The Meaning Octet......................................4 + 2.2 The Coding and Subcoding Octets........................5 + 2.2.1 ASN.1 Subcodings.....................................7 + 2.2.2 MIME Subcodings......................................7 + 2.2.3 Text Subcodings......................................8 + 3. Master File Representation..............................8 + 4. Performance Considerations..............................9 + 5. Security Considerations.................................9 + 6. IANA Considerations.....................................9 + 7. Full Copyright Statement................................9 + + References................................................11 + Author's Address..........................................12 + Expiration and File Name..................................12 + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT The Kitchen Sink Resource Record + + +1. Introduction + + The Domain Name System (DNS) provides a replicated distributed secure + hierarchical database which stores "resource records" (RRs) under + hierarchical domain names. This data is structured into zones which + are independently maintained. [RFC 1034, 1035, 2535] + + Numerous types of RRs have been defined. These support such critical + functions as host name to address translation (A, AAAA, etc. RRs), + automatic mail routing (MX etc. RRs), and other functions. In + addition, there are RRs defined related to the zone structure and + administration of the DNS (SOA, NS, and RP RRs), security (SIG, KEY, + and NXT RRs), etc. There is a TXT RR for the inclusion of general + human readable text. + + New RRs that are reasonably simple and designed via the open IETF + standards process are periodically added as new needs become + apparent. But there are people who want to put some proprietary, + complex and/or non-standard structured data in the DNS. In the past + they have frequently come up with some way of reinterpreting the TXT + RR, since that is one of the least constrained RRs. This is likely a + bad idea since all previous ways to reinterpreting the TXT RR have + sunk without a trace. (Well, if they actually got an RFC out, it's + still there, but, practically speaking, almost nobody actually uses + it.) + + If a new type of data is needed for a global interoperable use in the + DNS, the best course is to design a new RR that meets the need + through the IETF standards process. This draft defines an extremely + general and flexible RR which can be used for other data, such as + proprietary data, where global interoperability is not a + consideration. It includes representations of OSI ASN.1, MIME, XML, + and, recursively, DNS RRs. + + + +2. Kitchen Sink Resource Record + + The symbol for the kitchen sink resource record is SINK. Its type + number is 40. This type is defined across all DNS classes. + + The RDATA portion of the SINK RR is structured as follows: + + + + + + + + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT The Kitchen Sink Resource Record + + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | meaning | coding | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | subcoding | / + +--+--+--+--+--+--+--+--+ / + / data / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The "meaning", "coding", and "subcoding" octets are always present. + The "data" portion is variable length and could be null in some + cases. The size of the "data" portion can always be determined by + subtracting 3 from the SINK resource record RDLENGTH. The coding + octet gives the general structure of the data. The subcoding octet + provides additional information depending on the value of the coding + nibble. + + All references to "domain name" in this document mean a domain name + in the DNS CLASS of the SINK RR. + + + +2.1 The Meaning Octet + + The meaning octet indicates whether any semantic tagging appears at + the beginning of the data field and the format of such semantic + tagging. This contrasts with the coding and subcoding octets which + merely indicate format. The inclusion of such semantic tagging is + encouraged and it is expected to be the primary means by which + applications determine if a SINK RR is of the variety in which they + have interest. + + It is noted that multiple popular uses of SINK could develop that are + not distinguished by using different parts of the DNS name space or + different DNS classes. If this occurs, retrievals may fetch large + sets of SINK RR to be sorted through at the application level. + Should this occur, such popular uses of SINK should obtain and + migrate to their own RR number using normal RR number allocation + procedures. In addition, it would be possible to define an extended + query operation that selects from among SINK RRs based on the + semantic tag. + + The types of tags available are chosen to be globally unique and + under the control of some "owner". The owner designates the meaning + associated with the tags they control. Where the tag is a URI, it is + recommended that a retrieval from the URI fetch material that would + be helpful in determining this meaning. No a priori method is + defined for determining the meaning of other tags beside an out of + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT The Kitchen Sink Resource Record + + + band question to the owner. + + INITIAL ASSIGNED MEANING VALUES + + 0 - reserved. + + 1 - none. + 2 - OID. + 3 - domain name. + 4 - URI. + + 5-254 - available for assignment, see section 6. + + 255 - reserved. + + A meaning octet value of 1 indicates that there is no semantic + tagging at the beginning of the data area. The information, whatever + it is, starts at the beginning of the data field and is coded + according to the coding and subcoding octets. + + Meaning octet values of 2, 3, or 4, indicate, on the other hand, that + a semantic tag is present. A value of two indicates that a BER + [X.690] encoded OID appears prefixed by a single unsigned octet of + OID length count. A value of three indicates that a DNS domain name + appears in wire format with name compression prohibited. And a value + of four indicates that a null (zero) octet terminated URI appears. + + + +2.2 The Coding and Subcoding Octets + + The coding octet gives the major method by which the data in the data + field is encoded. It should always have a meaningful value. The + subcoding octet is intended to give additional coding details. + Although the subcoding octet is always present, it must be + interpreted in the context of the coding octet. For any coding octet + value which does not specify subcoding octet value meanings, the + subcoding octet MUST be ignored and SHOULD be zero. + + While not explicitly mentioned below, the data field will actually + start with a semantic tag if indicated by the meaning octet. If such + a semantic tag is present, any data prefix required by the coding or + subcoding octet is placed after the semantic tag and before the data. + + CODING OCTET VALUES + + 0 - reserved. + + 1 - DNS RRs. The data portion consists of DNS resource records + as they would be transmitted in a DNS response section. The + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT The Kitchen Sink Resource Record + + + subcoding octet is the number of RRs in the data area as an + unsigned integer. Domain names may be compressed via pointers + as in DNS replies. The origin for the pointers is the beginning + of the RDATA section of the SINK RR. Thus the SINK RR is safe + to cache since only code that knows how to parse the data + portion of a SINK RR need know of and can expand these + compressions. + + 2 - MIME structured data [RFC 2045, 2046]. The data portion is + a MIME structured message. The "MIME-Version:" header line may + be omitted unless the version is other than "1.0". The top + level Content-Transfer-Encoding may be encoded into the + subcoding octet (see section 2.2.2). Note that, to some extent, + the size limitations of DNS RRs may be overcome in the MIME case + by using the "Content-Type: message/external-body" mechanism. + + 3 - Text tagged data. The data potion consists of text formated + as specified in the TXT RR except that the first and every + subsequent odd numbered text item is considered to be a tag + labeling the immediately following text item. If there are an + odd number of text items overall, then the last is considered to + label a null text item. Syntax of the tags is as specified in + RFC 2396 for the "Authority Component" without the two leading + slashes ("//") or trailing slash using the DNS for authority. + Thus any organization with a domain name can assign tags without + fear of conflict. The subcodings octet specifies the encoding + of the labeled text items as specified in section 2.2.3. + + 4 - HTML. The subcoding octet indicates the version of HTML + with the major version number in the upper nibble and the minor + version number in the lower nibble. Thus, for example, HTML 3.2 + would be indicated by a 0x32 octet. + + 5 - XML. The subcoding octet is the version of XML, currently + 1. + + 6 - ASN.1 [X.680, etc.]. See section 2.2.1. + + 7-251 - Available for assignment, see section 6. + + 252 - Private coding format indicated by an OID. The format of + the data portion is indicated by an initial BER encoded OID + which is prefixed by a one octet unsigned length count for the + OID. The subcoding octet is available for whatever use the + private formating wishes to make of it. + + 253 - Private coding format indicated by a domain name. The + format of the data portion is indicated by an initial wire + format domain name with compression prohibited. (Such names are + self delimiting.) The subcoding octet is available for whatever + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT The Kitchen Sink Resource Record + + + use the private formating wishes to make of it. + + 254 - Private coding format indicated by a URI. The format of + the data portion is indicated by an initial URI [RFC 2396] which + is terminated by a zero (null) valued octet followed by the data + with that format. The subcoding octet is available for whatever + use the private formating wishes to make of it. The manner in + which the URI specifies the format is not defined but presumably + the retriever will recognize the URI by some pattern match. + + 255 - reserved. + + NOTE: the existence of a DNS RR coding and the infinite possibilities + of ASN.1, XML, and MIME permit one to SINK to even greater depths by + nesting. + + + +2.2.1 ASN.1 Subcodings + + For ASN.1 [X.680, etc.] data, a specific concrete encoding must be + chosen as indicated by the subcoding octet. + + ASN.* SUBCODINGS + + 0 - reserved. + 1 - BER ( Basic Encoding Rules [X.690] ). + 2 - DER ( Distinguished Encoding Rules [X.690] ). + 3 - PER ( Packed Encoding Rules ) Aligned [X.691]. + 4 - PER Unaligned [X.691]. + 5 - CER ( Canonical Encoding Rules [X.690] ). + 6-253 - available for assignment, see section 6. + 254 - private. This subcoding will never be assigned to a standard + set of encoding rules. An OID preceded by a one octet unsigned + length of OID appears at the beginning of the data area after + the ASN coding OID. + 255 - reserved. + + + +2.2.2 MIME Subcodings + + If the coding octet indicates the data is MIME structured, the + precise encoding is given by the subcoding octets as listed below. + + MIME SUBCODINGS + + 0 - reserved, see section 6. + 1 - 7bit. + 2 - 8bit. + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT The Kitchen Sink Resource Record + + + 3 - binary. + 4 - quoted-printable. + 5 - base64. + 6 - 253 - available for assignment, see section 6. + 254 - private. The data portion must start with an "x-" or "X-" + token denoting the private content-transfer-encoding immediately + followed by one null (zero) octet followed by the remainder of + the MIME object. + 255 - reserved, see section 6. + + + +2.2.3 Text Subcodings + + If the coding octet indicates the data is text, the exact encoding of + the text items is indicated by the subcoding octet as follows: + + TEXT SUBCODINGS + + 0 - reserved, see section 6. + 1 - ASCII. + 2 - UTF-7 [RFC 1642]. + 3 - UTF-8 [RFC 2044]. + 4 - ASCII with MIME header escapes [RFC 2047]. + 5 - 253 - available for assignment, see section 6. + 254 - private. Each text item must start with a domain name [RFC + 1034] in wire format without compression denoting the private + text encoding immediately followed by the remainder of the text + item. + 255 - reserved, see section 6. + + + +3. Master File Representation + + SINK resource records may appear as lines in zone master files. The + meaning, coding, and subcoding appear as unsigned decimal integers. + The data portion can be quite long. It is represented in base 64 + [RFC 2045] and may be divided up into any number of white space + separated substrings, down to single base 64 digits, which are + concatenated to obtain the full data. These substrings can span + lines using the standard parenthesis notation. (This type of base64 + master file data is also required to support the DNS KEY and SIG + security RRs [RFC 2535].) + + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT The Kitchen Sink Resource Record + + +4. Performance Considerations + + Currently DNS is optimized for small data transfers, generally not + exceeding 512 octets including overhead. Larger transfers are less + efficient but do work correctly and efforts are underway to make them + more efficient. + + It is easy to create very large RRs or RR sets using SINK. DNS + administrators should think about this and may wish to discourage + large RRs or RR sets. Consideration should also be given to putting + zones from which large RRs or RR sets will be commonly retrieved on + separate hosts which can be tuned for the load this will represent. + + + +5. Security Considerations + + Since the SINK resource record can be used to store arbitrary data in + the DNS, this data could have security consequences, particularly if + it is control, executable, macro, or interpretable information or + very large and might cause buffer overflow. Due care should be + taken. + + [RFC 2535] covers data original authentication of the data in the + domain name system including SINK RRs. + + + +6. IANA Considerations + + Assignment of specific meaning to the values listed herein as + "reserved" requires an IETF standards action. + + All other assignments of available meaning, coding, or subcoding + octet values are by IETF consensus. + + The many provisions for private indicita specified by separately + allocated OIDs, domain names, or URIs should cover most requirements + for private or proprietary values. + + + +7. 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 + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT The Kitchen Sink Resource Record + + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT The Kitchen Sink Resource Record + + +References + + [RFC 1034] - P. Mockapetris, "Domain names - concepts and + facilities", 11/01/1987. + + [RFC 1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + [RFC 1642] - D. Goldsmith, M. Davis, "UTF-7 - A Mail-Safe + Transformation Format of Unicode", 07/13/1994. + + [RFC 2044] - F. Yergeau, "UTF-8, a transformation format of Unicode + and ISO 10646", 10/30/1996. + + [RFC 2045] - N. Freed, N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + 12/02/1996. + + [RFC 2046] - N. Freed, N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", 12/02/1996. + + [RFC 2047] - K. Moore, "MIME (Multipurpose Internet Mail Extensions) + Part Three: Message Header Extensions for Non-ASCII Text", + 12/02/1996. + + [RFC 2396] - T. Berners-Lee, R. Fielding, L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", August 1998. + + [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", + March 1999. + + [X.680] - ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, + Information Technology - Abstract Syntax Notation One (ASN.1): + Specification of Basic Notation + + [X.681] - ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998, + Information Technology - Abstract Syntax Notation One (ASN.1): + Information Object Specification + + [X.682] - ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998, + Information Technology - Abstract Syntax Notation One (ASN.1): + Constraint Specification + + [X.683] - ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998, + Information Technology - Abstract Syntax Notation One (ASN.1): + Parameterization of ASN.1 Specifications + + [X.690] - ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, + Information Technology - ASN.1 Encoding Rules: Specification of Basic + Encoding Rules (BER), Canonical Encoding Rules (CER) and + + +D. Eastlake 3rd [Page 11] + + +INTERNET-DRAFT The Kitchen Sink Resource Record + + + Distinguished Encoding Rules (DER) + + [X.691] - ITU-T Recommendation X.691 (1997) | ISO/IEC 8825-2:1998, + Information Technology - ASN.1 Encoding Rules: Specification of + Packed Encoding Rules (PER) + + + +Author's Address + + Donald E. Eastlake 3rd + IBM + 65 Shindegan Hill Road + Carmel, 10512 USA + + Telephone: +1 914-276-2668 (h) + +1 914-784-7913 (w) + FAX: +1 914-784-3833 (w) + EMail: dee3@us.ibm.com + + + +Expiration and File Name + + This draft expires March 2000. + + Its file name is draft-ietf-dnsind-kitchen-sink-02.txt. + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 12] + diff --git a/doc/expired/draft-ietf-dnsind-local-compression-05.txt b/doc/expired/draft-ietf-dnsind-local-compression-05.txt new file mode 100644 index 0000000000..ec27e3ac77 --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-local-compression-05.txt @@ -0,0 +1,420 @@ +INTERNET-DRAFT Peter Koch +Expires: December 1999 Universitaet Bielefeld +Updates: 1035, 1183, 2163, 2168, 2535 June 1999 + + A New Scheme for the Compression of Domain Names + draft-ietf-dnsind-local-compression-05.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + 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." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + Comments should be sent to the author or the DNSIND WG mailing list + . + +Abstract + + The compression of domain names in DNS messages was introduced in + [RFC1035]. Although some remarks were made about applicability to + future defined resource record types, no method has been deployed yet + to support interoperable DNS compression for RR types specified since + then. + + This document summarizes current problems and proposes a new + compression scheme to be applied to future RR types which supports + interoperability. Also, suggestions are made how to deal with RR + types defined so far. + +1. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + +Koch Expires December 1999 [Page 1] + +INTERNET-DRAFT DNS Compression June 1999 + + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + Domain names herein are for explanatory purposes only and should not + be expected to lead to useful information in real life [RFC2606]. + +2. Background + + Domain name compression was introduced in [RFC1035], section 4.1.4, + as an optional protocol feature and later mandated by [RFC1123], + section 6.1.2.4. The intent was to reduce the message length, + especially that of UDP datagrams, by avoiding repetition of domain + names or even parts thereof. + + A domain name is internally represented by the concatenation of label + strings, where the first octet denotes the string length, not + including itself. The null string, consisting of a single octet of + zeroes, is the representation of the root domain name and also + terminates every domain name. + + As labels may be at most 63 characters long, the two most significant + bits in the length octet will always be zero. Compression works by + overloading the length octet with a second meaning. If the two MSB + have the value '1', the remainder of the length octet and the next + octet form a compression pointer, which denotes the position of the + next label of the current domain name in the message: + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | 1 1| OFFSET | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + It is important that these pointers always point backwards. + + Compression may occur in several places. First, the owner name of an + RR may be compressed. The compression target may be another owner + name or a domain name in the RDATA section of a previous RR. Second, + any domain name within the RDATA section may be compressed and the + target may be part of the same RR, being the owner name or another + domain name in the RDATA section, or it may live in a previous RR, + either as its owner or as a domain name in its RDATA section. In + fact, due to the chaining feature, combinations of the above may + occur. + +3. Problems + + While implementations shall use and must understand compressed domain + names in the RDATA section of "well known" RR types (those initially + defined in [RFC1035]), there is no interoperable way of applying + +Koch Expires December 1999 [Page 2] + +INTERNET-DRAFT DNS Compression June 1999 + + compression to the RDATA section of newer RRs: + + Quote from [RFC1123], section 6.1.3.5: + Compression relies on knowledge of the format of data inside a + particular RR. Hence compression must only be used for the + contents of well-known, class-independent RRs, and must never be + used for class-specific RRs or RR types that are not well-known. + The owner name of an RR is always eligible for compression. + + DNS records in messages may travel through caching resolvers not + aware of the particular RR's type and format. These caches cannot + rearrange compression pointers in the RDATA section simply because + they do not recognize them. Handing out these RRs in a different + context later will lead to confusion if the target resolver tries to + uncompress the domain names using wrong information. This is not + restricted to intermediate caching but affects any modification to + the order of RRs in the DNS message. + +4. Local Compression + + We often observe a certain locality in the domain names used as owner + and occuring in the RDATA section, e.g. in MX or NS RRs but also in + newer RR types [RFC1183]: + + host.foo.bar.example RP adm.foo.bar.example adm.persons.bar.example + + So, to still profit from compression without putting interoperability + at risk, a new scheme is defined which limits the effect of + compression to a single RR. + + In contrast to the usual method of using offsets relative to the + start of a DNS packet we start counting at the RR owner or calculate + pointers relative to the start of the RDATA to avoid context + sensitivity. We use an additional compression indicator for a two + octet local pointer: + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | 1 0| OFFSET | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The "10" bits will indicate the use of local compression and + distinguish it from conventional compression, plain labels and EDNS + label codes [EDNS0]. Two types of pointers need to be specified: + those pointing into the owner name and those pointing into RDATA. + + A) Pointers into the owner name are interpreted as the ordinal label + number (starting at 0 for the topmost label, the TLD). This way we + avoid the need for extra decompression of the owner name during + +Koch Expires December 1999 [Page 3] + +INTERNET-DRAFT DNS Compression June 1999 + + message composition or decomposition. + + The highest possible value of a compression pointer pointing into + the owner name is 254. The value 255 is reserved for future use. + + B) Pointers into the RDATA section start at the fixed value 256 for + the first octet and have a maximum value of 16383 limiting + possible targets to the first 16128 octets. The actual offset + relative to the start of RDATA is determined by subtracting 256 + from the value of the pointer. + + Local pointers MUST point to a previous occurence of the same name in + the same RR. Even domain names in another RR of the same type cannot + serve as compression targets since the order of RRs in an RRSet is + not necessarily stable. The length of the compressed name(s) MUST be + used in the length calculation for the RDLENGTH field. + +Example + + Consider a DNS message containing two resource records, one CNAME RR + and one XMPL RR, undefined and meaningless so far, with an RDATA + section consisting of two domain names: + + ab.foo.example IN CNAME bar.example + bar.example IN XMPL a.foo.example foo.example + + In a message this appears as follows (randomly starting at octet 12): + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 12 | 2 | a | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 14 | b | 3 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 16 | f | o | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 18 | o | 7 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 20 | e | x | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 22 | a | m | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 24 | p | l | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 26 | e | 0 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + 10 octets skipped (TYPE, CLASS, TTL, RDLENGTH) + +Koch Expires December 1999 [Page 4] + +INTERNET-DRAFT DNS Compression June 1999 + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 38 | 3 | b | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 40 | a | r | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 42 | 1 1| 19 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The XMPL RR with local compression applied: + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 44 | 1 1 | 38 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + 10 octets skipped (TYPE, CLASS, TTL, RDLENGTH) + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 56 | 1 | a | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 58 | 3 | f | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 60 | o | o | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 62 | 1 0| 0 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + 64 | 1 0| 258 | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The first local pointer at position 62 points to the topmost label + "example" of the XMPL RR's owner. + + The second local pointer at position 64 represents the "foo.example" + and points backwards into the RDATA section, third octet, at absolute + position 58. Note that with conventional compression this example + message would have occupied less space. + +5. Interaction with DNSSEC + + The security extensions to DNS [RFC2535] mandate that domain names in + RDATA be signed only in expanded, lower case format. For RR types + using local compression the specification is changed as follows: + + Resource Records subject to local compression MUST be stored, + signed, transmitted and verified in locally compressed form. Name + expansion or canonicalization MUST NOT be performed on the RDATA + section for signing or verification. + + This way RR type transparency can be achieved, since domain names in + +Koch Expires December 1999 [Page 5] + +INTERNET-DRAFT DNS Compression June 1999 + + the RDATA section are treated as arbitrary data and can be cached and + verified by resolvers not aware of the particular RR type. Old RR + types subject to conventional or no compression are not affected by + this change. + + Wildcard owners may serve as compression targets only in their fixed + part. Even if a particular query asks for a domain name which could + be used to compress the RDATA part more efficiently, this MUST NOT be + done. Otherwise signatures would be invalidated. + + Currently slave servers store zones in text format and re-encode the + data into wire format, e.g. after a restart. This encoding must be + unique to ensure signature validity. To achieve this, local + compression MUST be applied optimally, i.e. every domain name must be + compressed as far as possible and each local compression pointer must + point to the earliest available target (including the owner). + +6. Interaction with Binary Labels + + When constructing local compression pointers into the owner name, + every one-bit label is counted as a label. This way the compression + and decompression is independent of the actual bit-string + representation. + + For local compression pointers into the RDATA section, only bit- + string labels may serve as targets, not single one-bit labels. Bit- + string labels may be adjusted to increase compression efficiency + [BINLABELS, section 3.1] + + The internal representation of a domain name has a maximum length of + 255 [RFC 1035]. Any label consists of at least two octets, leading + to at most 127 labels per domain name plus the terminating zero + octet, which does not qualify as a compression target. With the + introduction of binary labels a domain name can consist of up to 1904 + labels (all one-bit labels). This document restricts the possible + compression targets in an owner name to the topmost 255 labels. This + limit was chosen to be consistent with [RFC2535], section 4.1.3. + +7. Old RR types and deployment + + Although differences in RDATA sections by class have not yet been + reported and the concept of classes did not really spread, we are + just considering the IN class here. + + The following RR types with domain names in the RDATA section have + been defined since [RFC1035] (Standards Track, Experimental and + Informational RFCs, ignoring withdrawn types): RP [RFC1183], AFSDB + [RFC1183], RT [RFC1183], SIG [RFC2535], PX [RFC2163], NXT [RFC2535], + +Koch Expires December 1999 [Page 6] + +INTERNET-DRAFT DNS Compression June 1999 + + SRV [RFC2052], NAPTR [RFC2168], KX [RFC2230]. Some specifications do + not mention DNS compression at all, others explicitly suggest it and + only in part identify interoperability issues. Only the KX and SRV + RR types are safe as their specifications prohibit compression. + + The specification of RP, AFSDB, RT, PX, and NAPTR is hereby changed + in that domain names in the RDATA section MUST NOT be compressed and + MUST NOT be compression targets. + + Local compression MUST NOT be used for owner names and it MUST NOT be + applied to domain names in RDATA sections of any RR type defined so + far. + + The specification of future RR types should explicitly select the use + of local compression or forbid RDATA domain name compression at all. + +8. Security Considerations + + The usual caveats for using unauthenticated DNS apply. This scheme is + believed not to introduce any new security problems. However, + implementors should be aware of problems caused by blindly following + compression pointers of any kind. [RFC1035] and this document limit + compression targets to previous occurences and this MUST be followed + in constructing and decoding messages. Otherwise applications might + be vulnerable to denial of service attacks launched by sending DNS + messages with infinite compression pointer loops. In addition, + pointers should be verified to really point to the start of a label + (for conventional and local RDATA pointers) and not beyond the end of + the domain name (for local owner name pointers). + + The maximum length of 255 applies to domain names in uncompressed + wire format, so care must be taken during decompression not to exceed + this limit to avoid buffer overruns. + +9. Acknowledgements + + The author would like to thank Andreas Gustafsson, Paul Vixie, Bob + Halley, Mark Andrews and Thomas Narten for their review and + constructive comments. + +10. References + + [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", + RFC 1034, STD 13, November 1987 + +Koch Expires December 1999 [Page 7] + +INTERNET-DRAFT DNS Compression June 1999 + + [RFC1035] Mockapetris,P., "Domain Names - Implementation and + Specification", RFC 1035, STD 13, November 1987 + + [RFC1123] Braden,R., "Requirements for Internet Hosts -- Application + and Support", RFC 1123, STD 3, October 1989 + + [RFC1183] Everhart,C., Mamakos,L., Ullmann,R., Mockapetris,P., "New + DNS RR Definitions", RFC 1183, October 1990 + + [RFC2052] Gulbrandsen,A., Vixie,P. "A DNS RR for specifying the + location of services (DNS SRV)", RFC 2052, October 1996 + + [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997 + + [RFC2163] Allocchio,C., "Using the Internet DNS to Distribute MIXER + Conformant Global Address Mapping (MCGAM)", RFC 2163, + January 1998 + + [RFC2168] Daniel,R., Mealling,M., "Resolution of Uniform Resource + Identifiers using the Domain Name System", RFC 2168, June + 1997 + + [RFC2230] Atkinson,R., "Key Exchange Delegation Record for the DNS", + RFC 2230, November 1997 + + [RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC + 2535, March 1999 + + [RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", + RFC 2606, BCP 32, June 1999 + + [EDNS0] Vixie,P., "Extension mechanisms for DNS (EDNS0)", draft- + ietf-dnsind-edns0-XX.txt, work in progress + + [BINLABELS] Crawford,M., "Binary Labels in the Domain Name System", + draft-ietf-dnsind-binary-labels-XX.txt, work in progress + +11. Author's Address + + Peter Koch + Universitaet Bielefeld + Technische Fakultaet + Postfach 10 01 31 + D-33501 Bielefeld + Germany + +Koch Expires December 1999 [Page 8] + +INTERNET-DRAFT DNS Compression June 1999 + + +49 521 106 2902 + + +Koch Expires December 1999 [Page 9] diff --git a/doc/expired/draft-ietf-dnsind-local-names-07.txt b/doc/expired/draft-ietf-dnsind-local-names-07.txt new file mode 100644 index 0000000000..63fcfcfb0e --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-local-names-07.txt @@ -0,0 +1,662 @@ +DNS Working Group Donald E. Eastlake, 3rd +INTERNET-DRAFT IBM +Expires December 1999 June 1999 + +draft-ietf-dnsind-local-names-07.txt + + + Local Domain Name System (DNS) Names + ----- ------ ---- ------ ----- ----- + + Donald E. Eastlake 3rd + + + +Status of This Document + + This draft, file name draft-ietf-dnsind-local-names-07.txt. + Distribution of this document is unlimited. Comments should be sent + to the DNS mailing list or to the author. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + + + +Abstract + + It is increasingly common for their to be "local" domain names which + are not intended to be seen from the global Internet. In some cases + this if for policy reasons, in other cases because they map to IP + addresses or other data which is only locally meaningful [RFC 1918, + 2373]. + + A new top level domain (TLD) name (.local) is reserved and a name + structure suggested below this TLD such that local private DNS zones + can safely be created without fear of conflict if these names should + leak out of a private enclave. It addition, a method of providing + DNS service for these names is suggested such that they are + maintained privately, similar to the reserved private IP addresses, + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT Local DNS Names + + + yet locally appear to be part of the global DNS name tree and are + reachable by a local resolver with no special knowledge. Additional + second level domain names are assigned under this TLD for IPv6 link + and site local addresses and loopback functions. + + + +Acknowledgments + + The valuable contributions of the following persons are gratefully + acknowledged: + + Dan Harrington + + Michael A. Patton + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT Local DNS Names + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + Acknowledgments............................................2 + + Table of Contents..........................................3 + + 1. Introduction............................................4 + 2. Local Names Via The .local Top Level Domain.............5 + 2.1 Local DNS Server Specifics.............................7 + 2.2 Local in-addr.arpa Zones...............................8 + 2.3 Name Conflicts.........................................8 + 2.4 Nested Enclaves........................................9 + 3. Other Names in .local...................................9 + 4. Security Considerations.................................9 + 4.1 Strength of Privacy Offered............................9 + 4.2 Interaction with DNSSEC...............................10 + + References................................................11 + Author's Address..........................................11 + Expiration and File Name..................................11 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT Local DNS Names + + +1. Introduction + + The global Internet Domain Name System (DNS) is documented in [RFC + 1034, 1035, 1591, 2606] and numerous additional Requests for Comment. + It defines a tree of names starting with root, ".", immediately below + which are top level domain names such as .com and .us. Below top + level domain names there are normally additional levels of names. + + Generally the information in the DNS is public and intended to be + globally accessible. Certainly, in the past, the model of the + Internet was one of end-to-end openness [RFC 1958]. However, with + increasing security threats and concerns, firewalls and enclaves have + appeared. In many cases, organizations have hosts or resources that + they specifically want to reference with DNS names but which they + also want to be walled off from global access and even from global + knowledge of the DNS name for the resource. + + In the realm of IP addresses, this has been accomplished by reserving + three blocks of IPv4 addresses as documented in [RFC 1918] and by + allocating parts of the IPv6 address space for link and site local + addresses [RFC 2373]. Familiarity with the contents of these RFCs is + assumed. Addresses in these blocks are not to be globally routed. + + In the DNS area, local private names have generally been achieved in + the past by "splitting" DNS at the enclave boundary, giving different + answers to resolvers depending or whether they are inside or outside + of the enclave, using different servers for inside and outside, etc. + as mentioned in [RFC 1918]. Such relatively complex configuration + diddling is at variance with the simple global tree structure of the + initial DNS concept. + + This document specifies an alternative approach to achieving the + effect of local names that is more in tune with the concept of a + single global DNS tree or at least the appearance of a single tree. + Use of this approach is not required and older techniques will + continue to work. + + [RFC 1918] requires that private IP addresses not be indirectly + exposed to the general Internet via DNS records or otherwise. By + implication, the same would be true of IPv6 local addresses. This + RFC provides the recommended way to accomplish such private IP + address hiding and carves out a limited exception thereto for the + addresses of the servers for some zones which are children of the + .local top level domain name. + + + + + + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT Local DNS Names + + +2. Local Names Via The .local Top Level Domain + + The fundamental idea, as described in more detail below, is to define + second level domains under .local which are served by DNS name + servers that have private IP addresses. These server's addresses + would only be routed within the domain to which the names are local. + Thus the servers, and the names and resource records inside them, + would not be directly accessible outside the enclave, if the + guidelines in this document are followed. + + The following figure shows a highly simplified overview of an example + configuration: + + +----------------------------+ + | domain/enclave A | + | | + | #====================# | + | H private IP addrs A H | + | H H | + +-----------------------O privhost1 H | + | | H H | + +-----+-----------------O privhost2 H | + | | | H H | + | | | #====================# | + | | a | | + | +--------------------O pubhost3 | + .local | | | | | + +----+ | | +----------------------------+ + | | | | + | | | | +----------------------------+ + | | | | | domain/enclave B | + (root) | | | | | | + . ----+ | | | | #====================# | + | | | | | H private IP addrs B H | + | | | | | H H | + | +--|--------------------O privhost2 H | + | | | | H H | + +-------+ +-----------------O privhost3 H | + .com | | H : H | + | | #====:===============# | + | | : | + | b +-------------O pubhost4 | + +------+ | | + | +-------------O pubhost5 | + | | | + | +----------------------------+ + | + | example + +---------------------O pubhost6 + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT Local DNS Names + + + Starting at the bottom, pubhost6 is intended to illustrate an + ordinary host connected to the Internet with domain name + pubhost6.example.com. Though not indicated in the above diagram, + every DNS zone is in fact served by at least two hosts (and some but + substantially more). The addresses of the servers for the root (.), + .com, and example.com zones would all be in the public portion of the + IP address space, i.e., in the space of all unicast IP addresses not + reserved for private use. + + Moving to the top of the figure, enclave A represents some + organization that wishes to have some hosts with publicly visible + names and some with hidden names that are visible only locally. + pubhost3.a.com is an example of a publicly visible host which would + probably have a public IP address although access to pubhost3 from + outside the enclave might be filtered or even blocked by a firewall + or the like. privhost1 and privhost2 are examples of hidden names. + If a zone with privhost1 and privhost2 in it is served by DNS servers + with private IP addresses ("private IP addresses A") such that the + servers are accessible within enclave A but not from outside enclave + A, then the information is that zone will only be locally visible. + As show in the above figure, privhost1 and privhost2 have addresses + that are also private IP addresses, making those hosts inaccessible + outside enclave A, but it is the private addresses of the DNS + servers, not of the hosts pointed to from within the private DNS + zone, that provides the protection for the DNS names and other + private DNS information. (From the above simplified diagram, it + might appear that fully qualified domain names of these hosts would + be privhost1.local and privhost2.local but the names are actually + more complex as explained in Section 2.1.) + + Finally, in the middle, another enclave is shown with two hosts with + visible names and public IP addresses, pubhost4.b.com and + pubhost5.b.com. In addition, there are two private host names + privhost2 and privhost3. The duplication of privhost2 between + enclaves A and B would not be a problem as only DNS resolvers in + enclave A can access the DNS servers with the zone having the enclave + A version of privhost2 and only DNS resolvers in enclave B can access + the DNS servers with the zone having the enclave B version of + privhost2. + + Publicly visible host names are required by [RFC 1918] to have public + (i.e., globally unique) IP addresses. Private DNS names would + normally have private IP addresses, and all do in the figure above, + but this is not required. A public IP address could be stored under + a private name. And, of course, it is possible for the same physical + host to have multiple IP addresses, including a mix of public and + private. The dotted line in the figure above is intended to indicate + that privhost3 and pubhost4 are actually the same physical machine. + The could be accomplished equally well by storing a single public + address for that host under both the public and private names or by + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT Local DNS Names + + + having the host answer to both a public IP address stored under the + public name and a private IP address stored under the private name. + In the later case you could even also store the public address along + with the private address under the private name. + + + +2.1 Local DNS Server Specifics + + A variety of second level names are provided in the .local zone each + of which is a delegation point to a zone with some number of name + servers in one of the private IP address space blocks. The multiple + second level names permit choice between the different private IP + blocks and different numbers of servers. Thus the actual fully + qualified name for the private host examples in the figure above + would be more like privhost1.a2.local, privhost2.a2.local, etc. (but + see Section 2.3 below). + + Glue records are provided to give private IP addresses for initial + name servers; however, it should be noted that the NS and A records + in the local zones will dominate the information stored in the .local + zone. This means that once a resolver has contacted a local server, + the list of NS RRs in the local zone on that server will control and + could contain more or different servers than were given at the chosen + .local delegation point. Nevertheless, the glue A records in the + global .local zone do place some constraints of the private IP + address of the local DNS servers implementing zones which are + children of .local. + + It is also possible for an enclave to locally configure its own + version of the .local zone. Depending on its enclave boundary + implementation, it might be able to constrain all of its internal + references to .local to use its own variant version. This version + could have whatever private addresses were desired for the name + servers involved. Such a configuration MAY be used, but it is + recommended that the globally accessible .local specified herein be + used for uniformity. That way, even a unconstrained resolver + starting from the normal root servers (i.e., an "out of the box" + resolver) will correctly resolve or fail to resolve names under + .local depending on the resolvers location in the network as + specified herein. + + It is only necessary for the local DNS servers to have private IP + addresses to achieve the effect of local names. However, care MUST + be taken that none of the local DNS servers or any server that might + cache their output is accessible by any network interface that has a + non-private IP address. Otherwise considerable confusion could + result if local names are resolved by a resolver outside a local + enclave to private IP addresses which have a different meaning for + that resolver. + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT Local DNS Names + + +2.2 Local in-addr.arpa Zones + + Inverse lookup of local names corresponding to private IP addresses + needs to be provided via the in-addr.arpa and ip6.int zones. Because + of the fixed naming within this zone, different names with different + numbers of servers or different addresses can not be provided. As + with the forward .local entries, the actual NS RRs in the servers + serving the private portions of the inverse in-addr.arpa will + dominate. When one of these is queried by a resolver, it can provide + information on additional servers for that particular subzone in the + private IP address portion of the in-addr.arpa tree. + + + +2.3 Name Conflicts + + The intention is that local names would only be used in the enclave + where the entities they refer to exist, and these names would not be + exported. However, experience indicates that. despite best efforts + to avoid it, some such names will leak out via email cc's, URL's in + HTML, etc. (Such leakage occurs regardless of how the local names + are formed or whether they are accessible via the default root zone.) + These leaked private names can cause confusion if they can conflict + with global names or names local to other enclaves. Use of the + .local top level domain assures no conflict with global names. To + assure no conflict with different local fully qualified names, the + domain name of the enclave SHOULD always be prefixed to .local. + + For example, a company might have + host1.company.example + as a globally accessible host and + host2.company.example.b3.local + as a host for internal use only. The global name could normally be + resolvable anywhere on the Internet while the local name could not be + resolved anywhere except within the company enclave. + + Note that different names were chosen for the initial label in the + two names above, i.e., host1 and host2. The reason for this is that, + in some environments, local hosts are referred to by an unqualified + names, such as host3. For DNS look up purposes, such a name must be + expanded into a fully qualified domain name and a "search list" of + possible suffix qualifications is tried. If, for example, both + host4.school.ac.example and host4.school.ac.example.b3.local existed, + then a local reference to "host4" would be ambiguous and could lead + to either machine depending on the order of qualifications tried. + This order could even be different in different pieces of local + software or on different local hosts, resulting in substantial + confusion. For this reason, it is strongly recommended that disjoint + name sets be used for global and local entity unqualified domain + names and that fully qualified domain names be used wherever + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT Local DNS Names + + + practical. + + + +2.4 Nested Enclaves + + It is possible to have enclaves within enclaves. In general the best + way to accomplish this is to use a different portion of the private + IP address space at each nesting level of enclave. (Private IP + address space can be reused in enclaves that are siblings or the + like.) Then similar entries to those proposed here for .local can be + made in the private zone referring to name servers with addresses in + the nested enclave's private IP address space. + + + +3. Other Names in .local + + Three additional second level domain names are assigned in the .local + top level domain for other types of local names. + + In particular, + link.local and + site.local + are reserved for use in qualifying IPv6 link local names and site + local names. + + In addition, loopback.local is assigned and given the loopback + address. + + + +4. Security Considerations + + This section discusses the strength of the privacy offered by using + subzones of .local and interactions with DNS security. + + + +4.1 Strength of Privacy Offered + + Local names, as proposed herein, are not intended to be a strong + security mechanism. + + The privacy of the DNS information protected by storing it in servers + with private IP addresses is weak. It is completely dependent on the + integrity of enclave perimeter routing to make these servers + inaccessible. And it may occasionally leak out in any case due to + inclusion in email address fields, web pages, and the like, although + such leakage should be no worse than current split DNS + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT Local DNS Names + + + implementations of DNS data hiding. + + Software should not depend on local names being accessible only + within a particular enclave as someone could deliberately create the + same names within a different enclave. This is true even if, as + recommended herein, the names incorporate the domain name of the + original enclave in an attempt to avoid such conflicts. + + + +4.2 Interaction with DNSSEC + + Although an enclave may derive some amount of security by virtue of + its isolation, it will normally be desirable to implement DNS + security [RFC 2535] within the enclave. The enclave owner should + generate their own keys and sign their subzone of .local. However, a + signed copy of their public key can not be included in the .local + zone as it is different for every enclave. Thus, to authenticate the + .local subzone contents, it will be necessary to sign the KEY RR at + the apex of the local subzone of .local with the .local zone key or + another key that is trusted by local resolvers or staticly configure + the public key for the .local subzone in local resolvers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT Local DNS Names + + +References + + RFC 1033 - M. Lottor, "Domain Administrators Operations Guide", + November 1987. + + RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", + STD 13, November 1987. + + RFC 1035 - P. Mockapetris, "Domain Names - Implementation and + Specifications", STD 13, November 1987. + + RFC 1591 - J. Postel, "Domain Name System Structure and Delegation", + 03/03/1994. + + RFC 1918 - Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. + Lear, "Address Allocation for Private Internets", 02/29/1996. + + RFC 1958 - B. Carpenter, "Architectural Principles of the Internet", + 06/06/1996. + + RFC 2373 - R. Hinden, S. Deering, "IP Version 6 Addressing + Architecture", July 1998 + + RFC 2535 - D. Eastlake, "Domain Name System Security Extensions", + March 1999. + + RFC 2606 - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", + June 1999. + + + +Author's Address + + Donald E. Eastlake 3rd + IBM + 65 Shindegan Hill Road, RR #1 + Carmel, NY 10512 USA + + Telephone: +1 914-276-2668 (h) + +1 914-784-7913 (w) + FAX: +1 914-784-3833 (w) + EMail: dee3@us.ibm.com + + + +Expiration and File Name + + This draft expires December 1999. + + Its file name is draft-ietf-dnsind-local-names-07.txt. + + +D. Eastlake 3rd [Page 11] + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 12] + diff --git a/doc/expired/draft-ietf-dnsind-rfc2052bis-02.txt b/doc/expired/draft-ietf-dnsind-rfc2052bis-02.txt new file mode 100644 index 0000000000..7db98afb97 --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-rfc2052bis-02.txt @@ -0,0 +1,560 @@ + + + +Applications Area Arnt Gulbrandsen +INTERNET-DRAFT Troll Technologies + Paul Vixie +Obsoletes: RFC 2052 Internet Software Consortium + January 1999 + + A DNS RR for specifying the location of services (DNS SRV) + +Status of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + 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." + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + +Abstract + + This document describes a DNS RR which specifies the location of the + server(s) for a specific protocol and domain (like a more general + form of MX). + +Overview and rationale + + Currently, one must either know the exact address of a server to + contact it, or broadcast a question. This has led to, for example, + ftp.whatever.com aliases [RFC 2219], the SMTP-specific MX RR, and + using MAC-level broadcasts to locate servers. + + The SRV RR allows administrators to use several servers for a single + domain, to move services from host to host with little fuss, and to + designate some hosts as primary servers for a service and others as + backups. + + Clients ask for a specific service/protocol for a specific domain + (the word domain is used here in the strict RFC 1034 sense), and get + back the names of any available servers. + + + + +Gulbrandsen and Vixie Proposed [Page 1] + +RFC 2052bis DNS SRV RR January 1999 + + + Note that where this document refers to "address records", it means A + RR's, AAAA RR's, or their most modern equivalent. + +Introductory example + + If a SRV-cognizant web-browser wants to retrieve + + http://www.example.com/ + + it does a lookup of + + _http._tcp.www.example.com + + and retrieves the document from one of the servers in the reply. The + example zone file near the end of this memo contains answering RRs + for this query. + +Definitions + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" + used in this document are to be interpreted as specified in BCP 14. + Other terms used in this document are defined in the DNS + specification, RFC 1034. + + +The format of the SRV RR + + Here is the format of the SRV RR, whose DNS type code is 33: + + _Service._Proto.Name TTL Class SRV Priority Weight Port Target + + (There is an example near the end of this document.) + + Service + The symbolic name of the desired service, as defined in Assigned + Numbers [STD 2] or locally. An underscore (_) is prepended to + the service identifier to avoid collisions with DNS labels that + occur in nature. + + Some widely used services, notably POP, don't have a single + universal name. If Assigned Numbers names the service + indicated, that name is the only name which is legal for SRV + lookups. Only locally defined services may be named locally. + The Service is case insensitive. + + Proto + The symbolic name of the desired protocol, with an underscore + (_) prepended to prevent collisions with DNS labels that occur + + + +Gulbrandsen and Vixie Proposed [Page 2] + +RFC 2052bis DNS SRV RR January 1999 + + + in nature. _TCP and _UDP are at present the most useful values + for this field, though any name defined by Assigned Numbers or + locally may be used (as for Service). The Proto is case + insensitive. + + Name + The domain this RR refers to. The SRV RR is unique in that the + name one searches for is not this name; the example near the end + shows this clearly. + + TTL + Standard DNS meaning [RFC 1035]. + + Class + Standard DNS meaning [RFC 1035]. SRV records occur in the IN + Class. + + Priority + As for MX, the priority of this target host. A client MUST + attempt to contact the target host with the lowest-numbered + priority it can reach; target hosts with the same priority + SHOULD be tried in an order defined by the weight field. The + range is 0-65535. This is a 16 bit binary integer in network + byte order. + + Weight + A load balancing mechanism. When selecting a target host among + the those that have the same priority, the chance of trying this + one first SHOULD be proportional to its weight, as specified + below. Larger weights lead to a higher probability of being + selected. The range of this number is 0-65535. This is a 16 + bit binary integer in network byte order. Domain administrators + are urged to use Weight 0 when there isn't any load balancing to + do, to make the RR easier to read for humans (less noisy). In + the presence records containing weights greater than 0, records + with weight 0 have a very small chance of being selected. + + To choose the target, the client SHOULD implement the effect of + this algorithm. This permits administrators to plan weights to + achieve the load distribution desired. Each time a target is + needed, the client should order the remaining (not previously + used) SRV RRs at the current priority in any random fashion, + except placing all those with weight 0 at the beginning of the + list. Compute the sum of the weights of those RRs, and with + each RR associate the running sum in the selected order. Then + choose a random number (not necessarily of integral value) + between 0 and the sum computed (inclusive), and select the RR + whose running sum value is the first in the selected order which + + + +Gulbrandsen and Vixie Proposed [Page 3] + +RFC 2052bis DNS SRV RR January 1999 + + + is greater than or equal to the random number selected. + + + Port + The port on this target host of this service. The range is + 0-65535. This is a 16 bit binary integer in network byte order. + This is often as specified in Assigned Numbers but need not be. + + Target + As for MX, the domain name of the target host. There MUST be + one or more address records for this name, the name MUST NOT be + an alias (in the sense of RFC 1034 or RFC 2181). Implementors + are urged, but not required, to return the address record(s) in + the Additional Data section. Unless and until permitted by + future standards action, name compression is not to be used for + this field. + + A Target of "." means that the service is decidedly not + available at this domain. + +Applicability Statement + + In general, it is expected that SRV records will be used by clients + for applications where the relevant protocol specification indicates + that clients should use the SRV record. The examples in this + document use familiar protocols as an aid in understanding. It is + not intended that those protocols will necessarily use SRV records. + +Domain administrator advice + + Expecting everyone to update their client applications when the first + internet site adds a SRV RR for some server is futile (even if + desirable). Therefore SRV would have to coexist with address record + lookups for existing protocols, and DNS administrators should try to + provide address records to support old clients: + + - Where the services for a single domain are spread over several + hosts, it seems advisable to have a list of address records at + the same DNS node as the SRV RR, listing reasonable (if perhaps + suboptimal) fallback hosts for Telnet, NNTP and other protocols + likely to be used with this name. Note that some programs only + try the first address they get back from e.g. gethostbyname(), + and we don't know how widespread this behavior is. + + - Where one service is provided by several hosts, one can either + provide address records for all the hosts (in which case the + round-robin mechanism, where available, will share the load + equally) or just for one (presumably the fastest). + + + +Gulbrandsen and Vixie Proposed [Page 4] + +RFC 2052bis DNS SRV RR January 1999 + + + - If a host is intended to provide a service only when the main + server(s) is/are down, it probably shouldn't be listed in + address records. + + - Hosts that are referenced by backup address records must use the + port number specified in Assigned Numbers for the service. + + - Designers of future protocols for which "secondary servers" is + not useful (or meaningful) may choose to not use SRV's support + for secondary servers. Clients for such protocols may use or + ignore SRV RRs with Priority higher than the RR with the lowest + Priority for a domain. + + Currently there's a practical limit of 512 bytes for DNS replies. + Until all resolvers can handle larger responses, domain + administrators are strongly advised to keep their SRV replies below + 512 bytes. + + All round numbers, wrote Dr. Johnson, are false, and these numbers + are very round: A reply packet has a 30-byte overhead plus the name + of the service ("_telnet._tcp.example.com" for instance); each SRV RR + adds 20 bytes plus the name of the target host; each NS RR in the NS + section is 15 bytes plus the name of the name server host; and + finally each A RR in the additional data section is 20 bytes or so, + and there are A's for each SRV and NS RR mentioned in the answer. + This size estimate is extremely crude, but shouldn't underestimate + the actual answer size by much. If an answer may be close to the + limit, using a DNS query tool (e.g. "dig") to look at the actual + answer is a good idea. + + +The "Weight" field + + Weight, the load balancing field, is not quite satisfactory, but the + actual load on typical servers changes much too quickly to be kept + around in DNS caches. It seems to the authors that offering + administrators a way to say "this machine is three times as fast as + that one" is the best that can practically be done. + + The only way the authors can see of getting a "better" load figure is + asking a separate server when the client selects a server and + contacts it. For short-lived services like SMTP an extra step in the + connection establishment seems too expensive, and for long-lived + services like telnet, the load figure may well be thrown off a minute + after the connection is established when someone else starts or + finishes a heavy job. + + + + + +Gulbrandsen and Vixie Proposed [Page 5] + +RFC 2052bis DNS SRV RR January 1999 + + +The Port number + + Currently, the translation from service name to port number happens + at the client, often using a file such as /etc/services. + + Moving this information to the DNS makes it less necessary to update + these files on every single computer of the net every time a new + service is added, and makes it possible to move standard services out + of the "root-only" port range on unix. + + +Usage rules + + A SRV-cognizant client SHOULD use this procedure to locate a list of + servers and connect to the preferred one: + + Do a lookup for QNAME=_service._protocol.target, QCLASS=IN, + QTYPE=SRV. + + If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV + RR which specifies the requested Service and Protocol in the + reply: + + If there is precisely one SRV RR, and its Target is "." + (the root domain), abort. + + Else, for all such RR's, build a list of (Priority, Weight, + Target) tuples + + Sort the list by priority (lowest number first) + + Create a new empty list + + For each distinct priority level + While there are still elements left at this priority + level + Select an element randomly, with probability + Weight, as specified above, and move it to the + tail of the new list + + For each element in the new list + + query the DNS for address records for the Target or + use any such records found in the Additional Data + section of the earlier SRV response. + + for each address record found, try to connect to the + (protocol, address, service). + + + +Gulbrandsen and Vixie Proposed [Page 6] + +RFC 2052bis DNS SRV RR January 1999 + + + else if the service desired is SMTP (and SMTP has been defined + elsewhere to expect SRV lookups) + + skip to RFC 974 (MX). + + else + + Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A + + for each address record found, try to connect to the + (protocol, address, service) + + + Notes: + + - Port numbers SHOULD NOT be used in place of the symbolic service + or protocol names (for the same reason why variant names cannot + be allowed: Applications would have to do two or more lookups). + + - If a truncated response comes back from an SRV query, the rules + described in [RFC2181] shall apply. + + - A client MAY use means other than Weight to choose among target + hosts with equal Priority. + + - A client MUST parse all of the RR's in the reply. + + - If the Additional Data section doesn't contain address records + for all the SRV RR's and the client may want to connect to the + target host(s) involved, the client MUST look up the address + record(s). (This happens quite often when the address record + has shorter TTL than the SRV or NS RR's.) + + - Future protocols could be designed to use SRV RR lookups as the + means by which clients locate their servers. + + +Fictional example + + This is (part of) the zone file for example.com, a still-unused + domain: + + $ORIGIN example.com. + @ SOA server.example.com. root.example.com. ( + 1995032001 3600 3600 604800 86400 ) + NS server.example.com. + NS ns1.ip-provider.net. + NS ns2.ip-provider.net. + + + +Gulbrandsen and Vixie Proposed [Page 7] + +RFC 2052bis DNS SRV RR January 1999 + + + _ftp._tcp SRV 0 0 21 server.example.com. + _finger._tcp SRV 0 0 79 server.example.com. + ; telnet - use old-slow-box or new-fast-box if either is + ; available, make three quarters of the logins go to + ; new-fast-box. + _telnet._tcp SRV 0 1 23 old-slow-box.example.com. + SRV 0 3 23 new-fast-box.example.com. + ; if neither old-slow-box or new-fast-box is up, switch to + ; using the sysdmin's box and the server + SRV 1 0 23 sysadmins-box.example.com. + SRV 1 0 23 server.example.com. + ; HTTP - server is the main server, new-fast-box is the backup + ; (On new-fast-box, the HTTP daemon runs on port 8000) + _http._tcp SRV 0 0 80 server.example.com. + SRV 10 0 8000 new-fast-box.example.com. + ; since we want to support both http://example.com/ and + ; http://www.example.com/ we need the next two RRs as well + _http._tcp.www SRV 0 0 80 server.example.com. + SRV 10 0 8000 new-fast-box.example.com. + ; SMTP - mail goes to the server, and to the IP provider if + ; the net is down + _smtp._tcp SRV 0 0 25 server.example.com. + SRV 1 0 25 mailhost.ip-provider.net. + @ MX 0 server.example.com. + MX 1 mailhost.ip-provider.net. + ; NNTP - use the IP provider's NNTP server + _nntp._tcp SRV 0 0 119 nntphost.ip-provider.net. + ; IDB is an locally defined protocol + _idb._tcp SRV 0 0 2025 new-fast-box.example.com. + ; addresses + server A 172.30.79.10 + old-slow-box A 172.30.79.11 + sysadmins-box A 172.30.79.12 + new-fast-box A 172.30.79.13 + ; backup address records - new-fast-box and old-slow-box are + ; included, naturally, and server is too, but might go + ; if the load got too bad + @ A 172.30.79.10 + A 172.30.79.11 + A 172.30.79.13 + ; backup address record for www.example.com + www A 172.30.79.10 + ; NO other services are supported + *._tcp SRV 0 0 0 . + *._udp SRV 0 0 0 . + + In this example, a telnet connection to "example.com." needs an SRV + lookup of "_telnet._tcp.example.com." and possibly A lookups of "new- + + + +Gulbrandsen and Vixie Proposed [Page 8] + +RFC 2052bis DNS SRV RR January 1999 + + + fast-box.example.com." and/or the other hosts named. The size of the + SRV reply is approximately 365 bytes: + + 30 bytes general overhead + 20 bytes for the query string, "_telnet._tcp.example.com." + 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new- + fast-box", "old-slow-box", "server" and "sysadmins-box" - + "example.com" in the query section is quoted here and doesn't + need to be counted again. + 75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server", + "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is + quoted and only needs to be counted once. + 120 bytes for the 6 address records (assuming IPv4 only) mentioned + by the SRV and NS RR's. + + +IANA Considerations + + The IANA has assigned RR type value 33 to the SRV RR. No other IANA + services are required by this document. + + +Changes from RFC 2052 + + This document obsoletes RFC 2052. The major change from that + previous, experimental, version of this specification is that now the + protocol and service labels are prepended with an underscore, to + lower the probability of an accidental clash with a similar name used + for unrelated purposes. Aside from that, changes are only intended + to increase the clarity and completeness of the document. + +Security Considerations + + The authors believes this RR to not cause any new security problems. + Some problems become more visible, though. + + - The ability to specify ports on a fine-grained basis obviously + changes how a router can filter packets. It becomes impossible + to block internal clients from accessing specific external + services, slightly harder to block internal users from running + unauthorized services, and more important for the router + operations and DNS operations personnel to cooperate. + + - There is no way a site can keep its hosts from being referenced + as servers (as, indeed, some sites become unwilling secondary + MXes today). This could lead to denial of service. + + - With SRV, DNS spoofers can supply false port numbers, as well as + + + +Gulbrandsen and Vixie Proposed [Page 9] + +RFC 2052bis DNS SRV RR January 1999 + + + host names and addresses. Because this vunerability exists + already, with names and addresses, this is not a new + vunerability, merely a slightly extended one, with little + practical effect. + +References + + STD 2: Reynolds, J., Postel, J., "Assigned Numbers", STD 2, RFC 1700, + October 1994 (as currently updated by the IANA). + + RFC 1034: Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + RFC 1035: Mockapetris, P., "Domain names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + RFC 974: Partridge, C., "Mail routing and the domain system", RFC + 974, January 1986. + + BCP 14: Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + RFC 2181: Elz, R., Bush, R., "Clarifications to the DNS + Specification", RFC 2181, July 1997 + + RFC 2219: Hamilton, M., Wright, R., "Use of DNS Aliases for Network + Services", BCP 17, RFC 2219, October 1997 + +Acknowledgements + + The algorithm used to select from the weighted SRV RRs of equal + priority is adapted from one supplied by Dan Bernstein. + +Authors' Addresses + + Arnt Gulbrandsen Paul Vixie + Troll Tech Internet Software Consortium + Postboks 6133 Etterstad 950 Charter Street + N-0602 Oslo, Norway Redwood City, CA 94063 + +47 22646966 +1 650 779 7001 + + + + + + + + + + + +Gulbrandsen and Vixie Proposed [Page 10] + diff --git a/doc/expired/draft-ietf-dnsind-rollover-00.txt b/doc/expired/draft-ietf-dnsind-rollover-00.txt new file mode 100644 index 0000000000..8d8cef1cfc --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-rollover-00.txt @@ -0,0 +1,648 @@ +INTERNET-DRAFT DNSIND Key Rollover +UPDATES RFC 1996 April 1999 + Expires October 1999 +draft-ietf-dnsind-rollover-00.txt + + + + Domain Name System (DNS) Security Key Rollover + ------ ---- ------ ----- -------- --- -------- + + Donald E. Eastlake 3rd, Mark Andrews + + + +Status of This Document + + This draft, file name draft-ietf-dnsind-rollover-00.txt, is intended + to be become a Proposed Standard RFC. Distribution of this document + is unlimited. Comments should be sent to the DNS working group + mailing list or to the authors. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + +Abstract + + Deployment of Domain Name System (DNS) security with good cryptologic + practice will involve large volumes of key rollover traffic. A + standard format and protocol for such messages will be necessary for + this to be practical and is specified herein. + + [Note: this draft has been moved to dnsind from dnssec as part of the + ongoing combination of these working groups. It would have been + draft-ietf-dnssec-rollover-01.txt otherwise.] + + + + +D. Eastlake 3rd, M. Andrews [Page 1] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Key Rollover Scenario...................................3 + 3. Rollover Operation......................................5 + 3.1 Rollover to Parent.....................................5 + 3.2 Rollover to Children...................................6 + 4. Secure Zone Cuts and Joinders...........................7 + 5. Security Considerations.................................8 + 6. IANA Considerations.....................................9 + + References................................................10 + Authors Address...........................................10 + Expiration and File Name..................................11 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd, M. Andrews [Page 2] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + +1. Introduction + + The Domain Name System (DNS) [RFC 1034, 1035] is the global + hierarchical replicated distributed database system for Internet + addressing, mail proxy, and other information. The DNS has been + extended to include digital signatures and cryptographic keys as + described in [RFC 2535]. + + The principle security service provided for DNS data is data origin + authentication. The owner of each zone signs the data in that zone + with a private key known only to the zone owner. Anyone that knows + the corresponding public key can then authenticate that zone data is + from the zone owner. To avoid having to preconfigure resolvers with + all zone's public keys, keys are stored in the DNS with each zone's + key signed by its parent (if the parent is secure). + + To obtain high levels of security, keys must be periodically changed, + or "rolled over". The longer a private key is used, the more likely + it is to be compromised due to cryptanalysis, accident, or treachery + [RFC 2541]. + + In a widely deployed DNS security system, the volume of update + traffic will be large. Just consider the .com zone. If only 10% of + its children are secure and change their keys only once a year, you + are talking about hundreds of thousands of new child public keys that + must be securely sent to the .com manager to sign and return with + their new parent signature. And when .com rolls over its private + key, it will needs to send hundred of thousands of new signatures on + the existing child public keys to the child zones. + + It will be impractical to handle such update volumes manually on a + case by case basis. The bulk of such key rollover updates must be + automated. + + The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" + in this document are to be interpreted as described in [RFC 2119]. + + + +2. Key Rollover Scenario + + Although DNSSEC provides for the storage of other keys in the DNS for + other purposes, DNSSEC zone keys are included solely for the purpose + of being retrieved to authenticate DNSSEC signatures. Thus, when a + zone key is being rolled over, the old public key should be left in + the zone, along with the addition of the new public key, for as long + as it will reasonably be needed to authenticate old signatures that + have been cached or are held by applications. Similarly, old parent + SIGs should be retained for a short time after a parent KEY(s) roll + over and new parent SIGs have been installed. + + +D. Eastlake 3rd, M. Andrews [Page 3] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + + If DNSSEC were universally deployed and all DNS server's clocks were + synchronized and zone transfers were instantaneous etc., it might be + possible to avoid ever having duplicate old/new KEY/SIG RRsets due to + simultaneous expiration of SIGs everywhere in the DNS. But these + assumptions do not hold. Security aware DNS servers decrease the TTL + of secure RRs served as the expiration of their authenticating SIG(s) + approaches but some dithered fudge must generally be left due to + clock skew, RR retention by applications, and the like. Retaining + old KEYs for a while after rolling over to new KEYs will be necessary + in practical cases. + + Assume a middle zone with a secure parent and a secure child wishes + to role over its KEY RRset. This RRset would probably be one KEY RR + per crypto algorithm used to secure the zone, but for this scenario, + we will simply assume it is one KEY RR. The old KEY RR and two SIG + RRs will exist at the apex of the middle zone. (These RRs may also + exist at the leaf node for this zone in its parent if the parent + chooses to store them there.) The contents of the middle zone and the + zone KEY RRs of its secure child will have SIGs under the old key. + + The middle zone owner needs to communicate with its parent to obtain + a new parental signature covering both the old and new KEY RRs and + covering just the new KEY RR. The signature on both is needed so the + old KEY can be retain for the period it might be needed to + authenticate old SIGs. The middle zone would probably want to obtain + these in advance so that it can install them at the right time along + with its new SIG RRs covering the content of its zone. Finally, it + needs to give new SIG RRs to its child that cover its KEY RRs so it + must signal its children to ask for such SIG RRs. + + BEFORE ROLLOVER SHORTLY AFTER AFTER ROLLOVER + + p.x KEY P1 p.x KEY P1 p.x KEY P1 + p.x SIG(KEY) P1 p.x SIG(KEY) P1 p.x SIG(KEY) P1 + p.x SIG(KEY) GP p.x SIG(KEY) GP p.x SIG(KEY) GP + + m.p.x KEY M1 m.p.x KEY M2 m.p.x KEY M2 + m.p.x SIG(KEY) P1 m.p.x KEY M1 m.p.x SIG(KEY) P1 + m.p.x SIG(KEY) M1 m.p.x SIG(KEY) P1 m.p.x SIG(KEY) M2 + m.p.x SIG(KEY) M2 + + c.m.p.x KEY C1 c.m.p.x KEY C1 c.m.p.x KEY C1 + c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) M2 c.m.p.x SIG(KEY) M2 + c.m.p.x SIG(KEY) C1 c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) C1 + c.m.p.x SIG(KEY) C1 + + p = parent, m = middle, c = child, GP = grandparent key + P* = parent key, M* = middle zone key, C* = child key + + + + +D. Eastlake 3rd, M. Andrews [Page 4] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + +3. Rollover Operation + + Rollover operations use a DNS request syntactically identical to the + UPDATE request [RFC 2136] (except that the operation code is ROLLOVER + which is equal to (TBD)) and use a new form of NOTIFY [RFC 1996]. + Considerations for such requests to the parent and children of a zone + are givens below. + + All rollover operations involve significant amounts of cryptographic + calculations. Appropriate rate limiting SHOULD be applied to avoid + denial of service attacks. + + [This draft does not consider cross-certification key rollover.] + + + +3.1 Rollover to Parent + + A zone rolling over its KEY RRset sends an upward ROLLOVER request to + its parent. Actually, it will normally do two upward ROLLOVERs, one + for a combined KEY RRset of its old and new KEYs and one for just its + new KEY RRset, as discussed above. + + The server selection algorithm in [RFC 2136] section 4 should be + used. A child needs to be configured with or determine the name of + its parent but SHOULD NOT remember the location of its parent other + than via normal DNS caching of address RRs so that rollover will + continue to work if its parent servers are moved. + + The ROLLOVER request Zone should be specified as the parent zone. + The request Update section has the new KEY RRset on which the parent + signature is requested along with the requesting zone's SIG(s) under + its old KEY(s) as RRs to be "added" to the parent zone. The + inception and expiration times in this child SIG or SIGs are the + requested inception and expiration times for the new parent SIG(s). + The "prerequisites" section has the old child KEY RRset with the + parent SIG (see next paragraph). + + An upward ROLLOVER request MUST be signed and if not signed a BADAUTH + response generated. The signature MUST be under the previous zone + KEY, so the parent can validate it, or under a valid TSIG key + [draft-ietf-dnsind-tsig-*.txt] arranged with the parent. Including + the "prerequisite" section as specified above enables a parent that + keeps no record of its children's KEYs to still authenticate a + child's ROLLOVER request based on the old child KEY because the + parent is presented with its own SIG on the old KEY. + + If the ROLLOVER command is erroneous or violates parental policy, an + Error response is returned. If a parent retains copies of its + children's KEYs, it may use that knowledge to validate ROLLOVER + + +D. Eastlake 3rd, M. Andrews [Page 5] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + + request SIGs and ignore the "prerequisites" section. + + If the ROLLOVER command is OK and the parent can sign online, its + response MAY include the new parent SIG(s) in the response Update + section. This response MUST be sent to the originator of the + request. + + If the parent can not sign online, it should return a response with + an empty Update section and queue the SIG(s) calculation request. + This response MUST be sent to the originator of the request. + + ROLLOVER response messages MUST always include the actual parent's + SOA signed with a key the child should recognize in the Additional + Information section (see section 4 below). + + Regardless of whether the server has sent the new signatures above, + it MUST, once it has calculated the new SIG(s), send a ROLLOVER to + the child zone using the DNS port (53) and the server selection + algorithm defined in RFC 2136, Section 4. This ROLLOVER reqeust + contains the KEY RRset that triggered it and the new SIG(s). There + are several reasons for sending the ROLLOVER response regardless of + whether the new SIG RR(s) were sent in the original response. One is + to provide an indication to the operators of the zone in the event + someone is trying to hijack the zone. Another is that this maximizes + the probability of the response getting through. + + Although the parent zone need not hold or serve the child's key, if + it does the ROLLOVER command REQUEST SHOULD NOT automatically update + the parent zone. A later UPDATE command can be used to actually put + the new KEY into the parent zone if desired and supported by parent + policy. + + This document does not cover the question of parental policy on key + rollovers. Parents may have restrictions on how far into the future + they will sign KEY RRsets, what algorithms or key lengths they will + support, might require payment for the service, etc. The signing of + a future KEY by a parent is, to some extent, a granting of future + authoritative existence to the controller of the child private key + even if the child zone ownership should change. The only effective + way of invalidating such future signed child public keys would be for + the parent to roll over its key(s), which might be an expensive + operation. + + + +3.2 Rollover to Children + + When a secure zone is going to rollover its key(s), it needs to re- + sign the zone keys of any secure children under its new key(s). The + parent simply notifIES the child via a rollover NOTIFY [RFC 1996] + + +D. Eastlake 3rd, M. Andrews [Page 6] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + + that the parent KEY(s) have changed. The child then proceeds to do + an upward ROLLOVER request, as described in 3.1 above to obtain the + new parental SIG(s). + + A rollover NOTIFY is a NOTIFY request [RFC 1996] that has a QTYPE of + SIG and the owner name of the child zone. The answer section has the + current parent SOA signed by a key the child will know (see section + 4). + + A rollover NOTIFY MUST be signed and if not signed a BADAUTH response + generated. The signature MUST be under the previous parental zone + KEY, so the child can validate it, or under a valid TSIG key [draft- + ietf-dnsind-tsig-*.txt] negotiated between parent and child. + + The rollover NOTIFY can be sent to any of the nameservers for the + child using the nameserver selection algorithm defined in RFC 2136, + Section 4. Nameservers for the child zone receiving a rollover + NOTIFY query will forward the rollover NOTIFY in the same manner as + an UPDATE is forwarded. + + Unless the master server is configured to initiate an automatic + ROLLOVER it MUST seek to inform its operators that a rollover NOTIFY + request has been received. This could be done by a number of methods + including generating a log message, generating an email request to + the child zone's SOA RNAME or any other method defined in the + server's configuration for the zone. The default SHOULD be to send + mail to the zone's SOA RNAME. As with all rollover operations, care + should be taken to rate limit these messages so prevent them being + used to facilitate a denial of service attack. + + Once the message has been sent (or suppressed if so configured) to + the child zone's administrator the master server for the child zone + is free to respond to the rollover NOTIFY request. + + + +4. Secure Zone Cuts and Joinders + + There are two other events that have some similarity to key rollover. + + The first is when a secure zone the is more than one level deep has a + zone cut introduced inside it. For example, assume zone example.com + has a.b.c.example.com, d.b.c.example.com and e.example.com in it. A + zone cut could be introduced such that b.c.example.com became a + separate child zone of example.com. A real world exampe would be a + company that structures its DNS as host.branch.company.example. It + might start out will all of these names in one zone but later decide + to delegate all or some of the branches to branch zone file + maintainers. + + + +D. Eastlake 3rd, M. Andrews [Page 7] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + + The second is when a secure zone absorbs a child zone eliminating a + zone cut. This is simply the inverse of the previous paragraph. + + From the point of view of the parent zone above the splitting zone or + above the upper of the two combining zones, there is no change. + + When a zone is split by introducing a cut, the newly created child + must be properly configured. + + However, from the point of view of a child of the splitting zone + which becomes a grandchild or a grandchild that becomes a child due + to joinder, there is a change in parent name. Therefore, in general, + there is a change in parent KEY(s). Unless the entity that handles + rollovers for the zone whose parent name has changed is appropriately + updated, future automated rollover will fail because it will be sent + to the old parent. + + For this reason and so that other consistency checks can be made, the + parent SOA and SIG(SOA) are always included in the Answer section of + rollover NOTIFY requests and in ROLLOVER responsess. For automated + rollover to the new cut or joined state to work, these SOAs must be + signed with old KEY(s) of the former parent so the signatures can be + validated by the zone whose parent name is changing. In the case of + a joinder, if the private key of the pinched out middle zone is not + available, then manual update of the former grandchild, now child, + will be necessary. In the case of introducing a cut, operational + coordination with the former parent, now grandparent, signing the + initial updates to the former child, now grandchild, will be needed + to automate the reconfiguration of the zones. + + + +5. Security Considerations + + The security of ROLLOVER or UPDATE requests is essential, otherwise + false children could steal parental authorization or a false parent + could cause a child to install an invalid signature on its zone key, + etc. + + A ROLLOVER request can be authenticated by request SIG(s)under the + old zone KEY(s) of the requestor [RFC 2535]. The response SHOULD + have transaction SIG(s) under the old zone KEY(s) of the responder. + (This public key security could be used to rollover a zone to the + unsecured state but at that point it would generally not be possible + to roll back without manual intervention.) + + Alternatively, if there is a prior arrangement between a child and a + parent, ROLLOVER requests and responses can be secured and + authenticated using TSIG [draft-ietf-dnsind-tsig-*.txt]. (TSIG + security could be used to rollover a zone to unsecured and to + + +D. Eastlake 3rd, M. Andrews [Page 8] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + + rollover an unsecured zone to the secured state.) + + A server that implements online signing SHOULD have the ability to + black list a zone and force manual processing or demand that a + particular signature be used to generate the ROLLOVER request. This + it to allow ROLLOVER to be used even after a private key has been + compromised. + + + +6. IANA Considerations + + The DNS operation code (TBD) is assigned to ROLLOVER. There are no + other IANA considerations in this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd, M. Andrews [Page 9] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + +References + + [RFC 1034] - "Domain names - concepts and facilities", P. + Mockapetris, 11/01/1987. + + [RFC 1035] - "Domain names - implementation and specification", P. + Mockapetris, 11/01/1987. + + [RFC 1996] - "A Mechanism for Prompt Notification of Zone Changes + (DNS NOTIFY)", P. Vixie, August 1996. + + [RFC 2119] - "Key words for use in RFCs to Indicate Requirement + Levels", S. Bradner. March 1997. + + [RFC 2136] - "Dynamic Updates in the Domain Name System (DNS + UPDATE)", P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April + 1997. + + [draft-ietf-dnsind-tsig-*.txt] + + [RFC 2535] - "Domain Name System Security Extensions", D. Eastlake. + March 1999. + + [RFC 2541] - "DNS Security Operational Considerations", D. Eastlake. + March 1999. + + + +Authors Address + + Donald E. Eastlake 3rd + IBM + 65 Sindegan Hill Road, RR #1 + Carmel, NY 10512 + + Telephone: +1 914-276-2668 (h) + +1 914-784-7913 (w) + FAX: +1 914-784-3833 (w) + EMail: dee3@us.ibm.com + + + Mark Andrews + Internet Software Consortium + 1 Seymour Street + Dundas Valley, NSW 2117 + AUSTRALIA + + Telephone: +61-2-9871-4742 + Email: marka@isc.org + + + +D. Eastlake 3rd, M. Andrews [Page 10] + + + +INTERNET-DRAFT April 1999 DNSSEC Key Rollover + + +Expiration and File Name + + This draft expires in October 1999. + + Its file name is draft-ietf-dnsind-rollover-00.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd, M. Andrews [Page 11] + + diff --git a/doc/expired/draft-ietf-dnsind-sec-rr-00.txt b/doc/expired/draft-ietf-dnsind-sec-rr-00.txt new file mode 100644 index 0000000000..81ab5155ad --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-sec-rr-00.txt @@ -0,0 +1,663 @@ +DNSIND WG Edward Lewis +INTERNET DRAFT NAI Labs +Category: I-D Jerry Scharf + ISC + Olafur Gudmundsson + NAI Labs + June 25, 1999 + The SEC Resource Record + + +Status of this Memo + +This document is an Internet-Draft and is in full conformance with all +provisions of Section 10 of RFC2026. + +Internet-Drafts are working documents of the Internet Engineering Task +Force (IETF), its areas, and its working groups. Note that other +groups may also distribute working documents as Internet- Drafts. + +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." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be accessed at +http://www.ietf.org/shadow.html. + +Comments should be sent to the authors or the DNSIND WG mailing list +namedroppers@internic.net. + +This draft expires on December 25, 1999. + +Copyright Notice + +Copyright (C) The Internet Society (1999). All rights reserved. + +Abstract + +A new DNS reseource record, the SECurity RR, is defined to address +concerns about the parent zone's holding of the child zone's KEY RR +set. These concerns are addressed in a manner that retains the +information needed by a secure resolver when asking a parent zone +about the child zone. This proposal updates RFC 2535 and RFC 2181. + +1. Introduction + +DNS security extensions require a signed zone to hold KEY RR sets for +each of its delegations. This requirement has four negative +implications for the top level domains, which, for the most part, +consist of delegation points. (These issues also impact other +delegating zones, these problems are not unique to the TLDs.) +Addressing these concerns by removing the requirement for the KEY RR +in the parent has an adverse effect on secure resolution of DNS + +Expires December 25, 1999 [Page 1] +Internet Draft June 25, 1999 + +signatures. A new DNS reseource record, the SECurity RR, is defined +to address these concerns. + +The Zone Key Referral, described in another draft by the same authors, +is one proposed response to the concerns about parent's holding child +keys. However, that proposal has two drawbacks. One, it results in +two KEY RR sets at a delegation, one in the parent and one in the +child, which differ. It also does not address the expression of +security parameters, such as whether or not the child zone uses the +NXT record (which is currently mandatory). + +This document will begin by repeating the arguments against the +holding of keys at the parent as presented in the Zone Key Referral. +The document will then present the need for information about the +child to be held in parent. Following this, the SEC RR will be +defined, its master file representation discussed, and implications on +name servers. + +(Editorial note. Sections 1.1 through 1.5 are copied nearly verbatim +from the Zone Key Referral so that retirement of that draft will not +cause a problem.) + +1.1 Reasons for removing the KEY data from the parent + +There are a number of different reasons for the removal of the KEY RR +from the parent. Reasons include: + + o the performance impact that holding keys has on name servers + o the problem of updating a widely delegated parent zone on demand + o statements in RFC 2181 on authoritative data at delegations + o perceived liability of the operator of a name server or registry + +1.2 Performance Issues + +A sample zone will be used to illustrate the problem. The example +will part from reality mostly in the length of zone names, which +changes the size of the owner and resource record data fields. + +Expires December 25, 1999 [Page 2] +Internet Draft June 25, 1999 + + # $ORIGIN test. + # @ IN SOA + # IN SIG SOA + # IN KEY <1024 bit zone key> + # IN SIG KEY + # IN SIG KEY + # IN NS ns.test. + # IN SIG NS + # IN NXT my-org.test. NS SOA SIG KEY NXT + # IN SIG NXT + # + # my-org IN KEY <1024 bit zone key> + # IN KEY <1024 bit zone key> + # IN SIG KEY + # IN NS ns1.my-org.test. + # IN NS ns2.my-org.test. + # IN NXT that-org.test. NS SIG KEY NXT + # IN SIG NXT + # + # that-org IN KEY 0xC100 3 255 + # IN SIG KEY + # IN NS ns1.that-org.test. + # IN NS ns2.that-org.test. + # IN NXT test. NS SIG KEY NXT + # IN SIG NXT + +In this zone file, "my-org" is a delegation point of interest with two +registered public keys. Presumably, one key is for signatures +generated currently and the other is for still living and valid but +older signatures. "that-org" is another delegation point, with a NULL +key. This signifies that this zone is unsecured. + +To analyze the performance impact of the storing of keys, the number +of bytes used to represent the RRs in the procotol format is used. +The actual number of bytes stored will likely be higher, accounting +for data structure overhead and alignment. The actual number of bytes +transferred will be lower due to DNS name compression. + +The number of bytes for my-org's two 1024-bit keys, two NS records, +NXT and the associated signatures is 526. (1024 bit RSA/MD5 keys were +used for the calculation.) The bytes needed for that-org (with the +NULL key) is 346. Currently, there are close to 2 million entries in +com., so if we take my-org as a typical domain, over 1GB on memory +will be needed for com. The zone keys used in the example are set to +1024 bits. This number may range from as low as 512 bits upwards to +over 3000 bits. + +The increased size of the data held for the zone cuts will have two +impacts at the transport and below layers. Bandwidth beyond that +currently needed will be used to carry the KEY records. The inclusion +of all of the child's keys will also push DNS over the UDP size limit +and start using TCP - which could cause critical problems for current + +Expires December 25, 1999 [Page 3] +Internet Draft June 25, 1999 + +heavily used name servers, like the root and TLD name servers. EDNS0 +[RFC-to-be] addresses expansion of UDP message size, which alleviates +this problem. + +Another impact, not illustrated by the example, is the frequency of +updates. If each time a public key for my-org is added or deleted, +the SOA serial number will have to increase, and the SOA signed again. +If an average zone changes the contents of its key RR set once per +month, there will be on average 45 updates per minute in a zone of 2 +million delegations. (This estimate does not address the fact that +signatures also expire, requiring a new signing of the zone +periodically.) + +1.3 Security Incident Recovery (w/ respect to keys only) + +Once a zone administrator is alerted that any key's private +counterpart has been discovered (exposed), the first action to be +taken is to stop advertising the public key in DNS. This doesn't end +the availability of the key - it will be residing in caches and given +in answers from those caches - but is the closest action resembling +revokation available in DNS. + +Stopping the advertisement in the zone's name servers is as quick as +altering the master file and restarting the name server. Having to do +this in two places will will only delay the time until the recovery is +complete. + +For example, a registrar of a top level domain has decided to update +its zone only on Mondays and Fridays due to the size of the zone. A +customer/delegatee is the victim of a break in, in which one of the +items taken is the file of private keys used to sign DNS data. If this +occurs on a Tuesday, the thief has until Friday to use the keys before +they disappear from the DNS, even if the child stops publishing them +immediately. + +If the public key set is in the parent zone, and the parent zone is +not able to make the change quickly, the public key cannot be revoked +quickly. If the parent only refers to there being a key at the child +zone, then the child has the agility to change the keys - even issue a +NULL key, which will force all signatures in the zone to become +suspect. + +1.4 DNS Clarifications + +RFC 2181, section 6, clarifies the status of data appearing at a zone +cut. Data at a zone cut is served authoritatively from the servers +listed in the NS set present at the zone cut. The data is not +(necessarily) served authoritatively from the parent. (The exception +is in servers handling both the parent and child zone.) + +Section 6 also mentions that there are two exceptions created by +DNSSEC, the NXT single record set and the KEY set. This proposal +addresses the exception relating to the KEY set, by removing the set + +Expires December 25, 1999 [Page 4] +Internet Draft June 25, 1999 + +from the parent. The SEC RR is introduced and belongs in the parent +zone, there is no counterpart in the child (at the apex). + +1.5 Liability + +Liability is a legal concept, so it is not wise to attempt an +engineering solution to it. However, the perceived liability incurred +in using DNSSEC by registrars may prevent the adoption of DNSSEC. +Hence DNSSEC should be engineered in such a way to address the +concern. + +One source of liability is the notion that by advertising a public key +for a child zone, a parent zone is providing a service of security. +With that comes responsibility. By having the parent merely indicate +that a child has a key (or has no key), the parent is providing less +in the way of security. If the parent is wrong, the potential loss is +less. Instead of falsely authenticated data, configuration errors +will be apparent to the resolving client. + +Whether or not the KEY RR remains advertised in the parent zone or the +SEC RR is in place, the parent zone administrators still have to +adhere to proper key handling practices, which are being documented in +DNSOP draft. In particular, the parent has to be sure that the keys +it is signing for a child have been submitted by the true +administrator of the the child zone, and not submitted by an imposter. + +1.6 The needs of the resolver + +Now that the reasons for removing the child's keys from the parent +zone have been presented, reasons why something must take their place +are presented. A "secure" resolver is a DNS resolver that receives an +answer and, if a signature arrives, verifies the signature. Most +often, this operation will happen in resolvers that are part of name +servers, as opposed to general purpose hosts. + +The first step in authenticating a DNS response is to see if the data +is accompanied by a signature. There are five possible outcomes. +Three results are not desirable, a signature may arrive but shouldn't, +no signature arrives but should, or a signature arrives but uses the +wrong cryptographic algorthm Two outcomes can be considered +successful, a signature arriving with the correct algorithm or no +signature arrives and shouldn't. (There is one other case - a +signature generated with an inappropriate key - which is a matter +beyond the scope of this draft.) + +Since the resolver can not instantly know whether a signature is +expected, the resolver must start a discovery process. This process +can be done by the resolver querying zones between the root and the +desired domain for information about the next successive zones. +(Optimizing this search is not presented here.) For this search to be +successful, the parent must hold something that indicates the status +of the child's security, so the resolver may search with certainty. +While refraining from using the word "policy" to describe the data, +the phrase "security parameters" is used. + +Expires December 25, 1999 [Page 5] +Internet Draft June 25, 1999 + +The security parameters of a zone are not entirely defined yet, and +will remain open until a critical mass of operations experience is +gained. Initially, the following information is known to be needed. + +The set of algorithms in use by the zone. +KEY RRs and SIG RRs have protocol fields indicating how the key is +made. For now, two are in distribution, a value of 1 for RSA/MD5 and +3 for DSA. Unfortunately, the value are numeric in 8 bits, so a +bitmap representation cannot be used. + +The mechanism for negative answers. +Currently, the NXT is mandatory, liked by some administrators and +disliked by other administrators. NXTs cannot be made optional, doing +so makes them obsolete. (An attacker can make the responses look like +a zone doesn't use NXTs, even if the zone does.) If the choice of NXT +or no NXT can be securely indicated, then this is solved. There have +been discussions on alternatives to the NXT record. By allowing a +zone to indicate the style of negative answer in use, alternatives can +be installed in experimental zones. + +Signature policy. +This is an untested issue. Expressing a policy, such as whether +multiple algorithms are used, whether verification of one signature +needed or all signatures, etc., has not been fully studied. + +2. The SEC RR + +The SEC RR is a record that describes the DNS security parameters of +the owner. The owner MUST also have an NS RR set, i.e., the owner +MUST be a cut point. A signed zone MUST have a SEC RR set for each +delegation point. + + 0 1 2 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Negative Answer Bitmap | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | | + ~ Security Parameters ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + The RDATA of the SEC RR + +The SEC RR RDATA contains two data fields. One is a 16-bit field +acting as a bitmap to indicate the means used to signify a negative +answer. The other field is an unbounded field of option-value pairs +indicating other salient settings for the zone. The latter field is +not padded to any particular byte boundary. + +The SEC RR is answered authoritatively from the parent zone, and is +signed by the parent. A properly configured delegation point in the +parent would have just an SEC RR, records used for negative answering, +and a glue NS set. The corresponding point in the child (the zone's +apex) would have the SOA, KEY set, NS records, negative answer + +Expires December 25, 1999 [Page 6] +Internet Draft June 25, 1999 + +records, and other desired and legal RR sets. SIG RR's appear in both +the parent and child side of the delegation. + +There is no other special processing of the SEC RR set. It is used in +a reply as an answer when it is the subject of a direct query (QTYPE +IS SEC) or when a QTYPE=ANY reaches the delegating zone. If a name +server is authoritative for both the parent and child, the SEC is +included in the ANY reply for the delegation point. + +(Editorial note: this region is in particular need of careful review.) + +The SEC RR for a name SHOULD be supplied optionally in the additional +data section if the CD bit is not set whenever a zone's NS or KEY set +is requested. If a request for a KEY set is sent to a parent-only +server and the server is not recursive, the server should add the SEC +record to the additional section of the referral message. + +If a name server authoritative for a child zone is asked for its SEC +RR and the server has never learned the SEC RR (whether through +caching the record or by also loading the parent zone), the server MAY +answer with a negative answer. The resolver seeking a SEC RR SHOULD +know to ask for this from a parent-serving name server. + +2.1 Negative Answer Bitmap + +The Negative Answer Bitmap indicates the mechanism for use in denying +the existance of data. The bitmap is 16 bits, the most significant +bit called 0, least significant is 15. + + Bit 0 = The parent doesn't know what the child uses (1=Yes) + Bit 1 = The child signs its negative answers (1=Yes) + Bit 2 = The child follows traditional DNS rules (1=yes) + Bit 3 = The child uses the NXT record (1=yes) + Bit 14 = The child uses a locally defined mechanism (1=yes) + Bit 15 = The length of the bit field has been extended (1=yes) + +Bits 4 through 14 are currently unassigned, and are under the purview +of IANA. Bit 15 MUST BE zero. (This specification must be +superceeded to define an extension mechanism.) + +A zone may use multiple mechanisms to indicate a negative answer. A +zone SHOULD expect that a resolver finding any one of the mechanisms +used in a reply indicates a negative answer, i.e. the mechanisms are +OR'd together. + +The only illegal values for this bit field are: + Bit 0 = 1 and any other bit turned on + Bit 0 = 0, Bit 1 = 1, and no other bit turned on + Bit 15 = 1 + +2.1.1 Bit 0 (Better titles will be attached later) + +The situation in which this bit is on should not arise, but it is +defined to be safe. The philosophy behind this is that security + +Expires December 25, 1999 [Page 7] +Internet Draft June 25, 1999 + +parameters should always be made explicit, including when a sitation +is unclear. + +2.1.2 Bit 1 + +This bit indicates that the child attachs SIG records to the resource +records used in the negative answer. For example, this may indicate +that the reslover should expect to see a SIG (NXT) when an NXT is +returned. + +2.1.3 Bit 2 + +The child will answer with an SOA or any of the other means used in +the past to indicate a negative answer. (I think a reference to the +negative answer/cache document should go here.) + +2.1.4. Bit 3 + +The child uses the NXT as defined in RFC 2535. This document declares +that the use of the NXT is optional, a deviation from RFC 2535. + +2.1.5 Bit 14 + +The child is using a mechanism that is not globally defined. A zone +should be in such a state for only experimental reasons and realize +that in this state, the negative answers it gives may not be useful to +the general population of resolvers. + +2.1.6 Bit 15 + +As of this specification, this bit must be 0 (zero). + +2.1.7 Unallocated bits + +The remainder of the bits must also be zero. A procedure will be +defined for allocating them. + +2.2 Security Parameters + +The Security parameters is a sequence of options and values. An +option is a numeric indicatior of the parameter. The value is usually +either a yes or no, or a enumerated value. In rare instances, an +option may require variable length data, in this case a triplet of +option-length-value is used. The presence of the length field is +indicated by the most significant bit in the option field being 1. +Due to the nature of the SEC RR, the length field is not commonly +used. + +The option field is 8 bits. The most significant bit of the options +field is turned on if there is a length field. The value field is +also 8 bits. If the option-length-value is needed, the length is 8 +bits and contains the number of octets comprising the value. No +padding is used. + +Expires December 25, 1999 [Page 8] +Internet Draft June 25, 1999 + +An option may appear multiple times in the Security Parameters. The +sequencing of the options is not significant. If two options + +contradict each other, this is an error, and is noted by the resolver. +A self-contradictory SEC RR is a security error and data from the zone +covered by it SHOULD be considered at risk. + +Option Values are + 0 Reserved + 1 Zone is unsigned + 2 Key Algorithm in use + 3 Signing policy + 0x70-0x7F Locally defined (no length field) + 0xF0-0xFF Locally defined (uses length field) + +All unassigned option values are under the control of IANA. Values 0 +to 127 do not use the length field, values 128 to 255 do use the +length field. The option value is to be treated as unsigned. + +2.2.1 Option 0 + +This option is reserved for future definition. + +2.2.2 Option 1 + +The parent has not signed a KEY RR for the child, therefore the child +zone has no DNSSEC approved signing keys. If this option is not +present, then the resolver SHOULD assume that there are zone keys in +the child zone. + +If the value of this is non-zero, this assertion is true. If the +value is zero, this assertion is false. If the parent has signed keys +for the child, the value is zero, however, in this case, the parent +SHOULD NOT include this option in the security parameters. + +It is tempting to exclude an unsigned zone option from this list, +relying on the absence of any in use key algorithms (option 2) to +imply that the zone is unsigned. The unsigned option is included to +make this information explicit, so that when analyzing a running zone, +it is obvious to an administrator that a zone is unsigned. + +2.2.3 Option 2 + +The parent has signed a key for the child which claims a particular +algorithm. This value field is equal to that of the algorithm field +of the triggering KEY RR. + +Option 2 can be repeated for different algorithms. It is not +necessary to have multiple Option 2 entries with the same key +algorithm value. + +If Option 1 and Option 2 appear in the same SEC RR, this is a +self-contradictory record. If neither Option 1 nor Option 2 appear, +this also constitues a self-contradictory record. + +Expires December 25, 1999 [Page 9] +Internet Draft June 25, 1999 + +2.2.4 Option 3 + +The child has the option to require that all material signatures +(those generated by DNSSEC-approved signing keys) must be validated +(within any temporal constraints) for the data to be considered valid. +The child may instead require that just one of the signatures be +validated. This may be a reflection of the manner in which a zone's +administration is shared amongst organizations. + +If Option 3 is not present (and Option 2 is), the resolver SHOULD +assume that ALL (temporally valid) signatures are required. If the +parent includes at least one Option 2, it SHOULD specify an Option 3, +with a value indicated by the child. + +Values for Option 3 are + 0 Reserved + 1 All signatures are required + 2 One signature is required + 256 Locally defined + +All remaining values are under the control of IANA. + +(Editorial note: whether the assumption that all signatures are +necessary or just one is sufficient in the absence of this option is +open to WG debate.) + +2.2.5 Options 0x70-0x7F + +This option is reserved for an organization to use locally, in an +experimental fashion. This option does not use the length field. +Global interpretation of this option is undefined. + +2.2.6 Options 0xF0-0xFF + +This option is reserved for an organization to use locally, in an +experimental fashion. This option uses the length field. Global +interpretation of this option is undefined. + +3. Master File Representation + +The SEC RR fields are to be represented as hexidecimal fields, with a +preceeding '0x', or in decimal format. Hexidecimal SHOULD be used. + +For example, the SEC RR representing a zone that use signed NXT +records, and has one or more DSA keys, one or more RSA keys, and +requires that just one signature be verified would be: + +myzone.test. 3500 IN SEC 0x5000 0x0201 0203 0302 + +(0x020102030302 is one field, hence one 0x prefix.) + +Hex values for the security parameters MAY BE separated by +whitespace, as shown. DNS data display routines SHOULD substitute + +Expires December 25, 1999 [Page 10] +Internet Draft June 25, 1999 + +mnemonics for these values, but MUST write the numeric form in master +files. + +4. Signature Policy + +The SEC RR must be signed by one or more zone keys of the parent +(delgating) zone, and the signatures must adhere to the parent's +policy. + +The SEC RR for the root zone is the lone exception, it appears at the +apex of the root zone, and must be signed sufficiently by the root's +zone key or keys. + +5. Cache Considerations + +When a SEC RR set for a name is held in a cache, it will have a +credibility rating indicating that the data came from the parent +(unless the parent and child share servers). When data about the same +name arrives from the child, with a higher credibility, the newly +arrived data MUST NOT cause the cache to remove the SEC RR. + +6. IANA Considerations + +IANA is requested to assign this RR an type parameter for DNS, and to +assign the indicated option numbers and values when requests are +approved. The procedure for requesting new options and values will be +defined in future versions of this specfication. + +7. Security Considerations + +This record is designed to address the concerns of securing delegation +points and resolving the security of DNS answers. This record is +important to the security because it supplies needed information and +eases the burden of security on the DNS. + +The SEC RR does require one piece of additional information not +addressed to date to be communicated from the parent to the child. +This is the signature policy. This will be needed in the operations +documents. + +Editorial Note: This document would benefit by a companion document +describing the process of evaluating the signatures in DNS. Such a +document would provide clearer input to the security parameters field. + +8. Editorial Considerations + +Although somewhat detailed in this current description, this record is +still in the formative state. The -00 document has been quickly +written to test the waters for interest. + +9. References + +RFC 2535 is the prime DNSSEC definition. RFC 2181 is the Clarify +document. EDNS0 reference needed... + +Expires December 25, 1999 [Page 11] +Internet Draft June 25, 1999 + +10. Acknowledgements + +This record is a successor to the Zone Key Referral, originally +promoted by John Gilmore and Jerry Scharf. A DNSSEC workshop +sponsored by the NIC-SE in May 1999 provided the enlightenment that +expanded the Zone Key Referral into the SEC RR proposal. + +11. Author's Addresses + +Edward Lewis Jerry Scharf Olafur Gudmundsson +NAI Labs Internet Software Consortium NAI Labs +3060 Washington Road 950 Charter St 3060 Washington Rd +Glenwood, MD 21738 Redwood City, CA 94063 Glenwood, MD 21738 ++1 443 259 2352 +1 650 779 7060 +1 443 259 2389 + + +12. 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 implmentation 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." + +Expires December 25, 1999 [Page 12] diff --git a/doc/expired/draft-ietf-dnsind-sigalgopt-00.txt b/doc/expired/draft-ietf-dnsind-sigalgopt-00.txt new file mode 100644 index 0000000000..c27dd9891c --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-sigalgopt-00.txt @@ -0,0 +1,164 @@ +Network Working Group R. Austein +draft-ietf-dnsind-sigalgopt-00.txt On Sabbatical + P. Vixie + Internet Software Consortium + October 1999 + + + DNS SIGALGOPT + + +Status of this document + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + 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." + + The list of current Internet-Drafts can be accessed at + + + The list of Internet-Draft Shadow Directories can be accessed at + + + Distribution of this document is unlimited. Please send comments to + the namedroppers@internic.net mailing list. + +Abstract + + This document describes a mechanism for conserving packet space in a + DNS response message in the presence of multiple DNSSEC signature + algorithms. + +Motivation and Scope + + DNSSEC [DNSSEC] specifies a general framework for attaching + cryptographic signatures to DNS resource records. The framework + includes provisions for multiple signature protocols, possibly even + on a per-name basis. While this open-ended framework is good and + useful, it poses a problem when multiple signature protocols are in + use and DNS message sizes are limited by the underlying UDP transport + packet size. EDNS0 [EDNS0] provides a way to specify a larger + + + +Austein & Vixie Expires 18 April 2000 [Page 1] + +draft-ietf-dnsind-sigalgopt-00.txt October 1999 + + + payload size, but this still does not entirely solve the problem for + large RRsets. Worse, in cases where multiple signature algorithms + generate a response packet so large that it must be truncated, the + signatures that fit into the truncated response will be useless if + the resolver doesn't know how to verify signatures generated with + that algorithm. + + This note proposes a way for a resolver to indicate which signature + algorithms it understands to a name server in the form of an ordered + list. When this mechanism is in use, the name server can conserve + packet space by (a) not sending signatures with algorithms that the + resolver will not understand, and (b) not sending multiple signatures + for the same resource records. + +Mechanism + + [DNSSEC] SIG RRs include a one-octet code indicating the algorithm + associated with a particular signature. The SIGALGOPT option defined + below allows the resolver to specify an ordered list of signature + algorithms using the same one-octet codes that DNSSEC uses. + + SIGALGOPT is encoded n the variable RDATA part of the OPT pseudo-RR + in the DNS request (see [EDNS0]). + + The OPTION-CODE for SIGALGOPT is [TBD]. + + The OPTION-DATA for SIGALGOPT is an ordered list of the one-octet + codes used by DNSSEC. + + If the SIGALGOPT option in a query specifies multiple signature + algorithms and signatures using more than one of those algorithms are + available in the zone, the server must respond with the signatures + corresponding to the first algorithm on the SIGALGOPT list that + matches, omitting any signatures corresponding to the remaining + algorithms. + + We have deliberately not provided a mechanism to return all the + matching signatures, because the purpose of the SIGALGOPT mechanism + is to minimize packet size. If the resolver wants to see all + available signatures, it should just leave off the SIGALGOPT option + entirely. + +Security Considerations + + Good question. What horrible things could a bad guy do by + creating/altering/deleting SIGALGOPT? Are any of the possible + attacks more interesting than denial of service? + + + + +Austein & Vixie Expires 18 April 2000 [Page 2] + +draft-ietf-dnsind-sigalgopt-00.txt October 1999 + + +IANA Considerations + + SIGALGOPT will need an option code. + + The signature algorithm codes themselves are borrowed from DNSSEC and + do not create any new issues for IANA. + +References + + [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and + facilities", RFC 1034, November 1987. + + [DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation + and specification", RFC 1035, November 1987. + + [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, + August 1999. + +Author's addresses: + + Rob Austein + On Sabbatical + sra@hactrn.net + + Paul Vixie + Internet Software Consortium + 950 Charter Street + Redwood City, CA 94063 + +1 650 779 7001 + vixie@isc.org + + + + + + + + + + + + + + + + + + +Austein & Vixie Expires 18 April 2000 [Page 3] diff --git a/doc/expired/draft-ietf-dnsind-test-tlds-13.txt b/doc/expired/draft-ietf-dnsind-test-tlds-13.txt new file mode 100644 index 0000000000..f0315eccbf --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-test-tlds-13.txt @@ -0,0 +1,290 @@ + +INTERNET-DRAFT Reserved TLDs + February 1999 + Expires August 1999 + + + + + Reserved Top Level DNS Names + -------- --- ----- --- ----- + + Donald E. Eastlake 3rd + Aliza R. Panitz + + + + + Status of This Document + + This draft is file name draft-ietf-dnsind-test-tlds-13.txt. + Distribution of this document is unlimited. Comments should be sent + to the DNS mailing list or to the + authors. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + + + + + + + + + + + + + + + +D. Eastlake, A. Panitz [Page 1] + + +INTERNET-DRAFT Reserved TLDs + + +Abstract + + To reduce the likelihood of conflict and confusion, a few top level + domain names are reserved for use in private testing, as examples in + documentation, and the like. In addition, a few second level domain + names reserved for use as examples are documented. + + + +Table of Contents + + Status of This Document....................................1 + + Abstract...................................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. TLDs for Testing, & Documentation Examples..............3 + 3. Reserved Example Second Level Domain Names..............4 + 4. IANA Considerations.....................................4 + 5. Security Considerations.................................4 + + References.................................................5 + Authors Addresses..........................................5 + Expiration and File Name...................................5 + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake, A. Panitz [Page 2] + + +INTERNET-DRAFT Reserved TLDs + + +1. Introduction + + The global Internet Domain Name System is documented in [RFC 1034, + 1035, 1591] and numerous additional Requests for Comment. It defines + a tree of names starting with root, ".", immediately below which are + top level domain names such as ".com" and ".us". Below top level + domain names there are normally additional levels of names. + + + +2. TLDs for Testing, & Documentation Examples + + There is a need for top level domain (TLD) names that can be used for + creating names which, without fear of conflicts with current or + future actual TLD names in the global DNS, can be used for private + testing of existing DNS related code, examples in documentation, DNS + related experimentation, invalid DNS names, or other similar uses. + + For example, without guidance, a site might set up some local + additional unused top level domains for testing of its local DNS code + and configuration. Later, these TLDs might come into actual use on + the global Internet. As a result, local attempts to reference the + real data in these zones could be thwarted by the local test + versions. Or test or example code might be written that accesses a + TLD that is in use with the thought that the test code would only be + run in a restricted testbed net or the example never actually run. + Later, the test code could escape from the testbed or the example be + actually coded and run on the Internet. Depending on the nature of + the test or example, it might be best for it to be referencing a TLD + permanently reserved for such purposes. + + To safely satisfy these needs, four domain names are reserved as + listed and described below. + + .test + .example + .invalid + .localhost + + ".test" is recommended for use in testing of current or new DNS + related code. + + ".example" is recommended for use in documentation or as + examples. + + ".invalid" is intended for use in online construction of domain + names that are sure to be invalid and which it is obvious at a glance + are invalid. + + The ".localhost" TLD has traditionally been statically defined + + +D. Eastlake, A. Panitz [Page 3] + + +INTERNET-DRAFT Reserved TLDs + + + in host DNS implementations as having an A record pointing to the + loop back IP address and is reserved for such use. Any other use + would conflict with widely deployed code which assumes this use. + + + + +3. Reserved Example Second Level Domain Names + + The Internet Assigned Numbers Authority (IANA) also currently has the + following second level domain names reserved which can be used as + examples. + + example.com + example.net + example.org + + + +4. IANA Considerations + + IANA has agreed to the four top level domain name reservations + specified in this document and will reserve them for the uses + indicated. + + + +5. Security Considerations + + Confusion and conflict can be caused by the use of a current or + future top level domain name in experimentation or testing, as an + example in documentation, to indicate invalid names, or as a synonym + for the loop back address. Test and experimental software can escape + and end up being run against the global operational DNS. Even + examples used "only" in documentation can end up being coded and + released or cause conflicts due to later real use and the possible + acquisition of intellectual property rights in such "example" names. + + The reservation of several top level domain names for these purposes + will minimize such confusion and conflict. + + + + + + + + + + + + +D. Eastlake, A. Panitz [Page 4] + + +INTERNET-DRAFT Reserved TLDs + + +References + + RFC 1034 - P. Mockapetris, "Domain names - concepts and facilities", + 11/01/1987. + + RFC 1035 - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + RFC 1591 - J. Postel, "Domain Name System Structure and Delegation", + 03/03/1994. + + + +Authors Addresses + + Donald E. Eastlake 3rd + IBM + 65 Shindegan Hill Road, RR #1 + Carmel, NY 10512 + + Telephone: +1 914-276-1668(h) + +1 914-784-7913(w) + FAX: +1 914-784-3833(3) + email: dee3@us.ibm.com + + + Aliza R. Panitz + 500 Stamford Dr. No. 310 + Newark, DE 19711 USA + + Telephone: +1 302-738-1554 + email: buglady@fuschia.net + + + +Expiration and File Name + + This draft expires August 1999. + + Its file name is draft-ietf-dnsind-test-tlds-13.txt. + + + + + + + + + + + + +D. Eastlake, A. Panitz [Page 5] + diff --git a/doc/expired/draft-ietf-dnsind-verify-00.txt b/doc/expired/draft-ietf-dnsind-verify-00.txt new file mode 100644 index 0000000000..1837fe9e7f --- /dev/null +++ b/doc/expired/draft-ietf-dnsind-verify-00.txt @@ -0,0 +1,158 @@ + + + INTERNET-DRAFT Mark Andrews (ISC) + February 1999 + + + Verifying Resource Records Without Knowing Their Contents + + + Status of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + 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." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + Abstract + + DNSSEC [RFC2065] provides a mechanism to cryptographically verify a + DNS resource record provided we can get it into canonical form. + + The problem is how do we do this without knowing the contents of all + resource record types? + + This document provides one possible solution to this problem. + + 1 - Terminology + + 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]. + + + + + Expires August 1999 [Page 1] + + INTERNET-DRAFT draft-ietf-dnsind-verify-00.txt February 1998 + + + 2 - Method + + In order to be able to canonicalise a resource record a resolver needs + to know where in the data domain names exist so that the resolver can + decompress the domain names and convert the uppercase ASCII in ordinary + labels to lowercase prior to the data being feed into the encryption + routines. + + This document propose that all new resource record types defined MUST + have a header at the start of the data section locating where the domain + names are in the data section. A new resource record for the purpose of + this document is any type NOT referenced in section 3 Old Types. Meta + queries such as MAILA (254), MAILB (253), AXFR (252) and IXFR (251) are + not covered by this document as they do not return data of this type. + + This table would be a series of unsigned 16 bit words in network order. + The first word contains the length of the table as 16 bit words not + counting the first word. Subsequent words contain the offset from the + start of the data to the start of relevent domain name in the data + assuming all domain names are uncompressed. Offsets in the table are in + the same order as domain names in the data. + + 3 Old Types + + The following types are deemed old and are NOT covered by this document. + A (1), NS (2), MD (3), MF (4), CNAME (5), SOA (6), MB (7), MG (8), MR + (9), NULL (10), WKS (11), PTR (12), HINFO (13), MINFO (14), MX (15), TXT + (16), RP (17), AFSDB (18), X25 (19), ISDN (20), RT (21), NSAP (22), + NSAP-PTR (23), SIG (24), KEY (25), PX (26), GPOS (27), AAAA (28), LOC + (29), NXT (30), EID (31), NIMLOC (32), SRV (33), ATMA (34), NAPTR (35), + KX (36), CERT (37), A6 (38), DNAME (39), UINFO (100), UID (101), GID + (102), UNSPEC (103), OPT (XXX), TKEY (249) and TSIG (250). + + + 4 Security Considerations + + It is believed that this document does not introduce any significant + additional security threats other that those that already exist when + using data from the DNS but rather enhances security by allowing new + resource record types to be checked by security aware resolvers. + + 5 IANA Considerations + + This document places no requirements apon IANA. + + + + + Expires August 1999 [Page 2] + + INTERNET-DRAFT draft-ietf-dnsind-verify-00.txt February 1998 + + + References + + + [RFC2065] + Eastlake, D. 3rd. and Kaufman, C,. "Domain Name System Security + Extensions," RFC 2065, January 1997 + + + [RFC2119] + Bradner, S., "Key words for use in RFCs to Indicate Requirement Lev­ + els," BCP 14, RFC 2119, March 1997 + + + Author's Address + + Mark Andrews + Internet Software Consortium + 1 Seymour St. + Dundas Valley + NSW 2117 + AUSTRALIA + +61 2 9871 4742 + + + + + + + + + + + + + + + + + + + + + + + + + + + Expires August 1999 [Page 3] + diff --git a/doc/expired/draft-ietf-dnssec-ar-00.txt b/doc/expired/draft-ietf-dnssec-ar-00.txt new file mode 100644 index 0000000000..fc1c3a332a --- /dev/null +++ b/doc/expired/draft-ietf-dnssec-ar-00.txt @@ -0,0 +1,618 @@ + + + + + +Domain Name System Security Working Group R. Watson +INTERNET DRAFT November 1997 + Expires in six months + + + DNSsec Authentication Referral Record (AR) + + +Status of this Document + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + 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." + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), + munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or + ftp.isi.edu (US West Coast). + +Abstract + + Authentication Referrals allow DNS to refer to authentication + mechanisms that supplement or replace the KEY RRs of DNSsec. + + Five Authentication Service types are defined: DNSsec, Kerberos IV, + Kerberos V, Network Information Service (NIS+), and Radius. + + + + + + + + + + + + + + + + + + +Watson [Page 1] + +Internet DRAFT DNSsec Authentication Referral November 1997 + + +1. Introduction + + Domain Name System Security [DNSSEC] extends the Domain Name System + (DNS) [RFC1034, RFC1035] to provide for data origin authentication, + public key distribution, and query and transaction authentication, + all based on public key cryptography and public key based digital + signatures. In many organizations, it is desirable to provide a + centralized source for authentication data, especially in + environments where multiple systems are used (for example, KerberosIV + and NIS+). Systems have been defined for distributing user + information in the DNS name-space [HESIOD], but DNS has traditionally + lacked the security necessary to safely distribute sensitive + authentication information. Authentication Referrals use DNSsec's + authenticated data capabilities to distribute mappings from entities + to authentication mechanisms. + +1.1 Keywords Used + + 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 RFC 2119. + +1.2 Definition of Terms + + Service Desiring Authentication (SDA): A service requiring a user to + authenticate before providing access. For example, the login program + on a UNIX host is an SDA. + + Authentication Service: A type of authentication system that allows + an SDA to verify the identity of a Client communicating with the SDA. + Services are typically accessed using an Authentication Server such + as a KerberosIV or Radius server. In a referral, both the type of + authentication service and the server address are provided. + + Client: An entity that wishes to connect to a service, in particular, + to an SDA. Clients are identified using a unique DNS Fully Qualified + Domain Name (FQDN), which contains records providing information on + verifying authentication. Authentication Client may refer to both + humans and hosts in this document. + + Authentication Username: In the event that an Authentication Service + is used, the Username may differ from the Client's FQDN in DNS. + + Authentication Realm: Some distributed authentication systems allow + for multiple "realms" in which authentication takes place. Realms + typically represent a set of identities and services over which a + single authority is responsible for authentication. Where + appropriate, referrals contain the name of the realm against which + + + +Watson [Page 2] + +Internet DRAFT DNSsec Authentication Referral November 1997 + + + they should be made. + + Authentication Server: Many authentication systems rely on a + centralized database, which may be found on the Authentication + Server. This database can be identified using the DNS FQDN for the + host. It is assumed that the Authentication Service type will + provide all other information necessary to communicate with the + Authentication Server. + +1.3 Authentication in DNSsec + + DNSsec provides a mechanism for the authentication of entities it + describes via KEY records containing public keys. This is adequate + for IP Security [IPSEC] and other key-based protocols (such as Secure + Shell [SSH]), but it is not useful for individual user + authentication. Typically such an authentication process involves + the encryption of data using the Client's public key (extracted from + DNSsec), which must then be decrypted by the Client and returned in + some other form (often encrypted with the SDA's public key to protect + both the challenge and the response). Users may be reluctant to + replace their traditional alpha-numeric password with 514-bit private + keys and then perform computation-intensive key manipulation and + signature-operations in their heads. While devices are available + that perform this function in a more accessible manner, they are not + yet mainstream, and a standard has not yet been proposed for + interaction between these devices and DNSsec-based authentication + systems. + + Existing distributed authentication systems commonly rely on a + password (shared secret) or a variable challenge-response mechanism + using a system-specific protocol. For example, both KerberosIV + [KERBEROSIV] and Radius [RADIUS] use protocols employing different + packet formats and privacy mechanisms. Because DNS was designed as a + publicly accessible distributed database, no mechanism for the + distribution of private data is provided, which makes the inclusion + of password data in the system both difficult and inappropriate. + + The AR resource record (RR type TBD) allows DNSsec to refer an SDA to + an Authentication Service when direct authentication based on the KEY + RR cannot be used. + +2. Authentication Referral Resource Record Format + + To provide storage for authentication referral information, a new RR + type is defined with the mnemonic AR. More than one AR RR MAY exist + in an RRset; the RRset MUST contain the complete list of + authentication mechanisms allowed for the DNS name. + + + + +Watson [Page 3] + +Internet DRAFT DNSsec Authentication Referral November 1997 + + +2.1 Record Format + + NAME The domain name of the entity to be authenticated. + TYPE AR (TBD) + CLASS IN (HS may also be appropriate) + TTL (as appropriate) + RdLen (variable) + RDATA + + Field Name Data Type Notes + ------------------------ ----------- ------------------------- + Authentication Server dname FQDN of the server that + will provide + authentication data + Authentication Realm dname Realm in which + authentication occurs + Authentication Service 16-bit int Authentication Service + Type as defined in 2.3 + Username Length 16-bit int Length of Authentication + Username string in octets + Authentication Username 8-bit int[] UTF-8 encoded name whose + use is defined by the + service type. + Other Data undefined Ignore any following + RDATA + + All integer values are stored in network byte order. The + Authentication Username field is an octet stream of length Username + Length. + + Meaning of Authentication Realm, Authentication Server, + Authentication Username are specific to each Authentication Service + type. + +2.2 Text Representation + + A simple text representation for the AR RR might be: + + NAME. IN AR [Server] [Realm] [AuthMnemonic] [Username] + +2.3 Authentication Service Types + + Different Authentication Services types will be assigned numeric + value. New services MUST be registered with IANA.* A mnemonic is + associated with each type to simplify textual representation. + + + + + + +Watson [Page 4] + +Internet DRAFT DNSsec Authentication Referral November 1997 + + + Value Mnemonic Authentication Service Name + ------ ----------- --------------------------- + 0 DNSSEC DNSsec + 1 KERBEROS_V4 Kerberos IV + 2 KERBEROS_V5 Kerberos V + 3 RADIUS Radius + 4 NISPLUS NIS+ + + * A method for registration will be described in detail in a later + version of this document. + +2.3.1 DNSsec Referral + + It may be desirable to refer authentication to another FQDN. For + example, an organization may have several user zones defined, but one + Client may exist in several of them. Rather than requiring separate + AR RRs, authentication may be forwarded to one canonical AR RR + containing other useful data, or to a record with a KEY RR. Some + fields defined across the AR record are not used: + + Field Name Value + ------------------------ ---------------------------------- + Authentication Server (empty) + Authentication Realm (empty) + Authentication Service 0 (DNSSEC) + Username Length (as appropriate) + Authentication Username FQDN of the entity referred to + + When using DNSsec referrals, it is important to avoid referral loops. + The appropriate interpretation order of coexisting KEY and AR records + is discussed in section 3. Referrals may point to either another AR + record or a record with authentication KEYs. If a DNSsec referral + record points to a non-existent name or no authentication information + is available at that name, the authentication MUST fail. + +2.3.1.1 DNSsec Referral Example + + NAME ROBERT.USER.WATSON.ORG. + TYPE AR (TBD) + CLASS IN + TTL 3600 + RdLen (as appropriate) + + + + + + + + + +Watson [Page 5] + +Internet DRAFT DNSsec Authentication Referral November 1997 + + + RDATA + + Field Name Value + ------------------------ ---------------------------------- + Authentication Server (empty) + Authentication Realm (empty) + Authentication Service 0 (DNSSEC) + Username Length 19 + Authentication Username rnw.andrew.cmu.edu. + + A textual representation of this record in zone USER.WATSON.ORG would + appears as: + + ROBERT IN AR (. . DNSSEC "rnw.andrew.cmu.edu.") + +2.3.2 Kerberos IV Referral + + The Authentication Username is a "principal.instance" pair where + instance may be alphanumeric, null, or the wildcard "*". For + authentication against user robert in realm WATSON.ORG, an + appropriate Authentication Username would be "robert.", indicating + that no instance is to be used. To require authentication against + another instance, the form "robert.admin" is appropriate. In some + circumstances, a wild-card Username entry might be used, "robert.*", + indicating that the Client MAY be prompted for a specific instance. + + Field Name Value + ----------------------- -------------------------------------- + Authentication Server Kerberos IV Server + Authentication Realm Kerberos IV Realm + Authentication Service 1 (Kerberos IV) + Username Length (length of Username in octets) + Authentication Username Kerberos IV principal.instance + +2.3.2.1 Kerberos IV Referral Example + + NAME ROBERT.USER.WATSON.ORG. + TYPE AR (TBD) + CLASS IN + TTL 3600 + RdLen (as appropriate) + + + + + + + + + + +Watson [Page 6] + +Internet DRAFT DNSsec Authentication Referral November 1997 + + + RDATA + + Field Name Value + ----------------------- ---------------------- + Authentication Server KERBEROS.WATSON.ORG. + Authentication Realm WATSON.ORG. + Authentication Service 1 (KERBEROS_V4) + Username Length 12 + Authentication Username robert.admin + + A textual representation of this record in zone USER.WATSON.ORG would + appear as: + + ROBERT IN AR (KERBEROS.WATSON.ORG. WATSON.ORG. + KERBEROS_V4 "robert.admin") + +2.3.3. Kerberos V Referral + + The specifics of this type will be specified in a future draft. It + is expected that Kerberos V referrals will be almost identical to + Kerberos IV, but with the "." principal/instance separator replaced + with a "/". + +2.3.4 Radius Referral + + Field Name Value + ----------------------- --------------------------------- + Authentication Server Radius Server + Authentication Realm (empty) + Authentication Service 3 (RADIUS) + Username Length (as appropriate) + Authentication Username Radius Username + +2.3.4.1 Radius Referral Example + + NAME ROBERT.USER.WATSON.ORG. + TYPE AR (TBD) + CLASS IN + TTL 3600 + RdLen (as appropriate) + + + + + + + + + + + +Watson [Page 7] + +Internet DRAFT DNSsec Authentication Referral November 1997 + + + RDATA + + Field Name Value + ----------------------- ---------------------- + Authentication Server RADIUS.WATSON.ORG. + Authentication Realm (empty) + Authentication Service 5 (RADIUS) + Username Length 6 + Authentication Username robert + + A textual representation of this record in zone USER.WATSON.ORG would + appear as: + + ROBERT IN AR (RADIUS.WATSON.ORG. . + RADIUS "robert") + +2.3.5 NIS+ Referral + + NIS+ referral will be documented in a separate document. Due to the + complex interactions between NIS and DNS, there are additional + concerns that must be addressed in greater detail than is appropriate + here. + +2.4 DNS Server Handling of the AR Resource Record + + When returning an AR RR as part of an RRset, a DNS server MAY include + Additional Records [RFC1034: Section 3.7] that it anticipates the SDA + requires. + +3. AR Resource Record Evaluation + + When performing a lookup on a Client's DNS entry, a signed RRset is + returned containing KEY RRs, SIG RRs, other data, and possibly an AR + RR. If KEY RRs are present and are permitted for use in user + authentication, public/private key authentication may take place. + Alternatively, the SDA may choose a different authentication + mechanism from the list of AR RRs. + +3.1 Authentication Rules + + Multiple AR RRs of different Authentication Service types may exist. + Similarly, multiple RRs of the same type may exist in an RRset. When + multiple RRs are returned, the SDA must select some subset of these + to try. A combination of local policy and and the desire for load + balancing determines the correct use of these RRs. + + Where multiple AR RRs of different Authentication Service type exist, + one of the available Services SHOULD be selected. This choice could + + + +Watson [Page 8] + +Internet DRAFT DNSsec Authentication Referral November 1997 + + + be made by local site policy (i.e., only to accept authentication by + Kerberos, or to not allow AR referral to another DNSsec name), or + with Client interaction (the user is prompted for the mechanism they + wish to authenticate against). If one Authentication Service fails, + the choice to retry against the same service or against different + Services should be made in accordance with local security policy. + + Where multiple RRs with the same Authentication Service Type exist + but different Authentication Realm or Username are present, the SDA + should make a choice in accordance with local site policy. For + example, a site might choose only to accept authentication to their + own Kerberos realm. + + Load balancing is desirable in the event that multiple RRs with the + same Authentication Realm, Authentication Service, and Username are + present. Such sets of related AR RRs may be considered to be + redundant records. DNS round-robin may be relied upon to reorder + them. + +3.1.1 Successful Authentication + + If the chain of signatures validates the initial Client records as + well as any further records referenced if a DNSsec referral is + performed, an authentication attempt MAY be performed. If an + attempted authentication succeeds, the SDA MUST accept the + authentication as valid. + +3.1.2 Failure in Authentication + + If any break in the signature chain occurs in DNSsec verification of + the records required for authentication, the authentication SHOULD + fail. If alternate mechanisms exist for authenticating the + Authentication Server, they MAY be used. + + If an Authentication Service is selected, and the authentication + fails for non-technical reasons [different word?], then the + authentication MUST fail. If a technical failure occurs (such as + being unable to contact the Authentication Server), the SDA MAY + select another AR record to attempt or MAY retry on the same server. + If no further AR records are present and any retries have also + failed, then the authentication MUST fail. + +4. Security Considerations + + It is expected that some system of access control will be used to + determine what, if any, services are provided to the authenticated + Client. + + + + +Watson [Page 9] + +Internet DRAFT DNSsec Authentication Referral November 1997 + + +4.1 DNSsec Use + + Spoofing of AR RRs could result in unauthorized authentication. + DNSsec MUST be used to verify the authenticity of the AR RRs, as well + as the chain to the DNS root. For example, if an AR refers to + Kerberos IV, DNSsec MUST be used to verify the retrieval of the + Client's AR record, and the retrieval of the Kerberos IV Server's IP + address from Authentication Server FQDN. + +4.2 The Weakest Link + + While DNSsec provides strong cryptography to protect data + authenticity and to allow expiration, many distributed security + mechanisms are not as strong. For example, while an AR record may be + valid, an NIS server connection may be spoofed, hijacked, + eavesdropped, etc. + +4.3 Local Site Policy + + Local site policy is relied upon for a number of key decisions in the + authentication process. For example, before attempting to follow an + AR chain, the SDA must first confirm that the initial name provided + is allowed to authenticate to it. It must also determine which + authentication service types in the AR list for the name are + appropriate for use. An SDA MAY choose not to accept authenticatino + to a weak Authentication Service. The definition of weak SHOULD be + defined in a local site policy. + + A site might accept initial attempts at authentication to + *.user.watson.org. On a successful and verified referral, it might + then be willing to accept authentication against any strong + Authentication Service (e.g., KerberosIV or KerberosV), but not + against weaker services (e.g., NIS). + + If AR information can be verified externally, do so. For example, if + Kerberos IV server to realm mapping information exists in a local + krb.conf, consistency should be verified. + + Correct logging practice, as well as approaches for dealing with + various types of failures given the varied mechanisms provided may + also involve significant local determination. All authentication + events SHOULD be logged. Selective reporting of errors to the Client + may also improve security. + + + + + + + + +Watson [Page 10] + +Internet DRAFT DNSsec Authentication Referral November 1997 + + +5. References + + [RFC1034] P. Mockapetris, ``Domain Names - Concepts and + Facilities,'' RFC 1034, ISI, November 1987. + + [RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification,'' RFC 1034, ISI, November 1987. + + [DNSSEC] D. Eastlake, C. Kaufman, ``Domain System Security + Extensions,'' RFC 2065, CyberCash & Irix, January 1997. + + [HESIOD] S. Dryer, ``The Hesiod Name Server,'' MIT, January 1988. + + [IPSEC] R. Atkinson, ``Security Architecture for the Internet + Protocol,'' RFC 1825, Navy Research Laboratory, August + 1995. + + [SSH] M. Ylonen, T. Kivinen, M. Saarinen, ``SSH Transport Layer + Protocol,'' draft-ietf-secsh-transport-02.txt, SSH, + October 1997. + + [KERBEROSIV] S. Miller, B. Neuman, J. Schiller, J. Saltzer, ``Kerberos + Authentication and Authorization System,'' MIT, December + 1988. + + [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, ``Remote + Authentication Dial In User Service (RADIUS),'' RFC 2138, + April 1997. + +6. Author's Address + + Robert Watson + Carnegie Mellon University + SMC 4105 + PO Box 3015 + Pittsburgh, PA 15230 + + Phone: (412) 862-2696 + + Email: robert+ietf@cyrus.watson.org + + + + + + + + + + + +Watson [Page 11] + diff --git a/doc/expired/draft-ietf-dnssec-as-map-05.txt b/doc/expired/draft-ietf-dnssec-as-map-05.txt new file mode 100644 index 0000000000..caaf932ca7 --- /dev/null +++ b/doc/expired/draft-ietf-dnssec-as-map-05.txt @@ -0,0 +1,522 @@ + +INTERNET-DRAFT Mapping AS Number into the DNS + July 1997 + Expires January 1998 + + + + + Mapping Autonomous Systems Number into the Domain Name System + ------- ---------- ------- ------ ---- --- ------ ---- ------ + + Donald E. Eastlake 3rd + + + +Status of This Document + + This draft, file name draft-ietf-dnssec-as-map-05.txt, is intended to + be become a Best Current Practice RFC concerning utilization of the + Domain Name System (DNS) to support routing security. Distribution of + this document is unlimited. Comments should be sent to the DNS + Security Working Group mailing list or to the + author. + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + To learn the current status of any Internet-Draft, please check the + 1id-abstracts.txt listing contained in the Internet-Drafts Shadow + Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), + nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), + munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT Mapping AS Numbers into the DNS + + +Abstract + + One requirement of secure routing is that independent routing + entities, such as those identified by Internet Autonomous System + Numbers, be able to authenticate messages to each other. Additions + have developed to the Domain Name System to enable it to be used for + authenticated public key distribution [RFC 2065]. This draft maps + all Autonomous System numbers into DNS Domain Names so that the DNS + security can be used to distribute their public keys. + + [Changes from previous version are to accommodate AS numbers larger + than 16 bits and to delegate on decimal boundaries rather than binary + boundaries.] + + + +Acknowledgements + + The contributions of the following persons, listed in alphabetic + order, to this draft are gratefully acknowledged: + + Ran Atkinson + + Christian Huitema + + Tony Li + + Michael A. Patton. + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT Mapping AS Numbers into the DNS + + +Table of Contents + + Status of This Document....................................1 + + Abstract...................................................2 + Acknowledgements...........................................2 + + Table of Contents..........................................3 + + 1. Introduction............................................4 + + 2. Autonomous System Number Mapping........................5 + + 3. Meaning of RRs..........................................6 + + 4. Security Considerations.................................8 + References.................................................8 + Author's Address...........................................8 + Expiration and File Name...................................9 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT Mapping AS Numbers into the DNS + + +1. Introduction + + There are a number of elements required to secure routing in the + Internet. One of these is a way that independently operated routing + domains be able to authenticate messages to each other. + + Sharing a private symmetric key between each pair of such domains is + impractical. Assuming 2**16 Autonomous System routing entities, + which is what is allowed in current versions of BGP, [RFC 1771], this + would imply approximately 2**31 pairs, an impractical number of keys + to securely generate, install, and periodically replace. + + The solution is to use public key technology whereby each routing + domain has a private key it can use to sign messages. Other domains + that know the corresponding public key can then authenticate these + messages. Such authenticated messages can be used to set up and + maintain efficient symmetric keys on an as needed basis. + + But how do the domains securely obtain the Autonomous System number + to public key mapping? + + Extensions have been developed for the Domain Name System that enable + it to be conveniently used for authenticated public key distribution + [RFC 2065]. A variety of key types can be supported. All that is + required is a mapping of Autonomous System numbers into domain names, + which is provided by this draft. + + It should be noted that the public keys retrieved from DNS will + likely be used primarily to authenticate initial connection set up + messages. Autonomous Systems that need to converse with any + frequency will probably negotiate more efficient symmetric session + keys. + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT Mapping AS Numbers into the DNS + + +2. Autonomous System Number Mapping + + Autonomous System (AS) numbers are usually written as decimal number + and when blocks of AS numbers are delegated to a registry, it is + normally on decimal boundaries. Their current use in BGP is limited + to 16 bits providing a maximum value of 65,535. For example, ANS is + autonomous system 690. However, there is no inherent size limit in + the AS concept. AS numbers are mapped into a domain name as + described below. + + Write the AS number, as usual, as a decimal number without any + "thousands" punctuation. If it is less than 5 digits, add leading + zeros to bring it up to five digits. Then simply reverse the order + of the digits, put a period between them, and append ".length.in- + as.arpa" where "length" is the number of AS digits. This mapping is + analogous to the IPv4 address mapping into the in-addr.arpa DNS + domain. + + Thus the domain name correspond to Autonomous System 690 (decimal) is + + 0.9.6.0.0.5.in-as.arpa. + + the domain corresponding to the largest possible AS number in BGP is + + 5.3.5.5.6.5.in-as.arpa. + + the domain corresponding to AS number 65,000 is + + 0.0.0.5.6.5.in-as.arpa. + + and the domain correspond to a hypothetical future greater than 16 + bit AS number 1,234,567 is + + 7.6.5.4.3.2.1.7.in-as.arpa. + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT Mapping AS Numbers into the DNS + + +3. Meaning of RRs + + The following guidance is given for some resource record (RR) types + that could be stored under the names mapped from AS numbers. The KEY + RR is given first, followed by the SIG RR, the NXT RR, and then some + additional RR types in alphabetic order. + + KEY: This type of RR associates a public key with the owner name + which, in this case, corresponds to an Autonomous System (AS). Under + DNS security as proposed in RFC 2065 the KEY RR can be used to store + a variety of digital keys. A KEY for use in securing routing + communications between ASs will have the end entity flag bit on, the + authentication use prohibited flag bit off, and a protocol byte or + flag bit indicating routing communications use. Such a public key can + be used to authenticate communications with or between ASs. The + existence of such KEY RRs in the primary reason for mapping AS names + into the DNS. + + SIG: The SIG signature resource record authenticates the RRs + that it signs as described in RFC 2065. Assuming the signer who + generated the SIG is trustworthy, such as the in-as.arpa zone owner, + then the signed RRs can be trusted. + + NXT: An NXT RR is used in DNS security to provide authenticated + denial of the existence of types and names as described in RFC 2065. + + A, AAAA: Type A or AAAA RRs SHOULD NOT be placed at AS nodes. + AS domain names are reserved for Autonomous Systems only and should + NOT be used for a host or any type of end entity other than an + Autonomous System. + + CNAME: This type of RR is an alias pointing to another domain + name. An AS could have a CNAME pointing to a different AS but this + is not likely to be very useful as AS RRs will normally be looked up + when the AS number is actually encountered in use. + + MX: There is no special use for an MX RR for an AS name. It + could point to a host that would accept mail related to that AS. + + NS: The presence of NS records under an AS name means that it + has been carved out as a subzone. This gives the AS complete control + over the zone refresh parameters and control over the creation of + inferior names. No special meaning is currently assigned to such + inferior names so, although this is not advised, they could be used + for hosts or whatever. In this case, the will also be a zone KEY at + the AS name, indicated by having the zone flag bit on. + + PTR: The part of the forward domain tree that administratively + corresponds to the AS SHOULD be indicated by a PTR RR. If some + entity, say example.xx, has several ASs, there would be PTRs to + + +Donald E. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT Mapping AS Numbers into the DNS + + + example.xx from several names in the in-as.arpa hierarchy. + + RP: A Responsible Person RR SHOULD appear under each AS name + telling you who you should contact in the case of problems with that + AS + + TXT: Text RRs can be used for comments, postal address, or + similar notes under an AS name. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT Mapping AS Numbers into the DNS + + +4. Security Considerations + + This document concerns a means to map Internet Autonomous System + numbers into the Domain Name System (DNS) so that DNS can be used to + provide secure distribution of Autonomous System's public keys. The + security of the resulting AS to key mapping is dependent on the + security of the DNS security extensions and of the DNS zone where the + key is stored. + + The most obvious way of using the AS keys retrieved from DNS is to + authenticate communications with a directly connected AS. However, + this does not prove that any routing information exchanged is + actually correct and note that routing information communicated over + this secured path may be indirectly forwarded from or to yet other + ASs. + + + +References + + [RFC 1034] - Domain Names - Concepts and Facilities, P. Mockapetris, + November 1987 + + [RFC 1035] - Domain Names - Implementation and Specifications, P. + Mockapetris, November 1987. + + [RFC 1771] - Y. Rekhter, T. Li, "A Border Gateway Protocol 4 (BGP- + 4)", 03/21/1995. + + [RFC 2065] - Domain Name System Security Extensions, D. Eastlake, C. + Kaufman, January 1997. + + + +Author's Address + + Donald E. Eastlake 3rd + CyberCash, Inc. + 318 Acton Street + Carlisle, MA 01741 USA + + Telephone: +1 508 287 4877 + +1 703 620-4200 (main office, Reston, VA) + FAX: +1 508 371 7148 + EMail: dee@cybercash.com + + + + + + + +Donald E. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT Mapping AS Numbers into the DNS + + +Expiration and File Name + + This draft expires January 1998. + + Its file name is draft-ietf-dnssec-as-map-05.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 9] + diff --git a/doc/expired/draft-ietf-dnssec-indirect-key-01.txt b/doc/expired/draft-ietf-dnssec-indirect-key-01.txt new file mode 100644 index 0000000000..a4804b79f6 --- /dev/null +++ b/doc/expired/draft-ietf-dnssec-indirect-key-01.txt @@ -0,0 +1,464 @@ + +INTERNET-DRAFT Indirect KEY RRs + November 1997 + Expires May 1998 + + + + Indirect KEY RRs in the Domain Name System + -------- --- --- -- --- ------ ---- ------ + + Donald E. Eastlake 3rd + + + +Status of This Document + + This draft, file name draft-ietf-dnssec-indirect-key-01.txt, is + intended to be become a Proposed Standard RFC. Distribution of this + document is unlimited. Comments should be sent to the DNSSEC mailing + list or to the author. + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + To learn the current status of any Internet-Draft, please check the + 1id-abstracts.txt listing contained in the Internet-Drafts Shadow + Directories on ds.internic.net (East USA), ftp.isi.edu (West USA), + nic.nordu.net (North Europe), ftp.nis.garr.it (South Europe), + munnari.oz.au (Pacific Rim), or ftp.is.co.za (Africa). + + + +Abstract + + RFC 2065 defines a means for storing cryptogrpahic public keys in the + Domain Name System. An additional code point is defined for the KEY + resource record (RR) algorithm field to indicate that the key itself + is not stored in the KEY RR but is pointed to by the KEY RR. + Encodings to indicate different types of key and pointer formats are + specified. + + + + + + + + +Donald E. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT Indirect KEY RRs + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + + 2. The Indirect KEY RR Algorithm...........................4 + 2.1 The Target Type Field..................................4 + 2.2 The Target Algorithm Field.............................5 + 2.3 The Hash Fields........................................5 + + 3. Performance Considerations..............................7 + 4. Security Considerations.................................7 + + References.................................................8 + Author's Address...........................................8 + Expiration and File Name...................................8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT Indirect KEY RRs + + +1. Introduction + + The Domain Name System (DNS) security extensions [RFC 2065] provide + for the general storage of public keys in the domain name system via + the KEY resource record (RR). These KEY RRs are used in support of + DNS security and may be used to support other security protocols. + KEY RRs can be associated with users, zones, and hosts or other end + entities named in the DNS. + + For reasons given below, in many cases it will be desireable to store + a key or keys elsewhere and merely point to it from the KEY RR. + Indirect key storage makes it possible to point to a key service via + a URL, to have a compact pointer to a larger key or set of keys, to + point to a certificate either inside DNS [see draft-ietf-dnssec- + certs-*.txt] or outside the DNS, and where appropriate, to store a + key or key set applicable to many DNS entries in some place and point + to it from those entries. + + However, to simplify DNSSEC implementation, this technique MUST NOT + be used for KEY RRs used in for verification in DNSSEC. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT Indirect KEY RRs + + +2. The Indirect KEY RR Algorithm + + Domain Name System (DNS) KEY Resource Record (RR) [RFC 2065] + algorithm number 252 is defined as the indirect key algorithm. This + algorithm MAY NOT be used for zone keys in support of DNS security. + All KEYs used in DNSSEC validation must be stored directly in the + DNS. + + When the algorithm byte of a KEY RR has thae value 252, the "public + key" portion of the RR is formated as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | target type | target alg. | hash type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | hash size | hash (variable size) / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ + | / + / pointer (varible size) / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + + + +2.1 The Target Type Field + + Target type specifies the type of the key containing data being + pointed at. + + Target types 0 and 65535 are reserved. + + Target type 1 indicates that the pointer is a domain name from which + KEY RRs [RFC 2065] should be retrieved. Name compression in the + pointer field is prohibited. + + Target type 2 indicates that the pointer is a null terminated + character string which is a URL [RFC 1738]. For exisiting data + transfer URL schemes, such as ftp, http, shttp, etc., the data is the + same as the public key portion of a KEY RR. (New URL schmes may be + defined which return multiple keys.) + + Target type 2 indicates that the pointer is a domain name from which + CERT RRs [draft-ietf-dnssec-certs-*.txt] should be retrieved. Name + compression in the pointer field is prohibiited. + + Target type 3 indicates that the pointer is a null terminated + character string which is a URL [RFC 1738]. For exisiting data + transfer URL schemes, such as ftp, http, shttp, etc., the data is the + same as the entire RDATA portion of a CERT RR [draft-ietf-dnssec- + + +Donald E. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT Indirect KEY RRs + + + certs-*.txt]. (New URL schmes may be defined which return multiple + such data blocks.) + + Target type 4 indicates that the pointer is a null terminated + character string which is a URL [RFC 1738]. For exisiting data + transfer URL schemes, such as ftp, http, shttp, etc., the data is a + PKCS#1 format key. (New URL schmes may be defined which return + multiple keys.) + + The target types 5 through 255 are available for assignment by IANA. + + Target type 256 through 511 (i.e., 256 + n) indicate that the pointer + is a null terminated character string which is a URL [RFC 1738]. For + exisiting data transfer URL schemes, such as ftp, http, shttp, etc., + the data is a certificate of the type indicated by a CERT RR [draft- + ietf-dnssec-certs-*.txt] certificate type of n. That is, target + types 257, 258, and 259 are PKIX, SPKI, and PGP certificates and + target types 509 and 510 are URL and OID private certificate types. + (New URL schmes may be defined which return multiple such + certificates.) + + Target types 512 through 65534 are available for assignment by IANA. + + + +2.2 The Target Algorithm Field + + The algorithm field is as defined in RFC 2065. if non-zero, it + specifies the algorithm type of the target key or keys pointed. If + zero, it does not specify what algorithm the target key or keys apply + to. + + + +2.3 The Hash Fields + + If the indirecting KEY RR is retrieved from an appropriately secure + DNS zone with a resolver implementing DNS security, then there would + be a high level of confidence in the entire value of the KEY RR + including any direct keys. This may or may not be true of any + indirect key pointed to. If that key is embodied in a certificate or + retrieved via a secure protocol such as SHTTP, it may also be secure. + But an indirecting KEY RR could, for example, simply have an FTP URL + pointing to a binary key stored elsewhere, the retrieval of which + would not be secure. + + The hash option in algorithm 252 KEY RRs provides a means of + extending the security of the indirecting KEY RR to the actual key + material pointed at. By inclduing a hash in a secure indirecting RR, + this secure hash can be checked against the hash of the actual keying + + +Donald E. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT Indirect KEY RRs + + + material + + Type Hash Algorithm + ---- -------------- + 0 indicates no hash present + 1 MD5 [RFC 1321] + 2 SHA-1 + 3 RIPEMD + 4-254 available for assignment + 255 reserved + + The hash size field is an unsigned octet count of the hash size. For + some hash algorithms it may be fixed by the algorithm choice but this + will not always be the case. For example, hash size is used to + distinguish between RIPEMD-128 (16 octets) and RIPEMD-160 (20 + octets). If the hash algorithm is 0, the hash size MUST be zero and + no hash octets are present. + + The hash field itself is variable size with its length specified by + the hash size field. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT Indirect KEY RRs + + +3. Performance Considerations + + With current public key technology, an indirect key will sometimes be + shorter than the keying material it points at. This may improve DNS + permformace in the retrieval of the initial KEY RR. However, an + additional retrieval step then needs to be done to get the actualy + keying material which must be added to the overall time to get the + public key. + + + +4. Security Considerations + + The indirecting step of using an indirect KEY RR adds complexity and + additional steps where security could go wrong. If the indirect key + RR was retrieved from a zone that was insecure for the resolver, you + have no security. If the indirect key RR, although secure itself, + point to a key which can not be securely retrieved and is not + validatated by a secure hash in the indirect key RR, you have no + security. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT Indirect KEY RRs + + +References + + PKCS#1 + + RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", + STD 13, November 1987. + + RFC 1035 - P. Mockapetris, "Domain Names - Implementation and + Specifications", STD 13, November 1987. + + RFC 1321 - R. Rivest, "The MD5 Message-Digest Algorithm", April 1992. + + RFC 1738 - T. Berners-Lee, L. Masinter & M. McCahill, "Uniform + Resource Locators (URL)", December 1994. + + RFC 2065 - D. Eastlake, C. Kaufman, "Domain Name System Security + Extensions", 01/03/1997. + + draft-ietf-dnssec-certs-*.txt + + + +Author's Address + + Donald E. Eastlake 3rd + CyberCash, Inc. + 318 Acton Street + Carlisle, MA 01741 USA + + Telephone: +1 978 287 4877 + +1 703 620-4200 (main office, Reston, VA) + FAX: +1 978 371 7148 + EMail: dee@cybercash.com + + + +Expiration and File Name + + This draft expires May 1998. + + Its file name is draft-ietf-dnssec-indirect-key-01.txt. + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 8] + diff --git a/doc/expired/draft-ietf-dnssec-key-handling-00.txt b/doc/expired/draft-ietf-dnssec-key-handling-00.txt new file mode 100644 index 0000000000..919b0be3bf --- /dev/null +++ b/doc/expired/draft-ietf-dnssec-key-handling-00.txt @@ -0,0 +1,473 @@ +Domain Name System Security WG Edward Lewis +INTERNET DRAFT Olafur Gudmundsson + Trusted Information Systems + November 21, 1997 + + + + Zone KEY RRSet Signing Procedure + + + +0.0 Status of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + 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.'' + + To learn the current status of any Internet-Draft, please check + the ``1id-abstracts.txt'' listing contained in the Internet- + Drafts Shadow Directories on ftp.is.co.za (Africa), + ds.internic.net (US East Coast), nic.nordu.net (Europe), + ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). + + This Internet Draft expires on 21 May 1998. + + Please send comments to the authors and dns-security@tis.com. + +1.0 Abstract + + Under the security extensions to DNS, as defined in RFC 2065 and + RFC 2137, a secured zone will have a KEY RRSet associated with + the domain name at the apex of the zone. This document covers + the manner in which this RRSet is generated, signed, and inserted + into the name servers. + +1.5 Change Log + + Version 01 - draft-lewis-dnskey-handling-01.txt: + + Minor editorial changes. + Added paragraph in section 3.1 elaborating on off-net versus off- + net signing. + Added paragraph in section 4.0, step 2, requiring proof of + private key ownership. + Added Change Log section. + + Version 02 - draft-ietf-dnssec-key-handling-00.txt: + Minor editorial changes. + Dynamic update reference changed from a draft to an RFC. + +Expires November 21, 1997 [Page 1] + +Internet Draft May 21, 1998 + +2.0 Introduction + + Under the security extensions to DNS, as defined in RFC 2065 + [RFC2065] and [RFC2137], a secured zone will have a KEY RRSet + associated with the domain name at the apex of the zone. At + least one of the KEY RR's will be a public key that is used + to verify SIG RR's in the zone. The SIG(KEY) RR covering this + RRSet must itself be signed by some other domain name, "some + other" being required to build a chain of trusted verifications. + (The alternative to requiring a different signer is to have + each name server hold all the public keys it will ever need in + a trusted place, which is not a scaleable solution.) A key + administration protocol external to the existing DNS protocol + is needed to produce the signature of the KEY RR's and to get + it into the DNS name servers. + + As this is a first document on the subject, the "administration + protocol" will be described more as an "administrative procedure + or method." + + The challenge is to design a secure procedure for handling the + unsigned public keys as they move from the place of generation + to a place where they are signed. The procedure must also + eventually lead to the insertion of the keys and signature into + the zone master file on a primary name server. The place of + generation and the place of the signing are recommended to be + disconnected from the Internet in order to protect the private + keys produced and/or used in the procedure. The two locations + may also be disconnected from each other. + + The security of the public keys in this procedure is crucial to + the operation of the secure zone. An attack in which a false + public key is submitted for signing would enable a masquerade of + the true zone data by the attacker. + +2.1 Terminology convention + + In the literature on DNS, different terms are used to describe + the relationship of zones. "Super-zone and sub-zone," "parent + and child," and "delegator and delegatee" each refer to two + zones joined at a "zone cut." For each of the set of terms, the + former is the zone above the cut point, the latter is below the + cut point. In this document, we use the terms delegator and + delegatee. + +3.0 DNSSEC Configuration Variants + + There are a number of variants in the way in which DNSSEC can be + configured that impact a discussion of key management. The + discussion in section 4.0 will assume a nominal configuration + (defined in section 3.4) to simplify this document. In this + section, pertinent configuration decisions are described, and + how the choices make a particular configuration differ from the + so-called nominal configuration. + +Expires November 21, 1997 [Page 2] + +Internet Draft May 21, 1998 + +3.1 Off/On-Net Signing + + In DNSSEC the configuration of DNS operations and signing fall + into two categories. The most secure is the use of an "off-net" + signer. The alternative is to use an "on-net" signer. These + two alternatives correspond to the Mode A and Mode B distinction + in UPDATE. (Mode A's initial zone signing is performed off- + net.) + + The decision whether off-net or on-net signing is used is based + upon the risk assessment of the site's network management. An + on-net key is more vulnerable to attack than an off-net key just + by being present somewhere on the network. Off-net signing is + recommended for tighter security. Being behind a firewall might + be deemed insufficient if the administration does not trust the + protection in other parts of the network. This is matter of + choice for sites. + + In off-net signing, the machinery performing the act of creating + the keyed signature is not reachable from the network the DNS + (name server set) is serving. I.e., there is no direct + mechanism for data transfer from the signing machine to a name + server. Without loss of generality, the DNS served network may + be thought of as the Internet. + + The off-net signer need not be a stand-alone machine it may be + on an "air-gapped" (not physically connected) network. This + network may be just a very local network (i.e., within one + office or machine room), reserved for sensitive network + administration use. For the purposes of this document, this + will be labeled the back-room network (even if just a stand- + alone machine is on it). + + The back-room network needs to be able to get information from + the Internet to derive the unsigned zone master files (among + other things). The back-room network generates the signed + files, which are inserted to the Internet DNS servers. The + mechanism to carry this out may be removable "static" media. + + ADDED for draft-01: + + (The preceding discussion focuses on the original signing of a + zone. Dynamic update requests for both off-net and on-net + situations are signed on-net, in the case of off-net, a + different key is used to sign the updates. The choice of off- + net or on-net is a comparison of the administrative effort to + maintain off-net signing versus the risk of an on-net private- + key compromise.) + + For the purposes of this document, if off-net signing is used, + we assume key generation is also performed off-net. + + On-net signing simply means the signer is accessible over the + Internet. If the back-room network exists, it is connected to + +Expires November 21, 1997 [Page 3] + +Internet Draft May 21, 1998 + + the Internet. In the procedures described below, the steps used + to transfer information from the Internet to the back-room + network are obviously unnecessary. + +3.2 Relationship of Zone and Key Signer + + In a nominal state, a zone's delegator will also be the signer + of the delegated zone's KEY RR set. E.g., for a zone named + "xz.test." with an NS RRSet at that name, the domain name + "test." would be the delegator of "xz.test." and signer of its + KEY RRSet. However, there may be cases in which some other + entity is the signer. + + The role and composition of the "other entity" is not yet + defined, and may or may not ever be defined. This entity has + been referred to as a Signing Authority, whose sole purpose is + to sign records for clients. This may be more or less a + certification authority for DNS KEY RRSets. For the purposes of + this document, this entity will be assumed to be the delegating + zone, and it will be referred to as the "signing entity." + +3.3 Name Server Topology + + The separation between two delegated zones may mean that the two + do not share any name servers, such as most names under .COM and + .COM itself. In general, the set of name servers for two zones + may overlap. This document will focus on cases in which zones + do not share name servers or other facilities. + + If the two zones share the same name servers they likely will + share the mechanism for the generation of zone keys. In this + case, the transfer of information between the zones becomes a + moot point because the problem may degenerate into accessing a + file in a shared file system. For zones sharing a back-room + network, the data for the two zones (between the off-net and on- + net machines) can be transferred together. + +3.4 The Nominal Configuration + + The nominal configuration used within the context of this + document is that the zones involved (one being the zone + generating the keys and the other zone performs the signing) + each employ off-line signing, and employ distinct sets of name + servers. In addition, the zone performing the signing is the + zone above the delegation point that creates the zone which is + generating and requesting the signing of its keys. + +4.0 Key Signing Protocol/Procedure + + The steps described here assume the nominal configuration in + section 3.4. In some configurations, the steps listed in this + section may degenerate into null or very simple operations. + Additionally, some steps can be carried out in parallel even + with the nominal configuration, so the strict ordering described + +Expires November 21, 1997 [Page 4] + +Internet Draft May 21, 1998 + + here need not be followed. + + Step 0. A delegation needs to be instituted. A means to + authenticate both the delegator to the delegatee and vice versa + is also needed. + + A delegation may only need to be created once. A NS RRSet and a + KEY RRSet must be installed by the delegating zone. Until a key + pair is generated the KEY RRSet will have a null zone key, + indicating that the delegated zone is initially unsecured. + + Instituting means to authenticate the participants must occur + initially, and then again if the means of authentication (e.g., + a secret key) is ever compromised. + + How a delegation comes about is a subject for registries and/or + local network administration policies and procedures. These + groups should be aware of the responsibilities entailed in + instituting DNS security, especially the need for an active + recurring relationship, as the remaining steps describe. + + It is assumed that at some point, the delegated zone acquires a + trusted public key(s) for at least one other entity. This could + be for root, the delegating zone, or for a signing authority. + These keys may be DNS zone keys or keys for some application, + e.g., trusted mail. This will enable the use of other secure + services to achieve the following steps. Selecting the services + may be within the scope of this document, but which should be + selected is still open for discussion. + + Step 1. Delegated zone generates zone keys. A new pair may be + generated without changing the other pairs in use (assuming + others exist). + + Step 2. The delegated zone sends keys to the signing entity. + All of the public key information, encoded in such a way that + the KEY RR's can be generated from it, crosses from the back- + room net to the Internet, and is shipped securely to the signing + entity. (Implementing "securely" is still an open issue.) It + is important that both the delegated zone and the signing entity + authenticate themselves to each other. + + All public keys must be included, both newly generated and those + in current use. Keys are retired through omission. + + ADDED for draft-01: + + The delegated zone must prove ownership of the private keys + corresponding to each public key. This may be done by signing + the collection of public key data with each of the private keys. + Thus the submission would consist of one copy of each public key + and as many signatures as there were public keys. (For example, + submitting five public keys would require sending all five plus + five signatures.) This signing is only done to prove the + +Expires November 21, 1997 [Page 5] + +Internet Draft May 21, 1998 + + ownership of the private key, not for authentication. + + Step 3. The signing entity signs the key set. The algorithm + used to sign the KEY RRSet need not be the same as the + algorithm(s) for which the keys were generated. + + Step 4. The delegated zone receives KEY RRSet and SIG(KEY) RR + from the signing entity. The delegated zone must verify the + keys and signature locally. The zone must also verify that the + KEY RRSet is identical to the set of keys submitted for + signature in step 2, to protect against a masquerader from + submitting keys for signature. Once the records are signed, + there is no requirement for enhanced security while transmitting + the information across the Internet because the DNS signature + provides non-repudiation. + + Step 5. Delegating zone gets the KEY RRSet and SIG(KEY) RR. + The KEY RRSet and the SIG(KEY) RR are sent from the signing + entity to the delegating zone's master files and optionally the + name servers. In the nominal case, the signing entity and the + delegating zone are one in the same, so this may be a trivial + step. (The latter is to ensure the public key will be available + for verifications once the signing process - step 7 - is + finished.) + + Step 6. The delegating zone signs its zone data. This step may + be done in parallel with steps 2-5. Note: signing a zone does + not require that a new key pair be generated. + + Step 7. The new zone data enters DNS. The KEY RRSet, SIG(KEY + RR) and the rest of the signed zone data and signatures traverse + from the back-room network and are inserted into the DNS primary + name server serving the Internet side. + + Steps 1 through 7 are repeated whenever a new key pair is + required. Note that the signing in step 6 may not sign all + records; some records may have signature records from older keys + that are sufficient. + +5.0 Resigning a KEY RRSet + + When the delegating zone resigns itself, the KEY RRSet of a + delegated zone may be resigned. In this case, the newly created + SIG(RR) must be sent to the delegatee for inclusion. + + The signing of a delegatee's keys in the manner of the previous + paragraph may be prompted by a request from the delegatee. A + SIG(RR) record may be approaching its expiration date, although + the KEY RRSet it is verifying has not changed. + +6.0 Open Issues + + This section is intentionally left undeveloped to encourage more + feedback. + +Expires November 21, 1997 [Page 6] + +Internet Draft May 21, 1998 + + + Timing of steps, required response times. + + The signing cycles of zones will likely be out of phase of each + other. If they were not, then there would be "signing crunches" + which would add variability to the spacing of events in the + procedure. One issue is how this should be addressed. Should + there be a recommended limit on signing entity's response? + Should this even be specified? + + Can secure e-mail be used? Perhaps, and discussions to this + effect have occurred, using secure e-mail as a conduit for (at + least) the unsigned keys. + +7.0 Operational Considerations + + A widely delegated zone, such as .COM, or a zone publishing KEY + RR's for others, such as a large Internet access provider, + should expect a huge performance impact in signing the KEY + RRSets for it delegations. Running on a Pentium 166MHz + computer, simply signing the current .COM records, requires 40 + hours. (Measured in January 1997.) This covers just the NXT + RRSets and a few other records. Having to sign a KEY RRSet for + each member of the zone will require about the same computing + resources, and much more overhead in the handling of the + individual KEY RRSets. + +8.0 Security Considerations + + This document discusses a procedure for handling the keys used + by DNS for its security and the keys for applications employing + DNS for key distribution. Once in DNS, keys are protected by + the presence of a keyed hash, which can be used to verify the + source and integrity of the public key data. During the process + described here, the keyed hash is not yet present, leaving the + keys vulnerable to modification. The security of this process + is crucial to the usefulness of DNS as a key distribution + mechanism. At this point many issue remain to be resolved, a + thorough security analysis of the process is premature. + +9.0 References + + [RFC2065] "Domain Name System Security Extensions," D. Eastlake, + 3rd, and C. Kaufman + http://ds.internic.net/rfc/rfc2065.txt + + [RFC2137] "Secure Domain Name System Dynamic Update," D. + Eastlake, 3rd + http://ds.internic.net/rfc/rfc2137.txt + + + + + + +Expires November 21, 1997 [Page 7] + +Internet Draft May 21, 1998 + +10.0 Author's Addresses + + Edward Lewis Olafur Gudmundsson + Trusted Information Systems Trusted Information Systems + 3060 Washington Road 3060 Washington Road + Glenwood, MD 21738 Glenwood, MD 21738 + +1 301 854 5794 +1 301 854 5700 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires November 21, 1997 [Page 8] + + diff --git a/doc/expired/draft-ietf-dnssec-rollover-00.txt b/doc/expired/draft-ietf-dnssec-rollover-00.txt new file mode 100644 index 0000000000..4aab0f5de1 --- /dev/null +++ b/doc/expired/draft-ietf-dnssec-rollover-00.txt @@ -0,0 +1,521 @@ + +INTERNET-DRAFT DNSSEC Key Rollover + October 1998 + Expires April 1999 + + + + + Domain Name System (DNS) Security Key Rollover + ------ ---- ------ ----- -------- --- -------- + + Donald E. Eastlake 3rd, Mark Andrews + + + +Status of This Document + + This draft, file name draft-ietf-dnssec-rollover-00.txt, is intended + to be become a Proposed Standard RFC. Distribution of this document + is unlimited. Comments should be sent to the DNS security mailing + list or to the authors. + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + + + +Abstract + + Practical deployment of Domain Name System (DNS) security with good + cryptologic practice will involve large volumes of key rollover + traffic. A standard format and protocol for such messages is + specified. + + + + + + + + + +D. Eastlake 3rd, M. Andrews [Page 1] + + +INTERNET-DRAFT October 1998 DNSSEC Key Rollover + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Key Rollover Scenarios..................................3 + 3. Rollover Operation......................................4 + 3.1 Rollover to Parent.....................................4 + 3.2 Rollover to Children...................................5 + 4. Rollover NOTIFY.........................................6 + 5. Security Considerations.................................7 + + References.................................................8 + Authors Address............................................8 + Expiration and File Name...................................9 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd, M. Andrews [Page 2] + + +INTERNET-DRAFT October 1998 DNSSEC Key Rollover + + +1. Introduction + + The Domain Name System (DNS) [RFC 1034, RFC 1035] is the global + hierarchical replicated distributed database system for Internet + addressing, mail proxy, and other information. The DNS has been + extended to include digital signatures and cryptographic keys as + described in [draft-ietf-dnssec-secext2-*]. + + The principle security service provided for DNS data is data origin + authentication. The owner of each zone signs the data in that zone + with a private key known only to the zone owner. Anyone that knows + the corresponding public key can then authenticate that zone data is + from the zone owner. To avoid having to preconfigure resolvers with + all zone's public keys, keys are stored in the DNS with each zone's + key signed by its parent (if the parent is secure). + + To obtain high levels of security, keys must be periodically changed, + or "rolled over". The longer a private key is used, the more likely + it is to be compromised due to cryptanalysis, accident, or treachery + [draft-ietf-dnssec-secops-*.txt]. + + In a widely deployed DNS security system, the volume of update + traffic will be large. Just consider the .com zone. If only 10% of + its children are secure and change their keys only once a year, you + are talking about hundreds of thousands of new child public keys that + must be securely sent to the .com manager to sign and return with + their new parent signature. And when .com rolls over its private + key, it will needs to send hundreds of thousands of new signatures on + the existing child public keys to the child zones. + + The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" + in this document are to be interpreted as described in RFC 2119. + + + +2. Key Rollover Scenarios + + Although DNSSEC provides for the storage of other keys in the DNS for + a variety of purposes, DNSSEC zone keys are included solely for the + purpose of being retrieved to authenticate DNSSEC signatures. Thus, + when a zone key is being rolled over, the old public key should be + left in the zone, along with the addition of the new public key, for + as long as it will reasonably be needed to authenticate old + signatures that have been cached or are held by applications. If + DNSSEC were universally deployed and all DNS server's clocks were + synchronized and zone transfers were instantaneous etc., it might be + possible to avoid ever having duplicate old/new KEY RRsets but they + will be necessary in practical cases. Security aware DNS servers + decrease the TTL of secure RRs served as the expiration of their + authenticating SIG(s) approaches but some dithered fudge must + + +D. Eastlake 3rd, M. Andrews [Page 3] + + +INTERNET-DRAFT October 1998 DNSSEC Key Rollover + + + generally be left due to clock skew and to avoid massive load on + large zones due to the signatures on their entire contents expiring + simultaneously. + + Assume a zone with a secure parent and secure children wishes to role + over its KEY RRset. This RRset would probably be one KEY RR per + crypto algorithm used to secure the zone, but for this scenario, we + will simply assume it is one KEY RR. The old KEY RR and two SIG RRs + will exist at the apex of the zone and these RRs may also exist at + the leaf node for this zone in its parent. The contents of the zone + and the zone KEY RRs of its secure children will have SIGs under the + old key. + + The zone owner needs to communicate with its parent to obtain a new + parental signature covering both the old and new KEY RRs and covering + just the new KEY RR. It would probably want to obtain these in + advance so that it can install them at the right time along with its + new SIG RRs covering the content of the zone. Finally, it needs to + give new SIG RRs to its children that cover their KEY RRs if it has + these, or signal its children to ask for such SIG RRs. + + + +3. Rollover Operation + + Rollover operations use a DNS request syntactically identical to the + UPDATE request [RFC 2136] except that the operation is ROLLOVER which + is equal to TBD. Considerations for such request to the parent and + children of a zone are given in the subsections. + + [This draft does not currently consider cross-certification key + rollover.] + + + +3.1 Rollover to Parent + + A zone rolling over its KEY RRset sends a ROLLOVER command to the + parent. The Zone should be specified as the parent zone and no + Prerequisites are included. The Update section has the KEY RRset on + which the parent signature is requested along with the requesting + zone's SIG(s) under its old KEY(s) as RRs to be added to the parent + zone. The inception and expiration times in this SIG are the + requested inception and expiration times for the parent SIG. + + If the ROLLOVER command is erroneous or violates parental policy, an + Error response is returned. + + If the ROLLOVER command is OK and the parent can sign online, its + response may include the new parent SIG(s) in the Update section. + + +D. Eastlake 3rd, M. Andrews [Page 4] + + +INTERNET-DRAFT October 1998 DNSSEC Key Rollover + + + This response MUST be sent to the originator of the request. + + If the parent can not sign online, it should return a response with + an empty Update section and queue the SIG(s) calculation request. + This response MUST be sent to the originator of the request. + + Regardless of whether the server has sent the new signatures above, + it MUST, once it has calculated the new SIG(s), send a ROLLOVER to + the child zone using the DNS port (53) and the server selection + algorithm defined in RFC 2136, Section 4. This ROLLOVER reqeust + contains the KEY RRset that triggered it and the new SIG(s). This + downward ROLLOVER request is distinguished from those in Section 3.2 + below in that the Zone section is the parental zone. + + The reason for sending the ROLLOVER request regardless of whether the + new SIG RR(s) were sent in the original response is to provide an + indication to the operators of the zone in the event someone is + trying to hijack the zone. + + Although the parent zone need not hold or serve the child's key, the + ROLLOVER command MUST NOT actually update the parent zone. A later + UPDATE command can be used to actually put the new KEY into the + parent zone if desired and supported by parent policy. + + This document does not cover the question of parental policy on key + rollovers. Parents may have restrictions on how far into the future + they will sign KEY RRsets, what algorithms or key lengths they will + support, might require payment for the service, etc. The signing of + a future KEY by a parent is, to some extent a granting to the + controller of the child private key of future authoritative existence + even if the child zone ownership should change. The only effective + way of invalidating such future signed child public keys would be for + the parent to roll over its key(s), which might be an expensive + operation. + + + +3.2 Rollover to Children + + When a zone is going to rollover its key(s), it needs to re-sign the + zone keys of any secure children under its new key(s). + + If the parent holds the KEY RRset for the child (whether or not it + actually serves it from the parent zone), it can simply do a ROLLOVER + request to to child specifying the child as the Zone in the request + and the new SIG(KEY)s to be added in the Update section. The + inception and expiration times in the SIG(s) indicate the time during + which the parent will be utilizing the new parent key. It is up to + the child when and how it adds the new parental SIG(s). The ROLLOVER + request may optionally indicate the deletion of old parental SIG(s) + + +D. Eastlake 3rd, M. Andrews [Page 5] + + +INTERNET-DRAFT October 1998 DNSSEC Key Rollover + + + but SHOULD only do so if the corresponding key is being withdrawn by + the parent in advance of the expiration time in the old SIG(s). It + is up to the child when and how it deletes the old parental SIG(s). + Even if the expiration of the old SIG(s) equals the inception time of + the new SIG(s), the child should serve both signatures for a fudge + time to account for clock skew. + + A ROLLOVER request is used instead of an UPDATE because serves may + wish to support ROLLOVER via special techniques, such as notification + to the operator, even when they have not implemented UPDATE. With + adequate advance notice, even manual cut and paste editing of the + master file and restarting of a DNS server process could work. + + If the parent does not retain knowledge of the child KEY RRset, then + the parent simply notifies the child via a ROLLOVER NOTIFY (see + Section 4 below) that the parent KEY(s) have changed. The child then + proceeds to do an upward ROLLOVER request to obtain the new parental + SIG(s). (This requires that a different method, such as TSIG, be + used to secure such ROLLOVER requests since we are assuming the + parent does not have authoritative knowledge of the child public key. + See Section 5 below.) + + The NOTIFY technique MAY also be used by parents who retain knowledge + of their children's KEY RRsets. + + + +4. Rollover NOTIFY + + A ROLLOVER NOTIFY informs a child zone that the parent zone want it + to resubmit its keys for resigning. + + A ROLLOVER NOTIFY MUST be signed and if not signed a BADAUTH response + generated. + + A ROLLOVER NOTIFY is a NOTIFY reqeust [RFC 1996] that has a QTYPE of + SIG and the owner name of the child zone. The answer section is + empty. + + The ROLLOVER NOTIFY can be sent to any of the nameservers for the + child using the nameserver selection algorithm defined in RFC 2136, + Section 4. + + Nameservers for the child zone receiving a ROLLOVER NOTIFY query will + forward the ROLLOVER NOTIFY in the saem manner as an UPDATE is + forwarded. + + Unless the master server is configured to initiate an automatic + ROLLOVER it MUST seek to inform its operators that a ROLLOVER NOTIFY + request has been received. This could be done by a number of methods + + +D. Eastlake 3rd, M. Andrews [Page 6] + + +INTERNET-DRAFT October 1998 DNSSEC Key Rollover + + + including generating a log message, generating an email request to + the child zone's SOA RNAME or any other method defined in the + server's configuration for the zone. The default should be to send + mail to the zone's SOA RNAME. Care should be taken to rate limit + these message so prevent them being used to facilitate a denial of + service attack. + + Once the message has been sent (or suppressed) to the child zone's + administrator the master server for the child zone is free to respond + to the ROLLOVER NOTIFY request. + + + +5. Security Considerations + + The security of ROLLOVER or UPDATE requests is essential, otherwise + false children could steal parental authorization or a false parent + could cause a child to install an invalid signature on its zone key, + etc. + + A ROLLOVER request can be authentication by request SIG(s)under the + old zone KEY(s) of the requestor [draft-ietf-dnssec-secext2-*.txt]. + The response SHOULD have transaction SIG(s) under the old zone KEY(s) + of the responder. (This public key security could be used to + rollover a zone to the unsecured state but at that point it would + generally not be possible to roll back without manual intervention.) + + Alternatively, if there is a prior arrangement between a child and a + parent, ROLLOVER requests and responses can be secured and + authenticated using TSIG [draft-ietf-dnssec-tsig-*.txt]. (TSIG + security could be used to rollover a zone to unsecured and to + rollover an unsecured zone to the secured state.) + + A server that implements online signing SHOULD have the ability to + black list a zone and force manual processing or demand that a + particular signature be used to generate the ROLLOVER request. This + it to allow ROLLOVER to be used even after a private key has been + compromised. + + + + + + + + + + + + + + +D. Eastlake 3rd, M. Andrews [Page 7] + + +INTERNET-DRAFT October 1998 DNSSEC Key Rollover + + +References + + [RFC 1034] - P. Mockapetris, "Domain names - concepts and + facilities", 11/01/1987. + + [RFC 1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + [RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", August 1996. + + [RFC 2136] - Dynamic Updates in the Domain Name System (DNS UPDATE). + P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. + + [draft-ietf-dnsind-tsig-*.txt] + + [draft-ietf-dnssec-update2-*.txt] + + [draft-ietf-dnssec-secext2-*.txt] + + [draft-ietf-dnssec-secops-*.txt] + + + +Authors Address + + Donald E. Eastlake 3rd + IBM + 318 Acton Street + Carlisle, MA 01741 USA + + Telephone: +1 978-287-4877 + +1 914-784-7913 + FAX: +1 978-371-7148 + EMail: dee3@us.ibm.com + + + Mark Andrews + Internet Software Consortium + 1 Seymour Street + Dundas Valley, NSW 2117 + AUSTRALIA + + Telephone: +61-2-9871-4742 + Email: marka@isc.org + + + + + + + +D. Eastlake 3rd, M. Andrews [Page 8] + + +INTERNET-DRAFT October 1998 DNSSEC Key Rollover + + +Expiration and File Name + + This draft expires in April 1999. + + Its file name is draft-ietf-dnssec-rollover-00.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd, M. Andrews [Page 9] diff --git a/doc/expired/draft-ietf-dnssec-secfail-00.txt b/doc/expired/draft-ietf-dnssec-secfail-00.txt new file mode 100644 index 0000000000..67b22bb7e5 --- /dev/null +++ b/doc/expired/draft-ietf-dnssec-secfail-00.txt @@ -0,0 +1,291 @@ +Internet-Draft B. Wellington, O. Gudmundsson +DNSSEC Working Group TISLabs + August 1998 + + + + Intermediate Security Failures in DNSSEC + + + + Status of this Memo + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + 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." + + To view the entire list of current Internet-Drafts, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net + (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au + (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US + West Coast). + + Distribution of this memo is unlimited. + + + + Abstract + + This document identifies the situations where a signature + verification fails in a recursive security aware DNS server, and + how DNS servers should handle these cases, and the errors that + should be reported to DNS resolvers. This document proposes a new + error to be returned by DNSSEC capable servers. + + A DNSSEC server acting as a recursive server MUST validate the + signatures on RRsets in a response it passes on; this draft + addresses the case when the data it receives fails signature + + + + + + + + + + + +Wellington, Gudmundsson Expires February 1999 [Page 1] + + +Internet-Draft dnssec-secfail-00.txt August 1998 + + + verification. The end resolver must be notified of this occurence + in such a way that it will not confuse it with another error. + + + + 1. Description + + A DNS [RFC1034, RFC1035] transaction is defined by a query/response + pair. The resolver (client) sends a query to a name server. The + name server will respond if it contains the necessary information, + or forward the request to an authoritative server. The response + consists of the answer to the query, as well as authority records + showing that the response came from a valid source, and additional + records. + + DNSSEC [RFC2065, SECEXT2] adds security to the DNS protocol. Each + RRset (set of DNS records with the same name/class/type) is + digitally signed, and the signature is verified by any server or + resolver who receives it. The receiver must therefore have a valid + key for verifying that data, as specified by a name/footprint pair. + A key's validity is determined by recursively verifying that it was + signed by a valid key; this recursion ends when a trusted key is + reached. Trusted keys must be obtained out of band, for example + through manual configuration. + + Consider a recursive name server (R) that forwards a query to + another server (S). R receives an response from S, and attempts to + verify the included RRsets using a key that it trusts. Note that + this key may either be implicitly trusted or authenticated. The + signature verification fails for one or more RRsets in the answer + or authority section. The name server must communicate this error + in its response. To do this, a new return code (RCODE) will be + used, denoted SECFAIL (value TBD). + + When a resolver receives a DNS response with an RCODE of SECFAIL, + that one of the following is true: + 1) server S has sent invalid data to server R. + 2) the data has been corrupted (possibly maliciously) between R and S. + 3) server R has preconfigured S's key incorrectly. + 4) There is more than one KEY with the same footprint and algorithm + for that name, and server R contains one different from the one used + by S to sign the data. This should not happen. + + None of the current RCODE values sufficiently describe the case + where the data exists, but cannot be successfully retrieved and/or + transmitted. It is the responsibility of both R and the resolver + to attempt to identify the source of the problem. + + + + + +Wellington, Gudmundsson Expires February 1999 [Page 2] + + +Internet-Draft dnssec-secfail-00.txt August 1998 + + + 2. Proposal + + When the recursive name server (R) fails to verify a signed RRset + in the answer or authority section of a response that it receives, + it sets the RCODE of the response to SECFAIL before forwarding the + response to the entity that originated the query. There are + several possible modifications that could be made to the data by R: + 1) all records could be passed unchanged + 2) all records could be dropped + 3) only the records that failed verification could be dropped + 4) the SIGs of all records that failed verification could be dropped + A solution to this problem has not yet been decided. + + If R receives a response with SECFAIL set, it does no processing on + the response, simply forwarding it if necessary. An intelligent + resolver MAY use additional queries to determine which of the + RRsets was invalid. The ERR record [ERR] or EDNS [EDNS] could also + be used to provide a more fine-grained description of the error. + + When R fails to verify an RRset, it can determine whether or not + the key used has successfully verified other data (a flag or + timestamp could be stored along with the key). If it has, then the + key has not been misconfigured, and the error is due to data + corruption (possibly malicious) or a data error on the + authoritative server (S). R cannot further quantify the problem. + If the key has never successfully verified data, then the problem + may be a misconfigured key, or it could be due to malicious + corruption or a very unreliable network. In any case, this should + be logged, and the maintainer of R should determine (out of band) + whether the preconfigured key is erroneous. R MAY elect to retry + the query; this would succeed if the error was due to transient + network problems or a partial attack. Unless a retransmission + yields success, R should always send a response with SECFAIL set. + + + + 3. Limitations + + If the path between a resolver and an authoritative server is + several hops, there is no way to determine at which recursive + server the SECFAIL error occurred. The data will be passed through + successive servers unchanged. + + There is no way to distinguish a server continuously reporting + invalid data from an active attack. For instance, if a server has + an preconfigured key that is invalid, all queries using that key + will fail. An attack could easily simulate this behavior. There + is no way to split SECFAIL into more specific errors, since the + + + + +Wellington, Gudmundsson Expires February 1999 [Page 3] + + +Internet-Draft dnssec-secfail-00.txt August 1998 + + + cause of the error cannot always be determined. + + + + 4. Security Considerations + + Unless transaction signatures of some form are used [RFC2065, + TSIG], the RCODE field of a DNS response is not protected, so the + SECFAIL RCODE could be added or stripped by an attacker. + + + + 5. References + + +[EDNS] P. Vixie, "Extensions to DNS (EDNS)", Internet + Draft , March 1998 + + +[ERR] R. Watson, O. Gudmundsson, "Error Record (ERR) + for DNS" Internet Draft , March 1998 + + +[RFC1034] P. Mockapetris, "Domain Names - Concepts and + Facilities", RFC 1034, ISI, November 1987. + + +[RFC1035] P. Mockapetris, "Domain Names - Implementation + and Specification", RFC 1034, ISI, November 1987. + + +[RFC2065] D. Eastlake, C. Kaufman, "Domain Name System + Security Extensions", RFC 2065, January 1997. + + +[SECEXT2] D. Eastlake, "Domain Name System Security Exten­ + sions", Internet Draft , April 1998. + + +[TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, "Secret + Key Transaction Signatures for DNS (TSIG)" Inter­ + net Draft , June + 1998. + + + + + + + +Wellington, Gudmundsson Expires February 1999 [Page 4] + + +Internet-Draft dnssec-secfail-00.txt August 1998 + + +6. Author address + + Brian Wellington, Olafur Gudmundsson + TIS Labs at Network Associates + 3060 Washington Road + Glenwood, MD 21738 + +1 301 854 6889 + bwelling@tis.com, ogud@tis.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Wellington, Gudmundsson Expires February 1999 [Page 5] + + diff --git a/doc/expired/draft-ietf-dnssec-simple-update-01.txt b/doc/expired/draft-ietf-dnssec-simple-update-01.txt new file mode 100644 index 0000000000..83b8c9c47b --- /dev/null +++ b/doc/expired/draft-ietf-dnssec-simple-update-01.txt @@ -0,0 +1,278 @@ + +DNSSEC Working Group Brian Wellington (TISLabs) +INTERNET-DRAFT February 1999 + + + +Updates: RFC 2065, RFC 2136, [TSIG] +Replaces: RFC 2137, [update2] + + + + Simple Secure Domain Name System (DNS) Dynamic Update + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + 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.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + This draft proposes an alternative method for performing secure + Domain Name System (DNS) dynamic updates. The method described here + is both simple and flexible enough to represent any policy decisions. + Secure communication based on request/transaction signatures [TSIG] + is used to provide authentication and authorization. + + + + + + + + + +Expires August 1999 [Page 1] + +INTERNET-DRAFT Simple Secure Dynamic Update February 1999 + + +1 - Introduction + +Dynamic update operations for the Domain Name System are defined in +[RFC2136], but no mechanisms for security have been defined. Request +and transaction signatures are defined in [TSIG]. + +Familiarity with the DNS system [RFC1034, RFC1035] as well as the +proposals mentioned above is assumed. Familiarity with DNS Security +[RFC2065, secext2] is assumed in section (4). + +1.1 - Overview of DNS Dynamic Update + +DNS dynamic update defines a new DNS opcode and a new interpretation of +the DNS message if that opcode is used. An update can specify +insertions or deletions of data, along with prerequisites necessary for +the updates to occur. All tests and changes for a DNS update request +are restricted to a single zone, and are performed at the primary server +for the zone. The primary server for a dynamic zone must increment the +zone SOA serial number when an update occurs or before the next +retrieval of the SOA. + +1.2 - Overview of DNS Transaction Security + +[TSIG] provides a means for two processes that share a secret key to +authenticate DNS requests and responses sent between them. This is done +by appending TSIG digital signature (keyed hash) RRs to those messages. +Keyed hashes are simple to calculate and verify, and do not require +caching of data. + +2 - Authentication + +TSIG records are attached to all secure dynamic update messages. This +allows the server to verifiably determine the originator of the message. +It can then use this information in the decision of whether to accept +the update. DNSSEC SIG records may be included in an update message, +but MAY NOT be used for authentication purposes in the update protocol. +If a message fails the authentication test due to an unauthorized key, +the failure is indicated with the REFUSED rcode. Other TSIG or dynamic +update errors are returned unchanged. + + + + + + + + + + + + +Expires August 1999 [Page 2] + +INTERNET-DRAFT Simple Secure Dynamic Update February 1999 + + +3 - Policy + +All policy is dictated by the server and is configurable by the zone +administrator. The server's policy defines criteria which determine if +the key used to sign the update is permitted to update the records +requested. By default, a key cannot make any changes to the zone; the +key's scope must be explicitly enabled. There are several reasons that +this process is implemented in the server and not the protocol (as in +[RFC2137, update2], where the signatory bits of KEY records may define +the policy). + +3.1 - Flexibility + +Storing policy in the signatory fields of DNS keys is overly +restrictive. Only a fixed number of bits are present, which means that +only a fixed number of policy decisions are representable. There are +many decisions that do not fit into the framework imposed by the +signatory field; a zone administrator cannot effectively impose a policy +not implemented in the draft defining the field. + +There may be any number of policies applied in the process of +authorization, and there are no restrictions on the scope of these +policies. Implementation of the policies is beyond the scope of this +document. + +3.2 - Simplicity + +Policy decisions in the server could be used as an adjunct to policy +fields in the KEY records. This could lead to confusion if the policies +are inconsistent. Furthermore, since there is no need to expose +policies, a central configuration point is more logical. + +3.3 - Extendibility + +If a policy is changed, there are no changes made to the DNS protocol or +the data on the wire. This means that new policies can be defined at +any point without adverse effects or interoperability concerns. + + + + + + + + + + + + + + +Expires August 1999 [Page 3] + +INTERNET-DRAFT Simple Secure Dynamic Update February 1999 + + +4 - Interaction with DNSSEC + +A successful update request may or may not include SIG records for each +RRset. Since SIG records are not used for authentication in this +protocol, they are not required. If the updated zone is signed, the +server will generate SIG records for each incoming RRset with the Zone +key (which MUST be online). If there are any non-DNSSEC SIG records +present, they are retained. If there are SIG records that have been +generated by the appropriate zone KEY, these SIGs are verified and +retained if the verification is successful. DNSSEC SIG records +generated by other KEYs are dropped. The server will generate SIG +records for each set with the Zone key, unless one has already been +verified. The server will also generate a new SOA record and possibly +new NXT records, and sign these with the Zone key. + +The server MUST update the SOA record and MAY generate new NXT records +when an update is received. Unlike traditional dynamic update, the +client is forbidden from updating SOA 1 NXT records. + +5 - Security considerations + +For a secure zone to support dynamic update, the Zone key MUST be online +(unlike [RFC2137]). No additional protection is offered by having the +Zone key offline and an Update key online, since compromising any key +that can sign the zone's data compromises the zone itself. + +6 - References + +[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities,'' + RFC 1034, ISI, November 1987. + +[RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification,'' RFC 1035, ISI, November 1987. + +[RFC2065] D. Eastlake, C. Kaufman, ``Domain Name System Security + Extensions,'' RFC 2065, CyberCash & Iris, January 1997. + +[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic + Updates in the Domain Name System,'' RFC 2136, ISC & Bellcore + & Cisco & DEC, April 1997. + +[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,'' RFC + 2137, CyberCash, April 1997. + +[secext2] D. Eastlake ``Domain Name System Security Extensions,'' + draft-ietf-dnssec-secext2-07.txt, IBM, December 1998. + + + + + +Expires August 1999 [Page 4] + +INTERNET-DRAFT Simple Secure Dynamic Update February 1999 + + +[TSIG] P. Vixie (ed), O. Gudmundsson, D. Eastlake, B. Wellington + ``Secret Key Transaction Signatures for DNS (TSIG),'' draft- + ietf-dnsind-tsig-08.txt, ISC & TISLabs & IBM & TISLabs, + February 1999. + +[update2] D. Eastlake ``Secure Domain Name System (DNS) Dynamic + Update,'' draft-ietf-dnssec-update2-00.txt, Transfinite + Systems Company, August 1998. + +7 - Author's Address + + + Brian Wellington + TISLabs at Network Associates + 3060 Washington Road, Route 97 + Glenwood, MD 21738 + +1 443 259 2369 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Expires August 1999 [Page 5] + diff --git a/doc/expired/draft-ietf-dnssec-tkey-01.txt b/doc/expired/draft-ietf-dnssec-tkey-01.txt new file mode 100644 index 0000000000..9349a36ab7 --- /dev/null +++ b/doc/expired/draft-ietf-dnssec-tkey-01.txt @@ -0,0 +1,1045 @@ + + +DNSSEC Working Group Donald E. Eastlake, 3rd +INTERNET-DRAFT IBM +Expires: March 1999 September 1998 + + + + Secret Key Establishment for DNS (TKEY RR) + ------ --- ------------- --- --- ----- --- + + Donald E. Eastlake 3rd + + + +Status of This Document + + This draft, file name draft-ietf-dnssec-tkey-01.txt, is intended to + be become a Proposed Standard RFC. Distribution of this document is + unlimited. Comments should be sent to the DNS security mailing list + or to the author. + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 1] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +Abstract + + [draft-ietf-dnsind-tsig-*.txt] provides a means of authenticating and + securing Domain Name System (DNS) queries and responses using shared + secret keys via the TSIG resource record (RR). However, it provides + no mechanism for setting up such keys other than manual exchange. + This document describes a TKEY RR that can be used in a number of + different modes to establish shared secret keys between a DNS + resolver and server. + + [changes from last draft: add IANA considerations section, make time + fields module 2**32, minor edits, update author info, ...] + + + +Acknowledgments + + The substantial comments and ideas of the following persons (listed + in alphabetic order) have been incorporated herein and are gratefully + acknowledged: + + Olafur Gudmundsson + + Stuart Kwan + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 2] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +Table of Contents + + Status of This Document....................................1 + + Abstract...................................................2 + Acknowledgments............................................2 + + Table of Contents..........................................3 + + 1. Introduction............................................4 + 1.1 General Principles.....................................4 + 1.2 Overview of Contents...................................5 + + 2. The TKEY Resource Record................................6 + + 3. Exchange via Resolver Query.............................8 + 3.1 Query for Server Assigned Keying.......................8 + 3.2 Query for Diffie-Hellman Exchanged Keying..............9 + 3.3 Query for GSS-API Established.........................10 + + 4. Spontaneous Server Inclusion...........................11 + 4.1 Spontaneous Server Assigned Keying....................11 + 4.2 Spontaneous Diffie-Hellman Keying.....................11 + 4.3 Spontaneous GSS-API Exchange..........................11 + 4.4 Spontaneous Key Deletion..............................12 + + 5. TKEY Dynamic Update Requests...........................13 + 5.1 Exchange via TKEY 'Add'...............................13 + 5.2 TKEY Deletion.........................................13 + + 6. Methods of Encryption..................................14 + + 7. IANA Considerations....................................15 + + 8. Security Considerations................................16 + + References................................................17 + + Author's Address..........................................18 + Expiration and File Name..................................18 + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 3] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +1. Introduction + + The Domain Name System (DNS) is a hierarchical, distributed, highly + available database used for mapping between domain names and + addresses, for email routing, and for other information [RFC 1034, + 1035]. It has been extended to provide for public key security and + dynamic update [RFC 2136, draft-ietf-dnssec-secext2-*.txt, draft- + ietf-dnssec-update2-*.txt]. + + [draft-ietf-dnsind-tsig-*.txt] provides a means of more efficiently + authenticating and securing DNS messages using shared secret keys via + the TSIG resource record (RR) but provides no mechanism for setting + up such keys other than manual exchange. This document describes a + TKEY RR that can be used in a number of different modes to establish + such shared secret keys between a DNS resolver and server. + + + +1.1 General Principles + + TKEY is a meta-RR that is not stored or cached in the DNS and does + not appear in zone files. It supports a variety of modes for the + establishment and deletion of shared secret keys between DNS entities + such as resolvers and servers. The establishment of such a key + requires that state be maintained at both the resolver and the server + and the allocation of the resources to maintain such state may + require mutual agreement. In the absence of such agreement, servers + are free to return errors for any attempt to use TKEY and resolvers + are free to ignore any TKEY RRs they receive. + + In all cases herein, the term "resolver" includes that part of a + server which makes full and incremental [RFC 1995] zone transfer + queries as well as other queries. + + Servers are not required to implement any particular mode or modes of + the defined modes of TKEY shared secret key establishment or deletion + and may return errors for any they do not support. Based on + experience, in the future more modes may be added or some modes + described herein may be deprecated. + + The means by which the shared secret keying material exchanged via + TKEY is actually used in any particular TSIG algorithm is algorithm + dependent and is defined in connection with that algorithm. + + Note that this keying material and TSIGs that use it are associated + with DNS hosts. They are not tied to zones. They may be used to + authenticate queries and responses but they do not provide zone + stored DNS data origin authentication [draft-ietf-dnssec-secext2- + *.txt]. + + + +Donald E. Eastlake, 3rd [Page 4] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + + Two modes of TKEY, the server assigned and resolver assigned modes, + perform encryption which may effect their export or inport status for + some countries. All other aspects of DNS security, including the + SIG, KEY, NXT, and TSIG RRs and all other defined modes of TKEY + perform authentication (signatures and signature verification) only. + + + +1.2 Overview of Contents + + Section 2 below specifies the TKEY resource record (RR) and provides + a high level description of its constituent fields. + + Section 3 discusses key exchange via queries for type TKEY. This is + applicable to the server assigned, Diffie-Hellman exchange, and GSS- + API establishment modes. + + Section 4 discusses spontaneous inclusion of TKEY RRs in responses by + servers. This is applicable to key deletion and to server assigned + and Diffie-Hellman exchange key establishment. + + Section 5 discusses use of dynamic update requests for type TKEY. + This supports optional key exchange via resolver update request, + which is applicable to key deletion and to the resolver assigned + mode. + + Section 6 describes encryption methods for transmitting secret key + information. + + Section 7 covers IANA considerations in assignment of TKEY modes. + + Finally, Section 8 touches on some security considerations. + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 5] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +2. The TKEY Resource Record + + The TKEY resource record (RR) has the structure given below. Its RR + type code is 249. + + Field Type Comment + ----- ---- ------- + + NAME domain see description below + TTYPE u_int16_t TKEY + CLASS u_int16_t ignored, should be zero + TTL u_int32_t SHOULD be zero + RDLEN u_int16_t size of RDATA + RDATA: Algorithhm: domain + Inception: u_int32_t + Expiration: u_int32_t + Mode: u_int16_t + Error: u_int16_t + Key Size: u_int16_t + Key Data: octet-stream + Other Size: u_int16_t + Other Data: octet-stream undefined by this protocol + + The Name field's meaning differs somewhat with mode and context as + explained in subsequent sections. + + The TTL field SHOULD always be zero to be sure that older DNS + implementations do not cache TKEY RRs. + + The algorithm name is a domain name with the same meaning as in + [draft-ietf-dnsind-tsig-*.txt]. The algorithm determines how the + secret keying material exchanged using the TKEY RR is actually used + to derive the algorithm specific key that is used. + + The inception time and expiration time are in number of seconds since + the beginning of 1 January 1970 GMT ignoring leap seconds treated as + modulo 2**32 using ring arithmetic [RFC 1982]. In messages between a + DNS resolver to a DNS server where these fields are meaningful, they + are the either requested validity interval for the keying material + asked for or specify the validity interval of keying material + provided. To avoid reply attack, to keying material used to + authenticate TKEY keying material MUST NOT have a lifetime of more + then 2**31 seconds. This applies to keying material used in either a + TSIG or a SIG(0) transacation or request signature. + + The mode field specifies the general scheme for key agreement. Note + that implementation of TKEY as a whole and of any particular mode is + optional. The following values of the Mode octet are defined or + reserved: + + + +Donald E. Eastlake, 3rd [Page 6] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + + Value Description + ----- ----------- + 0 - reserved + 1 server/responder assignment + 2 Diffie-Hellman exchange + 3 GSS-API negotiation + 4 resolver/querier assignment + 5 key deletion + 6-65534 - available, see IANA considerations section + 65535 -reserved + + The error code field is an extended RCODE. The following values are + defined: + Value Description + ----- ----------- + 0 - no error + 1-15 a DNS RCODE + 16 BADSIG + 17 BADKEY + 18 BADTIME + 19 BADMODE + + The key data size field is an unsigned 16 bit integer in network + order which specifies the size of the key exchange data field in + octets. The meaning of the key data depends on the mode. + + The Other Size and Other Data fields are not used. The RDLEN field + MUST equal the length of the RDATA section through the end of other + data or the RR is to be considered malformed and rejected. + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 7] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +3. Exchange via Resolver Query + + One method for a resolver and a server to establish a shared secret + key for use in TSIG is through queries from the resolver for type + TKEY. Such queries MUST either be accompanied by one or more TKEY + RRs in the additional information section to indicate the mode(s) in + use and other information where required or the resolver and server + must have a prior agreement that supplies any information that would + otherwise have had to be conveyed by TKEY RR(s) in the query. + + For TKEY(s) appearing in a query, the TKEY RR name SHOULD be a domain + locally unique at the resolver (or globally unique), less than 128 + octets long, and meaningful to the resolver to distinguish keys + and/or key agreement sessions. (For resolvers not wishing to make + this use of the name, it may be specified as root to minimize + length.) For TKEY(s) appearing in a response to a query, the TKEY RR + name SHOULD be a globally unique server assigned domain. If the TKEY + in a response is the result of a query containing a TKEY with a non- + root name, that query TKEY name SHOULD be incorporated as the prefix + of the response TKEY name. + + Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY + ignore the recursive header bit in TKEY queries they receive. + + For every mode defined below, the inception and expiration times in a + query TKEY are set to the time interval for which the resolver wishes + the requested key to be valid and they are set in a successful + response to the actual time interval during which the server will + consider the key valid. Future modes may be defined which ignore the + inception and expiration time fields. + + + +3.1 Query for Server Assigned Keying + + In server assigned keying, the DNS server host generates the keying + material and it is sent to the resolver encrypted under a resolver + host key. See section 6 for description of encryption methods. + + A resolver sends a query for type TKEY accompanied by a TKEY RR + specifying the "server assignment" mode and a resolver host KEY RR to + be used in encrypting the response, both in the additional + information section. The TKEY algorithm field is set to the signature + algorithm the resolver plans to use. It is recommended that any "key + data" provided in the query TKEY be strongly mixed with server + generated randomness [RFC 1750] to derive the keying material to be + used. The KEY that appears in the query SHOULD have a zero TTL. It + need not be accompanied by a SIG(KEY) and if the query is signed by + the resolver host and that signature is verified, then any SIG(KEY) + provided MAY be ignored for key exchange purposes. The KEY RR in + + +Donald E. Eastlake, 3rd [Page 8] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + + such a query SHOULD have a name that corresponds to the resolver host + but it is only essential that it be a public key for which the + resolver has the corresponding private key so it can decrypt the + response data. + + Accepting and responding to an unsigned query of this sort may drain + some entropy from an entropy pool being maintained by the server and + used for secret key generation and so might enable an entropy + exhaustion attack. In addition, some significant amount of + computational resources may be used in the public key encryption of + response data. To protect against these effects, a server SHOULD + require such a query to be signed and MAY rate limit responses. + + The server response contains a TKEY in its answer section with the + server assigned mode. If the error field is non-zero, the query + failed for the reason given. If the error field is zero, the KEY RR + provided in the query will be echoed back and the key data portion of + the response TKEY RR will be the server assigned keying data + encrypted under the public key in the KEY RR. The name of the TKEY + RR will be the server assigned name of the key and SHOULD be globally + unique. + + + +3.2 Query for Diffie-Hellman Exchanged Keying + + Diffie-Hellman (DH) key exchange is means whereby two parties can + derive some shared secret information without requiring any secrecy + of the messages they exchange [Schneier]. Provisions have been made + for the storage of DH public keys in the DNS [draft-ietf-dnssec-dhk- + *.txt]. + + A client sends a query for type TKEY accompanied by a TKEY RR in the + additional information section specifying the "Diffie-Hellman" mode + and accompanied by a KEY RR specifying a client host Diffie-Hellman + key. The TKEY algorithm field is set to the signature algorithm the + resolver plans to use and any "key data" provided is ignored by the + server. + + Accepting and responding to an unsigned query of this sort may use + significant computation at the server; however, if the server + requires that the request be signed, then if no shared secret is in + place to permit a TSIG to be used on the request, it would be + necessary to use a SIG(0) the verification of which would impose its + own computational load. + + The server response contains a TKEY in its answer section with the + Diffie-Hellman mode. If the error field is non-zero, the query failed + for the reason given. If the error field is zero, the client host + supplied Diffie-Hellman KEY should be echoed back and a server host + + +Donald E. Eastlake, 3rd [Page 9] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + + Diffie-Hellman KEY RR will also be present. + + Both parties can calculate the same shared secret quantity from the + pair of Diffie-Hellman keys used [Schneier] provided they use the + same modulus. If the server host does not have an appropriate + Diffie-Hellman key to use for the exchange, it should return the + BADKEY error. + + + +3.3 Query for GSS-API Established + + This is described in a separate document [draft-skwan-gss-tsig-*.txt] + which should be seen for the full description. Basically, when an + acceptable symmetric key is not yet in place, the resolver can send a + query for type TKEY with a TKEY specifying the GSS-API mode in the + additional information section and a GSS-API token in the key data + portion. The server responds with a TKEY specifying the GSS-API mode + and a GSS-API token in the key data portion. The resolver and server + feed these tokens to their local GSS implementation and interate + until an error is encountered or a key (GSS-API session) is + established. A similar exchange can be used to delete a GSS-API + session. + + Any issues of possible encryption of the GSS-API token data being + transmitted are handled by the GSS-API level. In addition, the GSS- + API level provides authentication so that this mode of TKEY query and + response MAY be, but do not need to be, signed with TSIG or SIG(0). + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 10] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +4. Spontaneous Server Inclusion + + A DNS server may include TKEY RRs spontaneously as additional + information in responses. This SHOULD only be done if the server + knows the querier understands TKEY and has this option implemented. + This technique can be used to establish a server assigned key, a + Diffie-Hellman exchange key, for GSS-API exchange, and to delete a + key. A disadvantage of this technique is that there is no way for + the server to get any immediate error or success indication back and, + in the case of UDP, no way to even know if the DNS response reached + the resolver. + + + +4.1 Spontaneous Server Assigned Keying + + A server can include in the additional information section of a + response a server assignment mode TKEY with encrypted keying material + in its key data section along with a KEY RR specifying the client + public key used for the encryption. Such a response SHOULD be signed + but the KEY RR need not be signed by a SIG(KEY). A server should + only do this if there is sufficient room in a query and it has reason + to believe the resolver will understand such additional data. The + KEY RR used MUST be one for which the resolver host has the + corresponding private key or it will not be able to decrypt the + keying material. + + + +4.2 Spontaneous Diffie-Hellman Keying + + A server can include in the additional information section of a + response a Diffie-Hellman exchange mode TKEY along with two KEY RRs + specifying the client and server host public keys used for the + exchange. Such a response SHOULD be signed but the KEY RRs need not + be signed by a SIG(KEY). A server should only do this if there is + sufficient room in a query and it has reason to believe the resolver + host will understand such additional data. + + + +4.3 Spontaneous GSS-API Exchange + + A server can spontaneously include in the additional information + section of a response, a GSS-API mode TKEY. The information in the + key data section of such a TKEY is a GSS-API token which SHOULD be + fed by the resolver to its local GSS-API implementation. If such a + response is signed, the signature must verify before processing the + data. To the extent that GSS-API provides its own security, such a + response may not need to be signed. To the extent that GSS-API + + +Donald E. Eastlake, 3rd [Page 11] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + + handles duplicated messages, such a spontaneous TKEY can be sent + repeatedly, until, perhaps, a response via a GSS-API mode TKEY query + is received. + + + +4.4 Spontaneous Key Deletion + + A server can hint to a client that it has deleted a symmetric key by + spontaneously including a TKEY RR in the additional information + section of a response with the key's name and specifying the key + deletion mode. Such a response SHOULD be signed. If authenticated, + it deletes all keys with the given name whose effective time period + overlaps the inception to expiration period given in the TKEY. (If + the inception time of one symmetric key is equal to the expiration + time of another, or vice versa, they do not overlap.) Failure by a + client to receive or properly process such additional information in + a response would simply mean that the client might use a key that the + server had discarded and then get an error indication. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 12] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +5. TKEY Dynamic Update Requests + + If a DNS server supports dynamic update [RFC 2136], then dynamic + update request can be used to exchange resolver assigned symmetric + keys as described in section 5.1 below and to delete previously + exchanged keys from a server as described in section 5.2 below. + + + +5.1 Exchange via TKEY 'Add' + + Optionally, a server can accept resolver assigned keys. The keying + material must be encrypted under a server host key for protection in + transmission as described in Section 6. + + The resolver sends an update request to add a TKEY RR that specifies + the keying data with a KEY RR in the additional information section + specifying the server host public key used to encrypt the data. The + name of the key and the keying data are completely controlled by the + sending resolver so a globally unique key name SHOULD be used. The + server SHOULD require that this request be signed with a TSIG, if + there already exists an appropriate shared secret, or a SIG(0) by the + resolver host. The KEY RR used MUST be one for which the server has + the corresponding private key or it will not be able to decrypt the + keying material. + + + +5.2 TKEY Deletion + + Keys established via TKEY can be treated as soft state. Since DNS + transactions are originated by the resolver, the resolver can simply + toss keys, although it may have to go through another key exchange if + it later needs one. Similarly, the server can discard keys although + that will result in an error on receiving a query with a TSIG using + the discarded key. + + The key expiration provided in the TKEY and the ability of each party + to discard keys may be adequate but servers that support dynamic + update [RFC 2136] may optionally implement key deletion whereby the + server discards a key on receipt from a resolver of a delete request + for a TKEY with the key's name. The mode and most fields of the TKEY + being "deleted" are ignored. But, to allow for the possibility of + multiple keys with the same name but different time periods, the only + key deleted are those whose time period overlaps with that specified + by the inception and expiration in the TKEY being "deleted". + + + + + + +Donald E. Eastlake, 3rd [Page 13] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +6. Methods of Encryption + + For the server assigned and resolver assigned key exchange, the + keying material is sent within the key data field of a TKEY RR + encrypted under the private key corresponding to the public key in an + accompanying KEY RR [draft-ietf-dnssec-secext2-*.txt]. The secret + keying material being send will generally be fairly short, usually + less than 256 bits, because that is adequate for very strong + protection with modern keyed hash or symmetric algorithms. + + If the KEY RR specifies the RSA algorithm, then the keying material + is encrypted as per the description of RSA encryption in PKCS-1. + (Note, the secret keying material being sent is directly RSA + encrypted in PKCS-1 format, It is not "enveloped" under some other + symmetric algorithm.) In the unlikely event that the keying material + will not fit within one RSA modulus of the chosen public key, + additional RSA encryption blocks are included. The length of each + block is clear from the public RSA key specified and the PKCS-1 + padding makes it clear what part of the encrypted data is actually + keying material and what part is formatting or the required at least + eight bytes of random [RFC 1750] padding. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 14] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +7. IANA Considerations + + Mode field values 0x0000 through 0x00FF, and 0XFF00 through 0XFFFF + can only be assigned by an IETF standards action excluding + Experimental Standards (and 1 through 5 are assigned by this Proposed + Standard). Special consideration should be given before the + allocation of meaning for Mode field values 0x0000 and 0xFFFF. + + Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF + are allocated by an IETF consensus (i.e., at this time, an IESG vote) + excluding Experimental Standards. + + Mode field values 0x1000 through 0xEFFF are allocated based on RFC + documentation of their use or the issuance of an Experimental + Standard. + + Mode values should not be changed when the status of their use + changes. I.E. a mode value assigned for an Experimental Standard + should not be changed later just because that standard's status is + changed to Proposed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 15] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +8. Security Considerations + + To avoid different interpretations of the inception and expiration + times in TKEY RRs, resovlers and servers exchanging them must have + the same idea of what time it is. One way of doing this is with the + NTP protocol [RFC 2030] but that or any other time synchronization + MUST be done securely. + + It is recommended that the server require TKEY queries be signed. + However, for currently defined modes, relatively little damage will + be done if an unsigned query of this sort is accepted and processed, + as described below for each mode. In addition, requiring that a TKEY + query be signed by a TSIG (if there exists an acceptable exchanged + key between the parties) or a SIG(0) may itself impose significant + computational requirements on the server, particularly in verifying + SIG(0) public key signatures. + + Responses to TKEY queries SHOULD always have DNS transaction + signatures to protect the integrity of any keying data, error codes, + etc. This signature, if present, MUST use a previously established + secret (TSIG) or public (SIG(0)) key and MUST NOT use any key that + the response to be verified is itself providing. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 16] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +References + + PKCS-1 - RSA Encryption Standard (An RSA Laboratories Technical + Note). + + RFC 1034 - P. Mockapetris, "Domain Names - Concepts and Facilities", + STD 13, November 1987. + + RFC 1035 - P. Mockapetris, "Domain Names - Implementation and + Specifications", STD 13, November 1987. + + RFC 1750 - D. Eastlake, S. Crocker & J. Schiller, "Randomness + Recommendations for Security", December 1994. + + RFC 1982 - Robert Elz, Rrandy Bush, "Serial Number Arithmetic", + 09/03/1996. + + RFC 1995 - Masatka Ohta, "Incremental Zone Transfer in DNS", August + 1996. + + RFC 2030 - D. Mills, "Simple Network Time Protocol (SNTP) Version 4 + for IPv4, IPv6 and OSI", October 1996. + + RFC 2136 - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. + + draft-ietf-dnsind-tsig-*.txt - P. Vixie, O. Gudmundsson, D. + Eastlake, "Secret Key Transaction Signatures for DNS (TSIG)". + + draft-ietf-dnssec-dhk-*.txt - D. Eastlake + + draft-ietf-dnssec-update2-*.txt - Donald E. Eastlake 3rd, "Secure + Domain Name System Dynamic Update". + + draft-ietf-dnssec-secext2-*.txt - Donald E. Eastlake 3rd, "Domain + Name System Security Extensions". + + draft-skwan-gss-tsig-*.txt - S. Kwan, P. Garg, R. Viswanathan, "GSS + Algorithm for TSIG (GSS-TSIG)" + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 17] + + +INTERNET-DRAFT The DNS TKEY RR September 1998 + + +Author's Address + + Donald E. Eastlake 3rd + IBM + 318 Acton Street + Carlisle, MA 01741 USA + + Telephone: +1 978 287 4877 + +1 914 784 7913 + FAX: +1 978 371 7148 + email: dee3@us.ibm.com + + + +Expiration and File Name + + This draft expires March 1999. + + Its file name is draft-ietf-dnssec-tkey-01.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake, 3rd [Page 18] + diff --git a/doc/expired/draft-ietf-dnssec-update2-00.txt b/doc/expired/draft-ietf-dnssec-update2-00.txt new file mode 100644 index 0000000000..860f5fa92a --- /dev/null +++ b/doc/expired/draft-ietf-dnssec-update2-00.txt @@ -0,0 +1,871 @@ + + +INTERNET-DRAFT Donald E. Eastlake 3rd +OBSOLETES RFC 2137 Transfinite Systems Company +Expires: February 1999 August 1998 + + + + Secure Domain Name System (DNS) Dynamic Update + ------ ------ ---- ------ ----- ------- ------ + + + + + +Status of This Document + + This draft, file name draft-ietf-dnssec-update2-00.txt, is intended + to become a Proposed Standard RFC obsoleting RFC 2137. Distribution + of this document is unlimited. Comments should be sent to the DNS + security mailing list or the author. + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + To view the entire list of current Internet-Drafts, please check the + "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow + Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern + Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific + Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + +Abstract + + Revised Domain Name System (DNS) protocol extensions to authenticate + the data in DNS and provide key distribution services have been + defined in draft-ietf-dnssec-secext2-*.txt, which obsoletes the + original DNS security protocol definition in RFC 2065. In addition, + symetric key DNS transaction signatures have been defined in draft- + ietf-dnsind-tsig-*.txt. Secure DNS Dynamic Update operations were + also been defined [RFC 2137] in connection RFC 2065. This document + updates secure dynamic update in light of draft-ietf-dnssec-secext2- + *.txt and draft-ietf-dnsind-tsig-*.txt. It describes how to use + digital signatures covering requests and data to secure updates and + restrict updates to those authorized to perform them as indicated by + the updater's possession of cryptographic keys. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + +Table of Contents + + Status of This Document....................................1 + + Abstract...................................................2 + + Table of Contents..........................................3 + + 1. Introduction............................................4 + 1.1. Overview of DNS Dynamic Update........................4 + 1.2. Overview of Public Key DNS Security...................4 + 1.3 Overview of Secret Key DNS Security....................5 + + 2. Two Basic Modes.........................................6 + 2.1. Mode A................................................6 + 2.2. Mode B................................................7 + + 3. Keys....................................................8 + 3.1. Update Keys...........................................8 + 3.1.1. Public Update Key Name Scope........................8 + 3.1.2. Public Update Key Class Scope.......................8 + 3.1.3. Public Update Key Signatory Field...................9 + 3.2. Zone Keys and Update Modes...........................10 + 3.3. Wildcard Public Key Punch Through....................11 + + 4. Update Signatures......................................13 + 4.1. Update Request Signatures............................13 + 4.2. Update Data Signatures...............................13 + + 5. Security Considerations................................14 + 6. IANA Considerations....................................14 + + References................................................15 + Author's Address..........................................15 + Expiration and File Name..................................15 + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + +1. Introduction + + Dynamic update operations have been defined for the Domain Name + System (DNS) in RFC 2136 but that RFC does not include a description + of security for those updates. Public key means of securing DNS data + and transactions and using it for public key distribution were + defined in RFC 2065 which has been updated by draft-ietf-dnssec- + sexect2-*.txt, and secret key means of securing DNS transactions are + defined in draft-ietf-dnsind-tsig-*.txt. + + This document provides techniques based on the updated DNS security + RFC draft-ietf-dnssec-sexect2-*.txt and draft-ietf-dnsind-tsig-*.txt + to authenticate DNS updates of secure zones. (Secret key signatures + could be used to authenticate updates on non-secured DNS zones. That + case In not considered in this document.) + + Familiarity with the DNS system [RFC 1034, 1035] is assumed. + Familiarity with the DNS security and dynamic update will be helpful. + + + +1.1. Overview of DNS Dynamic Update + + DNS dynamic update defines a new DNS opcode, new DNS request and + response structure if that opcode is used, and new error codes. An + update can specify complex combinations of deletion and insertion + (with or without pre-existence testing) of resource records (RRs) + with one or more owner names; however, all testing and changes for + any particular DNS update request are restricted to a single zone. + Updates occur at the primary server for a zone. + + The primary server for a dynamic zone must increment the zone SOA + serial number when an update occurs or the next time the SOA is + retrieved if one or more updates have occurred since the previous SOA + retrieval and the updates themselves did not update the SOA. + + + +1.2. Overview of Public Key DNS Security + + DNS security authenticates data in the DNS by also storing digital + signatures in the DNS as SIG resource records (RRs). A SIG RR + provides a digital signature on the set of all RRs with the same + owner name and class as the SIG and whose type is the type covered by + the SIG. The SIG RR cryptographically binds the covered RR set to + the signer, signature inception and expiration date, etc. There are + one or more keys associated with every secure zone and all data in + the secure zone is signed either by a zone key or by a dynamic update + key tracing its authority to a zone key. + + + +Donald E. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + + DNS security also defines transaction SIGs and request SIGs. + + Transaction SIGs appear at the end of a response. They authenticate + the response and bind it to the corresponding request using the key + of the host where the responding DNS server is. + + Request SIGs appear at the end of a request and authenticate the + request with the key of the submitting entity. + + DNS security also permits the storage of public keys in the DNS via + KEY RRs. These KEY RRs are also, of course, authenticated by SIG + RRs. KEY RRs for zones may be stored in their superzone and/or their + authoritive subzone servers so that the secure DNS tree of zones can + be traversed by a security aware resolver. + + + +1.3 Overview of Secret Key DNS Security + + draft-ietf-dnsind-tsig-*.txt provides a means for two processes that + share a secret key to authenticate DNS requests and responses sent + between them by appending TSIG digital signature RRs to those + requests and responses. Secret key digital signatures are generally + much faster to calculate and verify than public key digital + signatures. In addition, the need, in general, to cache KEY RRs and + perform the KEY-SIG chain verifications is avoided. + + However, the cost for this speed and simplicity in TSIG use is the + requirement to securely achieve key distribution or agreement between + the communicating processes and to achieve agreement as to the + authority represented by a correct TSIG on a requested using a + partciular key. + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + +2. Two Basic Modes + + A dynamic secure zone is any secure DNS zone that + (1) has a zone KEY RR signatory field indicates that updates are + implemented and either + (2a) contains one or more KEY RRs that can authorize dynamic + updates, i.e., entity or user KEY RRs with the signatory field + non-zero, or + (2b) has a primary server with one or more secret keys configured + to authorize updates requests and shared with one or more + update requesters. + + Note: 2a and 2b can both be true for a zone. + + There are two basic modes of dynamic secure zone which relate to the + update strategy, mode A and mode B. A summary comparison table is + given below and then each mode is described. + + SUMMARY OF DYNAMIC SECURE ZONE MODES + + CRITERIA: | MODE A | MODE B + =========================+====================+=================== + Definition: | Zone Key Off line | Zone Key On line + =========================+====================+=================== + Server Workload | Medium | High + -------------------------+--------------------+------------------- + Key Restrictions | Fine grain | Coarse grain + -------------------------+--------------------+------------------- + Dynamic Data Temporality | Transient | Permanent + -------------------------+--------------------+------------------- + Dynamic Key Rollover | No | Yes + -------------------------+--------------------+------------------- + + NOTE: The Mode A / Mode B distinction only effects the validation + and performance of update requests. It has no effect on retrievals. + + + +2.1. Mode A + + For mode A, the zone owner private key and static zone master file + are kept off-line for maximum security of the static zone contents. + + As a consequence, any dynamicly added or changed RRs are signed in + the secure zone by their authorizing dynamic update key and they are + backed up, along with this SIG RR, in a separate online dynamic + master file. In this type of zone, server computation is generally + reduced since the server need only check signatures on the update + data and request, which have already been signed by the updater + (generally a much faster operation than signing data) and update the + + +Donald E. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + + NXT RRs which need to be changed, if any. Because the dynamicly + added RRs retain their update KEY signed SIG, finer grained control + of updates can be implemented via the KEY RR signatory field (unique + name restriction and weak update key restriction). Because dynamic + data is only stored in the online dynamic master file and only + authenticated by dynamic keys which expire, updates are transient in + nature. Key rollover for an entity that can authorize dynamic + updates is more cumbersome since the authority of their key must be + traceable to a zone key and so, in general, they must securely + communicate a new key to the zone authority for manual transfer to + the off line static master file. NOTE: for this mode the zone SOA and + NXT RRs must be signed by a dynamic update key, which will be an end + entity key with an owner name of the zone name, and that private key + must be kept on line so that the SOA and NXTs can be changed for + updates. + + + +2.2. Mode B + + For mode B, the zone owner private key and master file are kept on- + line at the zone primary server. When authenticated updates succeed, + SIGs under the zone key for the resulting data (as well as possible + NXT and SOA changes) are calculated and these SIG (and possible + SOA/NXT) changes are entered into the zone and the unified on-line + master file. + + As a consequence, this mode generally requires more computational + effort on the part of the server as it computes zone data signatures + in addition to verifying the signatures on requests. Because signing + generally takes more effort than verification, these signatures + generally will take more effort to calculate than it would take to + verify the data signatures required in Mode A. Because the zone key + is used to sign all the zone data, the information as to who + originated the current state of dynamic RR sets and even that data is + the result of a dynamic update as opposed to coming from an original + master file, is lost, making unavailable the fine grain control of + some values of the KEY RR signatory field. In addition, the + incorporation of the updates into the primary master file and their + authentication by the zone key makes them permanent in nature. + Maintaining the zone key on-line also means that dynamic update keys + which are signed by the zone key can be dynamically updated in real + time since the zone key is available to dynamically sign new values. + + + + + + + + + +Donald E. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + +3. Keys + + Dynamic update requests depend on update keys as described in section + 3.1 below. In addition, the zone secure dynamic update mode and + availability of some options is indicated in the zone KEY(s). + Finally, a special rule is used in searching for KEYs to validate + updates as described in section 3.3. + + + +3.1. Update Keys + + All update requests to a secure zone must include signature(s) by one + or more private or secret keys that together can authorize that + update. In order for the Domain Name System (DNS) server executing + the update request to confirm this (1) any secret keys must be know + to it, along with the authority represented by the secret key, and + (2) any private key or keys must have the corresponding public key or + keys available to and authenticatable by that server as specially + flagged KEY Resource Records (RRs). + + The scope of authority of any secret keys is as configured at the + Server. Methods of describing and configuring such authority are not + discussed in this document. + + The scope of authority of public update keys is indicated by their + KEY RR owner name, class, and signatory field flags as described + below. In addition, such KEY RRs MUST be entity or user keys and not + have the authentication use prohibited bit on. + + All parts of the actual update MUST be within the scope/authority of + at least one of the keys used for a request SIG or TSIG on the update + request as described in section 4. + + + +3.1.1. Public Update Key Name Scope + + The owner name of any update authorizing KEY RR must (1) be the same + as the owner name of any RRs being added or deleted or (2) a wildcard + name including within its extended scope (see section 3.3) the name + of any RRs being added or deleted and those RRs must be in the same + zone. + + + +3.1.2. Public Update Key Class Scope + + The class of any update authorizing KEY RR must be the same as the + class of any RR's being added or deleted. + + +Donald E. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + +3.1.3. Public Update Key Signatory Field + + The four bit "signatory field" (see draft-ietf-dnssec-secext2-*.txt) + of any update authorizing KEY RR must be non-zero. The bits have the + meanings described below for non-zone keys (see section 3.2 for zone + type keys). + + UPDATE KEY RR SIGNATORY FIELD BITS + + 0 1 2 3 + +-----------+-----------+-----------+-----------+ + | zone | strong | unique | general | + +-----------+-----------+-----------+-----------+ + + Bit 0, zone control - If nonzero, this key is authorized to attach, + detach, and move zones by creating and deleting NS, glue A, and + zone KEY RR(s). If zero, the key can not authorize any update + that would effect such RRs. This bit is meaningful for both + type A and type B dynamic secure zones. An update attempting to + add an NS or zone KEY RR to a node (i.e., make the node a + delegation point) is illegal if there are any deeper nodes in + the zone. + + NOTE: do not confuse the "zone" signatory field bit with the + "zone" key type bit. + + Bit 1, strong update - If zero, the key can only authorize updates + where any existing RRs of the same owner and class are + authenticated by a SIG using the same key. If nonzero, this key + is authorized to add and delete RRs even if there are other RRs + with the same owner name and class that are authenticated by a + SIG signed with a different dynamic update KEY. This bit is + meaningful only for type A dynamic zones that have a zone KEY + advertising that the feature is available. It is ignored in + type B dynamic zones. + + Keeping this bit zero on multiple KEY RRs with the same or + nested wild card owner names permits multiple entities to exist + that can create and delete names but can not effect RRs with + different owner names from any they created. In effect, this + creates two levels of dynamic update key, strong and weak, where + weak keys are prohibited from interfering with each other but a + strong key can interfere with any weak keys or other strong + keys. + + Bit 2, unique name update - This bit is useful only if the owner name + is a wildcard. (Any dynamic update KEY with a non-wildcard name + is, in effect, a unique name update key.) If zero, this key is + authorized to add and updates RRs for any number of names within + its wildcard scope. If nonzero, this key is authorized to add + + +Donald E. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + + and update RRs for only a single owner name. If there already + exist RRs with one or more names signed by this key, they may be + updated but no new name created until the number of existing + names is reduced to zero. This bit is meaningful only for mode + A dynamic zones that have a zone KEY advertising that the + feature is available. It is ignored in mode B dynamic zones. + + This bit can be used to restrict a KEY from flooding a zone with + new names. In conjunction with a local administratively imposed + limit on the number of dynamic RRs with a particular name, it + can completely restrict a KEY from flooding a zone with RRs. + + Bit 3, general update - The general update signatory field bit has no + special meaning. If the other three bits are all zero, it must + be one so that the field is non-zero to designate that the key + is an update key. The meaning of all values of the signatory + field with the general bit on and one or more other signatory + field bits on is reserved. + + All the signatory bit update authorizations described above only + apply if the update is within the name and class scope as per + sections 3.1.1 and 3.1.2. + + + +3.2. Zone Keys and Update Modes + + Zone type keys are automatically authorized to sign anything in their + zone, of course, regardless of the value of their signatory field. + For zone keys, the signatory field bits have different means than + they they do for update keys, as shown below. The signatory field + MUST be zero if dynamic update is not supported for a secure zone and + MUST be non-zero if it is. + + + ZONE KEY RR SIGNATORY FIELD BITS + + 0 1 2 3 + +-----------+-----------+-----------+-----------+ + | mode | strong | unique | general | + +-----------+-----------+-----------+-----------+ + + Bit 0, mode - This bit indicates the update mode for this zone. Zero + indicates mode A while a one indicates mode B. + + Bit 1, strong update - If nonzero, this indicates that the "strong" + key feature described in section 3.1.3 above is implemented and + enabled for this secure zone. If zero, the feature is not + available and all update keys are treated as strong. Has no + effect if the zone is a mode B secure update zone. + + +Donald E. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + + Bit 2, unique name update - If nonzero, this indicates that the + "unique name" feature described in section 3.1.3 above is + implemented and enabled for this secure zone. If zero, this + feature is not available and no wildcard update key is treated + as restricted to a single name. Has no effect if the zone is a + mode B secure update zone. + + Bit 3, general - This bit has no special meaning. If dynamic update + for a zone is supported and the other bits in the zone key + signatory field are zero, it must be a one. The meaning of zone + keys where the signatory field has the general bit and one or + more other bits on is reserved. + + If there are multiple zone KEY RRs with non-zero signatory fields and + zone policy is in transition, they might have different signatory + field values. In that case, strong and unique name restrictions MUST + be enforced as long as there is a non-expired zone key being + advertised that indicates mode A with the strong or unique name bit + on respectively. Mode B updates (i.e., no data signatures) MUST be + supported as long as there is a non-expired zone key that indicates + mode B. Mode A or mode ambiguous updates may be treated as mode B + updates at server option if non-expired zone keys indicate that both + are supported. + + A server that will be executing update operations on a zone, that is, + the primary master server, MUST NOT advertize a zone key that will + attract requests for a mode or features that it can not support. + + + +3.3. Wildcard Public Key Punch Through + + Just as a zone key is valid throughout the entire zone, public update + keys with wildcard names are valid throughout their extended scope, + within the zone. That is, they remain valid for any name that would + match them, even existing specific names within their apparent scope. + + (If this were not so, then whenever a name within a wildcard scope + was created by dynamic update using a wildcard named public update + key for authorization, it would be necessary to first create a copy + of the KEY RR with this name, because otherwise the existence of the + more specific name would hide the authorizing KEY RR and would make + later updates impossible. An updater could create such a KEY RR but + could not zone sign it with their authorizing signer. They would + have to sign it with the same key using the wildcard name as signer. + (This would create update KEYs signed by update KEYs which was + permitted in RFC 2065 but, for simplicity, is prohibit in draft- + ietf-dnssec-secext2-*.txt which requires all KEYs to be signed by + zone keys.) Thus in creating, for example, one hundred type A RRs + authorized by a *.1.1.1.in-addr.arpa KEY RR, without key punch + + +Donald E. Eastlake 3rd [Page 11] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + + through 100 As, 100 KEYs, and 200 SIGs would have to be created as + opposed to merely 100 As and 100 SIGs with wildcard key punch + through.) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 12] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + +4. Update Signatures + + Two kinds of signatures can appear in updates. Request signatures, + which are always required, cover the entire request and authenticate + the DNS header, including opcode, counts, etc., as well as the data. + Data signatures, on the other hand, appear only among the RRs to be + added and are only required for mode A operation. These two types of + signatures are described further below. + + + +4.1. Update Request Signatures + + An update can effect multiple owner names in a zone. It may be that + these different names are covered by different public or secret + dynamic update keys. For every owner name effected, the updater must + know a private or secret key valid to authorize updates for that name + (and the zone's class) and must prove this by appending request SIG + and/or TSIG RRs under each such key. + + Request signatures occur in the Additional Information section. As + specified in draft-ietf-dnssec-secext2-*.txt, a public request + signature is a SIG RR occurring at the end of a request with a type + covered field of zero. As specified in draft-ietf-dnsind-tsig-*.txt, + a secret key request signature is a TSIG RR occuring at the end of + the request. Each request SIG or TSIG signs the entire request, + including DNS header, but excluding any other request signatures and + with the ARCOUNT in the DNS header set to what it would be without + the request signatures. + + + +4.2. Update Data Signatures + + Mode A dynamic secure zones require that the update requester provide + SIG RRs that will authenticate the after-update state of all RR sets + that are changed by the update and are non-empty after the update. + These SIG RRs appear in the request as RRs to be added and the + request must delete any previous data SIG RRs that are invalidated by + the request. + + In Mode B dynamic secure zones, all zone data is authenticated by + zone key SIG RRs. In this case, data signatures need not be included + with the update. A prospective updater can determine which mode an + updatable secure zone is using by examining the signatory field bits + of the zone KEY RR or RRs (see section 3.2). + + + + + + +Donald E. Eastlake 3rd [Page 13] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + +5. Security Considerations + + Any secure zone permitting dynamic updates is inherently less secure + than a static secure zone maintained off line as recommended in + draft-ietf-dnssec-secops-*.txt. If nothing else, secure dynamic + update requires on line change to and re-signing of the zone SOA + resource record (RR) to increase the SOA serial number. This means + that compromise of the primary server host could lead to arbitrary + serial number changes. + + Isolation of dynamic RRs to separate zones from those holding most + static RRs can limit the damage that could occur from breach of a + dynamic zone's security. + + + +6. IANA Considerations + + Allocations of values of the KEY RR Signatory field described herein + as "reserved" requires an IETF consensus. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Donald E. Eastlake 3rd [Page 14] + + +INTERNET-DRAFT Secure DNS Update August 1998 + + +References + + [RFC1035] - Domain Names - Implementation and Specifications, P. + Mockapetris, November 1987. + + [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris, + November 1987. + + [RFC2065] - Domain Name System Security Extensions. D. Eastlake, 3rd, + C. Kaufman. January 1997 + + [RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE). + P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 1997. + + [RFC2137] - Secure Domain Name System Dynamic Update. D. Eastlake. + April 1997. + + draft-ietf-dnsind-tsig-*.txt + + draft-ietf-dnssec-secext2-*.txt. + + draft-ietf-dnssec-secops-*.txt. + + + +Author's Address + + Donald E. Eastlake, 3rd + Transfinite Systems Company + 318 Acton Street + Carlisle, MA 01741 USA + + Telephone: +1 978-287-4877 + +1 978-371-7148 (fax) + email: dee3@torque.pothole.com + + + +Expiration and File Name + + This draft expires February 1999. + + Its file name is draft-ietf-dnssec-update2-00.txt. + + + + + + + + + +Donald E. Eastlake 3rd [Page 15] + diff --git a/doc/expired/draft-ietf-ipngwg-2292bis-00.txt b/doc/expired/draft-ietf-ipngwg-2292bis-00.txt new file mode 100644 index 0000000000..c25ce740ed --- /dev/null +++ b/doc/expired/draft-ietf-ipngwg-2292bis-00.txt @@ -0,0 +1,3531 @@ + + + + + + +INTERNET-DRAFT W. Richard Stevens (Consultant) +Expires: December 24, 1999 Matt Thomas (Consultant) +Obsoletes RFC 2292 Erik Nordmark (Sun) + June 24, 1999 + + + Advanced Sockets API for IPv6 + + + + +Abstract + + A separate specification [RFC-2553] contain changes to the sockets + API to support IP version 6. Those changes are for TCP and UDP-based + applications and will support most end-user applications in use + today: Telnet and FTP clients and servers, HTTP clients and servers, + and the like. + + But another class of applications exists that will also be run under + IPv6. We call these "advanced" applications and today this includes + programs such as Ping, Traceroute, routing daemons, multicast routing + daemons, router discovery daemons, and the like. The API feature + typically used by these programs that make them "advanced" is a raw + socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge + of the packet header formats used by these protocols. To provide + portability for applications that use raw sockets under IPv6, some + standardization is needed for the advanced API features. + + There are other features of IPv6 that some applications will need to + access: interface identification (specifying the outgoing interface + and determining the incoming interface) and IPv6 extension headers + that are not addressed in [RFC-2553]: The Routing header (source + routing), Hop-by-Hop options, and Destination options. This document + provides API access to these features too. + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 1] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet Draft expires December 24, 1999. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 2] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + +Table of Contents + + 1. Introduction .................................................... 6 + + 2. Common Structures and Definitions ............................... 7 + 2.1. The ip6_hdr Structure ...................................... 7 + 2.1.1. IPv6 Next Header Values ............................. 8 + 2.1.2. IPv6 Extension Headers .............................. 8 + 2.2. The icmp6_hdr Structure .................................... 10 + 2.2.1. ICMPv6 Type and Code Values ......................... 11 + 2.2.2. ICMPv6 Neighbor Discovery Type and Code Values ...... 12 + 2.3. Address Testing Macros ..................................... 14 + 2.4. Protocols File ............................................. 15 + + 3. IPv6 Raw Sockets ................................................ 15 + 3.1. Checksums .................................................. 17 + 3.2. ICMPv6 Type Filtering ...................................... 17 + + 4. Access to IPv6 and Extension Headers ............................ 20 + 4.1. TCP Implications ........................................... 21 + 4.2. UDP and Raw Socket Implications ............................ 22 + + 5. Packet Information .............................................. 23 + 5.1. Specifying/Receiving the Interface ......................... 24 + 5.2. Specifying/Receiving Source/Destination Address ............ 25 + 5.3. Specifying/Receiving the Hop Limit ......................... 25 + 5.4. Specifying the Next Hop Address ............................ 26 + 5.5. Additional Errors with sendmsg() and setsockopt() .......... 26 + + 6. Routing Header Option ........................................... 27 + 6.1. inet6_rth_space ............................................ 28 + 6.2. inet6_rth_init ............................................. 29 + 6.3. inet6_rth_add .............................................. 29 + 6.4. inet6_rth_reverse .......................................... 29 + 6.5. inet6_rth_segments ......................................... 30 + 6.6. inet6_rth_getaddr .......................................... 30 + + 7. Hop-By-Hop Options .............................................. 30 + 7.1. Receiving Hop-by-Hop Options ............................... 31 + 7.2. Sending Hop-by-Hop Options ................................. 31 + + 8. Destination Options ............................................. 32 + 8.1. Receiving Destination Options .............................. 32 + 8.2. Sending Destination Options ................................ 33 + + 9. Hop-by-Hop and Destination Options Processing ................... 33 + 9.1. inet6_opt_init ............................................. 34 + 9.2. inet6_opt_append ........................................... 34 + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 3] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + 9.3. inet6_opt_finish ........................................... 35 + 9.4. inet6_opt_set_val .......................................... 35 + 9.5. inet6_opt_next ............................................. 35 + 9.6. inet6_opt_find ............................................. 36 + 9.7. inet6_opt_get_val .......................................... 36 + + 10. Ordering of Ancillary Data and IPv6 Extension Headers ........... 37 + + 11. IPv6-Specific Options with IPv4-Mapped IPv6 Addresses ........... 37 + + 12. Extended interfaces for rresvport, rcmd and rexec ............... 38 + 12.1. rresvport_af .............................................. 38 + 12.2. rcmd_af ................................................... 38 + 12.3. rexec_af .................................................. 39 + + 13. Future Items .................................................... 39 + 13.1. Flow Labels ............................................... 39 + 13.2. Path MTU Discovery and UDP ................................ 39 + 13.3. Neighbor Reachability and UDP ............................. 39 + + 14. Summary of New Definitions ...................................... 39 + + 15. Security Considerations ......................................... 42 + + 16. Compatibility with RFC 2292 ..................................... 43 + + 17. Change History .................................................. 43 + + 18. TODO and Open Issues ............................................ 44 + + 19. References ...................................................... 45 + + 20. Acknowledgments ................................................. 46 + + 21. Authors' Addresses .............................................. 46 + + 22. Appendix A: Ancillary Data ...................................... 46 + 22.1. The msghdr Structure ...................................... 47 + 22.2. The cmsghdr Structure ..................................... 48 + 22.3. Ancillary Data Object Macros .............................. 49 + 22.3.1. CMSG_FIRSTHDR ...................................... 50 + 22.3.2. CMSG_NXTHDR ........................................ 51 + 22.3.3. CMSG_DATA .......................................... 52 + 22.3.4. CMSG_SPACE ......................................... 52 + 22.3.5. CMSG_LEN ........................................... 53 + + 23. Appendix B: Examples using the inet6_rth_XXX() functions ........ 53 + 23.1. Sending a Routing Header .................................. 53 + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 4] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + 23.2. Receiving Routing Headers ................................. 58 + + 24. Appendix C: Examples using the inet6_opt_XXX() functions ........ 60 + 24.1. Building options .......................................... 60 + 24.2. Parsing received options .................................. 62 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 5] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + +1. Introduction + + A separate specification [RFC-2553] contain changes to the sockets + API to support IP version 6. Those changes are for TCP and UDP-based + applications. This document defines some the "advanced" features of + the sockets API that are required for applications to take advantage + of additional features of IPv6. + + Today, the portability of applications using IPv4 raw sockets is + quite high, but this is mainly because most IPv4 implementations + started from a common base (the Berkeley source code) or at least + started with the Berkeley headers. This allows programs such as Ping + and Traceroute, for example, to compile with minimal effort on many + hosts that support the sockets API. With IPv6, however, there is no + common source code base that implementors are starting from, and the + possibility for divergence at this level between different + implementations is high. To avoid a complete lack of portability + amongst applications that use raw IPv6 sockets, some standardization + is necessary. + + There are also features from the basic IPv6 specification that are + not addressed in [RFC-2553]: sending and receiving Routing headers, + Hop-by-Hop options, and Destination options, specifying the outgoing + interface, and being told of the receiving interface. + + This document can be divided into the following main sections. + + 1. Definitions of the basic constants and structures required for + applications to use raw IPv6 sockets. This includes structure + definitions for the IPv6 and ICMPv6 headers and all associated + constants (e.g., values for the Next Header field). + + 2. Some basic semantic definitions for IPv6 raw sockets. For + example, a raw ICMPv4 socket requires the application to + calculate and store the ICMPv4 header checksum. But with IPv6 + this would require the application to choose the source IPv6 + address because the source address is part of the pseudo header + that ICMPv6 now uses for its checksum computation. It should be + defined that with a raw ICMPv6 socket the kernel always + calculates and stores the ICMPv6 header checksum. + + 3. Packet information: how applications can obtain the received + interface, destination address, and received hop limit, along + with specifying these values on a per-packet basis. There are a + class of applications that need this capability and the technique + should be portable. + + 4. Access to the optional Routing header, Hop-by-Hop, and + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 6] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + Destination extension headers. + + 5. Additional features required for improved IPv6 application + portability. + + The packet information along with access to the extension headers + (Routing header, Hop-by-Hop options, and Destination options) are + specified using the "ancillary data" fields that were added to the + 4.3BSD Reno sockets API in 1990. The reason is that these ancillary + data fields are part of the Posix.1g standard and should therefore be + adopted by most vendors. + + This document does not address application access to either the + authentication header or the encapsulating security payload header. + + All examples in this document omit error checking in favor of brevity + and clarity. + + We note that many of the functions and socket options defined in this + document may have error returns that are not defined in this + document. Many of these possible error returns will be recognized + only as implementations proceed. + + Datatypes in this document follow the Posix.1g format: intN_t means a + signed integer of exactly N bits (e.g., int16_t) and uintN_t means an + unsigned integer of exactly N bits (e.g., uint32_t). + + Note that we use the (unofficial) terminology ICMPv4, IGMPv4, and + ARPv4 to avoid any confusion with the newer ICMPv6 protocol. + + +2. Common Structures and Definitions + + Many advanced applications examine fields in the IPv6 header and set + and examine fields in the various ICMPv6 headers. Common structure + definitions for these headers are required, along with common + constant definitions for the structure members. + + Two new headers are defined: and . + + When an include file is specified, that include file is allowed to + include other files that do the actual declaration or definition. + + +2.1. The ip6_hdr Structure + + The following structure is defined as a result of including + . Note that this is a new header. + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 7] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + + struct ip6_hdr { + union { + struct ip6_hdrctl { + uint32_t ip6_un1_flow; /* 8 bits traffic class, 24 bits flow-ID */ + uint16_t ip6_un1_plen; /* payload length */ + uint8_t ip6_un1_nxt; /* next header */ + uint8_t ip6_un1_hlim; /* hop limit */ + } ip6_un1; + uint8_t ip6_un2_vfc; /* 4 bits version, top 4 bits tclass */ + } ip6_ctlun; + struct in6_addr ip6_src; /* source address */ + struct in6_addr ip6_dst; /* destination address */ + }; + + #define ip6_vfc ip6_ctlun.ip6_un2_vfc + #define ip6_flow ip6_ctlun.ip6_un1.ip6_un1_flow + #define ip6_plen ip6_ctlun.ip6_un1.ip6_un1_plen + #define ip6_nxt ip6_ctlun.ip6_un1.ip6_un1_nxt + #define ip6_hlim ip6_ctlun.ip6_un1.ip6_un1_hlim + #define ip6_hops ip6_ctlun.ip6_un1.ip6_un1_hlim + + + +2.1.1. IPv6 Next Header Values + + IPv6 defines many new values for the Next Header field. The + following constants are defined as a result of including + . + + #define IPPROTO_HOPOPTS 0 /* IPv6 Hop-by-Hop options */ + #define IPPROTO_IPV6 41 /* IPv6 header */ + #define IPPROTO_ROUTING 43 /* IPv6 Routing header */ + #define IPPROTO_FRAGMENT 44 /* IPv6 fragmentation header */ + #define IPPROTO_ESP 50 /* encapsulating security payload */ + #define IPPROTO_AH 51 /* authentication header */ + #define IPPROTO_ICMPV6 58 /* ICMPv6 */ + #define IPPROTO_NONE 59 /* IPv6 no next header */ + #define IPPROTO_DSTOPTS 60 /* IPv6 Destination options */ + + Berkeley-derived IPv4 implementations also define IPPROTO_IP to be 0. + This should not be a problem since IPPROTO_IP is used only with IPv4 + sockets and IPPROTO_HOPOPTS only with IPv6 sockets. + + +2.1.2. IPv6 Extension Headers + + Six extension headers are defined for IPv6. We define structures for + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 8] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + all except the Authentication header and Encapsulating Security + Payload header, both of which are beyond the scope of this document. + The following structures are defined as a result of including + . + + /* Hop-by-Hop options header */ + struct ip6_hbh { + uint8_t ip6h_nxt; /* next header */ + uint8_t ip6h_len; /* length in units of 8 octets */ + /* followed by options */ + }; + + /* Destination options header */ + struct ip6_dest { + uint8_t ip6d_nxt; /* next header */ + uint8_t ip6d_len; /* length in units of 8 octets */ + /* followed by options */ + }; + + /* Routing header */ + struct ip6_rthdr { + uint8_t ip6r_nxt; /* next header */ + uint8_t ip6r_len; /* length in units of 8 octets */ + uint8_t ip6r_type; /* routing type */ + uint8_t ip6r_segleft; /* segments left */ + /* followed by routing type specific data */ + }; + + /* Type 0 Routing header */ + struct ip6_rthdr0 { + uint8_t ip6r0_nxt; /* next header */ + uint8_t ip6r0_len; /* length in units of 8 octets */ + uint8_t ip6r0_type; /* always zero */ + uint8_t ip6r0_segleft; /* segments left */ + uint32_t ip6r0_reserved; /* reserved field */ + struct in6_addr ip6r0_addr[1]; /* up to 127 addresses */ + }; + + /* Fragment header */ + struct ip6_frag { + uint8_t ip6f_nxt; /* next header */ + uint8_t ip6f_reserved; /* reserved field */ + uint16_t ip6f_offlg; /* offset, reserved, and flag */ + uint32_t ip6f_ident; /* identification */ + }; + + #if BYTE_ORDER == BIG_ENDIAN + #define IP6F_OFF_MASK 0xfff8 /* mask out offset from _offlg */ + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 9] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + #define IP6F_RESERVED_MASK 0x0006 /* reserved bits in ip6f_offlg */ + #define IP6F_MORE_FRAG 0x0001 /* more-fragments flag */ + #else /* BYTE_ORDER == LITTLE_ENDIAN */ + #define IP6F_OFF_MASK 0xf8ff /* mask out offset from _offlg */ + #define IP6F_RESERVED_MASK 0x0600 /* reserved bits in ip6f_offlg */ + #define IP6F_MORE_FRAG 0x0100 /* more-fragments flag */ + #endif + + Defined constants for fields larger than 1 byte depend on the byte + ordering that is used. This API assumes that the fields in the + protocol headers are left in the network byte order, which is big- + endian for the Internet protocols. If not, then either these + constants or the fields being tested must be converted at run-time, + using something like htons() or htonl(). + + (Note: We show an implementation that supports both big-endian and + little-endian byte ordering, assuming a hypothetical compile-time #if + test to determine the byte ordering. The constant that we show, + BYTE_ORDER, with values of BIG_ENDIAN and LITTLE_ENDIAN, are for + example purposes only. If an implementation runs on only one type of + hardware it need only define the set of constants for that hardware's + byte ordering.) + + +2.2. The icmp6_hdr Structure + + The ICMPv6 header is needed by numerous IPv6 applications including + Ping, Traceroute, router discovery daemons, and neighbor discovery + daemons. The following structure is defined as a result of including + . Note that this is a new header. + + + + + + + + + + + + + + + + + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 10] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + + struct icmp6_hdr { + uint8_t icmp6_type; /* type field */ + uint8_t icmp6_code; /* code field */ + uint16_t icmp6_cksum; /* checksum field */ + union { + uint32_t icmp6_un_data32[1]; /* type-specific field */ + uint16_t icmp6_un_data16[2]; /* type-specific field */ + uint8_t icmp6_un_data8[4]; /* type-specific field */ + } icmp6_dataun; + }; + + #define icmp6_data32 icmp6_dataun.icmp6_un_data32 + #define icmp6_data16 icmp6_dataun.icmp6_un_data16 + #define icmp6_data8 icmp6_dataun.icmp6_un_data8 + #define icmp6_pptr icmp6_data32[0] /* parameter prob */ + #define icmp6_mtu icmp6_data32[0] /* packet too big */ + #define icmp6_id icmp6_data16[0] /* echo request/reply */ + #define icmp6_seq icmp6_data16[1] /* echo request/reply */ + #define icmp6_maxdelay icmp6_data16[0] /* mcast group membership */ + + + +2.2.1. ICMPv6 Type and Code Values + + In addition to a common structure for the ICMPv6 header, common + definitions are required for the ICMPv6 type and code fields. The + following constants are also defined as a result of including + . + + #define ICMP6_DST_UNREACH 1 + #define ICMP6_PACKET_TOO_BIG 2 + #define ICMP6_TIME_EXCEEDED 3 + #define ICMP6_PARAM_PROB 4 + + #define ICMP6_INFOMSG_MASK 0x80 /* all informational messages */ + + #define ICMP6_ECHO_REQUEST 128 + #define ICMP6_ECHO_REPLY 129 + #define ICMP6_MEMBERSHIP_QUERY 130 + #define ICMP6_MEMBERSHIP_REPORT 131 + #define ICMP6_MEMBERSHIP_REDUCTION 132 + + #define ICMP6_DST_UNREACH_NOROUTE 0 /* no route to destination */ + #define ICMP6_DST_UNREACH_ADMIN 1 /* communication with */ + /* destination */ + /* admin. prohibited */ + #define ICMP6_DST_UNREACH_NOTNEIGHBOR 2 /* not a neighbor */ + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 11] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + #define ICMP6_DST_UNREACH_ADDR 3 /* address unreachable */ + #define ICMP6_DST_UNREACH_NOPORT 4 /* bad port */ + + #define ICMP6_TIME_EXCEED_TRANSIT 0 /* Hop Limit == 0 in transit */ + #define ICMP6_TIME_EXCEED_REASSEMBLY 1 /* Reassembly time out */ + + #define ICMP6_PARAMPROB_HEADER 0 /* erroneous header field */ + #define ICMP6_PARAMPROB_NEXTHEADER 1 /* unrecognized Next Header */ + #define ICMP6_PARAMPROB_OPTION 2 /* unrecognized IPv6 option */ + + The five ICMP message types defined by IPv6 neighbor discovery + (133-137) are defined in the next section. + + +2.2.2. ICMPv6 Neighbor Discovery Type and Code Values + + The following structures and definitions are defined as a result of + including . + + #define ND_ROUTER_SOLICIT 133 + #define ND_ROUTER_ADVERT 134 + #define ND_NEIGHBOR_SOLICIT 135 + #define ND_NEIGHBOR_ADVERT 136 + #define ND_REDIRECT 137 + + struct nd_router_solicit { /* router solicitation */ + struct icmp6_hdr nd_rs_hdr; + /* could be followed by options */ + }; + + #define nd_rs_type nd_rs_hdr.icmp6_type + #define nd_rs_code nd_rs_hdr.icmp6_code + #define nd_rs_cksum nd_rs_hdr.icmp6_cksum + #define nd_rs_reserved nd_rs_hdr.icmp6_data32[0] + + struct nd_router_advert { /* router advertisement */ + struct icmp6_hdr nd_ra_hdr; + uint32_t nd_ra_reachable; /* reachable time */ + uint32_t nd_ra_retransmit; /* retransmit timer */ + /* could be followed by options */ + }; + + #define nd_ra_type nd_ra_hdr.icmp6_type + #define nd_ra_code nd_ra_hdr.icmp6_code + #define nd_ra_cksum nd_ra_hdr.icmp6_cksum + #define nd_ra_curhoplimit nd_ra_hdr.icmp6_data8[0] + #define nd_ra_flags_reserved nd_ra_hdr.icmp6_data8[1] + #define ND_RA_FLAG_MANAGED 0x80 + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 12] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + #define ND_RA_FLAG_OTHER 0x40 + #define nd_ra_router_lifetime nd_ra_hdr.icmp6_data16[1] + + struct nd_neighbor_solicit { /* neighbor solicitation */ + struct icmp6_hdr nd_ns_hdr; + struct in6_addr nd_ns_target; /* target address */ + /* could be followed by options */ + }; + + #define nd_ns_type nd_ns_hdr.icmp6_type + #define nd_ns_code nd_ns_hdr.icmp6_code + #define nd_ns_cksum nd_ns_hdr.icmp6_cksum + #define nd_ns_reserved nd_ns_hdr.icmp6_data32[0] + + struct nd_neighbor_advert { /* neighbor advertisement */ + struct icmp6_hdr nd_na_hdr; + struct in6_addr nd_na_target; /* target address */ + /* could be followed by options */ + }; + + #define nd_na_type nd_na_hdr.icmp6_type + #define nd_na_code nd_na_hdr.icmp6_code + #define nd_na_cksum nd_na_hdr.icmp6_cksum + #define nd_na_flags_reserved nd_na_hdr.icmp6_data32[0] + #if BYTE_ORDER == BIG_ENDIAN + #define ND_NA_FLAG_ROUTER 0x80000000 + #define ND_NA_FLAG_SOLICITED 0x40000000 + #define ND_NA_FLAG_OVERRIDE 0x20000000 + #else /* BYTE_ORDER == LITTLE_ENDIAN */ + #define ND_NA_FLAG_ROUTER 0x00000080 + #define ND_NA_FLAG_SOLICITED 0x00000040 + #define ND_NA_FLAG_OVERRIDE 0x00000020 + #endif + + struct nd_redirect { /* redirect */ + struct icmp6_hdr nd_rd_hdr; + struct in6_addr nd_rd_target; /* target address */ + struct in6_addr nd_rd_dst; /* destination address */ + /* could be followed by options */ + }; + + #define nd_rd_type nd_rd_hdr.icmp6_type + #define nd_rd_code nd_rd_hdr.icmp6_code + #define nd_rd_cksum nd_rd_hdr.icmp6_cksum + #define nd_rd_reserved nd_rd_hdr.icmp6_data32[0] + + struct nd_opt_hdr { /* Neighbor discovery option header */ + uint8_t nd_opt_type; + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 13] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + uint8_t nd_opt_len; /* in units of 8 octets */ + /* followed by option specific data */ + }; + + #define ND_OPT_SOURCE_LINKADDR 1 + #define ND_OPT_TARGET_LINKADDR 2 + #define ND_OPT_PREFIX_INFORMATION 3 + #define ND_OPT_REDIRECTED_HEADER 4 + #define ND_OPT_MTU 5 + + struct nd_opt_prefix_info { /* prefix information */ + uint8_t nd_opt_pi_type; + uint8_t nd_opt_pi_len; + uint8_t nd_opt_pi_prefix_len; + uint8_t nd_opt_pi_flags_reserved; + uint32_t nd_opt_pi_valid_time; + uint32_t nd_opt_pi_preferred_time; + uint32_t nd_opt_pi_reserved2; + struct in6_addr nd_opt_pi_prefix; + }; + + #define ND_OPT_PI_FLAG_ONLINK 0x80 + #define ND_OPT_PI_FLAG_AUTO 0x40 + + struct nd_opt_rd_hdr { /* redirected header */ + uint8_t nd_opt_rh_type; + uint8_t nd_opt_rh_len; + uint16_t nd_opt_rh_reserved1; + uint32_t nd_opt_rh_reserved2; + /* followed by IP header and data */ + }; + + struct nd_opt_mtu { /* MTU option */ + uint8_t nd_opt_mtu_type; + uint8_t nd_opt_mtu_len; + uint16_t nd_opt_mtu_reserved; + uint32_t nd_opt_mtu_mtu; + }; + + We note that the nd_na_flags_reserved flags have the same byte + ordering problems as we discussed with ip6f_offlg. + + +2.3. Address Testing Macros + + The basic API ([RFC-2553]) defines some macros for testing an IPv6 + address for certain properties. This API extends those definitions + with additional address testing macros, defined as a result of + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 14] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + including . + + int IN6_ARE_ADDR_EQUAL(const struct in6_addr *, + const struct in6_addr *); + + + +2.4. Protocols File + + Many hosts provide the file /etc/protocols that contains the names of + the various IP protocols and their protocol number (e.g., the value + of the protocol field in the IPv4 header for that protocol, such as 1 + for ICMP). Some programs then call the function getprotobyname() to + obtain the protocol value that is then specified as the third + argument to the socket() function. For example, the Ping program + contains code of the form + + struct protoent *proto; + + proto = getprotobyname("icmp"); + + s = socket(PF_INET, SOCK_RAW, proto->p_proto); + + Common names are required for the new IPv6 protocols in this file, to + provide portability of applications that call the getprotoXXX() + functions. + + We define the following protocol names with the values shown. These + are taken from ftp://ftp.isi.edu/in-notes/iana/assignments/protocol- + numbers. + + hopopt 0 # hop-by-hop options for ipv6 + ipv6 41 # ipv6 + ipv6-route 43 # routing header for ipv6 + ipv6-frag 44 # fragment header for ipv6 + esp 50 # encapsulating security payload for ipv6 + ah 51 # authentication header for ipv6 + ipv6-icmp 58 # icmp for ipv6 + ipv6-nonxt 59 # no next header for ipv6 + ipv6-opts 60 # destination options for ipv6 + + + +3. IPv6 Raw Sockets + + Raw sockets bypass the transport layer (TCP or UDP). With IPv4, raw + sockets are used to access ICMPv4, IGMPv4, and to read and write IPv4 + datagrams containing a protocol field that the kernel does not + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 15] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + process. An example of the latter is a routing daemon for OSPF, + since it uses IPv4 protocol field 89. With IPv6 raw sockets will be + used for ICMPv6 and to read and write IPv6 datagrams containing a + Next Header field that the kernel does not process. Examples of the + latter are a routing daemon for OSPF for IPv6 and RSVP (protocol + field 46). + + All data sent via raw sockets MUST be in network byte order and all + data received via raw sockets will be in network byte order. This + differs from the IPv4 raw sockets, which did not specify a byte + ordering and used the host's byte order for certain IP header fields. + + Another difference from IPv4 raw sockets is that complete packets + (that is, IPv6 packets with extension headers) cannot be sent or + received using the IPv6 raw sockets API. Instead, ancillary data + objects are used to transfer the extension headers and hoplimit + information, as described later in this document. Should an + application need access to the complete IPv6 packet, some other + technique, such as the datalink interfaces BPF or DLPI, must be used. + + All fields in the IPv6 header that an application might want to + change (i.e., everything other than the version number) can be + modified using ancillary data and/or socket options by the + application for output. All fields in a received IPv6 header (other + than the version number and Next Header fields) and all extension + headers are also made available to the application as ancillary data + on input. Hence there is no need for a socket option similar to the + IPv4 IP_HDRINCL socket option and on receipt the application will + only receive the payload i.e. the data after the IPv6 header and all + the extension headers. + + When writing to a raw socket the kernel will automatically fragment + the packet if its size exceeds the path MTU, inserting the required + fragmentation headers. On input the kernel reassembles received + fragments, so the reader of a raw socket never sees any fragment + headers. + + When we say "an ICMPv6 raw socket" we mean a socket created by + calling the socket function with the three arguments PF_INET6, + SOCK_RAW, and IPPROTO_ICMPV6. + + Most IPv4 implementations give special treatment to a raw socket + created with a third argument to socket() of IPPROTO_RAW, whose value + is normally 255. We note that this value has no special meaning to + an IPv6 raw socket (and the IANA currently reserves the value of 255 + when used as a next-header field). (Note: This feature was added to + IPv4 in 1988 by Van Jacobson to support traceroute, allowing a + complete IP header to be passed by the application, before the + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 16] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + IP_HDRINCL socket option was added.) + + +3.1. Checksums + + The kernel will calculate and insert the ICMPv6 checksum for ICMPv6 + raw sockets, since this checksum is mandatory. + + For other raw IPv6 sockets (that is, for raw IPv6 sockets created + with a third argument other than IPPROTO_ICMPV6), the application + must set the new IPV6_CHECKSUM socket option to have the kernel (1) + compute and store a checksum for output, and (2) verify the received + checksum on input, discarding the packet if the checksum is in error. + This option prevents applications from having to perform source + address selection on the packets they send. The checksum will + incorporate the IPv6 pseudo-header, defined in Section 8.1 of + [RFC-2460]. This new socket option also specifies an integer offset + into the user data of where the checksum is located. + + int offset = 2; + setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset, sizeof(offset)); + + By default, this socket option is disabled. Setting the offset to -1 + also disables the option. By disabled we mean (1) the kernel will + not calculate and store a checksum for outgoing packets, and (2) the + kernel will not verify a checksum for received packets. + + (Note: Since the checksum is always calculated by the kernel for an + ICMPv6 socket, applications are not able to generate ICMPv6 packets + with incorrect checksums (presumably for testing purposes) using this + API.) + + +3.2. ICMPv6 Type Filtering + + ICMPv4 raw sockets receive most ICMPv4 messages received by the + kernel. (We say "most" and not "all" because Berkeley-derived + kernels never pass echo requests, timestamp requests, or address mask + requests to a raw socket. Instead these three messages are processed + entirely by the kernel.) But ICMPv6 is a superset of ICMPv4, also + including the functionality of IGMPv4 and ARPv4. This means that an + ICMPv6 raw socket can potentially receive many more messages than + would be received with an ICMPv4 raw socket: ICMP messages similar to + ICMPv4, along with neighbor solicitations, neighbor advertisements, + and the three multicast listener discovery messages. + + Most applications using an ICMPv6 raw socket care about only a small + subset of the ICMPv6 message types. To transfer extraneous ICMPv6 + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 17] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + messages from the kernel to user can incur a significant overhead. + Therefore this API includes a method of filtering ICMPv6 messages by + the ICMPv6 type field. + + Each ICMPv6 raw socket has an associated filter whose datatype is + defined as + + struct icmp6_filter; + + This structure, along with the macros and constants defined later in + this section, are defined as a result of including the + header. + + The current filter is fetched and stored using getsockopt() and + setsockopt() with a level of IPPROTO_ICMPV6 and an option name of + ICMP6_FILTER. + + Six macros operate on an icmp6_filter structure: + + void ICMP6_FILTER_SETPASSALL (struct icmp6_filter *); + void ICMP6_FILTER_SETBLOCKALL(struct icmp6_filter *); + + void ICMP6_FILTER_SETPASS ( int, struct icmp6_filter *); + void ICMP6_FILTER_SETBLOCK( int, struct icmp6_filter *); + + int ICMP6_FILTER_WILLPASS (int, + const struct icmp6_filter *); + int ICMP6_FILTER_WILLBLOCK(int, + const struct icmp6_filter *); + + The first argument to the last four macros (an integer) is an ICMPv6 + message type, between 0 and 255. The pointer argument to all six + macros is a pointer to a filter that is modified by the first four + macros examined by the last two macros. + + The first two macros, SETPASSALL and SETBLOCKALL, let us specify that + all ICMPv6 messages are passed to the application or that all ICMPv6 + messages are blocked from being passed to the application. + + The next two macros, SETPASS and SETBLOCK, let us specify that + messages of a given ICMPv6 type should be passed to the application + or not passed to the application (blocked). + + The final two macros, WILLPASS and WILLBLOCK, return true or false + depending whether the specified message type is passed to the + application or blocked from being passed to the application by the + filter pointed to by the second argument. + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 18] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + When an ICMPv6 raw socket is created, it will by default pass all + ICMPv6 message types to the application. + + As an example, a program that wants to receive only router + advertisements could execute the following: + + struct icmp6_filter myfilt; + + fd = socket(PF_INET6, SOCK_RAW, IPPROTO_ICMPV6); + + ICMP6_FILTER_SETBLOCKALL(&myfilt); + ICMP6_FILTER_SETPASS(ND_ROUTER_ADVERT, &myfilt); + setsockopt(fd, IPPROTO_ICMPV6, ICMP6_FILTER, &myfilt, sizeof(myfilt)); + + The filter structure is declared and then initialized to block all + messages types. The filter structure is then changed to allow router + advertisement messages to be passed to the application and the filter + is installed using setsockopt(). + + The icmp6_filter structure is similar to the fd_set datatype used + with the select() function in the sockets API. The icmp6_filter + structure is an opaque datatype and the application should not care + how it is implemented. All the application does with this datatype + is allocate a variable of this type, pass a pointer to a variable of + this type to getsockopt() and setsockopt(), and operate on a variable + of this type using the six macros that we just defined. + + Nevertheless, it is worth showing a simple implementation of this + datatype and the six macros. + + struct icmp6_filter { + uint32_t icmp6_filt[8]; /* 8*32 = 256 bits */ + }; + + #define ICMP6_FILTER_WILLPASS(type, filterp) \ + ((((filterp)->icmp6_filt[(type) >> 5]) & (1 << ((type) & 31))) != 0) + #define ICMP6_FILTER_WILLBLOCK(type, filterp) \ + ((((filterp)->icmp6_filt[(type) >> 5]) & (1 << ((type) & 31))) == 0) + #define ICMP6_FILTER_SETPASS(type, filterp) \ + ((((filterp)->icmp6_filt[(type) >> 5]) |= (1 << ((type) & 31)))) + #define ICMP6_FILTER_SETBLOCK(type, filterp) \ + ((((filterp)->icmp6_filt[(type) >> 5]) &= ~(1 << ((type) & 31)))) + #define ICMP6_FILTER_SETPASSALL(filterp) \ + memset((filterp), 0xFF, sizeof(struct icmp6_filter)) + #define ICMP6_FILTER_SETBLOCKALL(filterp) \ + memset((filterp), 0, sizeof(struct icmp6_filter)) + + (Note: These sample definitions have two limitations that an + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 19] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + implementation may want to change. The first four macros evaluate + their first argument two times. The second two macros require the + inclusion of the header for the memset() function.) + + +4. Access to IPv6 and Extension Headers + + Applications need to be able to control IPv6 header and extension + header content when sending as well as being able to receive the + content of these headers. This is done by defining socket option + types which can be used both with setsockopt and with ancillary data. + Ancillary data is discussed in Appendix A. The following optional + information can be exchanged between the application and the kernel: + + 1. The send/receive interface and source/destination address, + 2. The hop limit, + 3. Next hop address, + 4. Routing header. + 5. Hop-by-Hop options, and + 6. Destination options (both before and after a Routing header). + + First, to receive any of this optional information (other than the + next hop address, which can only be set), the application must call + setsockopt() to turn on the corresponding flag: + + int on = 1; + + setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on)); + setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on)); + setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); + setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on)); + setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); + setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDRDSTOPTS, + &on, sizeof(on)); + + When any of these options are enabled, the corresponding data is + returned as control information by recvmsg(), as one or more + ancillary data objects. + + Two different mechanisms exist for sending this optional information: + + 1. Using setsockopt to specify the option content for a socket. + These are known an "sticky" options since they effect all + transmitted packets on the socket until either the a new + setsockopt is done or the options are overridden using ancillary + data. + + 2. Using ancillary data to specify the option content for a single + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 20] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + datagram. This only applies to datagram and raw sockets; not to + TCP sockets. + + + The three socket option parameters and the three cmsghdr fields that + describe the options/ancillary data objects are summarized as: + + opt level/ optname/ optval/ + cmsg_level cmsg_type cmsg_data[] + ------------ ------------ ------------------------ + IPPROTO_IPV6 IPV6_PKTINFO in6_pktinfo structure + IPPROTO_IPV6 IPV6_HOPLIMIT int + IPPROTO_IPV6 IPV6_NEXTHOP socket address structure + IPPROTO_IPV6 IPV6_RTHDR implementation dependent + IPPROTO_IPV6 IPV6_HOPOPTS implementation dependent + IPPROTO_IPV6 IPV6_DSTOPTS implementation dependent + IPPROTO_IPV6 IPV6_RTHDRDSTOPTS implementation dependent + + + All these options are described in detail in following sections. All + the constants beginning with IPV6_ are defined as a result of + including the header. + + (Note: We intentionally use the same constant for the cmsg_level + member as is used as the second argument to getsockopt() and + setsockopt() (what is called the "level"), and the same constant for + the cmsg_type member as is used as the third argument to getsockopt() + and setsockopt() (what is called the "option name"). This is + consistent with the existing use of ancillary data in 4.4BSD: + returning the destination address of an IPv4 datagram.) + + (Note: It is up to the implementation what it passes as ancillary + data for the Routing header option, Hop-by-Hop option, and + Destination options, since the API to these features is through a set + of inet6_rth_XXX() and inet6_opt_XXX() functions that we define + later. These functions serve two purposes: to simplify the interface + to these features (instead of requiring the application to know the + intimate details of the extension header formats), and to hide the + actual implementation from the application. Nevertheless, we show + some examples of these features that store the actual extension + header as the ancillary data. Implementations need not use this + technique.) + + +4.1. TCP Implications + + It is not possible to use ancillary data to transmit the above + options for TCP since there is not a one-to-one mapping between send + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 21] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + operations and the TCP segments being transmitted. Instead an + application can use setsockopt to specify them as sticky options. + When the application uses setsockopt to specify the above options it + is expected that TCP will start using the new information when + sending segments. However, TCP may or may not use the new + information when retransmitting segments that were originally sent + when the old sticky options were in effect. + + Applications using TCP can use ancillary data (after enabling the + desired IPV6_RECVxxx options) to receive the IPv6 and extension + header information. However, since there is not a one-to-one mapping + between received TCP segments and recv operations seen by the + application, when different TCP segments have different IPv6 and + extension headers the application might not be able to observe all + received headers. For efficiency reasons it is recommended that a + TCP implementation not send ancillary data items with every received + segment but instead try to detect the points in the data stream when + the requested IPv6 and extension header content changes and only send + a single ancillary data item at the time of the change. Also, TCP + should send ancillary data items at the start of the connection and + when the application enables a new IPV6_RECVxxx option. + + For example, assume an application has enabled IPV6_RECVHOPLIMIT + before a connection is established. Then the first recvmsg() would + have an IPV6_HOPLIMIT item indicating the hop limit in the first data + segment. Should the hoplimit in the received data segment change a + subsequent recvmsg() will also have an IPV6_HOPLIMIT item. However, + the application must be prepared to handle ancillary data items even + though the hop limit did not change. Note that should the hop limit + in received ACK-only segments be different than the hop limit in data + segments the application might only be able to observe the hop limit + in the received data segments. + + The above example was for hop limit but the application should be + prepared to handle the corresponding behavior for the other option + information. + + The above recvmsg() behavior allows the application to detect changes + in the received IPv6 and extension headers without resorting to + periodic getsockopt() calls. + + +4.2. UDP and Raw Socket Implications + + The receive behavior for UDP and raw sockets is quite + straightforward. After the application has enabled an IPV6_RECVxxx + socket option it will receive ancillary data items for every + recvmsg() call containing the requested information. If the + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 22] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + application asks for e.g., IPV6_RTHDR and a received datagram does + not contain a Routing header an implementation might either exclude + the IPV6_RTHDR ancillary data item or pass up an item with zero + length (cmsg_data being zero length). Note that due to buffering in + the socket implementation there might be some packets queued when an + IPV6_RECVxxx option is enabled and they might not have the ancillary + data information. + + For sending the application has the choice between using sticky + options and ancillary data. The application can also use both having + the sticky options specify the "default" and using ancillary data to + override the default options. Note that if any ancillary data is + specified in a call to sendmsg(), all of the sticky options are + overridden for that datagram. For example, if the application has + set IPV6_RTHDR using a sticky option and later passes IPV6_HOPLIMIT + as ancillary data this will override the IPV6_RTHDR sticky option and + no Routing header will be sent with that datagram. + + +5. Packet Information + + There are four pieces of information that an application can specify + for an outgoing packet using ancillary data: + + 1. the source IPv6 address, + 2. the outgoing interface index, + 3. the outgoing hop limit, and + 4. the next hop address. + + Three similar pieces of information can be returned for a received + packet as ancillary data: + + 1. the destination IPv6 address, + 2. the arriving interface index, and + 3. the arriving hop limit. + + + The first two pieces of information are contained in an in6_pktinfo + structure that is set with setsockopt() or sent as ancillary data + with sendmsg() and received as ancillary data with recvmsg(). This + structure is defined as a result of including the + header. + + struct in6_pktinfo { + struct in6_addr ipi6_addr; /* src/dst IPv6 address */ + unsigned int ipi6_ifindex; /* send/recv interface index */ + }; + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 23] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + In the socket option and cmsghdr level will be IPPROTO_IPV6, the type + will be IPV6_PKTINFO, and the first byte of the option value and + cmsg_data[] will be the first byte of the in6_pktinfo structure. An + application can clear any sticky IPV6_PKTINFO option by either doing + a setsockopt for option with optlen being zero, or by doing a + "regular" setsockopt with ipi6_addr being in6addr_any and + ipi6_ifindex being zero. + + This information is returned as ancillary data by recvmsg() only if + the application has enabled the IPV6_RECVPKTINFO socket option: + + int on = 1; + setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on)); + + + (Note: The hop limit is not contained in the in6_pktinfo structure + for the following reason. Some UDP servers want to respond to client + requests by sending their reply out the same interface on which the + request was received and with the source IPv6 address of the reply + equal to the destination IPv6 address of the request. To do this the + application can enable just the IPV6_RECVPKTINFO socket option and + then use the received control information from recvmsg() as the + outgoing control information for sendmsg(). The application need not + examine or modify the in6_pktinfo structure at all. But if the hop + limit were contained in this structure, the application would have to + parse the received control information and change the hop limit + member, since the received hop limit is not the desired value for an + outgoing packet.) + + +5.1. Specifying/Receiving the Interface + + Interfaces on an IPv6 node are identified by a small positive + integer, as described in Section 4 of [RFC-2553]. That document also + describes a function to map an interface name to its interface index, + a function to map an interface index to its interface name, and a + function to return all the interface names and indexes. Notice from + this document that no interface is ever assigned an index of 0. + + When specifying the outgoing interface, if the ipi6_ifindex value is + 0, the kernel will choose the outgoing interface. If the application + specifies an outgoing interface for a multicast packet, the interface + specified by the ancillary data overrides any interface specified by + the IPV6_MULTICAST_IF socket option (described in [RFC-2553]), for + that call to sendmsg() only. + + When the IPV6_PKTINFO socket option is enabled, the received + interface index is always returned as the ipi6_ifindex member of the + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 24] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + in6_pktinfo structure. + + +5.2. Specifying/Receiving Source/Destination Address + + The source IPv6 address can be specified by calling bind() before + each output operation, but supplying the source address together with + the data requires less overhead (i.e., fewer system calls) and + requires less state to be stored and protected in a multithreaded + application. + + When specifying the source IPv6 address as ancillary data, if the + ipi6_addr member of the in6_pktinfo structure is the unspecified + address (IN6ADDR_ANY_INIT or in6addr_any), then (a) if an address is + currently bound to the socket, it is used as the source address, or + (b) if no address is currently bound to the socket, the kernel will + choose the source address. If the ipi6_addr member is not the + unspecified address, but the socket has already bound a source + address, then the ipi6_addr value overrides the already-bound source + address for this output operation only. + + The kernel must verify that the requested source address is indeed a + unicast address assigned to the node. + + When the in6_pktinfo structure is returned as ancillary data by + recvmsg(), the ipi6_addr member contains the destination IPv6 address + from the received packet. + + +5.3. Specifying/Receiving the Hop Limit + + The outgoing hop limit is normally specified with either the + IPV6_UNICAST_HOPS socket option or the IPV6_MULTICAST_HOPS socket + option, both of which are described in [RFC-2553]. Specifying the + hop limit as ancillary data lets the application override either the + kernel's default or a previously specified value, for either a + unicast destination or a multicast destination, for a single output + operation. Returning the received hop limit is useful for programs + such as Traceroute and for IPv6 applications that need to verify that + the received hop limit is 255 (e.g., that the packet has not been + forwarded). + + The received hop limit is returned as ancillary data by recvmsg() + only if the application has enabled the IPV6_RECVHOPLIMIT socket + option: + + int on = 1; + setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on)); + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 25] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + In the cmsghdr structure containing this ancillary data, the + cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be + IPV6_HOPLIMIT, and the first byte of cmsg_data[] will be the first + byte of the integer hop limit. + + Nothing special need be done to specify the outgoing hop limit: just + specify the control information as ancillary data for sendmsg() or + using setsockopt(). As specified in [RFC-2553], the interpretation + of the integer hop limit value is + + x < -1: return an error of EINVAL + x == -1: use kernel default + 0 <= x <= 255: use x + x >= 256: return an error of EINVAL + + + +5.4. Specifying the Next Hop Address + + The IPV6_NEXTHOP ancillary data object specifies the next hop for the + datagram as a socket address structure. In the cmsghdr structure + containing this ancillary data, the cmsg_level member will be + IPPROTO_IPV6, the cmsg_type member will be IPV6_NEXTHOP, and the + first byte of cmsg_data[] will be the first byte of the socket + address structure. + + This is a privileged option. (Note: It is implementation defined and + beyond the scope of this document to define what "privileged" means. + Unix systems use this term to mean the process must have an effective + user ID of 0.) + + If the socket address structure contains an IPv6 address (e.g., the + sin6_family member is AF_INET6), then the node identified by that + address must be a neighbor of the sending host. If that address + equals the destination IPv6 address of the datagram, then this is + equivalent to the existing SO_DONTROUTE socket option. + + +5.5. Additional Errors with sendmsg() and setsockopt() + + With the IPV6_PKTINFO socket option there are no additional errors + possible with the call to recvmsg(). But when specifying the + outgoing interface or the source address, additional errors are + possible from sendmsg() or setsockopt(). Note that some + implementations might only be able to return this type of errors for + setsockopt(). The following are examples, but some of these may not + be provided by some implementations, and some implementations may + define additional errors: + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 26] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + ENXIO The interface specified by ipi6_ifindex does not exist. + + ENETDOWN The interface specified by ipi6_ifindex is not enabled + for IPv6 use. + + EADDRNOTAVAIL ipi6_ifindex specifies an interface but the address + ipi6_addr is not available for use on that interface. + + EHOSTUNREACH No route to the destination exists over the interface + specified by ifi6_ifindex. + + +6. Routing Header Option + + Source routing in IPv6 is accomplished by specifying a Routing header + as an extension header. There can be different types of Routing + headers, but IPv6 currently defines only the Type 0 Routing header + [RFC-2460]. This type supports up to 127 intermediate nodes (limited + by the length field in the extension header). With this maximum + number of intermediate nodes, a source, and a destination, there are + 128 hops. + + Source routing with IPv4 sockets API (the IP_OPTIONS socket option) + requires the application to build the source route in the format that + appears as the IPv4 header option, requiring intimate knowledge of + the IPv4 options format. This IPv6 API, however, defines eight + functions that the application calls to build and examine a Routing + header, and the ability to use sticky options or ancillary data to + communicate this information between the application and the kernel. + + Three functions build a Routing header: + + inet6_rth_space() - return #bytes required for Routing header + inet6_rth_init() - initialize buffer data for Routing header + inet6_rth_add() - add one IPv6 address to the Routing header + + Three functions deal with a returned Routing header: + + inet6_rth_reverse() - reverse a Routing header + inet6_rth_segments() - return #segments in a Routing header + inet6_rth_getaddr() - fetch one address from a Routing header + + The function prototypes for these functions are all in the + header. + + To receive a Routing header the application must enable the + IPV6_RECVRTHDR socket option: + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 27] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + + int on = 1; + setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); + + To send a Routing header the application specifies it either as + ancillary data in a call to sendmsg() or using setsockopt(). + + The application can remove any sticky Routing header by calling + setsockopt() for IPV6_RTHDR with a zero option length. + + When using ancillary data a Routing header is passed between the + application and the kernel as follows: The cmsg_level member has a + value of IPPROTO_IPV6 and the cmsg_type member has a value of + IPV6_RTHDR. The contents of the cmsg_data[] member is implementation + dependent and should not be accessed directly by the application, but + should be accessed using the six functions that we are about to + describe. + + The following constant is defined in the header: + + #define IPV6_RTHDR_TYPE_0 0 /* IPv6 Routing header type 0 */ + + When a Routing header is specified, the destination address specified + for connect(), sendto(), or sendmsg() is the final destination + address of the datagram. The Routing header then contains the + addresses of all the intermediate nodes. + + +6.1. inet6_rth_space + + + size_t inet6_rth_space(int type, int segments); + + This function returns the number of bytes required to hold a Routing + header of the specified type containing the specified number of + segments (addresses). For an IPv6 Type 0 Routing header, the number + of segments must be between 0 and 127, inclusive. The return value + is just the space for the Routing header. When the application uses + ancillary data it must pass the returned length to CMSG_LEN to + determine how much memory is needed for the ancillary data object + (including the cmsghdr structure). + + If the return value is 0, then either the type of the Routing header + is not supported by this implementation or the number of segments is + invalid for this type of Routing header. + + (Note: This function returns the size but does not allocate the space + required for the ancillary data. This allows an application to + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 28] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + allocate a larger buffer, if other ancillary data objects are + desired, since all the ancillary data objects must be specified to + sendmsg() as a single msg_control buffer.) + + +6.2. inet6_rth_init + + + void *inet6_rth_init(void *bp, int bp_len, int type, int segments); + + This function initializes the buffer pointed to by bp to contain a + Routing header of the specified type. When the application uses + ancillary data the application must initialize any cmsghdr fields. + + The caller must allocate the buffer and its size can be determined by + calling inet6_rth_space(). + + Upon success the return value is the pointer to the buffer (bp), and + this is then used as the first argument to the next two functions. + Upon an error the return value is NULL. + + +6.3. inet6_rth_add + + + int inet6_rth_add(void *bp, const struct in6_addr *addr); + + This function adds the IPv6 address pointed to by addr to the end of + the Routing header being constructed. + + If successful, the segleft member of the Routing Header is updated to + account for the new address in the Routing header and the return + value of the function is 0. Upon an error the return value of the + function is -1. + + +6.4. inet6_rth_reverse + + + int inet6_rth_reverse(const void *in, void *out) + + This function takes a Routing header extension header (pointed to by + the first argument) and writes a new Routing header that sends + datagrams along the reverse of that route. Both arguments are + allowed to point to the same buffer (that is, the reversal can occur + in place). + + The return value of the function is 0 on success, or -1 upon an + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 29] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + error. + + +6.5. inet6_rth_segments + + + int inet6_rth_segments(const void *bp); + + This function returns the number of segments (addresses) contained in + the Routing header described by bp. On success the return value is + zero or greater. The return value of the function is -1 upon an + error. + + +6.6. inet6_rth_getaddr + + + struct in6_addr *inet6_rth_getaddr(const void *bp, int index); + + This function returns a pointer to the IPv6 address specified by + index (which must have a value between 0 and one less than the value + returned by inet6_rth_segments()) in the Routing header described by + bp. An application should first call inet6_rth_segments() to obtain + the number of segments in the Routing header. + + Upon an error the return value of the function is NULL. + + +7. Hop-By-Hop Options + + A variable number of Hop-by-Hop options can appear in a single Hop- + by-Hop options header. Each option in the header is TLV-encoded with + a type, length, and value. + + Today only three Hop-by-Hop options are defined for IPv6 [RFC-2460]: + Jumbo Payload, Pad1, and PadN, although a proposal exists for a + router-alert Hop-by-Hop option. The Jumbo Payload option should not + be passed back to an application and an application should receive an + error if it attempts to set it. This option is processed entirely by + the kernel. It is indirectly specified by datagram-based + applications as the size of the datagram to send and indirectly + passed back to these applications as the length of the received + datagram. The two pad options are for alignment purposes and are + automatically inserted by a sending kernel when needed and ignored by + the receiving kernel. This section of the API is therefore defined + for future Hop-by-Hop options that an application may need to specify + and receive. + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 30] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + Individual Hop-by-Hop options (and Destination options, which are + described shortly, and which are very similar to the Hop-by-Hop + options) may have specific alignment requirements. For example, the + 4-byte Jumbo Payload length should appear on a 4-byte boundary, and + IPv6 addresses are normally aligned on an 8-byte boundary. These + requirements and the terminology used with these options are + discussed in Section 4.2 and Appendix B of [RFC-2460]. The alignment + of first byte of each option is specified by two values, called x and + y, written as "xn + y". This states that the option must appear at + an integer multiple of x bytes from the beginning of the options + header (x can have the values 1, 2, 4, or 8), plus y bytes (y can + have a value between 0 and 7, inclusive). The Pad1 and PadN options + are inserted as needed to maintain the required alignment. The + functions below need to know the alignment of the end of the option + (which is always in the form "xn," where x can have the values 1, 2, + 4, or 8) and the total size of the data portion of the option. These + are passed as the "align" and "len" arguments to inet6_opt_append(). + + Multiple Hop-by-Hop options must be specified by the application by + placing them in a single extension header. + + Finally, we note that use of some Hop-by-Hop options or some + Destination options, might require special privilege. That is, + normal applications (without special privilege) might be forbidden + from setting certain options in outgoing packets, and might never see + certain options in received packets. + + +7.1. Receiving Hop-by-Hop Options + + To receive Hop-by-Hop options the application must enable the + IPV6_RECVHOPOPTS socket option: + + int on = 1; + setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on)); + + When using ancillary data a Hop-by-hop options is passed between the + application and the kernel as follows: The cmsg_level member will be + IPPROTO_IPV6 and the cmsg_type member will be IPV6_HOPOPTS. These + options are then processed by calling the inet6_opt_next(), + inet6_opt_find(), and inet6_opt_get_val() functions, described + shortly. + + +7.2. Sending Hop-by-Hop Options + + To send a Hop-by-Hop options header, the application specifies the + header either as ancillary data in a call to sendmsg() or using + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 31] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + setsockopt(). + + The application can remove any sticky Hop-by-Hop extension header by + calling setsockopt() for IPV6_HOPOPTS with a zero option length. + + All the Hop-by-Hop options must specified by a single ancillary data + object. The cmsg_level member is set to IPPROTO_IPV6 and the + cmsg_type member is set to IPV6_HOPOPTS. The option is normally + constructed using the inet6_opt_init(), inet6_opt_append(), + inet6_opt_finish(), and inet6_set_val() functions, described shortly. + + Additional errors may be possible from sendmsg() and setsockopt() if + the specified option is in error. + + +8. Destination Options + + A variable number of Destination options can appear in one or more + Destination option headers. As defined in [RFC-2460], a Destination + options header appearing before a Routing header is processed by the + first destination plus any subsequent destinations specified in the + Routing header, while a Destination options header appearing after a + Routing header is processed only by the final destination. As with + the Hop-by-Hop options, each option in a Destination options header + is TLV-encoded with a type, length, and value. + + Today no Destination options are defined for IPv6 [RFC-2460], + although proposals exist to use Destination options with Mobile IPv6. + + +8.1. Receiving Destination Options + + To receive Destination options appearing after a Routing header (or + in a packet without a Routing header) the application must enable the + IPV6_RECVDSTOPTS socket option: + + int on = 1; + setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on)); + + To receive Destination options appearing before a Routing header the + application must enable the IPV6_RECVRTHDRDSTOPTS socket option: + + int on = 1; + setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDRDSTOPTS, + &on, sizeof(on)); + + All the Destination options appearing before a Routing header are + returned as one ancillary data object described by a cmsghdr + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 32] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + structure (with cmsg_type set to IPV6_RTHDRDSTOPTS) and all the + Destination options appearing after a Routing header (or in a packet + without a Routing header) are returned as another ancillary data + object described by a cmsghdr structure (with cmsg_type set to + IPV6_DSTOPTS). For all these ancillary data objects, the cmsg_level + member will be IPPROTO_IPV6. + + These options are then processed by calling the inet6_opt_next(), + inet6_opt_find(), and inet6_opt_get_value() functions. + + +8.2. Sending Destination Options + + To send a Destination options header, the application specifies it + either as ancillary data in a call to sendmsg() or using + setsockopt(). + + The application can remove any sticky Destination extension header by + calling setsockopt() for IPV6_RTHDRDSTOPTS/IPV6_DSTOPTS with a zero + option length. + + As described earlier, one set of Destination options can appear + before a Routing header, and one set can appear after a Routing + header (or in a packet with no Routing header). Each set can consist + of one or more options but each set is a single extension header. + + When using ancillary data a Destination options header is passed + between the application and the kernel as follows: The set preceding + a Routing header are specified with the cmsg_level member is set to + IPPROTO_IPV6 and the cmsg_type member is set to IPV6_RTHDRDSTOPTS. + Any setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently + ignore when sending packets unless a Routing header is also + specified. + + The set of Destination options after a Routing header, which are also + used when no Routing header is present, are specified with the + cmsg_level member is set to IPPROTO_IPV6 and the cmsg_type member is + set to IPV6_DSTOPTS. + + The Destination options are normally constructed using the + inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and + inet6_set_val() functions, described shortly. + + Additional errors may be possible from sendmsg() and setsockopt() if + the specified option is in error. + + +9. Hop-by-Hop and Destination Options Processing + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 33] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + Building and parsing the Hop-by-Hop and Destination options is + complicated for the reasons given earlier. We therefore define a set + of functions to help the application. The function prototypes for + these functions are all in the header. + + The first 3 functions (init, append, and finish) are used both to + calculate the needed buffer size for the options, and to actually + encode the options once the application has allocated a buffer for + the header. In order to only calculate the size the application must + pass a NULL extbuf and a zero extlen to those functions. + + +9.1. inet6_opt_init + + + int inet6_opt_init(void *extbuf, size_t extlen); + + This function returns the number of bytes needed for the empty + extension header i.e. without any options. If extbuf is not NULL it + also initializes the extension header to have the correct length + field. If the extlen value is too small or not a multiple of 8 the + function fails and returns -1. + + +9.2. inet6_opt_append + + + int inet6_opt_append(void *extbuf, size_t extlen, int prevlen, + uint8_t type, size_t len, uint_t align, + void **databufp); + + Prevlen should be the length returned by inet6_opt_init() or a + previous inet6_opt_append(). This function returns the updated total + length taking into account adding an option with length 'len' and + alignment 'align'. If extbuf is not NULL then, in addition to + returning the length, the function inserts any needed pad option, + initializes the option (setting the type and length fields) and + returns a pointer to the location for the option content in databufp. + If the option does not fit in the extension header buffer the + function returns -1. + + type is the 8-bit option type. len is the length of the option data + (i.e. excluding the option type and option length fields). + + Once inet6_opt_append() has been called the application can use the + databuf directly, or use inet6_opt_set_val() to specify the content + of the option. + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 34] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + The option type must have a value from 2 to 255, inclusive. (0 and 1 + are reserved for the Pad1 and PadN options, respectively.) + + The option data length must have a value between 0 and 255, + inclusive, and is the length of the option data that follows. + + The align parameter must have a value of 1, 2, 4, or 8. The len + value can not exceed the value of align. + + +9.3. inet6_opt_finish + + + int inet6_opt_finish(void *extbuf, size_t extlen, int prevlen); + + Prevlen should be the length returned by inet6_opt_init() or + inet6_opt_append(). This function returns the updated total length + taking into account the final padding of the extension header to make + it a multiple of 8 bytes. If extbuf is not NULL the function also + initializes the option by inserting a Pad1 or PadN option of the + proper length. + + If the necessary pad does not fit in the extension header buffer the + function returns -1. + + +9.4. inet6_opt_set_val + + + int inet6_opt_set_val(void *databuf, size_t offset, void *val, + int vallen); + + Databuf should be a pointer returned by inet6_opt_append(). This + function inserts data items of various sizes (1, 2, 4, or 8 bytes) in + the data portion of the option. val should point to the data to be + inserted. Offset specifies where in the data portion of the option + the value should be inserted; the first byte after the option type + and length is accessed by specifying an offset of zero. + + The function returns the offset for the next field (i.e., offset + + vallen) which can be used when composing option content with multiple + fields. + + +9.5. inet6_opt_next + + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 35] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + + int inet6_opt_next(void *extbuf, size_t extlen, int prevlen, + uint8_t *typep, size_t *lenp, + void **databufp); + + This function parses received extension headers returning the next + option. Extbuf and extlen specifies the extension header. Prevlen + should either be zero (for the first option) or the length returned + previous inet6_opt_next() or inet6_opt_find(). It specifies the + position where to continue scanning the extension buffer. The next + option is returned by updating typep, lenp, and databufp. This + function returns the updated "previous" length taking into account + the option that was returned. + + +9.6. inet6_opt_find + + + int inet6_opt_find(void *extbuf, size_t extlen, int prevlen, + uint8_t type, size_t *lenp, + void **databufp); + + This function is similar to the previously described inet6_opt_next() + function, except this function lets the caller specify the option + type to be searched for, instead of always returning the next option + in the extension header. + + If an option of the specified type is located, the function returns + the updated "previous" total length taking into account the option + that was returned and any options that didn't match the type. + + If an option of the specified type is not located, the return value + is -1. If an error occurs, the return value is -1. + + +9.7. inet6_opt_get_val + + + int inet6_opt_get_val(void *databuf, size_t offset, void *val, + int vallen); + + Databuf should be a pointer returned by inet6_opt_next() or + inet6_opt_find(). This function extracts data items of various sizes + (1, 2, 4, or 8 bytes) in the data portion of the option. val should + point to the destination for the extracted data. Offset specifies + from where in the data portion of the option the value should be + extracted; the first byte after the option type and length is + accessed by specifying an offset of zero. + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 36] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + The function returns the offset for the next field (i.e., offset + + vallen) which can be used when extracting option content with + multiple fields. + + +10. Ordering of Ancillary Data and IPv6 Extension Headers + + Three IPv6 extension headers can be specified by the application and + returned to the application using ancillary data with sendmsg() and + recvmsg(): the Routing header, Hop-by-Hop options, and Destination + options. When multiple ancillary data objects are transferred via + recvmsg() and these objects represent any of these three extension + headers, their placement in the control buffer is directly tied to + their location in the corresponding IPv6 datagram. This API imposes + some ordering constraints for using these ancillary data objects with + sendmsg(). + + All Hop-by-Hop options must be specified in a single ancillary data + object. Should multiple be specified the implementation might choose + an arbitrary one or drop the packet. + + All Destination options that precede a Routing header must be + specified in a single ancillary data object. If there is no Routing + header ancillary data object the IPV6_RTHDRDSTOPTS object will be + silently ignored. + + All Destination options that follow a Routing header (or are used + without a Routing header) must be specified in a single ancillary + data object. + + If Destination options are specified in the control buffer after a + Routing header, or if Destination options are specified without a + Routing header, the kernel will place those Destination options after + an authentication header and/or an encapsulating security payload + header, if present. + + +11. IPv6-Specific Options with IPv4-Mapped IPv6 Addresses + + The various socket options and ancillary data specifications defined + in this document apply only to true IPv6 sockets. It is possible to + create an IPv6 socket that actually sends and receives IPv4 packets, + using IPv4-mapped IPv6 addresses, but the mapping of the options + defined in this document to an IPv4 datagram is beyond the scope of + this document. + + In general, attempting to specify an IPv6-only option, such as the + Hop-by-Hop options, Destination options, or Routing header on an IPv6 + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 37] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + socket that is using IPv4-mapped IPv6 addresses, will probably result + in an error. Some implementations, however, may provide access to + the packet information (source/destination address, send/receive + interface, and hop limit) on an IPv6 socket that is using IPv4-mapped + IPv6 addresses. + + +12. Extended interfaces for rresvport, rcmd and rexec + + TBD + + +12.1. rresvport_af + + The rresvport() function is used by the rcmd() function, and this + function is in turn called by many of the "r" commands such as + rlogin. While new applications are not being written to use the + rcmd() function, legacy applications such as rlogin will continue to + use it and these will be ported to IPv6. + + rresvport() creates an IPv4/TCP socket and binds a "reserved port" to + the socket. Instead of defining an IPv6 version of this function we + define a new function that takes an address family as its argument. + + #include + + int rresvport_af(int *port, int family); + + This function behaves the same as the existing rresvport() function, + but instead of creating an IPv4/TCP socket, it can also create an + IPv6/TCP socket. The family argument is either AF_INET or AF_INET6, + and a new error return is EAFNOSUPPORT if the address family is not + supported. + + (Note: There is little consensus on which header defines the + rresvport() and rcmd() function prototypes. 4.4BSD defines it in + , others in , and others don't define the function + prototypes at all.) + + +12.2. rcmd_af + + TBD + + int rcmd_af(char **ahost, unsigned short rport, const char *locuser, + const char *remuser, const char *cmd, int *fd2p, int af) + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 38] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + +12.3. rexec_af + + TBD + + int rexec_af(char **ahost, unsigned short rport, const char *name, + const char *pass, const char *cmd, int *fd2p, int af) + + + +13. Future Items + + Some additional items may require standardization, but no concrete + proposals have been made for the API to perform these tasks. These + may be addressed in a later document. + + +13.1. Flow Labels + + Earlier revisions of this document specified a set of + inet6_flow_XXX() functions to assign, share, and free IPv6 flow + labels. Consensus, however, indicated that it was premature to + specify this part of the API. + + +13.2. Path MTU Discovery and UDP + + A standard method may be desirable for a UDP application to determine + the "maximum send transport-message size" (Section 5.1 of [RFC-1981]) + to a given destination. This would let the UDP application send + smaller datagrams to the destination, avoiding fragmentation. + + +13.3. Neighbor Reachability and UDP + + A standard method may be desirable for a UDP application to tell the + kernel that it is making forward progress with a given peer (Section + 7.3.1 of [RFC-2461]). This could save unneeded neighbor + solicitations and neighbor advertisements. + + +14. Summary of New Definitions + + The following list summarizes the constants and structure, + definitions discussed in this memo, sorted by header. + + ICMP6_DST_UNREACH + ICMP6_DST_UNREACH_ADDR + ICMP6_DST_UNREACH_ADMIN + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 39] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + ICMP6_DST_UNREACH_NOPORT + ICMP6_DST_UNREACH_NOROUTE + ICMP6_DST_UNREACH_NOTNEIGHBOR + ICMP6_ECHO_REPLY + ICMP6_ECHO_REQUEST + ICMP6_INFOMSG_MASK + ICMP6_MEMBERSHIP_QUERY + ICMP6_MEMBERSHIP_REDUCTION + ICMP6_MEMBERSHIP_REPORT + ICMP6_PACKET_TOO_BIG + ICMP6_PARAMPROB_HEADER + ICMP6_PARAMPROB_NEXTHEADER + ICMP6_PARAMPROB_OPTION + ICMP6_PARAM_PROB + ICMP6_TIME_EXCEEDED + ICMP6_TIME_EXCEED_REASSEMBLY + ICMP6_TIME_EXCEED_TRANSIT + ND_NA_FLAG_OVERRIDE + ND_NA_FLAG_ROUTER + ND_NA_FLAG_SOLICITED + ND_NEIGHBOR_ADVERT + ND_NEIGHBOR_SOLICIT + ND_OPT_MTU + ND_OPT_PI_FLAG_AUTO + ND_OPT_PI_FLAG_ONLINK + ND_OPT_PREFIX_INFORMATION + ND_OPT_REDIRECTED_HEADER + ND_OPT_SOURCE_LINKADDR + ND_OPT_TARGET_LINKADDR + ND_RA_FLAG_MANAGED + ND_RA_FLAG_OTHER + ND_REDIRECT + ND_ROUTER_ADVERT + ND_ROUTER_SOLICIT + + struct icmp6_filter{}; + struct icmp6_hdr{}; + struct nd_neighbor_advert{}; + struct nd_neighbor_solicit{}; + struct nd_opt_hdr{}; + struct nd_opt_mtu{}; + struct nd_opt_prefix_info{}; + struct nd_opt_rd_hdr{}; + struct nd_redirect{}; + struct nd_router_advert{}; + struct nd_router_solicit{}; + + IPPROTO_AH + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 40] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + IPPROTO_DSTOPTS + IPPROTO_ESP + IPPROTO_FRAGMENT + IPPROTO_HOPOPTS + IPPROTO_ICMPV6 + IPPROTO_IPV6 + IPPROTO_NONE + IPPROTO_ROUTING + IPV6_RECVDSTOPTS + IPV6_RECVHOPLIMIT + IPV6_RECVHOPOPTS + IPV6_RECVPKTINFO + IPV6_RECVRTHDR + IPV6_RECVRTHDRDSTOPTS + IPV6_DSTOPTS + IPV6_HOPLIMIT + IPV6_HOPOPTS + IPV6_NEXTHOP + IPV6_PKTINFO + IPV6_RTHDR + IPV6_RTHDRDSTOPTS + IPV6_RTHDR_TYPE_0 + struct in6_pktinfo{}; + + IP6F_OFF_MASK + IP6F_RESERVED_MASK + IP6F_MORE_FRAG + struct ip6_dest{}; + struct ip6_frag{}; + struct ip6_hbh{}; + struct ip6_hdr{}; + struct ip6_rthdr{}; + struct ip6_rthdr0{}; + + struct cmsghdr{}; + struct msghdr{}; + + + The following list summarizes the function and macro prototypes + discussed in this memo, sorted by header. + + void ICMP6_FILTER_SETBLOCK(int, struct icmp6_filter *); + void ICMP6_FILTER_SETBLOCKALL(struct icmp6_filter *); + void ICMP6_FILTER_SETPASS(int, struct icmp6_filter *); + void ICMP6_FILTER_SETPASSALL(struct icmp6_filter *); + int ICMP6_FILTER_WILLBLOCK(int, + const struct icmp6_filter *); + int ICMP6_FILTER_WILLPASS(int, + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 41] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + const struct icmp6_filter *); + + int IN6_ARE_ADDR_EQUAL(const struct in6_addr *, + const struct in6_addr *); + + int inet6_opt_append(void *, size_t, int, + uint8_t, size_t, uint_8, void **); + int inet6_opt_get_val(void *, size_t, void *, int); + int inet6_opt_find(void *, size_t, int, uint8_t , + size_t *, void **); + int inet6_opt_finish(void *, size_t, int); + int inet6_opt_init(void *, size_t); + int inet6_opt_next(void *, size_t, int, uint8_t *, + size_t *, void **); + int inet6_opt_set_val(void *, size_t, void *, int); + + int inet6_rth_add(void *, + const struct in6_addr *); + struct in6_addr inet6_rth_getaddr(const void *, + int); + void *inet6_rth_init(void *, int, int, int); + int inet6_rth_reverse(const void *, void *); + int inet6_rth_segments(const void *); + size_t inet6_rth_space(int, int); + + unsigned char *CMSG_DATA(const struct cmsghdr *); + struct cmsghdr *CMSG_FIRSTHDR(const struct msghdr *); + unsigned int CMSG_LEN(unsigned int); + struct cmsghdr *CMSG_NXTHDR(const struct msghdr *mhdr, + const struct cmsghdr *); + unsigned int CMSG_SPACE(unsigned int); + + int rresvport_af(int *, int); + int rcmd_af(char **, unsigned short, const char *, + const char *, const char *, int *, int); + int rexec_af(char **, unsigned short , const char *, + const char *, const char *, int *, int); + + + +15. Security Considerations + + The setting of certain Hop-by-Hop options and Destination options may + be restricted to privileged processes. Similarly some Hop-by-Hop + options and Destination options may not be returned to nonprivileged + applications. + + The ability to specify an arbitrary source address using IPV6_PKTINFO + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 42] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + must be prevented; at least for non-privileged processes. + + +16. Compatibility with RFC 2292 + + The intent is that implementations that so desire should be able to + conform to both this document and to RFC 2292. + + This is possible since this document doesn't redefine any of the + existing socket options and since it uses new names for the + inet6_XXX() functions that take different arguments. + + Thus implementations that wish to provide support for RFC 2292 can + retain the support for IPV6_PKTOPTIONS, allow the setting of + IPV6_RTHDR etc to a sizeof(int) value to enable receipt of ancillary + data, and provide the old (as well as the new) inet6_XXX() functions. + + +17. Change History + + Changes from RFC 2292: + + - Removed the IPV6_PKTOPTIONS socket option by allowing sticky + options to be set with individual setsockopt calls. This + simplifies the protocol stack implementation by not having to + handle options within options and also clarifies the failure + semantics when some option is incorrectly formatted. + + - Added the IPV6_RTHDRDSTOPTS for a Destination header before the + Routing header. This is necessary to allow setting these + Destination headers without IPV6_PKTOPTIONS. + + - Removed the ability to be able to specify Hop-by-Hop and + Destination options using multiple ancillary data items. The + application, using the inet6_option_*() routines, is responsible + for formatting the whole extension header. This removes the need + for the protocol stack to somehow guess the alignment + restrictions on options when concatenating them together. + + - Added separate IPV6_RECVxxx options to enable the receipt of the + corresponding ancillary data items. This makes the API cleaner + since it allows the application to retrieve with getsockopt the + sticky options it has set with setsockopt. + + - Clarified how sticky options are turned off. + + - Clarified how and when TCP returns ancillary data. + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 43] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + - Removed the support for the loose/strict Routing header since + that has been removed from the IPv6 specification. + + - Modified the inet6_rthdr_XXX() functions to not assume a cmsghdr + structure in order to work with both sticky options and ancillary + data. Renamed the functions to inet6_rth_XXX() to allow + implementations to provide both the old and new functions. + + - Modified the inet6_option_XXX() functions to not assume a cmsghdr + structure in order to work with both sticky options and ancillary + data. Renamed the functions to inet6_opt_XXX() to allow + implementations to provide both the old and new functions. + + - The new inet6_opt_XXX() functions were made different that the + old as to not require structure declarations but instead use + functions to add the individual fields to the option. + + - Changed inet6_rthdr_getaddr() to operate on index O through N-1 + (used to be 1 through N). + + - Changed the comments in the struct ip6_hdr from "priority" to + "traffic class". + + - Clarified the alignment issues involving ancillary data to allow + for separate alignment of cmsghdr structures and the data. Made + CMSG_SPACE() return an upper bound on the needed space. + + - Added rcmd_af() and rexec_af(). + + +18. TODO and Open Issues + + Items left to do: + + - Add mechanism to avoid fragmentation by sending at the minimum + IPv6 MTU. Suggest an IPV6_USE_MIN_MTU socket option. + + - Add MTU notification so that UDP and raw socket applications can + participate in path MTU discovery. Suggest an ancillary data + item which might be received without any data (i.e. recvmsg + returns zero): IPV6_PATHMTU The receipt of this ancillary data + item is enabled with IPV6_RECVPATHMTU. + + - Add Reachability confirmation for UDP and raw socket + applications. Suggest an ancillary data item for sendmsg() + called IPV6_REACHCONF which takes no value (i.e. it is zero + length). + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 44] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + Open issues: + + - Should we make the content of IPV6_RTHDR, IPV6_HOPOPTS etc be + specified as the extension header format (struct ip6_rthdr etc) + instead of the current "implementation dependent"? + + - Are the new inet6_opt_set_val() and inet6_opt_get_val() useful? + There implementation is just an assignment/bcopy based on the + length of the data item. + + - "If the application asks for e.g., IPV6_RTHDR and a received + datagram does not contain a Routing header an implementation + might either exclude the IPV6_RTHDR ancillary data item or pass + up an item with zero length (cmsg_data being zero length)." + Discussion: Do we want the above behavior? Or always exclude the + ancillary data item? + + - Should we add option definitions (IPV6OPT_PAD1 etc) and all the + different flags for the headers defined in section 2? + + - "Note that if any ancillary data is specified in a call to + sendmsg(), all of the sticky options are overridden for that + datagram." We could instead define that a zero-length cmsghdr + (for the specific level and type) is needed to override an + individual sticky options instead. Should we? + + - The examples use CMSG_LEN and CMSG_SPACE interchangeably. The + latter only needs to be used when there are multiple ancillary + data items in a control buffer. This should be clarified + somewhere. + + +19. References + + + [RFC-2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 + (IPv6), Specification", RFC 2460, Dec. 1998. + + [RFC-2553] Gilligan, R. E., Thomson, S., Bound, J., Stevens, W., + "Basic Socket Interface Extensions for IPv6", RFC 2553, + March 1999. + + [RFC-1981] McCann, J., Deering, S., Mogul, J, "Path MTU Discovery + for IP version 6", RFC 1981, Aug. 1996. + + [RFC-2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 45] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + Discovery for IP Version 6 (IPv6)", RFC 2461, Dec. 1998. + + +20. Acknowledgments + + Matt Thomas and Jim Bound have been working on the technical details + in this draft for over a year. Keith Sklower is the original + implementor of ancillary data in the BSD networking code. Craig Metz + provided lots of feedback, suggestions, and comments based on his + implementing many of these features as the document was being + written. + + The following provided comments on earlier drafts: Pascal Anelli, + Hamid Asayesh, Ran Atkinson, Karl Auerbach, Hamid Asayesh, Matt + Crawford, Sam T. Denton, Richard Draves, Francis Dupont, Bob + Gilligan, Tim Hartrick, Masaki Hirabaru, Yoshinobu Inoue, Mukesh + Kacker, A. N. Kuznetsov, Pedro Marques, Jack McCann, der Mouse, John + Moy, Thomas Narten, Steve Parker, Charles Perkins, Tom Pusateri, + Pedro Roque, Sameer Shah, Peter Sjodin, Stephen P. Spackman, Jinmei + Tatuya, Karen Tracey, Quaizar Vohra, Carl Williams, Steve Wise, and + Kazu Yamamoto. + + +21. Authors' Addresses + + W. Richard Stevens + 1202 E. Paseo del Zorro + Tucson, AZ 85718 + Email: rstevens@kohala.com + + + Matt Thomas + 3am Software Foundry + 8053 Park Villa Circle + Cupertino, CA 95014 + Email: matt@3am-software.com + + + Erik Nordmark + Sun Microsystems, Inc. + 901 San Antonio Road + Palo Alto, CA 94303, USA + Email: erik.nordmark@eng.sun.com + + + +22. Appendix A: Ancillary Data + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 46] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + 4.2BSD allowed file descriptors to be transferred between separate + processes across a UNIX domain socket using the sendmsg() and + recvmsg() functions. Two members of the msghdr structure, + msg_accrights and msg_accrightslen, were used to send and receive the + descriptors. When the OSI protocols were added to 4.3BSD Reno in + 1990 the names of these two fields in the msghdr structure were + changed to msg_control and msg_controllen, because they were used by + the OSI protocols for "control information", although the comments in + the source code call this "ancillary data". + + Other than the OSI protocols, the use of ancillary data has been + rare. In 4.4BSD, for example, the only use of ancillary data with + IPv4 is to return the destination address of a received UDP datagram + if the IP_RECVDSTADDR socket option is set. With Unix domain sockets + ancillary data is still used to send and receive descriptors. + + Nevertheless the ancillary data fields of the msghdr structure + provide a clean way to pass information in addition to the data that + is being read or written. The inclusion of the msg_control and + msg_controllen members of the msghdr structure along with the cmsghdr + structure that is pointed to by the msg_control member is required by + the Posix.1g sockets API standard. + + + +22.1. The msghdr Structure + + The msghdr structure is used by the recvmsg() and sendmsg() + functions. Its Posix.1g definition is: + + struct msghdr { + void *msg_name; /* ptr to socket address structure */ + socklen_t msg_namelen; /* size of socket address structure */ + struct iovec *msg_iov; /* scatter/gather array */ + size_t msg_iovlen; /* # elements in msg_iov */ + void *msg_control; /* ancillary data */ + socklen_t msg_controllen; /* ancillary data buffer length */ + int msg_flags; /* flags on received message */ + }; + + The structure is declared as a result of including . + + (Note: Before Posix.1g the two "void *" pointers were typically "char + *", and the two socklen_t members and the size_t member were + typically integers. Earlier drafts of Posix.1g had the two socklen_t + members as size_t, but Draft 6.6 of Posix.1g, apparently the final + draft, changed these to socklen_t to simplify binary portability for + 64-bit implementations and to align Posix.1g with X/Open's Networking + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 47] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + Services, Issue 5. The change in msg_control to a "void *" pointer + affects any code that increments this pointer.) + + (Note: Before Posix.1g the cmsg_len member was an integer, and not a + socklen_t. See the Note in the previous section for why socklen_t is + used here.) + + Most Berkeley-derived implementations limit the amount of ancillary + data in a call to sendmsg() to no more than 108 bytes (an mbuf). + This API requires a minimum of 10240 bytes of ancillary data, but it + is recommended that the amount be limited only by the buffer space + reserved by the socket (which can be modified by the SO_SNDBUF socket + option). (Note: This magic number 10240 was picked as a value that + should always be large enough. 108 bytes is clearly too small as the + maximum size of a Routing header is 2048 bytes.) + + +22.2. The cmsghdr Structure + + The cmsghdr structure describes ancillary data objects transferred by + recvmsg() and sendmsg(). Its Posix.1g definition is: + + struct cmsghdr { + socklen_t cmsg_len; /* #bytes, including this header */ + int cmsg_level; /* originating protocol */ + int cmsg_type; /* protocol-specific type */ + /* followed by unsigned char cmsg_data[]; */ + }; + + This structure is declared as a result of including . + + As shown in this definition, normally there is no member with the + name cmsg_data[]. Instead, the data portion is accessed using the + CMSG_xxx() macros, as described shortly. Nevertheless, it is common + to refer to the cmsg_data[] member. + + When ancillary data is sent or received, any number of ancillary data + objects can be specified by the msg_control and msg_controllen + members of the msghdr structure, because each object is preceded by a + cmsghdr structure defining the object's length (the cmsg_len member). + Historically Berkeley-derived implementations have passed only one + object at a time, but this API allows multiple objects to be passed + in a single call to sendmsg() or recvmsg(). The following example + shows two ancillary data objects in a control buffer. + + + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 48] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + + |<--------------------------- msg_controllen -------------------------->| + | OR | + |<--------------------------- msg_controllen ----------------------->| + | | + |<----- ancillary data object ----->|<----- ancillary data object ----->| + |<------ min CMSG_SPACE() --------->|<------ min CMSG_SPACE() --------->| + | | | + |<---------- cmsg_len ---------->| |<--------- cmsg_len ----------->| | + |<--------- CMSG_LEN() --------->| |<-------- CMSG_LEN() ---------->| | + | | | | | + +-----+-----+-----+--+-----------+--+-----+-----+-----+--+-----------+--+ + |cmsg_|cmsg_|cmsg_|XX| |XX|cmsg_|cmsg_|cmsg_|XX| |XX| + |len |level|type |XX|cmsg_data[]|XX|len |level|type |XX|cmsg_data[]|XX| + +-----+-----+-----+--+-----------+--+-----+-----+-----+--+-----------+--+ + ^ + | + msg_control + points here + + + The fields shown as "XX" are possible padding, between the cmsghdr + structure and the data, and between the data and the next cmsghdr + structure, if required by the implementation. While sending an + application may or may not include padding at the end of last + ancillary data in msg_controllen and implementations must accept both + as valid. On receiving a portable application must provide space for + padding at the end of the last ancillary data as implementations may + copy out the padding at the end of the control message buffer and + include it in the received msg_controllen. When recvmsg() is called + if msg_controllen is too small for all the ancillary data items + including any trailing padding after the last item an implementation + may set MSG_CTRUNC. + + +22.3. Ancillary Data Object Macros + + To aid in the manipulation of ancillary data objects, three macros + from 4.4BSD are defined by Posix.1g: CMSG_DATA(), CMSG_NXTHDR(), and + CMSG_FIRSTHDR(). Before describing these macros, we show the + following example of how they might be used with a call to recvmsg(). + + + + + + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 49] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + + struct msghdr msg; + struct cmsghdr *cmsgptr; + + /* fill in msg */ + + /* call recvmsg() */ + + for (cmsgptr = CMSG_FIRSTHDR(&msg); cmsgptr != NULL; + cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) { + if (cmsgptr->cmsg_level == ... && cmsgptr->cmsg_type == ... ) { + u_char *ptr; + + ptr = CMSG_DATA(cmsgptr); + /* process data pointed to by ptr */ + } + } + + We now describe the three Posix.1g macros, followed by two more that + are new with this API: CMSG_SPACE() and CMSG_LEN(). All these macros + are defined as a result of including . + + +22.3.1. CMSG_FIRSTHDR + + + struct cmsghdr *CMSG_FIRSTHDR(const struct msghdr *mhdr); + + CMSG_FIRSTHDR() returns a pointer to the first cmsghdr structure in + the msghdr structure pointed to by mhdr. The macro returns NULL if + there is no ancillary data pointed to the by msghdr structure (that + is, if either msg_control is NULL or if msg_controllen is less than + the size of a cmsghdr structure). + + One possible implementation could be + + #define CMSG_FIRSTHDR(mhdr) \ + ( (mhdr)->msg_controllen >= sizeof(struct cmsghdr) ? \ + (struct cmsghdr *)(mhdr)->msg_control : \ + (struct cmsghdr *)NULL ) + + (Note: Most existing implementations do not test the value of + msg_controllen, and just return the value of msg_control. The value + of msg_controllen must be tested, because if the application asks + recvmsg() to return ancillary data, by setting msg_control to point + to the application's buffer and setting msg_controllen to the length + of this buffer, the kernel indicates that no ancillary data is + available by setting msg_controllen to 0 on return. It is also + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 50] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + easier to put this test into this macro, than making the application + perform the test.) + + +22.3.2. CMSG_NXTHDR + + + struct cmsghdr *CMSG_NXTHDR(const struct msghdr *mhdr, + const struct cmsghdr *cmsg); + + CMSG_NXTHDR() returns a pointer to the cmsghdr structure describing + the next ancillary data object. mhdr is a pointer to a msghdr + structure and cmsg is a pointer to a cmsghdr structure. If there is + not another ancillary data object, the return value is NULL. + + The following behavior of this macro is new to this API: if the value + of the cmsg pointer is NULL, a pointer to the cmsghdr structure + describing the first ancillary data object is returned. That is, + CMSG_NXTHDR(mhdr, NULL) is equivalent to CMSG_FIRSTHDR(mhdr). If + there are no ancillary data objects, the return value is NULL. This + provides an alternative way of coding the processing loop shown + earlier: + + struct msghdr msg; + struct cmsghdr *cmsgptr = NULL; + + /* fill in msg */ + + /* call recvmsg() */ + + while ((cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) != NULL) { + if (cmsgptr->cmsg_level == ... && cmsgptr->cmsg_type == ... ) { + u_char *ptr; + + ptr = CMSG_DATA(cmsgptr); + /* process data pointed to by ptr */ + } + } + + + One possible implementation could be: + + + + + + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 51] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + + #define CMSG_NXTHDR(mhdr, cmsg) \ + (((cmsg) == NULL) ? CMSG_FIRSTHDR(mhdr) : \ + (((u_char *)(cmsg) + ALIGN_H((cmsg)->cmsg_len) \ + + ALIGN_D(sizeof(struct cmsghdr)) > \ + (u_char *)((mhdr)->msg_control) + (mhdr)->msg_controllen) ? \ + (struct cmsghdr *)NULL : \ + (struct cmsghdr *)((u_char *)(cmsg) + ALIGN_H((cmsg)->cmsg_len)))) + + The macros ALIGN_H() and ALIGN_D(), which are implementation + dependent, round their arguments up to the next even multiple of + whatever alignment is required for the start of the cmsghdr structure + and the data, respectively. (This is probably a multiple of 4 or 8 + bytes.) They are often the same macro in implementations platforms + where alignment requirement for header and data is chosen to be + identical. + + +22.3.3. CMSG_DATA + + + unsigned char *CMSG_DATA(const struct cmsghdr *cmsg); + + CMSG_DATA() returns a pointer to the data (what is called the + cmsg_data[] member, even though such a member is not defined in the + structure) following a cmsghdr structure. + + One possible implementation could be: + + #define CMSG_DATA(cmsg) ( (u_char *)(cmsg) + \ + ALIGN_D(sizeof(struct cmsghdr)) ) + + + +22.3.4. CMSG_SPACE + + + unsigned int CMSG_SPACE(unsigned int length); + + This macro is new with this API. Given the length of an ancillary + data object, CMSG_SPACE() returns an upper bound on the space + required by the object and its cmsghdr structure, including any + padding needed to satisfy alignment requirements. This macro can be + used, for example, to allocate space dynamically for the ancillary + data. This macro should not be used to initialize the cmsg_len + member of a cmsghdr structure; instead use the CMSG_LEN() macro. + + One possible implementation could be: + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 52] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + + #define CMSG_SPACE(length) ( ALIGN_D(sizeof(struct cmsghdr)) + \ + ALIGN_H(length) ) + + + +22.3.5. CMSG_LEN + + + unsigned int CMSG_LEN(unsigned int length); + + This macro is new with this API. Given the length of an ancillary + data object, CMSG_LEN() returns the value to store in the cmsg_len + member of the cmsghdr structure, taking into account any padding + needed to satisfy alignment requirements. + + One possible implementation could be: + + #define CMSG_LEN(length) ( ALIGN_D(sizeof(struct cmsghdr)) + length ) + + Note the difference between CMSG_SPACE() and CMSG_LEN(), shown also + in the figure in Section 4.2: the former accounts for any required + padding at the end of the ancillary data object and the latter is the + actual length to store in the cmsg_len member of the ancillary data + object. + + +23. Appendix B: Examples using the inet6_rth_XXX() functions + + Here we show an example for both sending Routing headers and + processing and reversing a received Routing header. + + +23.1. Sending a Routing Header + + As an example of these Routing header functions defined in this + document, we go through the function calls for the example on p. 17 + of [RFC-2460]. The source is S, the destination is D, and the three + intermediate nodes are I1, I2, and I3. + + S -----> I1 -----> I2 -----> I3 -----> D + + src: * S S S S S + dst: D I1 I2 I3 D D + A[1]: I1 I2 I1 I1 I1 I1 + A[2]: I2 I3 I3 I2 I2 I2 + A[3]: I3 D D D I3 I3 + #seg: 3 3 2 1 0 3 + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 53] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + src and dst are the source and destination IPv6 addresses in the IPv6 + header. A[1], A[2], and A[3] are the three addresses in the Routing + header. #seg is the Segments Left field in the Routing header. + + The six values in the column beneath node S are the values in the + Routing header specified by the sending application using sendmsg() + of setsockopt(). The function calls by the sender would look like: + + void *extptr; + int extlen; + struct msghdr msg; + struct cmsghdr *cmsgptr; + int cmsglen; + struct sockaddr_in6 I1, I2, I3, D; + + extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3); + cmsglen = CMSG_LEN(extlen); + cmsgptr = malloc(cmsglen); + cmsgptr->cmsg_len = cmsglen; + cmsgptr->cmsg_level = IPPROTO_IPV6; + cmsgptr->cmsg_type = IPV6_RTHDR; + + optptr = CMSG_DATA(cmsgptr); + optptr = inet6_rth_init(optptr, optlen, IPV6_RTHDR_TYPE_0, 3); + + inet6_rth_add(optptr, &I1.sin6_addr); + inet6_rth_add(optptr, &I2.sin6_addr); + inet6_rth_add(optptr, &I3.sin6_addr); + + msg.msg_control = cmsgptr; + msg.msg_controllen = cmsglen; + + /* finish filling in msg{}, msg_name = D */ + /* call sendmsg() */ + + We also assume that the source address for the socket is not + specified (i.e., the asterisk in the figure). + + The four columns of six values that are then shown between the five + nodes are the values of the fields in the packet while the packet is + in transit between the two nodes. Notice that before the packet is + sent by the source node S, the source address is chosen (replacing + the asterisk), I1 becomes the destination address of the datagram, + the two addresses A[2] and A[3] are "shifted up", and D is moved to + A[3]. + + The columns of values that are shown beneath the destination node are + the values returned by recvmsg(), assuming the application has + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 54] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + enabled both the IPV6_RECVPKTINFO and IPV6_RECVRTHDR socket options. + The source address is S (contained in the sockaddr_in6 structure + pointed to by the msg_name member), the destination address is D + (returned as an ancillary data object in an in6_pktinfo structure), + and the ancillary data object specifying the Routing header will + contain three addresses (I1, I2, and I3). The number of segments in + the Routing header is known from the Hdr Ext Len field in the Routing + header (a value of 6, indicating 3 addresses). + + The return value from inet6_rth_segments() will be 3 and + inet6_rth_getaddr(0) will return I1, inet6_rth_getaddr(1) will return + I2, and inet6_rth_getaddr(2) will return I3, + + If the receiving application then calls inet6_rth_reverse(), the + order of the three addresses will become I3, I2, and I1. + + We can also show what an implementation might store in the ancillary + data object as the Routing header is being built by the sending + process. If we assume a 32-bit architecture where sizeof(struct + cmsghdr) equals 12, with a desired alignment of 4-byte boundaries, + then the call to inet6_rth_space(3) returns 68: 12 bytes for the + cmsghdr structure and 56 bytes for the Routing header (8 + 3*16). + + The call to inet6_rth_init() initializes the ancillary data object to + contain a Type 0 Routing header: + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | cmsg_len = 20 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | cmsg_level = IPPROTO_IPV6 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | cmsg_type = IPV6_RTHDR | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The first call to inet6_rth_add() adds I1 to the list. + + + + + + + + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 55] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | cmsg_len = 36 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | cmsg_level = IPPROTO_IPV6 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | cmsg_type = IPV6_RTHDR | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Address[1] = I1 + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + cmsg_len is incremented by 16, and the Segments Left field is + incremented by 1. + + The next call to inet6_rth_add() adds I2 to the list. + + + + + + + + + + + + + + + + + + + + + + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 56] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | cmsg_len = 52 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | cmsg_level = IPPROTO_IPV6 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | cmsg_type = IPV6_RTHDR | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Address[1] = I1 + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Address[2] = I2 + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + cmsg_len is incremented by 16, and the Segments Left field is + incremented by 1. + + The last call to inet6_rth_add() adds I3 to the list. + + + + + + + + + + + + + + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 57] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | cmsg_len = 68 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | cmsg_level = IPPROTO_IPV6 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | cmsg_type = IPV6_RTHDR | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=3 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Address[1] = I1 + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Address[2] = I2 + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Address[3] = I3 + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + cmsg_len is incremented by 16, and the Segments Left field is + incremented by 1. + + +23.2. Receiving Routing Headers + + This example assumes that the application has enabled IPV6_RECVRTHDR + socket option. The application prints and reverses a source route + and uses that to echo the received data. + + struct sockaddr_in6 addr; + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 58] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + struct msghdr msg; + struct iovec iov; + struct cmsghdr *cmsgptr; + size_t cmsgspace; + void *optptr; + int optlen; + + int segments; + int i; + char databuf[8192]; + + segments = 100; /* Enough */ + optlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, segments); + cmsgspace = CMSG_SPACE(optlen); + cmsgptr = malloc(cmsgspace); + if (cmsgptr == NULL) { + perror("malloc"); + exit(1); + } + optptr = CMSG_DATA(cmsgptr); + + msg.msg_control = (char *)cmsgptr; + msg.msg_controllen = cmsgspace; + msg.msg_name = (struct sockaddr *)&addr; + msg.msg_namelen = sizeof (addr); + msg.msg_iov = &iov; + msg.msg_iovlen = 1; + iov.iov_base = databuf; + iov.iov_len = sizeof (databuf); + msg.msg_flags = 0; + if (recvmsg(s, &msg, 0) == -1) { + perror("recvmsg"); + return; + } + if (msg.msg_controllen != 0 && + cmsgptr->cmsg_level == IPPROTO_IPV6 && + cmsgptr->cmsg_type == IPV6_RTHDR) { + struct in6_addr *in6; + char asciiname[INET6_ADDRSTRLEN]; + struct ip6_rthdr0 *rthdr; + + rthdr = (struct ip6_rthdr0 *)optptr; + segments = inet6_rth_segments(optptr); + printf("route (%d segments, %d left): ", + segments, rthdr->ip6r0_segleft); + for (i = 0; i < segments; i++) { + in6 = inet6_rth_getaddr(optptr, i); + if (in6 == NULL) + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 59] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + printf(" "); + else + printf("%s ", inet_ntop(AF_INET6, + (void *)in6->s6_addr, + asciiname, INET6_ADDRSTRLEN)); + } + if (inet6_rth_reverse(optptr, optptr) == -1) { + printf("reverse failed"); + return; + } + } + iov.iov_base = databuf; + iov.iov_len = strlen(databuf); + if (sendmsg(s, &msg, 0) == -1) + perror("sendmsg"); + if (cmsgptr != NULL) + free(cmsgptr); + + Note: The above example is a simple illustration. It skips some + error checks involving the MSG_TRUNC and MSG_CTRUNC flags. + + +24. Appendix C: Examples using the inet6_opt_XXX() functions + + This shows how Hop-by-Hop and Destination options can be both built + as well as parsed using the inet6_opt_XXX() functions. This examples + assume that there are defined values for OPT_X and OPT_Y. + + +24.1. Building options + + We now provide an example that builds two Hop-by-Hop options using + the example in Appendix B of [RFC-2460]. + + void *extbuf; + size_t extlen; + int currentlen; + void *databuf; + size_t offset; + uint8_t value1; + uint16_t value2; + uint32_t value4; + uint64_t value8; + + /* Estimate the length */ + currentlen = inet6_opt_init(NULL, 0); + if (currentlen == -1) + return (-1); + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 60] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + currentlen = inet6_opt_append(NULL, 0, currentlen, OPT_X, 12, 8, NULL); + if (currentlen == -1) + return (-1); + currentlen = inet6_opt_append(NULL, 0, currentlen, OPT_Y, 7, 4, NULL); + if (currentlen == -1) + return (-1); + currentlen = inet6_opt_finish(NULL, 0, currentlen); + if (currentlen == -1) + return (-1); + extlen = currentlen; + + extbuf = malloc(extlen); + if (extbuf == NULL) { + perror("malloc"); + return (-1); + } + currentlen = inet6_opt_init(extbuf, extlen); + if (currentlen == -1) + return (-1); + + currentlen = inet6_opt_append(extbuf, extlen, currentlen, + OPT_X, 12, 8, &databuf); + if (currentlen == -1) + return (-1); + /* Insert value 0x12345678 for 4-octet field */ + offset = 0; + value4 = 0x12345678; + offset = inet6_opt_set_val(databuf, offset, &value4, sizeof (value4)); + /* Insert value 0x0102030405060708 for 8-octet field */ + value8 = 0x0102030405060708; + offset = inet6_opt_set_val(databuf, offset, &value8, sizeof (value8)); + + currentlen = inet6_opt_append(extbuf, extlen, currentlen, + OPT_Y, 7, 4, &databuf); + if (currentlen == -1) + return (-1); + /* Insert value 0x01 for 1-octet field */ + offset = 0; + value1 = 0x01; + offset = inet6_opt_set_val(databuf, offset, &value1, sizeof (value1)); + /* Insert value 0x1331 for 2-octet field */ + value2 = 0x1331; + offset = inet6_opt_set_val(databuf, offset, &value2, sizeof (value2)); + /* Insert value 0x01020304 for 4-octet field */ + value4 = 0x01020304; + offset = inet6_opt_set_val(databuf, offset, &value4, sizeof (value4)); + + currentlen = inet6_opt_finish(extbuf, extlen, currentlen); + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 61] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + if (currentlen == -1) + return (-1); + /* extbuf and extlen are now completely formatted */ + + + +24.2. Parsing received options + + This example parses and prints the content of the two options in the + previous example. + + int + print_opt(void *extbuf, size_t extlen) + { + ip6_dest_t *ext; + int currentlen; + uint8_t type; + size_t len; + void *databuf; + size_t offset; + uint8_t value1; + uint16_t value2; + uint32_t value4; + uint64_t value8; + + ext = (ip6_dest_t *)extbuf; + printf("nxt %u, len %u (bytes %d)\n", ext->ip6d_nxt, + ext->ip6d_len, (ext->ip6d_len + 1) * 8); + + currentlen = 0; + while (1) { + currentlen = inet6_opt_next(extbuf, extlen, currentlen, + &type, &len, &databuf); + if (currentlen == -1) + break; + printf("Received opt %u len %u\n", + type, len); + switch (type) { + case IPV6OPT_PAD1: + printf("PAD1\n"); + break; + case IPV6OPT_PADN: + printf("PADN (N=%d)\n", len + 2); + break; + case OPT_X: + offset = 0; + offset = inet6_opt_get_val(databuf, offset, + &value4, sizeof (value4)); + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 62] + +INTERNET-DRAFT Advanced Sockets API for IPv6 June 24, 1999 + + + printf("X 4-byte field %x\n", value4); + offset = inet6_opt_get_val(databuf, offset, + &value8, sizeof (value8)); + printf("X 8-byte field %llx\n", value8); + break; + case OPT_Y: + offset = 0; + offset = inet6_opt_get_val(databuf, offset, + &value1, sizeof (value1)); + printf("Y 1-byte field %x\n", value1); + offset = inet6_opt_get_val(databuf, offset, + &value2, sizeof (value2)); + printf("Y 2-byte field %x\n", value2); + offset = inet6_opt_get_val(databuf, offset, + &value4, sizeof (value4)); + printf("Y 4-byte field %x\n", value4); + break; + default: + printf("Unknown option %u\n", type); + break; + } + } + return (0); + } + + + + + + + + + + + + + + + + + + + + + + + + + + + +draft-ietf-ipngwg-2292bis-00.txt [Page 63] + diff --git a/doc/expired/draft-ietf-ipngwg-bsd-api-new-06.txt b/doc/expired/draft-ietf-ipngwg-bsd-api-new-06.txt new file mode 100644 index 0000000000..ffcfb0e6d2 --- /dev/null +++ b/doc/expired/draft-ietf-ipngwg-bsd-api-new-06.txt @@ -0,0 +1,2176 @@ + +Internet Engineering Task Force R.E. Gilligan (FreeGate) +INTERNET-DRAFT S. Thomson (Bellcore) +Obsoletes RFC 2133 Jim Bound (Compaq) + W. R. Stevens (Consultant) + January 25, 1999 + + + + + + + Basic Socket Interface Extensions for IPv6 + + + + +Status of this Memo + + This document is a submission by the Internet Protocol IPv6 + Working Group of the Internet Engineering Task Force (IETF). + Comments should be submitted to the ipng@sunroof.eng.sun.com + mailing list. + + This document is an Internet-Draft. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its + areas, and its working groups. Note that other groups may also + distribute working documents as Internet-Drafts. + + 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." + + To view the entire list of current Internet-Drafts, please check + the "1id-abstracts.txt" listing contained in the Internet-Drafts + Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net + (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East + Coast), or ftp.isi.edu (US West Coast). + + Distribution of this memo is unlimited. + + +Abstract + +The de facto standard application program interface (API) for TCP/IP +applications is the "sockets" interface. Although this API was +developed for Unix in the early 1980s it has also been implemented on a +wide variety of non-Unix systems. TCP/IP applications written using the +sockets API have in the past enjoyed a high degree of portability and we +would like the same portability with IPv6 applications. But changes are +required to the sockets API to support IPv6 and this memo describes +these changes. These include a new socket address structure to carry +IPv6 addresses, new address conversion functions, and some new socket +options. These extensions are designed to provide access to the basic +IPv6 features required by TCP and UDP applications, including +multicasting, while introducing a minimum of change into the system and +providing complete compatibility for existing IPv4 applications. +Additional extensions for advanced IPv6 features (raw sockets and access +to the IPv6 extension headers) are defined in another document [4]. + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 1] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +Table of Contents: + +1. Introduction.................................................3 +2. Design Considerations........................................3 +2.1 What Needs to be Changed....................................3 +2.2 Data Types..................................................5 +2.3 Headers.....................................................5 +2.4 Structures..................................................5 +3. Socket Interface.............................................5 +3.1 IPv6 Address Family and Protocol Family.....................5 +3.2 IPv6 Address Structure......................................6 +3.3 Socket Address Structure for 4.3BSD-Based Systems...........6 +3.4 Socket Address Structure for 4.4BSD-Based Systems...........7 +3.5 The Socket Functions........................................8 +3.6 Compatibility with IPv4 Applications........................9 +3.7 Compatibility with IPv4 Nodes...............................9 +3.8 IPv6 Wildcard Address......................................10 +3.9 IPv6 Loopback Address......................................11 +3.10 Portability Additions.....................................11 +4. Interface Identification....................................13 +4.1 Name-to-Index..............................................14 +4.2 Index-to-Name..............................................14 +4.3 Return All Interface Names and Indexes.....................15 +4.4 Free Memory................................................15 +5. Socket Options..............................................15 +5.1 Unicast Hop Limit..........................................16 +5.2 Sending and Receiving Multicast Packets....................16 +6. Library Functions...........................................18 +6.1 Nodename-to-Address Translation............................18 +6.2 Address-To-Nodename Translation............................21 +6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....22 +6.4 Protocol-Independent Nodename and Service Name Translation.22 +6.5 Socket Address Structure to Nodename and Service Name......25 +6.6 Address Conversion Functions...............................26 +6.7 Address Testing Macros.....................................27 +7. Summary of New Definitions..................................28 +8. Security Considerations.....................................29 +9. Year 2000 Considerations....................................29 +Changes From RFC 2133..........................................30 +Acknowledgments................................................32 +References.....................................................33 +Authors' Addresses.............................................33 + + + + + + + + + + + + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 2] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +1. Introduction + +While IPv4 addresses are 32 bits long, IPv6 interfaces are identified by +128-bit addresses. The socket interface makes the size of an IP address +quite visible to an application; virtually all TCP/IP applications for +BSD-based systems have knowledge of the size of an IP address. Those +parts of the API that expose the addresses must be changed to +accommodate the larger IPv6 address size. IPv6 also introduces new +features (e.g., traffic class and flowlabel), some of which must be made +visible to applications via the API. This memo defines a set of +extensions to the socket interface to support the larger address size +and new features of IPv6. + + + +2. Design Considerations + +There are a number of important considerations in designing changes to +this well-worn API: + + - The API changes should provide both source and binary + compatibility for programs written to the original API. That + is, existing program binaries should continue to operate when + run on a system supporting the new API. In addition, existing + applications that are re-compiled and run on a system supporting + the new API should continue to operate. Simply put, the API + changes for IPv6 should not break existing programs. An additonal + mechanism for implementations to verify this is to verify the new + symbols are protected by Feature Test Macros as described in IEEE Std + 1003.1. (Such Feature Test Macros are not defined by this RFC.) + + - The changes to the API should be as small as possible in order + to simplify the task of converting existing IPv4 applications to + IPv6. + + - Where possible, applications should be able to use this + API to interoperate with both IPv6 and IPv4 hosts. Applications + should not need to know which type of host they are + communicating with. + + - IPv6 addresses carried in data structures should be 64-bit + aligned. This is necessary in order to obtain optimum + performance on 64-bit machine architectures. + +Because of the importance of providing IPv4 compatibility in the API, +these extensions are explicitly designed to operate on machines that +provide complete support for both IPv4 and IPv6. A subset of this API +could probably be designed for operation on systems that support only +IPv6. However, this is not addressed in this memo. + + + +2.1 What Needs to be Changed + +The socket interface API consists of a few distinct components: + + - Core socket functions. + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 3] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + - Address data structures. + + - Name-to-address translation functions. + + - Address conversion functions. + +The core socket functions -- those functions that deal with such things +as setting up and tearing down TCP connections, and sending and +receiving UDP packets -- were designed to be transport independent. +Where protocol addresses are passed as function arguments, they are +carried via opaque pointers. A protocol-specific address data structure +is defined for each protocol that the socket functions support. +Applications must cast pointers to these protocol-specific address +structures into pointers to the generic "sockaddr" address structure +when using the socket functions. These functions need not change for +IPv6, but a new IPv6-specific address data structure is needed. + +The "sockaddr_in" structure is the protocol-specific data structure for +IPv4. This data structure actually includes 8-octets of unused space, +and it is tempting to try to use this space to adapt the sockaddr_in +structure to IPv6. Unfortunately, the sockaddr_in structure is not +large enough to hold the 16-octet IPv6 address as well as the other +information (address family and port number) that is needed. So a new +address data structure must be defined for IPv6. + +IPv6 addresses are scoped [2] so they could be link-local, site, +organization, global, or other scopes at this time undefined. To +support applications that want to be able to identify a set of +interfaces for a specific scope, the IPv6 sockaddr_in structure must +support a field that can be used by an implementation to identify a set +of interfaces identifying the scope for an IPv6 address. + +The name-to-address translation functions in the socket interface are +gethostbyname() and gethostbyaddr(). These are left as is and new +functions are defined to support IPv4 and IPv6. Additionally, the POSIX +1003.g draft [3] specifies a new nodename-to-address translation +function which is protocol independent. This function can also be used +with IPv4 and IPv6. + +The address conversion functions -- inet_ntoa() and inet_addr() -- +convert IPv4 addresses between binary and printable form. These +functions are quite specific to 32-bit IPv4 addresses. We have designed +two analogous functions that convert both IPv4 and IPv6 addresses, and +carry an address type parameter so that they can be extended to other +protocol families as well. + +Finally, a few miscellaneous features are needed to support IPv6. New +interfaces are needed to support the IPv6 traffic class, flow label, and +hop limit header fields. New socket options are needed to control the +sending and receiving of IPv6 multicast packets. + +The socket interface will be enhanced in the future to provide access to +other IPv6 features. These extensions are described in [4]. + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 4] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +2.2 Data Types + +The data types of the structure elements given in this memo are intended +to be examples, not absolute requirements. Whenever possible, data +types from Draft 6.6 (March 1997) of POSIX 1003.1g are used: uintN_t +means an unsigned integer of exactly N bits (e.g., uint16_t). We also +assume the argument data types from 1003.1g when possible (e.g., the +final argument to setsockopt() is a size_t value). Whenever buffer +sizes are specified, the POSIX 1003.1 size_t data type is used (e.g., +the two length arguments to getnameinfo()). + + + +2.3 Headers + +When function prototypes and structures are shown we show the headers +that must be #included to cause that item to be defined. + + + +2.4 Structures + +When structures are described the members shown are the ones that must +appear in an implementation. Additional, nonstandard members may also +be defined by an implementation. As an additional precaution +nonstandard members could be verified by Feature Test Macros as +described in IEEE Std 1003.1. (Such Feature Test Macros are not defined +by this RFC.) + +The ordering shown for the members of a structure is the recommended +ordering, given alignment considerations of multibyte members, but an +implementation may order the members differently. + + + +3. Socket Interface + +This section specifies the socket interface changes for IPv6. + + + +3.1 IPv6 Address Family and Protocol Family + +A new address family name, AF_INET6, is defined in . The +AF_INET6 definition distinguishes between the original sockaddr_in +address data structure, and the new sockaddr_in6 data structure. + +A new protocol family name, PF_INET6, is defined in . +Like most of the other protocol family names, this will usually be +defined to have the same value as the corresponding address family name: + + #define PF_INET6 AF_INET6 + +The PF_INET6 is used in the first argument to the socket() function to +indicate that an IPv6 socket is being created. + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 5] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +3.2 IPv6 Address Structure + +A new in6_addr structure holds a single IPv6 address and is defined as a +result of including : + + struct in6_addr { + uint8_t s6_addr[16]; /* IPv6 address */ + }; + +This data structure contains an array of sixteen 8-bit elements, which +make up one 128-bit IPv6 address. The IPv6 address is stored in network +byte order. + +The structure in6_addr above is usually implemented with an embedded +union with extra fields that force the desired alignment level in a +manner similar to BSD implementations of "struct in_addr". Those +additional implementation details are omitted here for simplicity. + +An example is as follows: + +struct in6_addr { + union { + uint8_t _S6_u8[16]; + uint32_t _S6_u32[4]; + uint64_t _S6_u64[2]; + } _S6_un; +}; +#define s6_addr _S6_un._S6_u8 + + + +3.3 Socket Address Structure for 4.3BSD-Based Systems + +In the socket interface, a different protocol-specific data structure is +defined to carry the addresses for each protocol suite. Each protocol- +specific data structure is designed so it can be cast into a protocol- +independent data structure -- the "sockaddr" structure. Each has a +"family" field that overlays the "sa_family" of the sockaddr data +structure. This field identifies the type of the data structure. + +The sockaddr_in structure is the protocol-specific address data +structure for IPv4. It is used to pass addresses between applications +and the system in the socket functions. The following sockaddr_in6 +structure holds IPv6 addresses and is defined as a result of including +the header: + + struct sockaddr_in6 { + sa_family_t sin6_family; /* AF_INET6 */ + in_port_t sin6_port; /* transport layer port # */ + uint32_t sin6_flowinfo; /* IPv6 traffic class & flow info */ + struct in6_addr sin6_addr; /* IPv6 address */ + uint32_t sin6_scope_id; /* set of interfaces for a scope */ + }; + +This structure is designed to be compatible with the sockaddr data +structure used in the 4.3BSD release. + +The sin6_family field identifies this as a sockaddr_in6 structure. This + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 6] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +field overlays the sa_family field when the buffer is cast to a sockaddr +data structure. The value of this field must be AF_INET6. + +The sin6_port field contains the 16-bit UDP or TCP port number. This +field is used in the same way as the sin_port field of the sockaddr_in +structure. The port number is stored in network byte order. + +The sin6_flowinfo field is a 32-bit field that contains two pieces of +information: the traffic class and the flow label. The contents and +interpretation of this member is specified in [1]. The sin6_flowinfo +field SHOULD be set to zero by an implementation prior to using the +sockaddr_in6 structure by an application on receive operations. + +The sin6_addr field is a single in6_addr structure (defined in the +previous section). This field holds one 128-bit IPv6 address. The +address is stored in network byte order. + +The ordering of elements in this structure is specifically designed so +that when sin6_addr field is aligned on a 64-bit boundary, the start of +the structure will also be aligned on a 64-bit boundary. This is done +for optimum performance on 64-bit architectures. + +The sin6_scope_id field is a 32-bit integer that identifies a set of +interfaces as appropriate for the scope of the address carried in the +sin6_addr field. For a link scope sin6_addr sin6_scope_id would be an +interface index. For a site scope sin6_addr, sin6_scope_id would be a +site identifier. The mapping of sin6_scope_id to an interface or set of +interfaces is left to implementation and future specifications on the +subject of site identifiers. + +Notice that the sockaddr_in6 structure will normally be larger than the +generic sockaddr structure. On many existing implementations the +sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both +being 16 bytes. Any existing code that makes this assumption needs to +be examined carefully when converting to IPv6. + + + +3.4 Socket Address Structure for 4.4BSD-Based Systems + +The 4.4BSD release includes a small, but incompatible change to the +socket interface. The "sa_family" field of the sockaddr data structure +was changed from a 16-bit value to an 8-bit value, and the space saved +used to hold a length field, named "sa_len". The sockaddr_in6 data +structure given in the previous section cannot be correctly cast into +the newer sockaddr data structure. For this reason, the following +alternative IPv6 address data structure is provided to be used on +systems based on 4.4BSD. It is defined as a result of including the + header. + + struct sockaddr_in6 { + uint8_t sin6_len; /* length of this struct */ + sa_family_t sin6_family; /* AF_INET6 */ + in_port_t sin6_port; /* transport layer port # */ + uint32_t sin6_flowinfo; /* IPv6 flow information */ + struct in6_addr sin6_addr; /* IPv6 address */ + uint32_t sin6_scope_id; /* set of interfaces for a scope */ + }; + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 7] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +The only differences between this data structure and the 4.3BSD variant +are the inclusion of the length field, and the change of the family +field to a 8-bit data type. The definitions of all the other fields are +identical to the structure defined in the previous section. + +Systems that provide this version of the sockaddr_in6 data structure +must also declare SIN6_LEN as a result of including the +header. This macro allows applications to determine whether they are +being built on a system that supports the 4.3BSD or 4.4BSD variants of +the data structure. + + + +3.5 The Socket Functions + +Applications call the socket() function to create a socket descriptor +that represents a communication endpoint. The arguments to the socket() +function tell the system which protocol to use, and what format address +structure will be used in subsequent functions. For example, to create +an IPv4/TCP socket, applications make the call: + + s = socket(PF_INET, SOCK_STREAM, 0); + +To create an IPv4/UDP socket, applications make the call: + + s = socket(PF_INET, SOCK_DGRAM, 0); + +Applications may create IPv6/TCP and IPv6/UDP sockets by simply using +the constant PF_INET6 instead of PF_INET in the first argument. For +example, to create an IPv6/TCP socket, applications make the call: + + s = socket(PF_INET6, SOCK_STREAM, 0); + +To create an IPv6/UDP socket, applications make the call: + + s = socket(PF_INET6, SOCK_DGRAM, 0); + +Once the application has created a PF_INET6 socket, it must use the +sockaddr_in6 address structure when passing addresses in to the system. +The functions that the application uses to pass addresses into the +system are: + + bind() + connect() + sendmsg() + sendto() + +The system will use the sockaddr_in6 address structure to return +addresses to applications that are using PF_INET6 sockets. The +functions that return an address from the system to an application are: + + accept() + recvfrom() + recvmsg() + getpeername() + getsockname() + +No changes to the syntax of the socket functions are needed to support + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 8] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +IPv6, since all of the "address carrying" functions use an opaque +address pointer, and carry an address length as a function argument. + + + +3.6 Compatibility with IPv4 Applications + +In order to support the large base of applications using the original +API, system implementations must provide complete source and binary +compatibility with the original API. This means that systems must +continue to support PF_INET sockets and the sockaddr_in address +structure. Applications must be able to create IPv4/TCP and IPv4/UDP +sockets using the PF_INET constant in the socket() function, as +described in the previous section. Applications should be able to hold +a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP sockets +simultaneously within the same process. + +Applications using the original API should continue to operate as they +did on systems supporting only IPv4. That is, they should continue to +interoperate with IPv4 nodes. + + + +3.7 Compatibility with IPv4 Nodes + +The API also provides a different type of compatibility: the ability for +IPv6 applications to interoperate with IPv4 applications. This feature +uses the IPv4-mapped IPv6 address format defined in the IPv6 addressing +architecture specification [2]. This address format allows the IPv4 +address of an IPv4 node to be represented as an IPv6 address. The IPv4 +address is encoded into the low-order 32 bits of the IPv6 address, and +the high-order 96 bits hold the fixed prefix 0:0:0:0:0:FFFF. IPv4- +mapped addresses are written as follows: + + ::FFFF: + +These addresses can be generated automatically by the getipnodebyname() +function when the specified host has only IPv4 addresses (as described +in Section 6.1). + +Applications may use PF_INET6 sockets to open TCP connections to IPv4 +nodes, or send UDP packets to IPv4 nodes, by simply encoding the +destination's IPv4 address as an IPv4-mapped IPv6 address, and passing +that address, within a sockaddr_in6 structure, in the connect() or +sendto() call. When applications use PF_INET6 sockets to accept TCP +connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the +system returns the peer's address to the application in the accept(), +recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded +this way. + +Few applications will likely need to know which type of node they are +interoperating with. However, for those applications that do need to +know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is +provided. + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 9] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +3.8 IPv6 Wildcard Address + +While the bind() function allows applications to select the source IP +address of UDP packets and TCP connections, applications often want the +system to select the source address for them. With IPv4, one specifies +the address as the symbolic constant INADDR_ANY (called the "wildcard" +address) in the bind() call, or simply omits the bind() entirely. + +Since the IPv6 address type is a structure (struct in6_addr), a symbolic +constant can be used to initialize an IPv6 address variable, but cannot +be used in an assignment. Therefore systems provide the IPv6 wildcard +address in two forms. + +The first version is a global variable named "in6addr_any" that is an +in6_addr structure. The extern declaration for this variable is defined +in : + + extern const struct in6_addr in6addr_any; + +Applications use in6addr_any similarly to the way they use INADDR_ANY in +IPv4. For example, to bind a socket to port number 23, but let the +system select the source address, an application could use the following +code: + + struct sockaddr_in6 sin6; + . . . + sin6.sin6_family = AF_INET6; + sin6.sin6_flowinfo = 0; + sin6.sin6_port = htons(23); + sin6.sin6_addr = in6addr_any; /* structure assignment */ + . . . + if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) + . . . + +The other version is a symbolic constant named IN6ADDR_ANY_INIT and is +defined in . This constant can be used to initialize an +in6_addr structure: + + struct in6_addr anyaddr = IN6ADDR_ANY_INIT; + +Note that this constant can be used ONLY at declaration time. It can +not be used to assign a previously declared in6_addr structure. For +example, the following code will not work: + + /* This is the WRONG way to assign an unspecified address */ + struct sockaddr_in6 sin6; + . . . + sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */ + +Be aware that the IPv4 INADDR_xxx constants are all defined in host byte +order but the IPv6 IN6ADDR_xxx constants and the IPv6 in6addr_xxx +externals are defined in network byte order. + + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 10] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +3.9 IPv6 Loopback Address + +Applications may need to send UDP packets to, or originate TCP +connections to, services residing on the local node. In IPv4, they can +do this by using the constant IPv4 address INADDR_LOOPBACK in their +connect(), sendto(), or sendmsg() call. + +IPv6 also provides a loopback address to contact local TCP and UDP +services. Like the unspecified address, the IPv6 loopback address is +provided in two forms -- a global variable and a symbolic constant. + +The global variable is an in6_addr structure named "in6addr_loopback." +The extern declaration for this variable is defined in : + + extern const struct in6_addr in6addr_loopback; + +Applications use in6addr_loopback as they would use INADDR_LOOPBACK in +IPv4 applications (but beware of the byte ordering difference mentioned +at the end of the previous section). For example, to open a TCP +connection to the local telnet server, an application could use the +following code: + + struct sockaddr_in6 sin6; + . . . + sin6.sin6_family = AF_INET6; + sin6.sin6_flowinfo = 0; + sin6.sin6_port = htons(23); + sin6.sin6_addr = in6addr_loopback; /* structure assignment */ + . . . + if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1) + . . . + +The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined in +. It can be used at declaration time ONLY; for example: + + struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT; + +Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment to +a previously declared IPv6 address variable. + + + +3.10 Portability Additions + +One simple addition to the sockets API that can help application writers +is the "struct sockaddr_storage". This data structure can simplify +writing code portable across multiple address families and platforms. +This data structure is designed with the following goals. + + - It has a large enough implementation specific maximum size to store + the desired set of protocol specific socket address data structures. + Specifically, it is at least large enough to accommodate sockaddr_in + and sockaddr_in6 and possibly other protocol specific socket + addresses too. + - It is aligned at an appropriate boundary so protocol specific socket + address data structure pointers can be cast to it and access their + fields without alignment problems. (e.g. pointers to sockaddr_in6 + and/or sockaddr_in can be cast to it and access fields without alignment + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 11] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + problems). + - It has the initial field(s) isomorphic to the fields of the + "struct sockaddr" data structure on that implementation which + can be used as a discriminants for deriving the protocol in use. + These initial field(s) would on most implementations either be a + single field of type "sa_family_t" (isomorphic to sa_family field, + 16 bits) or two fields of type uint8_t and sa_family_t respectively, + (isomorphic to sa_len and sa_family_t, 8 bits each). + +An example implementation design of such a data structure would be as +follows. + +/* + * Desired design of maximum size and alignment + */ +#define _SS_MAXSIZE 128 /* Implementation specific max size */ +#define _SS_ALIGNSIZE (sizeof (int64_t)) + /* Implementation specific desired alignment */ +/* + * Definitions used for sockaddr_storage structure paddings design. + */ +#define _SS_PAD1SIZE (_SS_ALIGNSIZE - sizeof (sa_family_t)) +#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+ + _SS_PAD1SIZE + _SS_ALIGNSIZE)) +struct sockaddr_storage { + sa_family_t __ss_family; /* address family */ + /* Following fields are implementation specific */ + char __ss_pad1[_SS_PAD1SIZE]; + /* 6 byte pad, this is to make implementation + /* specific pad up to alignment field that */ + /* follows explicit in the data structure */ + int64_t __ss_align; /* field to force desired structure */ + /* storage alignment */ + char __ss_pad2[_SS_PAD2SIZE]; + /* 112 byte pad to achieve desired size, */ + /* _SS_MAXSIZE value minus size of ss_family */ + /* __ss_pad1, __ss_align fields is 112 */ +}; + +On implementations where sockaddr data structure includes a "sa_len", +field this data structure would look like this: + +/* + * Definitions used for sockaddr_storage structure paddings design. + */ +#define _SS_PAD1SIZE (_SS_ALIGNSIZE - + (sizeof (uint8_t) + sizeof (sa_family_t)) +#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+ + _SS_PAD1SIZE + _SS_ALIGNSIZE)) +struct sockaddr_storage { + uint8_t __ss_len; /* address length */ + sa_family_t __ss_family; /* address family */ + /* Following fields are implementation specific */ + char __ss_pad1[_SS_PAD1SIZE]; + /* 6 byte pad, this is to make implementation + /* specific pad up to alignment field that */ + /* follows explicit in the data structure */ + int64_t __ss_align; /* field to force desired structure */ + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 12] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + /* storage alignment */ + char __ss_pad2[_SS_PAD2SIZE]; + /* 112 byte pad to achieve desired size, */ + /* _SS_MAXSIZE value minus size of ss_len, */ + /* __ss_family, __ss_pad1, __ss_align fields is 112 */ +}; + +The above example implementation illustrates a data structure which will +align on a 64 bit boundary. An implementation specific field +"__ss_align" along "__ss_pad1" is used to force a 64-bit alignment which +covers proper alignment good enough for needs of sockaddr_in6 (IPv6), +sockaddr_in (IPv4) address data structures. The size of padding fields +__ss_pad1 depends on the chosen alignment boundary. The size of padding +field __ss_pad2 depends on the value of overall size chosen for the +total size of the structure. This size and alignment are represented in +the above example by implementation specific (not required) constants +_SS_MAXSIZE (chosen value 128) and _SS_ALIGNMENT (with chosen value 8). +Constants _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value +112) are also for illustration and not required. The implementation +specific definitions and structure field names above start with an +underscore to denote implementation private namespace. Portable code is +not expected to access or reference those fields or constants. + +The sockaddr_storage structure solves the problem of declaring storage +for automatic variables which is large enough and aligned enough for +storing socket address data structure of any family. For example, code +with a file descriptor and without the context of the address family can +pass a pointer to a variable of this type where a pointer to a socket +address structure is expected in calls such as getpeername() and +determine the address family by accessing the received content after the +call. + +The sockaddr_storage structure may also be useful and applied to certain +other interfaces where a generic socket address large enough and aligned +for use with multiple address families may be needed. A discussion of +those interfaces is outside the scope of this document. + +Also, much existing code assumes that any socket address structure can +fit in a generic sockaddr structure. While this has been true for IPv4 +socket address structures, it has always been false for Unix domain +socket address structures (but in practice this has not been a problem) +and it is also false for IPv6 socket address structures (which can be a +problem). + +So now an application can do the following: + + struct sockaddr_storage __ss; + struct sockaddr_in6 *sin6; + sin6 = (struct sockaddr_in6 *) &__ss; + + + +4. Interface Identification + +This API uses an interface index (a small positive integer) to identify +the local interface on which a multicast group is joined (Section 5.3). +Additionally, the advanced API [4] uses these same interface indexes to +identify the interface on which a datagram is received, or to specify + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 13] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +the interface on which a datagram is to be sent. + +Interfaces are normally known by names such as "le0", "sl1", "ppp2", and +the like. On Berkeley-derived implementations, when an interface is +made known to the system, the kernel assigns a unique positive integer +value (called the interface index) to that interface. These are small +positive integers that start at 1. (Note that 0 is never used for an +interface index.) There may be gaps so that there is no current +interface for a particular positive interface index. + +This API defines two functions that map between an interface name and +index, a third function that returns all the interface names and +indexes, and a fourth function to return the dynamic memory allocated by +the previous function. How these functions are implemented is left up +to the implementation. 4.4BSD implementations can implement these +functions using the existing sysctl() function with the NET_RT_IFLIST +command. Other implementations may wish to use ioctl() for this +purpose. + + + +4.1 Name-to-Index + +The first function maps an interface name into its corresponding index. + + #include + + unsigned int if_nametoindex(const char *ifname); + +If the specified interface name does not exist, the return value is 0, +and errno is set to ENXIO. If there was a system error (such as +running out of memory), the return value is 0 and errno is set to the +proper value (e.g., ENOMEM). + + + +4.2 Index-to-Name + +The second function maps an interface index into its corresponding name. + + #include + + char *if_indextoname(unsigned int ifindex, char *ifname); + +The ifname argument must point to a buffer of at least IF_NAMESIZE bytes +into which the interface name corresponding to the specified index is +returned. (IF_NAMESIZE is also defined in and its value +includes a terminating null byte at the end of the interface name.) This +pointer is also the return value of the function. If there is no +interface corresponding to the specified index, NULL is returned, and +errno is set to ENXIO, if there was a system error (such as running out +of memory), if_indextoname returns NULL and errno would be set to the +proper value (e.g., ENOMEM). + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 14] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +4.3 Return All Interface Names and Indexes + +The if_nameindex structure holds the information about a single +interface and is defined as a result of including the header. + + struct if_nameindex { + unsigned int if_index; /* 1, 2, ... */ + char *if_name; /* null terminated name: "le0", ... */ + }; + +The final function returns an array of if_nameindex structures, one +structure per interface. + + struct if_nameindex *if_nameindex(void); + +The end of the array of structures is indicated by a structure with an +if_index of 0 and an if_name of NULL. The function returns a NULL +pointer upon an error, and would set errno to the appropriate value. + +The memory used for this array of structures along with the interface +names pointed to by the if_name members is obtained dynamically. This +memory is freed by the next function. + + + +4.4 Free Memory + +The following function frees the dynamic memory that was allocated by +if_nameindex(). + + #include + + void if_freenameindex(struct if_nameindex *ptr); + +The argument to this function must be a pointer that was returned by +if_nameindex(). + +Currently net/if.h doesn't have prototype definitions for functions and +it is recommended that these definitions be defined in net/if.h as well +and the struct if_nameindex{}. + + + +5. Socket Options + +A number of new socket options are defined for IPv6. All of these new +options are at the IPPROTO_IPV6 level. That is, the "level" parameter +in the getsockopt() and setsockopt() calls is IPPROTO_IPV6 when using +these options. The constant name prefix IPV6_ is used in all of the new +socket options. This serves to clearly identify these options as +applying to IPv6. + +The declaration for IPPROTO_IPV6, the new IPv6 socket options, and +related constants defined in this section are obtained by including the +header . + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 15] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +5.1 Unicast Hop Limit + +A new setsockopt() option controls the hop limit used in outgoing +unicast IPv6 packets. The name of this option is IPV6_UNICAST_HOPS, and +it is used at the IPPROTO_IPV6 layer. The following example illustrates +how it is used: + + int hoplimit = 10; + + if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, + (char *) &hoplimit, sizeof(hoplimit)) == -1) + perror("setsockopt IPV6_UNICAST_HOPS"); + +When the IPV6_UNICAST_HOPS option is set with setsockopt(), the option +value given is used as the hop limit for all subsequent unicast packets +sent via that socket. If the option is not set, the system selects a +default value. The integer hop limit value (called x) is interpreted as +follows: + + x < -1: return an error of EINVAL + x == -1: use kernel default + 0 <= x <= 255: use x + x >= 256: return an error of EINVAL + +The IPV6_UNICAST_HOPS option may be used with getsockopt() to determine +the hop limit value that the system will use for subsequent unicast +packets sent via that socket. For example: + + int hoplimit; + size_t len = sizeof(hoplimit); + + if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS, + (char *) &hoplimit, &len) == -1) + perror("getsockopt IPV6_UNICAST_HOPS"); + else + printf("Using %d for hop limit.\n", hoplimit); + + + +5.2 Sending and Receiving Multicast Packets + +IPv6 applications may send UDP multicast packets by simply specifying an +IPv6 multicast address in the address argument of the sendto() function. + +Three socket options at the IPPROTO_IPV6 layer control some of the +parameters for sending multicast packets. Setting these options is not +required: applications may send multicast packets without using these +options. The setsockopt() options for controlling the sending of +multicast packets are summarized below. These three options can also be +used with getsockopt(). + + IPV6_MULTICAST_IF + + Set the interface to use for outgoing multicast packets. + The argument is the index of the interface to use. + + Argument type: unsigned int + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 16] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + IPV6_MULTICAST_HOPS + + Set the hop limit to use for outgoing multicast packets. + (Note a separate option - IPV6_UNICAST_HOPS - is + provided to set the hop limit to use for outgoing + unicast packets.) + + The interpretation of the argument is the same + as for the IPV6_UNICAST_HOPS option: + + x < -1: return an error of EINVAL + x == -1: use kernel default + 0 <= x <= 255: use x + x >= 256: return an error of EINVAL + + If IPV6_MULTICAST_HOPS is not set, the default is 1 + (same as IPv4 today) + + Argument type: int + + IPV6_MULTICAST_LOOP + + If a multicast datagram is sent to a group to which the sending host + itself belongs (on the outgoing interface), a copy of the datagram is + looped back by the IP layer for local delivery if this option is set to + 1. If this option is set to 0 a copy is not looped back. Other option + values return an error of EINVAL. + + If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback; same as + IPv4 today). + + Argument type: unsigned int + +The reception of multicast packets is controlled by the two setsockopt() +options summarized below. An error of EOPNOTSUPP is returned if these +two options are used with getsockopt(). + + IPV6_JOIN_GROUP + + Join a multicast group on a specified local interface. + If the interface index is specified as 0, + the kernel chooses the local interface. + For example, some kernels look up the multicast group + in the normal IPv6 routing table and using the resulting interface. + + Argument type: struct ipv6_mreq + + IPV6_LEAVE_GROUP + + Leave a multicast group on a specified interface. + + Argument type: struct ipv6_mreq + +The argument type of both of these options is the ipv6_mreq structure, +defined as a result of including the header; + + struct ipv6_mreq { + struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */ + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 17] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + unsigned int ipv6mr_interface; /* interface index */ + }; + +Note that to receive multicast datagrams a process must join the +multicast group and bind the UDP port to which datagrams will be sent. +Some processes also bind the multicast group address to the socket, in +addition to the port, to prevent other datagrams destined to that same +port from being delivered to the socket. + + + +6. Library Functions + +New library functions are needed to perform a variety of operations with +IPv6 addresses. Functions are needed to lookup IPv6 addresses in the +Domain Name System (DNS). Both forward lookup (nodename-to-address +translation) and reverse lookup (address-to-nodename translation) need +to be supported. Functions are also needed to convert IPv6 addresses +between their binary and textual form. + +We note that the two existing functions, gethostbyname() and +gethostbyaddr(), are left as-is. New functions are defined to handle +both IPv4 and IPv6 addresses. + + + +6.1 Nodename-to-Address Translation + +The commonly used function gethostbyname() is inadequate for many +applications, first because it provides no way for the caller to specify +anything about the types of addresses desired (IPv4 only, IPv6 only, +IPv4-mapped IPv6 are OK, etc.), and second because many implementations +of this function are not thread safe. RFC 2133 defined a function named +gethostbyname2() but this function was also inadequate, first because +its use required setting a global option (RES_USE_INET6) when IPv6 +addresses were required, and second because a flag argument is needed to +provide the caller with additional control over the types of addresses +required. + +The following function is new and must be thread safe: + + #include + #include + + struct hostent *getipnodebyname(const char *name, int af, int flags + int *error_num); + +The name argument can be either a node name or a numeric address string +(i.e., a dotted-decimal IPv4 address or an IPv6 hex address). The af +argument specifies the address family, either AF_INET or AF_INET6. The +error_num value is returned to the caller, via a pointer, with the +appropriate error code in error_num, to support thread safe error code +returns. error_num will be set to one of the following values: + + HOST_NOT_FOUND + + No such host is known. + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 18] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + NO_ADDRESS + + The server recognised the request and the name but no address + is available. Another type of request to the name server for + the domain might return an answer. + + NO_RECOVERY + + An unexpected server failure occurred which cannot be recovered. + + TRY_AGAIN + + A temporary and possibly transient error occurred, such as a + failure of a server to respond. + + +The flags argument specifies the types of addresses that are searched +for, and the types of addresses that are returned. We note that a +special flags value of AI_DEFAULT (defined below) should handle most +applications. + +That is, porting simple applications to use IPv6 replaces the call + + hptr = gethostbyname(name); + +with + + hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num); + +and changes any subsequent error diagnosis code to use error_num instead +of externally declared variables, such as h_errno. + +Applications desiring finer control over the types of addresses searched +for and returned, can specify other combinations of the flags argument. + +A flags of 0 implies a strict interpretation of the af argument: + + - If flags is 0 and af is AF_INET, then the caller wants only IPv4 + addresses. A query is made for A records. If successful, the IPv4 + addresses are returned and the h_length member of the hostent + structure will be 4, else the function returns a NULL pointer. + + - If flags is 0 and if af is AF_INET6, then the caller wants only + IPv6 addresses. A query is made for AAAA records. If successful, + the IPv6 addresses are returned and the h_length member of the + hostent structure will be 16, else the function returns a NULL + pointer. + +Other constants can be logically-ORed into the flags argument, to modify +the behavior of the function. + + - If the AI_V4MAPPED flag is specified along with an af of + AF_INET6, then the caller will accept IPv4-mapped IPv6 + addresses. That is, if no AAAA records are found then a query + is made for A records and any found are returned as IPv4-mapped + IPv6 addresses (h_length will be 16). The AI_V4MAPPED flag is + ignored unless af equals AF_INET6. + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 19] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + - The AI_ALL flag is used in conjunction with the AI_V4MAPPED + flag, and is only used with the IPv6 address family. When AI_ALL + is logically or'd with AI_V4MAPPED flag then the caller wants + all addresses: IPv6 and IPv4-mapped IPv6. A query is first made + for AAAA records and if successful, the IPv6 addresses are returned. + Another query is then made for A records and any found are returned + as IPv4-mapped IPv6 addresses. h_length will be 16. Only if both + queries fail does the function return a NULL pointer. This flag is + ignored unless af equals AF_INET6. + + - The AI_ADDRCONFIG flag specifies that a query for AAAA records + should occur only if the node has at least one IPv6 source address + configured and a query for A records should occur only if the + node has at least one IPv4 source address configured. + + For example, if the node has no IPv6 source addresses configured, + and af equals AF_INET6, and the node name being looked up has both + AAAA and A records, then: + + (a) if only AI_ADDRCONFIG is specified, the function returns a + NULL pointer; + (b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A records + are returned as IPv4-mapped IPv6 addresses; + +The special flags value of AI_DEFAULT is defined as + + #define AI_DEFAULT (AI_V4MAPPED | AI_ADDRCONFIG) + +We noted that the getipnodebyname() function must allow the name +argument to be either a node name or a literal address string (i.e., a +dotted-decimal IPv4 address or an IPv6 hex address). This saves +applications from having to call inet_pton() to handle literal address +strings. + +There are four scenarios based on the type of literal address string and +the value of the af argument. + +The two simple cases are: + +When name is a dotted-decimal IPv4 address and af equals AF_INET, or +when name is an IPv6 hex address and af equals AF_INET6. The members of +the returned hostent structure are: h_name points to a copy of the name +argument, h_aliases is a NULL pointer, h_addrtype is a copy of the af +argument, h_length is either 4 (for AF_INET) or 16 (for AF_INET6), +h_addr_list[0] is a pointer to the 4-byte or 16-byte binary address, and +h_addr_list[1] is a NULL pointer. + +When name is a dotted-decimal IPv4 address and af equals AF_INET6, and +flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is returned: +h_name points to an IPv6 hex address containing the IPv4-mapped IPv6 +address, h_aliases is a NULL pointer, h_addrtype is AF_INET6, h_length +is 16, h_addr_list[0] is a pointer to the 16-byte binary address, and +h_addr_list[1] is a NULL pointer. If AI_V4MAPPED is set (with or +without AI_ALL) return IPv4-mapped otherwise return NULL. + +It is an error when name is an IPv6 hex address and af equals AF_INET. +The function's return value is a NULL pointer and error_num equals +HOST_NOT_FOUND. + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 20] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +6.2 Address-To-Nodename Translation + +The following function has the same arguments as the existing +gethostbyaddr() function, but adds an error number. + + #include + #include + + struct hostent *getipnodebyaddr(const void *src, size_t len, int af, + int *error_num); + +As with getipnodebyname(), getipnodebyaddr() must be thread safe. The +error_num value is returned to the caller with the appropriate error +code, to support thread safe error code returns. The following error +conditions may be returned for error_num: + + HOST_NOT_FOUND + + No such host is known. + + NO_ADDRESS + + The server recognized the request and the name but no address + is available. Another type of request to the name server for + the domain might return an answer. + + NO_RECOVERY + + An unexpected server failure occurred which cannot be recovered. + + TRY_AGAIN + + A temporary and possibly transient error occurred, such as a + failure of a server to respond. + + +One possible source of confusion is the handling of IPv4-mapped IPv6 +addresses and IPv4-compatible IPv6 addresses, but the following logic +should apply. + + 1. If af is AF_INET6, and if len equals 16, and if the IPv6 address + is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address, + then skip over the first 12 bytes of the IPv6 address, set af to + AF_INET, and set len to 4. + + 2. If af is AF_INET, lookup the name for the given IPv4 address + (e.g., query for a PTR record in the in-addr.arpa domain). + + 3. If af is AF_INET6, lookup the name for the given IPv6 address + (e.g., query for a PTR record in the ip6.int domain). + + 4. If the function is returning success, then the single address that + is returned in the hostent structure is a copy of the first argument + to the function with the same address family that was passed as + an argument to this function. + +All four steps listed are performed, in order. Also note that the IPv6 +hex addresses "::" and "::1" MUST NOT be treated as IPv4-compatible + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 21] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +addresses, and if the address is "::", HOST_NOT_FOUND MUST be returned +and a query of the address not performed. + +Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return false +for "::" and "::1". + + + +6.3 Freeing memory for getipnodebyname and getipnodebyaddr + +The hostent structure does not change from its existing definition. +This structure, and the information pointed to by this structure, are +dynamically allocated by getipnodebyname and getipnodebyaddr. The +following function frees this memory: + + #include + + void freehostent(struct hostent *ptr); + + + +6.4 Protocol-Independent Nodename and Service Name Translation + +Nodename-to-address translation is done in a protocol-independent +fashion using the getaddrinfo() function that is taken from the +Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g +(Protocol Independent Interfaces) draft specification [3]. + +The official specification for this function will be the final POSIX +standard, with the following additional requirements: + + - getaddrinfo() (along with the getnameinfo() function described in + the next section) must be thread safe. + + - The AI_NUMERICHOST is new with this document. + + - All fields in socket address structures returned by getaddrinfo() + that are not filled in through an explicit argument (e.g., + sin6_flowinfo and sin_zero) must be set to 0. (This makes it easier + to compare socket address structures.) + + - getaddrinfo() must fill in the length field of a socket address structure + (e.g., sin6_len) on systems that support this field. + +We are providing this independent description of the function because +POSIX standards are not freely available (as are IETF documents). + + #include + #include + + int getaddrinfo(const char *nodename, const char *servname, + const struct addrinfo *hints, + struct addrinfo **res); + +The addrinfo structure is defined as a result of including the +header. + + struct addrinfo { + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 22] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */ + int ai_family; /* PF_xxx */ + int ai_socktype; /* SOCK_xxx */ + int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ + size_t ai_addrlen; /* length of ai_addr */ + char *ai_canonname; /* canonical name for nodename */ + struct sockaddr *ai_addr; /* binary address */ + struct addrinfo *ai_next; /* next structure in linked list */ + }; + +The return value from the function is 0 upon success or a nonzero error +code. The following names are the nonzero error codes from +getaddrinfo(), and are defined in : + + EAI_ADDRFAMILY address family for nodename not supported + EAI_AGAIN temporary failure in name resolution + EAI_BADFLAGS invalid value for ai_flags + EAI_FAIL non-recoverable failure in name resolution + EAI_FAMILY ai_family not supported + EAI_MEMORY memory allocation failure + EAI_NODATA no address associated with nodename + EAI_NONAME nodename nor servname provided, or not known + EAI_SERVICE servname not supported for ai_socktype + EAI_SOCKTYPE ai_socktype not supported + EAI_SYSTEM system error returned in errno + +The nodename and servname arguments are pointers to null-terminated +strings or NULL. One or both of these two arguments must be a non-NULL +pointer. In the normal client scenario, both the nodename and servname +are specified. In the normal server scenario, only the servname is +specified. A non-NULL nodename string can be either a node name or a +numeric host address string (i.e., a dotted-decimal IPv4 address or an +IPv6 hex address). A non-NULL servname string can be either a service +name or a decimal port number. + +The caller can optionally pass an addrinfo structure, pointed to by the +third argument, to provide hints concerning the type of socket that the +caller supports. In this hints structure all members other than +ai_flags, ai_family, ai_socktype, and ai_protocol must be zero or a NULL +pointer. A value of PF_UNSPEC for ai_family means the caller will +accept any protocol family. A value of 0 for ai_socktype means the +caller will accept any socket type. A value of 0 for ai_protocol means +the caller will accept any protocol. For example, if the caller handles +only TCP and not UDP, then the ai_socktype member of the hints structure +should be set to SOCK_STREAM when getaddrinfo() is called. If the +caller handles only IPv4 and not IPv6, then the ai_family member of the +hints structure should be set to PF_INET when getaddrinfo() is called. +If the third argument to getaddrinfo() is a NULL pointer, this is the +same as if the caller had filled in an addrinfo structure initialized to +zero with ai_family set to PF_UNSPEC. + +Upon successful return a pointer to a linked list of one or more +addrinfo structures is returned through the final argument. The caller +can process each addrinfo structure in this list by following the +ai_next pointer, until a NULL pointer is encountered. In each returned +addrinfo structure the three members ai_family, ai_socktype, and +ai_protocol are the corresponding arguments for a call to the socket() +function. In each addrinfo structure the ai_addr member points to a + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 23] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +filled-in socket address structure whose length is specified by the +ai_addrlen member. + +If the AI_PASSIVE bit is set in the ai_flags member of the hints +structure, then the caller plans to use the returned socket address +structure in a call to bind(). In this case, if the nodename argument +is a NULL pointer, then the IP address portion of the socket address +structure will be set to INADDR_ANY for an IPv4 address or +IN6ADDR_ANY_INIT for an IPv6 address. + +If the AI_PASSIVE bit is not set in the ai_flags member of the hints +structure, then the returned socket address structure will be ready for +a call to connect() (for a connection-oriented protocol) or either +connect(), sendto(), or sendmsg() (for a connectionless protocol). In +this case, if the nodename argument is a NULL pointer, then the IP +address portion of the socket address structure will be set to the +loopback address. + +If the AI_CANONNAME bit is set in the ai_flags member of the hints +structure, then upon successful return the ai_canonname member of the +first addrinfo structure in the linked list will point to a null- +terminated string containing the canonical name of the specified +nodename. + +If the AI_NUMERICHOST bit is set in the ai_flags member of the hints +structure, then a non-NULL nodename string must be a numeric host +address string. Otherwise an error of EAI_NONAME is returned. This +flag prevents any type of name resolution service (e.g., the DNS) from +being called. + +All of the information returned by getaddrinfo() is dynamically +allocated: the addrinfo structures, and the socket address structures +and canonical node name strings pointed to by the addrinfo structures. +To return this information to the system the function freeaddrinfo() is +called: + + #include + #include + + void freeaddrinfo(struct addrinfo *ai); + +The addrinfo structure pointed to by the ai argument is freed, along +with any dynamic storage pointed to by the structure. This operation is +repeated until a NULL ai_next pointer is encountered. + +To aid applications in printing error messages based on the EAI_xxx +codes returned by getaddrinfo(), the following function is defined. + + #include + #include + + char *gai_strerror(int ecode); + +The argument is one of the EAI_xxx values defined earlier and the return +value points to a string describing the error. If the argument is not +one of the EAI_xxx values, the function still returns a pointer to a +string whose contents indicate an unknown error. + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 24] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +6.5 Socket Address Structure to Nodename and Service Name + +The POSIX 1003.1g specification includes no function to perform the +reverse conversion from getaddrinfo(): to look up a nodename and service +name, given the binary address and port. Therefore, we define the +following function: + + #include + #include + + int getnameinfo(const struct sockaddr *sa, socklen_t salen, + char *host, size_t hostlen, + char *serv, size_t servlen, + int flags); + +This function looks up an IP address and port number provided by the +caller in the DNS and system-specific database, and returns text strings +for both in buffers provided by the caller. The function indicates +successful completion by a zero return value; a non-zero return value +indicates failure. + +The first argument, sa, points to either a sockaddr_in structure (for +IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP address +and port number. The salen argument gives the length of the sockaddr_in +or sockaddr_in6 structure. + +The function returns the nodename associated with the IP address in the +buffer pointed to by the host argument. The caller provides the size of +this buffer via the hostlen argument. The service name associated with +the port number is returned in the buffer pointed to by serv, and the +servlen argument gives the length of this buffer. The caller specifies +not to return either string by providing a zero value for the hostlen or +servlen arguments. Otherwise, the caller must provide buffers large +enough to hold the nodename and the service name, including the +terminating null characters. + +Unfortunately most systems do not provide constants that specify the +maximum size of either a fully-qualified domain name or a service name. +Therefore to aid the application in allocating buffers for these two +returned strings the following constants are defined in : + + #define NI_MAXHOST 1025 + #define NI_MAXSERV 32 + +The first value is actually defined as the constant MAXDNAME in recent +versions of BIND's header (older versions of BIND +define this constant to be 256) and the second is a guess based on the +services listed in the current Assigned Numbers RFC. + +The final argument is a flag that changes the default actions of this +function. By default the fully-qualified domain name (FQDN) for the +host is looked up in the DNS and returned. If the flag bit NI_NOFQDN is +set, only the nodename portion of the FQDN is returned for local hosts. + +If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be +located in the DNS, the numeric form of the host's address is returned +instead of its name (e.g., by calling inet_ntop() instead of +getipnodebyaddr()). If the flag bit NI_NAMEREQD is set, an error is + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 25] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +returned if the host's name cannot be located in the DNS. + +If the flag bit NI_NUMERICSERV is set, the numeric form of the service +address is returned (e.g., its port number) instead of its name. The +two NI_NUMERICxxx flags are required to support the "-n" flag that many +commands provide. + +A fifth flag bit, NI_DGRAM, specifies that the service is a datagram +service, and causes getservbyport() to be called with a second argument +of "udp" instead of its default of "tcp". This is required for the few +ports (e.g. 512-514) that have different services for UDP and TCP. + +These NI_xxx flags are defined in along with the AI_xxx flags +already defined for getaddrinfo(). + + + +6.6 Address Conversion Functions + +The two functions inet_addr() and inet_ntoa() convert an IPv4 address +between binary and text form. IPv6 applications need similar functions. +The following two functions convert both IPv6 and IPv4 addresses: + + #include + #include + + int inet_pton(int af, const char *src, void *dst); + + const char *inet_ntop(int af, const void *src, + char *dst, size_t size); + +The inet_pton() function converts an address in its standard text +presentation form into its numeric binary form. The af argument +specifies the family of the address. Currently the AF_INET and AF_INET6 +address families are supported. The src argument points to the string +being passed in. The dst argument points to a buffer into which the +function stores the numeric address. The address is returned in network +byte order. Inet_pton() returns 1 if the conversion succeeds, 0 if the +input is not a valid IPv4 dotted-decimal string or a valid IPv6 address +string, or -1 with errno set to EAFNOSUPPORT if the af argument is +unknown. The calling application must ensure that the buffer referred +to by dst is large enough to hold the numeric address (e.g., 4 bytes for +AF_INET or 16 bytes for AF_INET6). + +If the af argument is AF_INET, the function accepts a string in the +standard IPv4 dotted-decimal form: + + ddd.ddd.ddd.ddd + +where ddd is a one to three digit decimal number between 0 and 255. +Note that many implementations of the existing inet_addr() and +inet_aton() functions accept nonstandard input: octal numbers, +hexadecimal numbers, and fewer than four numbers. inet_pton() does not +accept these formats. + +If the af argument is AF_INET6, then the function accepts a string in +one of the standard IPv6 text forms defined in Section 2.2 of the +addressing architecture specification [2]. + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 26] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +The inet_ntop() function converts a numeric address into a text string +suitable for presentation. The af argument specifies the family of the +address. This can be AF_INET or AF_INET6. The src argument points to a +buffer holding an IPv4 address if the af argument is AF_INET, or an IPv6 +address if the af argument is AF_INET6, the address must be in network +byte order. The dst argument points to a buffer where the function will +store the resulting text string. The size argument specifies the size +of this buffer. The application must specify a non-NULL dst argument. +For IPv6 addresses, the buffer must be at least 46-octets. For IPv4 +addresses, the buffer must be at least 16-octets. In order to allow +applications to easily declare buffers of the proper size to store IPv4 +and IPv6 addresses in string form, the following two constants are +defined in : + + #define INET_ADDRSTRLEN 16 + #define INET6_ADDRSTRLEN 46 + +The inet_ntop() function returns a pointer to the buffer containing the +text string if the conversion succeeds, and NULL otherwise. Upon +failure, errno is set to EAFNOSUPPORT if the af argument is invalid or +ENOSPC if the size of the result buffer is inadequate. + + + +6.7 Address Testing Macros + +The following macros can be used to test for special IPv6 addresses. + + #include + + int IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *); + int IN6_IS_ADDR_LOOPBACK (const struct in6_addr *); + int IN6_IS_ADDR_MULTICAST (const struct in6_addr *); + int IN6_IS_ADDR_LINKLOCAL (const struct in6_addr *); + int IN6_IS_ADDR_SITELOCAL (const struct in6_addr *); + int IN6_IS_ADDR_V4MAPPED (const struct in6_addr *); + int IN6_IS_ADDR_V4COMPAT (const struct in6_addr *); + + int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *); + int IN6_IS_ADDR_MC_GLOBAL (const struct in6_addr *); + +The first seven macros return true if the address is of the specified +type, or false otherwise. The last five test the scope of a multicast +address and return true if the address is a multicast address of the +specified scope or false if the address is either not a multicast +address or not of the specified scope. Note that IN6_IS_ADDR_LINKLOCAL +and IN6_IS_ADDR_SITELOCAL return true only for the two local-use IPv6 +unicast addresses. These two macros do not return true for IPv6 +multicast addresses of either link-local scope or site-local scope. + + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 27] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +7. Summary of New Definitions + +The following list summarizes the constants, structure, and extern +definitions discussed in this memo, sorted by header. + + IF_NAMESIZE + struct if_nameindex{}; + + AI_ADDRCONFIG + AI_DEFAULT + AI_ALL + AI_CANONNAME + AI_NUMERICHOST + AI_PASSIVE + AI_V4MAPPED + EAI_ADDRFAMILY + EAI_AGAIN + EAI_BADFLAGS + EAI_FAIL + EAI_FAMILY + EAI_MEMORY + EAI_NODATA + EAI_NONAME + EAI_SERVICE + EAI_SOCKTYPE + EAI_SYSTEM + NI_DGRAM + NI_MAXHOST + NI_MAXSERV + NI_NAMEREQD + NI_NOFQDN + NI_NUMERICHOST + NI_NUMERICSERV + struct addrinfo{}; + + IN6ADDR_ANY_INIT + IN6ADDR_LOOPBACK_INIT + INET6_ADDRSTRLEN + INET_ADDRSTRLEN + IPPROTO_IPV6 + IPV6_JOIN_GROUP + IPV6_LEAVE_GROUP + IPV6_MULTICAST_HOPS + IPV6_MULTICAST_IF + IPV6_MULTICAST_LOOP + IPV6_UNICAST_HOPS + SIN6_LEN + extern const struct in6_addr in6addr_any; + extern const struct in6_addr in6addr_loopback; + struct in6_addr{}; + struct ipv6_mreq{}; + struct sockaddr_in6{}; + + AF_INET6 + PF_INET6 + struct sockaddr_storage; + +The following list summarizes the function and macro prototypes + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 28] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +discussed in this memo, sorted by header. + + int inet_pton(int, const char *, void *); + const char *inet_ntop(int, const void *, + char *, size_t); + + char *if_indextoname(unsigned int, char *); + unsigned int if_nametoindex(const char *); + void if_freenameindex(struct if_nameindex *); + struct if_nameindex *if_nameindex(void); + + int getaddrinfo(const char *, const char *, + const struct addrinfo *, + struct addrinfo **); + int getnameinfo(const struct sockaddr *, socklen_t, + char *, size_t, char *, size_t, int); + void freeaddrinfo(struct addrinfo *); + char *gai_strerror(int); + struct hostent *getipnodebyname(const char *, int, int, + int *); + struct hostent *getipnodebyaddr(const void *, size_t, int, + int *); + void freehostent(struct hostent *); + + int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *); + int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_MULTICAST(const struct in6_addr *); + int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *); + int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *); + int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *); + int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *); + + + + +8. Security Considerations + +IPv6 provides a number of new security mechanisms, many of which need to +be accessible to applications. Companion memos detailing the extensions +to the socket interfaces to support IPv6 security are being written. + + + +9. Year 2000 Considerations + +There are no issues for this draft concerning the Year 2000 issue +regarding the use of dates. + + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 29] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +Changes From RFC 2133 + +Changes made in the March 1998 Edition (-01 draft): + + Changed all "hostname" to "nodename" for consistency with other IPv6 + documents. + + Section 3.3: changed comment for sin6_flowinfo to be "traffic class & + flow info" and updated corresponding text description to current + definition of these two fields. + + Section 3.10 ("Portability Additions") is new. + + Section 6: a new paragraph was added reiterating that the existing + gethostbyname() and gethostbyaddr() are not changed. + + Section 6.1: change gethostbyname3() to getnodebyname(). Add + AI_DEFAULT to handle majority of applications. Renamed + AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and IPv4 + addresses too. Defined exactly what getnodebyname() must return if + the name argument is a numeric address string. + + Section 6.2: change gethostbyaddr() to getnodebyaddr(). Reword items + 2 and 3 in the description of how to handle IPv4-mapped and IPv4- + compatible addresses to "lookup a name" for a given address, instead + of specifying what type of DNS query to issue. + + Section 6.3: added two more requirements to getaddrinfo(). + + Section 7: added the following constants to the list for : + AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED. Add union sockaddr_union and + SA_LEN to the lists for . + + Updated references. + +Changes made in the November 1997 Edition (-00 draft): + + The data types have been changed to conform with Draft 6.6 of the + Posix 1003.1g standard. + + Section 3.2: data type of s6_addr changed to "uint8_t". + + Section 3.3: data type of sin6_family changed to "sa_family_t". data + type of sin6_port changed to "in_port_t", data type of sin6_flowinfo + changed to "uint32_t". + + Section 3.4: same as Section 3.3, plus data type of sin6_len changed + to "uint8_t". + + Section 6.2: first argument of gethostbyaddr() changed from "const + char *" to "const void *" and second argument changed from "int" to + "size_t". + + Section 6.4: second argument of getnameinfo() changed from "size_t" + to "socklen_t". + + The wording was changed when new structures were defined, to be more + explicit as to which header must be included to define the structure: + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 30] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section 3.4 + (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3 + (ipv6_mreq{}), and Section 6.3 (addrinfo{}). + + Section 4: NET_RT_LIST changed to NET_RT_IFLIST. + + Section 5.1: The IPV6_ADDRFORM socket option was removed. + + Section 5.3: Added a note that an option value other than 0 or 1 for + IPV6_MULTICAST_LOOP returns an error. Added a note that + IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP can + also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and + IPV6_DROP_MEMBERSHIP cannot be used with getsockopt(). + + Section 6.1: Removed the description of gethostbyname2() and its + associated RES_USE_INET6 option, replacing it with gethostbyname3(). + + Section 6.2: Added requirement that gethostbyaddr() be thread safe. + Reworded step 4 to avoid using the RES_USE_INET6 option. + + Section 6.3: Added the requirement that getaddrinfo() and + getnameinfo() be thread safe. Added the AI_NUMERICHOST flag. + + Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and + IN6_IS_ADDR_SITELOCAL macros. + +Changes made to the draft -01 specification Sept 98 + + Changed priority to traffic class in the spec. + + Added the need for scope identification in section 2.1. + + Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and 3.4. + + Changed 3.10 to use generic storage structure to support holding IPv6 + addresses and removed the SA_LEN macro. + + Distinguished between invalid input parameters and system failures + for Interface Identification in Section 4.1 and 4.2. + + Added defaults for multicast operations in section 5.2 and changed + the names from ADD to JOIN and DROP to LEAVE to be consistent with + IPv6 multicast terminology. + + Changed getnodebyname to getipnodebyname, getnodebyaddr to + getipnodebyaddr, and added MT safe error code to function parameters + in section 6. + + Moved freehostent to its own sub-section after getipnodebyaddr now + 6.3 (so this bumps all remaining sections in section 6. + + Clarified the use of AI_ALL and AI_V4MAPPED that these are dependent + on the AF parameter and must be used as a conjunction in section 6.1. + + Removed the restriction that literal addresses cannot be used with a + flags argument in section 6.1. + + Added Year 2000 Section to the draft + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 31] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + + Deleted Reference to the following because the attached is deleted from + the ID directory and has expired. But the logic from the aforementioned + draft still applies, so that was kept in Section 6.2 bullets after 3rd + paragraph. + [7] P. Vixie, "Reverse Name Lookups of Encapsulated IPv4 Addresses + in IPv6", Internet-Draft, , + May 1996. + + Deleted the following reference as it is no longer referenced. + And the draft has expired. + [3] D. McDonald, "A Simple IP Security API Extension to BSD Sockets", + Internet-Draft, , + March 1997. + + Deleted the following reference as it is no longer referenced. + [4] C. Metz, "Network Security API for Sockets", + Internet-Draft, , + January 1998. + + Update current references to current status. + + Added alignment notes for in6_addr and sin6_addr. + + Clarified further that AI_V4MAPPED must be used with a dotted IPv4 + literal address for getipnodebyname(), when address family is + AF_INET6. + + Added text to clarify "::" and "::1" when used by getipnodebyaddr(). + + + + +Acknowledgments + +Thanks to the many people who made suggestions and provided feedback to +this document, including: Werner Almesberger, Ran Atkinson, Fred Baker, +Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve Deering, +Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom Herbert, +Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron +Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave Mitton, Thomas Narten, +Josh Osborne, Craig Partridge, Jean-Luc Richier, Erik Scoredos, Keith +Sklower, Matt Thomas, Harvey Thompson, Dean D. Throop, Karen Tracey, +Glenn Trewitt, Paul Vixie, David Waitzman, Carl Williams, and Kazu +Yamamoto, + +The getaddrinfo() and getnameinfo() functions are taken from an earlier +Internet Draft by Keith Sklower. As noted in that draft, William Durst, +Steven Wise, Michael Karels, and Eric Allman provided many useful +discussions on the subject of protocol-independent name-to-address +translation, and reviewed early versions of Keith Sklower's original +proposal. Eric Allman implemented the first prototype of getaddrinfo(). +The observation that specifying the pair of name and service would +suffice for connecting to a service independent of protocol details was +made by Marshall Rose in a proposal to X/Open for a "Uniform Network +Interface". + +Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh Kacker +made many contributions to this document. Ramesh Govindan made a number + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 32] + + +INTERNET-DRAFT draft-ietf-ipngwg-bsd-api-new-06.txt January 1999 + + +of contributions and co-authored an earlier version of this memo. + + + +References + + [1] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460 Draft Standard. + + [2] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", + RFC 2373, July 1998 Draft Standard. + + [3] IEEE, "Protocol Independent Interfaces", + IEEE Std 1003.1g, DRAFT 6.6, + March 1997. + + [4] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6", + RFC 2292, February 1998. + + + + +Authors' Addresses + +Robert E. Gilligan +FreeGate Corporation +1208 E. Arques Ave. +Sunnyvale, CA 94086 +Phone: +1 408 617 1004 +Email: gilligan@freegate.net + +Susan Thomson +Bell Communications Research +MRE 2P-343, 445 South Street +Morristown, NJ 07960 +Telephone: +1 201 829 4514 +Email: set@thumper.bellcore.com + +Jim Bound +Compaq Computer Corporation +110 Spitbrook Road ZK3-3/U14 +Nashua, NH 03062-2698 +Phone: +1 603 884 0400 +Email: bound@zk3.dec.com + +W. Richard Stevens +1202 E. Paseo del Zorro +Tucson, AZ 85718-2826 +Phone: +1 520 297 9416 +Email: rstevens@kohala.com + + + + + + + + + + +draft-ietf-ipng-bsd-api-new-06.txt Expires June 1999 [Page 33] diff --git a/doc/expired/draft-ietf-ipngwg-dns-lookups-05.txt b/doc/expired/draft-ietf-ipngwg-dns-lookups-05.txt new file mode 100644 index 0000000000..e6f8ebc6a1 --- /dev/null +++ b/doc/expired/draft-ietf-ipngwg-dns-lookups-05.txt @@ -0,0 +1,813 @@ +IPng Working Group Matt Crawford +Internet Draft Fermilab + Christian Huitema + Susan Thomson + Bellcore + October 14, 1999 + + DNS Extensions to Support IPv6 Address Aggregation and Renumbering + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + 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." + + To view the list Internet-Draft Shadow Directories, see + http://www.ietf.org/shadow.html. + +1. Abstract + + This document defines changes to the Domain Name System to support + renumberable and aggregatable IPv6 addressing. The changes include + a new resource record type to store an IPv6 address in a manner + which expedites network renumbering, one new query type and updated + definitions of existing query types that return Internet addresses + as part of additional section processing. + + For lookups keyed on IPv6 addresses (often called reverse lookups), + this document defines a new zone structure which allows a zone to be + used without modification for parallel copies of an address space + (as for a multihomed provider or site) and across network + renumbering events. + +Expires April 19, 2000 Crawford et al. [Page 1] + +Internet Draft IPv6 DNS October 14, 1999 + +2. Introduction + + Maintenance of address information in the DNS is one of several + obstacles which have prevented site and provider renumbering from + being feasible in IP version 4. Arguments about the importance of + network renumbering for the preservation of a stable routing system + and for other purposes may be read in documents cited here as + [RENUM]. To support the storage of IPv6 addresses without impeding + renumbering we define the following extensions. + + o A new resource record type, "A6", is defined to map a domain + name to an IPv6 address, with a provision for indirection for + leading "prefix" bits. + + o Existing queries that perform additional section processing to + locate IPv4 addresses are redefined to do that processing for + both IPv4 and IPv6 addresses. + + o A new domain, IP6.INT, is defined to support lookups based on + IPv6 address. + + o A new prefix-delegation method is defined, relying on new DNS + features [BITLBL, DNAME]. + + The changes are designed to be compatible with existing application + programming interfaces. The existing support for IPv4 addresses is + retained. Transition issues related to the coexistence of both IPv4 + and IPv6 addresses in DNS are discussed in [TRANS]. + + This memo proposes a replacement for the specification in RFC 1886 + and a departure from current implementation practices. The changes + are designed to facilitate network renumbering and multihoming. + Domains employing the A6 record for IPv6 addresses can insert + automatically-generated AAAA records in zone files to ease + transition. It is expected that after a reasonable period, RFC 1886 + will become Historic. + + The next three major sections of this document are an overview of + the facilities defined or employed by this specification, the + specification itself, and examples of use. + + 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 [KWORD]. The key + word "SUGGESTED" signifies a strength between MAY and SHOULD: it is + believed that compliance with the suggestion has tangible benefits + in most instances. + +Expires April 19, 2000 Crawford et al. [Page 2] + +Internet Draft IPv6 DNS October 14, 1999 + +3. Overview + + This section provides an overview of the DNS facilities for storage + of IPv6 addresses and for lookups based on IPv6 address, including + those defined here and elsewhere. + +3.1. Name-to-Address Lookup + + IPv6 addresses are stored in one or more A6 resource records. A + single A6 record may include a complete IPv6 address, or a + contiguous portion of an address and information leading to one or + more prefixes. Prefix information comprises a prefix length and a + DNS name which is in turn the owner of one or more A6 records + defining the prefix or prefixes which are needed to form one or more + complete IPv6 addresses. When the prefix length is zero, no DNS + name is present and all the leading bits of the address are + significant. There may be multiples levels of indirection and the + existence of multiple A6 records at any level multiplies the number + of IPv6 addresses which are formed. + + An application looking up an IPv6 address will generally cause the + DNS resolver to access several A6 records, and multiple IPv6 + addresses may be returned even if the queried name was the owner of + only one A6 record. The authenticity of the returned address(es) + cannot be directly verified by DNS Security [DNSSEC]. The A6 + records which contributed to the address(es) may of course be + verified if signed. + +3.2. Underlying Mechanisms for Reverse Lookups + + This section describes the new DNS features which this document + exploits. This section is an overview, not a specification of those + features. The reader is directed to the referenced documents for + more details on each. + +3.2.1. Delegation on Arbitrary Boundaries + + This new scheme for reverse lookups relies on a new type of DNS + label called the "bit-string label" [BITLBL]. This label compactly + represents an arbitrary string of bits which is treated as a + hierarchical sequence of one-bit domain labels. Resource records + can thereby be stored on arbitrary bit-boundaries. + + Examples in section 6 will employ the following textual + representation for bit-string labels, which is a subset of the + +Expires April 19, 2000 Crawford et al. [Page 3] + +Internet Draft IPv6 DNS October 14, 1999 + + syntax defined in [BITLBL]. A base indicator "x" for hexadecimal + and a sequence of hexadecimal digits is enclosed between "\[" and + "]". The bits denoted by the digits represent a sequence of one-bit + domain labels ordered from most to least significant. (This is the + opposite of the order they would appear if listed one bit at a time, + but it appears to be a convenient notation.) The digit string may + be followed by a slash ("/") and a decimal count. If omitted, the + implicit count is equal to four times the number of hexadecimal + digits. + + Consecutive bit-string labels are equivalent (up to the limit + imposed by the size of the bit count field) to a single bit-string + label containing all the bits of the consecutive labels in the + proper order. As an example, either of the following domain names + could be used in a QCLASS=IN, QTYPE=PTR query to find the name of + the node with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32. + + \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.INT. + + \[x0A0020FFFE812B32/64].\[x0009/16]. + \[x07C00040/32].\[xFFF0/13].\[x2/3].IP6.INT. + + Note that bits are left-justified in a hexadecimal string. + +3.2.2. Reusable Zones + + DNS address space delegation is implemented not by zone cuts and NS + records, but by a new analogue to the CNAME record, called the DNAME + resource record [DNAME]. The DNAME record provides alternate naming + to an entire subtree of the domain name space, rather than to a + single node. It causes some suffix of a queried name to be + substituted with a name from the DNAME record's RDATA. + + For example, a resolver or server providing recursion, while looking + up a QNAME a.b.c.d.e.f may encounter a DNAME record + + d.e.f. DNAME w.xy. + + which will cause it to look for a.b.c.w.xy. + +Expires April 19, 2000 Crawford et al. [Page 4] + +Internet Draft IPv6 DNS October 14, 1999 + +4. Specifications + +4.1. The A6 Record Type + + The A6 record type is specific to the IN (Internet) class and has + type number 38 (decimal). + +4.1.1. Format + + The RDATA portion of the A6 record contains two or three fields. + + +-----------+------------------+-------------------+ + |Prefix len.| Address suffix | Prefix name | + | (1 octet) | (0..16 octets) | (0..255 octets) | + +-----------+------------------+-------------------+ + + o A prefix length, encoded as an eight-bit unsigned integer with + value between 0 and 128 inclusive. + + o An IPv6 address suffix, encoded in network order (high-order + octet first). There MUST be exactly enough octets in this field + to contain a number of bits equal to 128 minus prefix length, + with 0 to 7 leading pad bits to make this field an integral + number of octets. Pad bits, if present, MUST be set to zero + when loading a zone file and ignored (other than for SIG + [DNSSEC] verification) on reception. + + o The name of the prefix, encoded as a domain name. By the rules + of [DNSIS], this name MUST NOT be compressed. + + The domain name component SHALL NOT be present if the prefix length + is zero. The address suffix component SHALL NOT be present if the + prefix length is 128. + + It is SUGGESTED that an A6 record intended for use as a prefix for + other A6 records have all the insignificant trailing bits in its + address suffix field set to zero. + +4.1.2. Processing + + A query with QTYPE=A6 causes type A6 and type NS additional section + processing for the prefix names, if any, in the RDATA field of the + A6 records in the answer section. This processing SHOULD be + recursively applied to the prefix names of A6 records included as + +Expires April 19, 2000 Crawford et al. [Page 5] + +Internet Draft IPv6 DNS October 14, 1999 + + additional data. When space in the reply packet is a limit, + inclusion of additional A6 records takes priority over NS records. + + It is an error for a A6 record with prefix length L1 > 0 to refer to + a domain name which owns a A6 record with a prefix length L2 > L1. + If such a situation is encountered by a resolver, the A6 record with + the offending (larger) prefix length MUST be ignored. Robustness + precludes signaling an error if addresses can still be formed from + valid A6 records, but it is SUGGESTED that zone maintainers from + time to time check all the A6 records their zones reference. + +4.1.3. Textual Representation + + The textual representation of the RDATA portion of the A6 resource + record in a zone file comprises two or three fields separated by + whitespace. + + o A prefix length, represented as a decimal number between 0 and + 128 inclusive, + + o the textual representation of an IPv6 address as defined in + [AARCH] (although some leading and/or trailing bits may not be + significant), + + o a domain name, if the prefix length is not zero. + + The domain name MUST be absent if the prefix length is zero. The + IPv6 address MAY be be absent if the prefix length is 128. A number + of leading address bits equal to the prefix length SHOULD be zero, + either implicitly (through the :: notation) or explicitly, as + specified in section 4.1.1. + +4.1.4. Name Resolution Procedure + + To obtain the IPv6 address or addresses which belong to a given + hostname, a DNS client MUST obtain one or more complete chains of A6 + records, each chain beginning with a record owned by the given + hostname and including a record owned by the prefix name in that + record, and so on recursively, ending with an A6 record with a + prefix length of zero. One IPv6 address is formed from one such + chain by taking the value of each bit position from the earliest A6 + record which validly covers that position, as indicated by the + prefix length. The set of all IPv6 addresses for the given hostname + comprises the addresses formed from all complete chains of A6 + records beginning at that hostname, discarding records which have + invalid prefix lengths as defined in section 4.1.2. + +Expires April 19, 2000 Crawford et al. [Page 6] + +Internet Draft IPv6 DNS October 14, 1999 + + If some A6 queries fail and others succeed, a client might obtain a + non-empty but incomplete set of IPv6 addresses for a host. In many + situations this may be acceptable. The completeness of a set of A6 + records may always be determined by inspection. + +4.2. Zone Structure for Reverse Lookups + + Very little of the new scheme's data actually appears under IP6.INT; + only the first level of delegation needs to be under that domain. + More levels of delegation could be placed under IP6.INT if some + top-level delegations were done via NS records instead of DNAME + records, but this would incur some cost in renumbering ease at the + level of TLAs [AGGR]. Therefore, it is declared here that all + address space delegations SHOULD be done by the DNAME mechanism + rather than NS. + + In addition, since uniformity in deployment will simplify + maintenance of address delegations, it is SUGGESTED that address and + prefix information be stored immediately below a DNS label "IP6". + Stated another way, conformance with this suggestion would mean that + "IP6" is the first label in the RDATA field of DNAME records which + support IPv6 reverse lookups. + + When any "reserved" or "must be zero" bits are adjacent to a + delegation boundary, the higher-level entity MUST retain those bits + in its own control and delegate only the bits over which the lower- + level entity has authority. + + To find the name of a node given its IPv6 address, a DNS client MUST + perform a query with QCLASS=IN, QTYPE=PTR on the name formed from + the 128 bit address as one or more bit-string labels [BITLBL], + followed by the two standard labels "IP6.INT". If recursive service + was not obtained from a server and the desired PTR record was not + returned, the resolver MUST handle returned DNAME records as + specified in [DNAME] and iterate. + +5. Modifications to Existing Query Types + + All existing query types that perform type A additional section + processing, i.e. the name server (NS), mail exchange (MX), and + mailbox (MB) query types, and the experimental AFS data base (AFSDB) + and route through (RT) types, must be redefined to perform type A, + A6 and AAAA additional section processing, with type A having the + highest priority for inclusion and type AAAA the lowest. This + redefinition means that a name server may add any relevant IPv4 and + IPv6 address information available locally to the additional section + +Expires April 19, 2000 Crawford et al. [Page 7] + +Internet Draft IPv6 DNS October 14, 1999 + + of a response when processing any one of the above queries. The + recursive inclusion of A6 records referenced by A6 records already + included in the additional section is OPTIONAL. + +6. Usage Illustrations + + This section provides examples of use of the mechanisms defined in + the previous section. All addresses and domains mentioned here are + intended to be fictitious and for illustrative purposes only. + Example delegations will be on 4-bit boundaries solely for + readability; this specification is indifferent to bit alignment. + + Use of the IPv6 aggregatable address format [AGGR] is assumed in the + examples. + +6.1. A6 Record Chains + + Let's take the example of a site X that is multi-homed to two + "intermediate" providers A and B. The provider A is itself multi- + homed to two "transit" providers, C and D. The provider B gets its + transit service from a single provider, E. For simplicity suppose + that C, D and E all belong to the same top-level aggregate (TLA) + with identifier (including format prefix) '2345', and the TLA + authority at ALPHA-TLA.ORG assigns to C, D and E respectively the + next level aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 + and 2345:000E::/32. + + C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the + prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to + B. + + A assigns to X the subscriber identification '11' and B assigns the + subscriber identification '22'. As a result, the site X inherits + three address prefixes: + + o 2345:00C1:CA11::/48 from A, for routes through C. + o 2345:00D2:DA11::/48 from A, for routes through D. + o 2345:000E:EB22::/48 from B, for routes through E. + + Let us suppose that N is a node in the site X, that it is assigned + to subnet number 1 in this site, and that it uses the interface + identifier '1234:5678:9ABC:DEF0'. In our configuration, this node + will have three addresses: + +Expires April 19, 2000 Crawford et al. [Page 8] + +Internet Draft IPv6 DNS October 14, 1999 + + o 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 + o 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0 + o 2345:000E:EB22:0001:1234:5678:9ABC:DEF0 + +6.1.1. Authoritative Data + + We will assume that the site X is represented in the DNS by the + domain name X.EXAMPLE, while A, B, C, D and E are represented by + A.NET, B.NET, C.NET, D.NET and E.NET. In each of these domains, we + assume a subdomain "IP6" that will hold the corresponding prefixes. + The node N is identified by the domain name N.X.EXAMPLE. The + following records would then appear in X's DNS. + + $ORIGIN X.EXAMPLE. + N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 + SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 + IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. + IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. + + And elsewhere there would appear + + SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET. + SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET. + + SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET. + + A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG. + + A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG. + + B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG. + + C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0:: + D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0:: + E.NET.ALPHA-TLA.ORG. A6 0 2345:000E:: + +6.1.2. Glue + + When, as is common, some or all DNS servers for X.EXAMPLE are within + the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry + enough "glue" information to enable DNS clients to reach those + nameservers. This is true in IPv6 just as in IPv4. However, the A6 + record affords the DNS administrator some choices. The glue could + be any of + +Expires April 19, 2000 Crawford et al. [Page 9] + +Internet Draft IPv6 DNS October 14, 1999 + + o a minimal set of A6 records duplicated from the X.EXAMPLE zone, + + o a (possibly smaller) set of records which collapse the structure + of that minimal set, + + o or a set of A6 records with prefix length zero, giving the + entire global addresses of the servers. + + The trade-off is ease of maintenance against robustness. The best + and worst of both may be had together by implementing either the + first or second option together with the third. To illustrate the + glue options, suppose that X.EXAMPLE is served by two nameservers + NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers + ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively. + Then the top-level zone EXAMPLE would include one (or more) of the + following sets of A6 records as glue. + + $ORIGIN EXAMPLE. ; first option + X NS NS1.X + NS NS2.X + NS1.X A6 64 ::1:11:111:1111 SUBNET-1.IP6.X + NS2.X A6 64 ::2:22:222:2222 SUBNET-2.IP6.X + SUBNET-1.IP6.X A6 48 0:0:0:1:: IP6.X + SUBNET-2.IP6.X A6 48 0:0:0:2:: IP6.X + IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. + IP6.X A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. + + $ORIGIN EXAMPLE. ; second option + X NS NS1.X + NS NS2.X + NS1.X A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET. + A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET. + NS2.X A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET. + A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET. + + $ORIGIN EXAMPLE. ; third option + X NS NS1.X + NS NS2.X + NS1.X A6 0 2345:00C1:CA11:1:1:11:111:1111 + A6 0 2345:00D2:DA11:1:1:11:111:1111 + A6 0 2345:000E:EB22:1:1:11:111:1111 + NS2.X A6 0 2345:00C1:CA11:2:2:22:222:2222 + A6 0 2345:00D2:DA11:2:2:22:222:2222 + A6 0 2345:000E:EB22:2:2:22:222:2222 + + The first and second glue options are robust against renumbering of + +Expires April 19, 2000 Crawford et al. [Page 10] + +Internet Draft IPv6 DNS October 14, 1999 + + X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if + those providers' own DNS is unreachable. The glue records of the + third option are robust against DNS failures elsewhere than the + zones EXAMPLE and X.EXAMPLE themselves, but must be updated when X's + address space is renumbered. + + If the EXAMPLE zone includes redundant glue, for instance the union + of the A6 records of the first and third options, then under normal + circumstances duplicate IPv6 addresses will be derived by DNS + clients. But if provider DNS fails, addresses will still be + obtained from the zero-prefix-length records, while if the EXAMPLE + zone lags behind a renumbering of X.EXAMPLE, half of the addresses + obtained by DNS clients will still be up-to-date. + + The zero-prefix-length glue records can of course be automatically + generated and/or checked in practice. + +6.1.3. Variations + + Several more-or-less arbitrary assumptions are reflected in the + above structure. All of the following choices could have been made + differently, according to someone's notion of convenience or an + agreement between two parties. + + First, that site X has chosen to put subnet information in a + separate A6 record rather than incorporate it into each node's + A6 records. + + Second, that site X is referred to as "SUBSCRIBER-X" by both of + its providers A and B. + + Third, that site X chose to indirect its provider information + through A6 records at IP6.X.EXAMPLE containing no significant + bits. An alternative would have been to replicate each subnet + record for each provider. + + Fourth, B and E used a slightly different prefix naming + convention between themselves than did A, C and D. Each + hierarchical pair of network entities must arrange this naming + between themselves. + + Fifth, that the upward prefix referral chain topped out at + ALPHA-TLA.ORG. There could have been another level which + assigned the TLA values and holds A6 records containing those + bits. + + Finally, the above structure reflects an assumption that address + fields assigned by a given entity are recorded only in A6 records + +Expires April 19, 2000 Crawford et al. [Page 11] + +Internet Draft IPv6 DNS October 14, 1999 + + held by that entity. Those bits could be entered into A6 records in + the lower-level entity's zone instead, thus: + + IP6.X.EXAMPLE. A6 40 0:0:11:: IP6.A.NET. + IP6.X.EXAMPLE. A6 40 0:0:22:: IP6.B.NET. + + IP6.A.NET. A6 28 0:1:CA00:: IP6.C.NET. + and so on. + + Or the higher-level entities could hold both sorts of A6 records + (with different DNS owner names) and allow the lower-level entities + to choose either mode of A6 chaining. But the general principle of + avoiding data duplication suggests that the proper place to store + assigned values is with the entity that assigned them. + + It is possible, but not necessarily recommended, for a zone + maintainer to forego the renumbering support afforded by the + chaining of A6 records and to record entire IPv6 addresses within + one zone file. + +6.2. Reverse Mapping Zones + + Supposing that address space assignments in the TLAs with Format + Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in + zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then + the IP6.INT zone would include + + $ORIGIN IP6.INT. + \[x234500/24] DNAME IP6.ALPHA-TLA.ORG. + \[x267800/24] DNAME IP6.BRAVO-TLA.ORG. + \[x29AB00/24] DNAME IP6.CHARLIE-TLA.XY. + + Eight trailing zero bits have been included in each TLA ID to + reflect the eight reserved bits in the current aggregatable global + unicast addresses format [AGGR]. + +6.2.1. The TLA level + + ALPHA-TLA's assignments to network providers C, D and E are + reflected in the reverse data as follows. + + \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. + \[xD/4].IP6.ALPHA-TLA.ORG. DNAME IP6.D.NET. + \[x0E/8].IP6.ALPHA-TLA.ORG. DNAME IP6.E.NET. + +Expires April 19, 2000 Crawford et al. [Page 12] + +Internet Draft IPv6 DNS October 14, 1999 + +6.2.2. The ISP level + + The providers A through E carry the following delegation information + in their zone files. + + \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. + \[x2DA/12].IP6.D.NET. DNAME IP6.A.NET. + \[xEB/8].IP6.E.NET. DNAME IP6.B.NET. + \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. + \[x22/8].IP6.B.NET. DNAME IP6.X.EXAMPLE. + + Note that some domain names appear in the RDATA of more than one + DNAME record. In those cases, one zone is being used to map + multiple prefixes. + +6.2.3. The Site Level + + Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to- + name translations. This domain is now referenced by two different + DNAME records held by two different providers. + + $ORIGIN IP6.X.EXAMPLE. + \[x0001/16] DNAME SUBNET-1 + \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE. + and so on. + + SUBNET-1 need not have been named in a DNAME record; the subnet bits + could have been joined with the interface identifier. But if + subnets are treated alike in both the A6 records and in the reverse + zone, it will always be possible to keep the forward and reverse + definition data for each prefix in one zone. + +6.3. Lookups + + A DNS resolver looking for a hostname for the address + 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the + DNAME records shown above and would form new queries. Assuming that + it began the process knowing servers for IP6.INT, but that no server + it consulted provided recursion and none had other useful additional + information cached, the sequence of queried names and responses + would be (all with QCLASS=IN, QTYPE=PTR): + +Expires April 19, 2000 Crawford et al. [Page 13] + +Internet Draft IPv6 DNS October 14, 1999 + + To a server for IP6.INT: + QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.INT. + + Answer: + \[x234500/24].IP6.INT. DNAME IP6.ALPHA-TLA.ORG. + + To a server for IP6.ALPHA-TLA.ORG: + QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG. + + Answer: + \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET. + + To a server for IP6.C.NET.: + QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET. + + Answer: + \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET. + + To a server for IP6.A.NET.: + QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET. + + Answer: + \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE. + + To a server for IP6.X.EXAMPLE.: + QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE. + + Answer: + \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE. + \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE. + + All the DNAME (and NS) records acquired along the way can be cached + to expedite resolution of addresses topologically near to this + address. And if another global address of N.X.EXAMPLE were resolved + within the TTL of the final PTR record, that record would not have + to be fetched again. + +6.4. Deployment Note + + In the illustrations in section 6.1, hierarchically adjacent + entities, such as a network provider and a customer, must agree on a + DNS name which will own the definition of the delegated prefix(es). + One simple convention would be to use a bit-string label + representing exactly the bits which are assigned to the lower-level + entity by the higher. For example, "SUBSCRIBER-X" could be replaced + by "\[x11/8]". This would place the A6 record(s) defining the + +Expires April 19, 2000 Crawford et al. [Page 14] + +Internet Draft IPv6 DNS October 14, 1999 + + delegated prefix at exactly the same point in the DNS tree as the + DNAME record associated with that delegation. The cost of this + simplification is that the lower-level zone must update its upward- + pointing A6 records when it is renumbered. This cost may be found + quite acceptable in practice. + +7. Transition from AAAA Records on coexistence with A Records + + Administrators of zones which contain A6 records can easily + accommodate deployed resolvers which understand AAAA records but not + A6 records. Such administrators can do automatic generation of AAAA + records for all of a zone's names which own A6 records by a process + which mimics the resolution of a hostname to an IPv6 address (see + section 4.1.4). Attention must be paid to the TTL assigned to a + generated AAAA record, which MUST be no more than the minimum of the + TTLs of the A6 records that were used to form the IPv6 address in + that record. For full robustness, those A6 records which were in + different zones should be monitored for changes (in TTL or RDATA) + even when there are no changes to zone for which AAAA records are + being generated. If the zone is secure [DNSSEC], the generated AAAA + records SHOULD be signed along with the rest of the zone data. + + A zone-specific heuristic MAY be used to avoid generation of AAAA + records for A6 records which record prefixes, although such + superfluous records would be relatively few in number and harmless. + Examples of such heuristics include omitting A6 records with a + prefix length less than the largest value found in the zone file, or + records with an address suffix field with a certain number of + trailing zero bits. + + On the client side, when looking up and IPv6 address, the order of + A6 and AAAA queries MAY be configurable to be one of: A6, then AAAA; + AAAA, then A6; A6 only; or both in parallel. The default order (or + only order, if not configurable) MUST be to try A6 first, then AAAA. + If and when the AAAA becomes deprecated a new document will change + the default. + + The guidelines and options for precedence between IPv4 and IPv6 + addresses are specified in [TRANS]. All mentions of AAAA records in + that document are henceforth to be interpreted as meaning A6 and/or + AAAA records in the order specified in the previous paragraph. + +8. Security Considerations + + The signing authority [DNSSEC] for the A6 records which determine an + IPv6 address is distributed among several entities, reflecting the + +Expires April 19, 2000 Crawford et al. [Page 15] + +Internet Draft IPv6 DNS October 14, 1999 + + delegation path of the address space which that address occupies. + DNS Security is fully applicable to bit-string labels and DNAME + records. However, just as with IPv4's IN-ADDR.ARPA, authentication + of data in the reverse zones is not equivalent to authentication of + any forward data. + +9. IANA Considerations + + The A6 resource record has been assigned a Type value of 38. + +10. Acknowledgments + + The authors would like to thank the following persons for valuable + discussions and reviews: Mark Andrews, Rob Austein, Jim Bound, + Randy Bush, Brian Carpenter, David Conrad, Steve Deering, Francis + Dupont, Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob + Hinden, Bill Manning, Keith Moore, Thomas Narten, Erik Nordmark, + Mike O'Dell, Michael Patton and Ken Powell. + +11. References + + [AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [AGGR] Hinden, R., O'Dell, M. and S. Deering, "An IPv6 Aggregatable + Global Unicast Address Format". RFC 2374, July 1998. + + [BITLBL] Crawford, M., "Binary Labels in the Domain Name System", + RFC 2673, August 1999. + + [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, + August 1999. + + [DNSIS] Mockapetris, P. V., "Domain names - implementation and + specification", RFC 1035, November 1987. + + [DNSSEC] Eastlake, D. 3rd and C. Kaufman, "Domain Name System + Security Extensions", RFC 2535, March 1999. + + [KWORD] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels," RFC 2119. + + [RENUM] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC + 1900, February 1996. + +Expires April 19, 2000 Crawford et al. [Page 16] + +Internet Draft IPv6 DNS October 14, 1999 + + Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: + Why would I want it and what is it anyway?", RFC 2071, January + 1997. + + Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address + Behaviour Today", RFC 2101, February 1997. + + [TRANS] Gilligan, R. and E. Nordmark, "Transition Mechanisms for + IPv6 Hosts and Routers", RFC 1933, April 1996. + +12. Authors' Addresses + + Matt Crawford Christian Huitema Susan Thomson + Fermilab Bellcore Bellcore + MS 368 MCC 1J236B MCC 1C259B + PO Box 500 445 South Street 445 South Street + Batavia, IL 60510 Morristown, NJ 07960 Morristown, NJ 07960 + USA USA USA + + +1 630 840-3461 +1 201 829-4266 +1 201 829-4514 + crawdad@fnal.gov +huitema@research.telcordia.comset@research.telcordia.com + +Expires April 19, 2000 Crawford et al. [Page 17] diff --git a/doc/expired/draft-schroeppel-dnsind-ecc-00.txt b/doc/expired/draft-schroeppel-dnsind-ecc-00.txt new file mode 100644 index 0000000000..39a1639810 --- /dev/null +++ b/doc/expired/draft-schroeppel-dnsind-ecc-00.txt @@ -0,0 +1,869 @@ +INTERNET-DRAFT ECC in the DNS +Expires April 2000 October 1999 +draft-schroeppel-dnsind-ecc-00.txt + + + + + Elliptic Curve KEYs and SIGs in the DNS + -------- ----- ---- --- ---- -- --- --- + + Richard C. Schroeppel + Donald Eastlake 3rd + + +Status of This Document + + This draft, file name draft-schroeppel-dnsind-ecc-00.txt, is intended + to be become a Proposed Standard RFC. Distribution of this document + is unlimited. Comments should be sent to the DNS mailing list + or to the authors. + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. Internet-Drafts are working + documents of the Internet Engineering Task Force (IETF), its areas, + and its working groups. Note that other groups may also distribute + working documents as Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six + months. Internet-Drafts may be updated, replaced, or obsoleted by + other documents at any time. It is not appropriate to use Internet- + Drafts as reference material or to cite them other than as a + ``working draft'' or ``work in progress.'' + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + + +Abstract + + A standard method for storing elliptic curve cryptographic keys and + signatures in the Domain Name System is described which utilizes DNS + KEY and SIG resource records. + + + + + + + + + +R. Schroeppel, et al [Page 1] + + +INTERNET-DRAFT ECC in the DNS + + +Acknowledgement + + The assistance of Hilarie K. Orman in the production of this document + is greatfully acknowledged. + + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Acknowledgement............................................2 + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. Elliptic Curve KEY Resource Records.....................3 + 3. The Elliptic Curve Equation.............................9 + 4. How do I Compute Q, G, and Y?..........................10 + 5. Elliptic Curve SIG Resource Records....................11 + 6. Performance Considerations.............................13 + 7. Security Considerations................................13 + 8. IANA Considerations....................................13 + + References................................................14 + + Authors' Addresses........................................15 + Expiration and File Name..................................15 + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 2] + + +INTERNET-DRAFT ECC in the DNS + + +1. Introduction + + The Domain Name System (DNS) is the global hierarchical replicated + distributed database system for Internet addressing, mail proxy, and + other information. The DNS has been extended to include digital + signatures and cryptographic keys as described in [RFC 2535]. Thus + the DNS can now be secured and used for secure key distribution. + + Elliptic curve keys can be used for signatures, as shown herein, and + also for key agreement and encryption. This document describes how to + store elliptic curve cryptographic (ECC) keys and signatures in the + DNS. Familiarity with ECC cryptography is assumed [Menezes]. + + 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 [RFC 2119]. + + + +2. Elliptic Curve KEY Resource Records + + Elliptic curve public keys are stored in the DNS as KEY RRs using + algorithm number 4 (see [RFC 2535]). The structure of the RDATA + portion of this RR is as shown below. The first 4 octets, including + the flags, protocol, and algorithm fields are common to all KEY RRs. + The remainder is the "public key" part of the KEY RR. + + The period of key validity is not in the KEY RR but is indicated by + the SIG RR(s) which signs and authenticates the KEY RR(s) at that + domain name and class. + + The research world continues to churn on the issue of which is the + best elliptic curve system, which finite field to use, and how to + best represent elements in the field. + + We have defined representations for every type of finite field, and + every type of elliptic curve. The reader should be aware that there + is a unique finite field with a particular number of elements, but + many possible representations of that field and its elements. If two + different representations of a field are given, they are + interconvertible with a tedious but practical precomputation, + followed by a fast computation for each field element to be + converted. It is perfectly reasonable for an algorithm to work + internally with one field representation, and convert to and from a + different external representation. + + + + + + + +R. Schroeppel, et al [Page 3] + + +INTERNET-DRAFT ECC in the DNS + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | KEY flags | protocol | algorithm=4 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S M -FMT- A B Z| + +-+-+-+-+-+-+-+-+ + | LP | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | P (length determined from LP) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LF | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | F (length determined from LF) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEG | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DEGJ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TRDV | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LH | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | H (length determined from LH) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |S| LK | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | K (length determined from LK) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LQ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Q (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | A (length determined from LA) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ALTA | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LB | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | B (length determined from LB) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | C (length determined from LC) .../ + + +R. Schroeppel, et al [Page 4] + + +INTERNET-DRAFT ECC in the DNS + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LG | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | G (length determined from LG) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LY | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Y (length determined from LY) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + SMFMTABZ is a flags octet as follows: + + S = 1 indicates that the remaining 7 bits of the octet selects + one of 128 predefined choices of finite field, element + representation, elliptic curve, and signature parameters. + MFMTABZ are omitted, as are all parameters from LP through G. + LY and Y are retained. + + If S = 0, the remaining parameters are as in the picture and + described below. + + M determines the type of field underlying the elliptic curve. + + M = 0 if the field is a GF[2^N] field; + + M = 1 if the field is a (mod P) or GF[P^D] field with P>2. + + FMT is a three bit field describing the format of the field + representation. + + FMT = 0 for a (mod P) field. + > 0 for an extension field, either GF[2^D] or GF[P^D]. + The degree D of the extension, and the field polynomial + must be specified. The field polynomial is always monic + (leading coefficient 1.) + + FMT = 1 The field polynomial is given explicitly; D is implied. + + If FMT >=2, the degree D is given explicitly. + + = 2 The field polynomial is implicit. + = 3 The field polynomial is a binomial. P>2. + = 4 The field polynomial is a trinomial. + = 5 The field polynomial is the quotient of a trinomial by a + short polynomial. P=2. + = 6 The field polynomial is a pentanomial. P=2. + + Flags A and B apply to the elliptic curve parameters. + + + + +R. Schroeppel, et al [Page 5] + + +INTERNET-DRAFT ECC in the DNS + + + A = 1 When P>=5, the curve parameter A is negated. If P=2, then + A=1 indicates that the A parameter is special. See the + ALTA parameter below, following A. The combination A=1, + P=3 is forbidden. + + B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3, + then B=1 indicates an alternate elliptic curve equation is + used. When P=2 and B=1, an additional curve parameter C + is present. + + The Z bit SHOULD be set to zero on creation of KEY RR and MUST + be ignored when processing a KEY RR (when S=0). + + Most of the remaining parameters are present in some formats and + absent in others. The presence or absence of a parameter is + determined entirely by the flags. When a parameter occurs, it is in + the order defined by the picture. + + Of the remaining parameters, PFHKQABCGY are variable length. When + present, each is preceded by a one-octet length field as shown in the + diagram above. The length field does not include itself. The length + field may have values from 0 through 110. The parameter length in + octets is determined by a conditional formula: If LL<=64, the + parameter length is LL. If LL>64, the parameter length is 16 times + (LL-60). In some cases, a parameter value of 0 is sensible, and MAY + be represented by an LL value of 0, with the data field omitted. A + length value of 0 represents a parameter value of 0, not an absent + parameter. (The data portion occupies 0 space.) There is no + requirement that a parameter be represented in the minimum number of + octets; high-order 0 octets are allowed at the front end. Parameters + are always right adjusted, in a field of length defined by LL. The + octet-order is always most-significant first, least-significant last. + The parameters H and K may have an optional sign bit stored in the + unused high-order bit of their length fields. + + LP defines the length of the prime P. P must be an odd prime. The + parameters LP,P are present if and only if the flag M=1. If M=0, the + prime is 2. + + LF,F define an explicit field polynomial. This parameter pair is + present only when FMT = 1. The length of a polynomial coefficient is + ceiling(log2 P) bits. Coefficients are in the numerical range [0,P- + 1]. The coefficients are packed into fixed-width fields, from higher + order to lower order. All coefficients must be present, including + any 0s and also the leading coefficient (which is required to be 1). + The coefficients are right justified into the octet string of length + specified by LF, with the low-order "constant" coefficient at the + right end. As a concession to storage efficiency, the higher order + bits of the leading coefficient may be elided, discarding high-order + 0 octets and reducing LF. The degree is calculated by determining + + +R. Schroeppel, et al [Page 6] + + +INTERNET-DRAFT ECC in the DNS + + + the bit position of the left most 1-bit in the F data (counting the + right most bit as position 0), and dividing by ceiling(log2 P). The + division must be exact, with no remainder. In this format, all of + the other degree and field parameters are omitted. The next + parameters will be LQ,Q. + + If FMT>=2, the degree of the field extension is specified explicitly, + usually along with other parameters to define the field polynomial. + + DEG is a two octet field that defines the degree of the field + extension. The finite field will have P^DEG elements. DEG is + present when FMT>=2. + + When FMT=2, the field polynomial is specified implicitly. No other + parameters are required to define the field; the next parameters + present will be the LQ,Q pair. The implicit field poynomial is the + lexicographically smallest irreducible (mod P) polynomial of the + correct degree. The ordering of polynomials is by highest-degree + coefficients first -- the leading coefficient 1 is most important, + and the constant term is least important. Coefficients are ordered + by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial + of degree D is X^D (which is not irreducible). The next is X^D+1, + which is sometimes irreducible, followed by X^D-1, which isn't. + Assuming odd P, this series continues to X^D - (P-1)/2, and then goes + to X^D + X, X^D + X + 1, X^D + X - 1, etc. + + When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be + odd. The polynomial is determined by the degree and the low order + term K. Of all the field parameters, only the LK,K parameters are + present. The high-order bit of the LK octet stores on optional sign + for K; if the sign bit is present, the field polynomial is X^DEG - K. + + When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH + + K. When P=2, the H and K parameters are implicitly 1, and are + omitted from the representation. Only DEG and DEGH are present; the + next parameters are LQ,Q. When P>2, then LH,H and LK,K are + specified. Either or both of LH, LK may contain a sign bit for its + parameter. + + When FMT=5, then P=2 (only). The field polynomial is the exact + quotient of a trinomial divided by a small polynomial, the trinomial + divisor. The small polynomial is right-adjusted in the two octet + field TRDV. DEG specifies the degree of the field. The degree of + TRDV is calculated from the position of the high-order 1 bit. The + trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If + DEGH is 0, the middle term is omitted from the trinomial. The + quotient must be exact, with no remainder. + + When FMT=6, then P=2 (only). The field polynomial is a pentanomial, + with the degrees of the middle terms given by the three 2-octet + + +R. Schroeppel, et al [Page 7] + + +INTERNET-DRAFT ECC in the DNS + + + values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI + + X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI + > DEGJ > 0. + + DEGH, DEGI, DEGJ are two-octet fields that define the degree of + a term in a field polynomial. DEGH is present when FMT = 4, + 5, or 6. DEGI and DEGJ are present only when FMT = 6. + + TRDV is a two-octet right-adjusted binary polynomial of degree < + 16. It is present only for FMT=5. + + LH and H define the H parameter, present only when FMT=4 and P + is odd. The high bit of LH is an optional sign bit for H. + + LK and K define the K parameter, present when FMT = 3 or 4, and + P is odd. The high bit of LK is an optional sign bit for K. + + The remaining parameters are concerned with the elliptic curve and + the signature algorithm. + + LQ defines the length of the prime Q. Q is a prime > 2^159. + + In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data + member of the pair is an element from the finite field defined + earlier. The length field defines a long octet string. Field + elements are represented as (mod P) polynomials of degree < DEG, with + DEG or fewer coefficients. The coefficients are stored from left to + right, higher degree to lower, with the constant term last. The + coefficients are represented as integers in the range [0,P-1]. Each + coefficient is allocated an area of ceiling(log2 P) bits. The field + representation is right-justified; the "constant term" of the field + element ends at the right most bit. The coefficients are fitted + adjacently without regard for octet boundaries. (Example: if P=5, + three bits are used for each coefficient. If the field is GF[5^75], + then 225 bits are required for the coefficients, and as many as 29 + octets may be needed in the data area. Fewer octets may be used if + some high-order coefficients are 0.) If a flag requires a field + element to be negated, each non-zero coefficient K is replaced with + P-K. To save space, 0 bits may be removed from the left end of the + element representation, and the length field reduced appropriately. + This would normally only happen with A,B,C, because the designer + chose curve parameters with some high-order 0 coefficients or bits. + + If the finite field is simply (mod P), then the field elements are + simply numbers (mod P), in the usual right-justified notation. If + the finite field is GF[2^D], the field elements are the usual right- + justified polynomial basis representation. + + + + + +R. Schroeppel, et al [Page 8] + + +INTERNET-DRAFT ECC in the DNS + + + LA,A is the first parameter of the elliptic curve equation. + When P>=5, the flag A = 1 indicates A should be negated (mod + P). When P=2 (indicated by the flag M=0), the flag A = 1 + indicates that the parameter pair LA,A is replaced by the two + octet parameter ALTA. In this case, the parameter A in the + curve equation is x^ALTA, where x is the field generator. + Parameter A often has the value 0, which may be indicated by + LA=0 (with no A data field), and sometimes A is 1, which may + be represented with LA=1 and a data field of 1, or by setting + the A flag and using an ALTA value of 0. + + LB,B is the second parameter of the elliptic curve equation. + When P>=5, the flag B = 1 indicates B should be negated (mod + P). When P=2 or 3, the flag B selects an alternate curve + equation. + + LC,C is the third parameter of the elliptic curve equation, + present only when P=2 (indicated by flag M=0) and flag B=1. + + LG,G defines a point on the curve, of order Q. The W-coordinate + of the curve point is given explicitly; the Z-coordinate is + implicit. + + LY,Y is the user's public signing key, another curve point of + order Q. The W-coordinate is given explicitly; the Z- + coordinate is implicit. The LY,Y parameter pair is always + present. + + + +3. The Elliptic Curve Equation + + (The coordinates of an elliptic curve point are named W,Z instead of + the more usual X,Y to avoid confusion with the Y parameter of the + signing key.) + + The elliptic curve equation is determined by the flag octet, together + with information about the prime P. The primes 2 and 3 are special; + all other primes are treated identically. + + If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3 + + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D]. + If A and/or B is negative (i.e., in the range from P/2 to P), and + P>=5, space may be saved by putting the sign bit(s) in the A and B + bits of the flags octet, and the magnitude(s) in the parameter + fields. + + If M=1 and P=3, the B flag has a different meaning: it specifies an + alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of + the right-hand-side is different. When P=3, this equation is more + + +R. Schroeppel, et al [Page 9] + + +INTERNET-DRAFT ECC in the DNS + + + commonly used. + + If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 + + A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A + parameter can often be 0 or 1, or be chosen as a single-1-bit value. + The flag B is used to select an alternate curve equation, Z^2 + C*Z = + W^3 + A*W + B. This is the only time that the C parameter is used. + + + +4. How do I Compute Q, G, and Y? + + The number of points on the curve is the number of solutions to the + curve equation, + 1 (for the "point at infinity"). The prime Q must + divide the number of points. Usually the curve is chosen first, then + the number of points is determined with Schoof's algorithm. This + number is factored, and if it has a large prime divisor, that number + is taken as Q. + + G must be a point of order Q on the curve, satisfying the equation + + Q * G = the point at infinity (on the elliptic curve) + + G may be chosen by selecting a random [RFC 1750] curve point, and + multiplying it by (number-of-points-on-curve/Q). G must not itself + be the "point at infinity"; in this astronomically unlikely event, a + new random curve point is recalculated. + + G is specified by giving its W-coordinate. The Z-coordinate is + calculated from the curve equation. In general, there will be two + possible Z values. The rule is to choose the "positive" value. + + In the (mod P) case, the two possible Z values sum to P. The smaller + value is less than P/2; it is used in subsequent calculations. In + GF[P^D] fields, the highest-degree non-zero coefficient of the field + element Z is used; it is chosen to be less than P/2. + + In the GF[2^N] case, the two possible Z values xor to W (or to the + parameter C with the alternate curve equation). The numerically + smaller Z value (the one which does not contain the highest-order 1 + bit of W (or C)) is used in subsequent calculations. + + Y is specified by giving the W-coordinate of the user's public + signature key. The Z-coordinate value is determined from the curve + equation. As with G, there are two possible Z values; the same rule + is followed for choosing which Z to use. + + + + + + +R. Schroeppel, et al [Page 10] + + +INTERNET-DRAFT ECC in the DNS + + + During the key generation process, a random [RFC 1750] number X must + be generated such that 1 <= X <= Q-1. X is the private key and is + used in the final step of public key generation where Y is computed + as + + Y = X * G (as points on the elliptic curve) + + If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2 + in the (mod P) case, or the high-order non-zero coefficient of Z > + P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the + GF[2^N] case), then X must be replaced with Q-X. This will + correspond to the correct Z-coordinate. + + + +5. Elliptic Curve SIG Resource Records + + The signature portion of the SIG RR RDATA area, when using the EC + algorithm, is shown below. See [RFC 2535] for fields in the SIG RR + RDATA which precede the signature itself. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | R, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | S, (length determined from LQ) .../ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + R and S are integers (mod Q). Their length is specified by the LQ + field of the corresponding KEY RR and can also be calculated from the + SIG RR's RDLENGTH. They are right justified, high-order-octet first. + The same conditional formula for calculating the length from LQ is + used as for all the other length fields above. + + The data signed is determined as specified in [RFC 2535]. Then the + following steps are taken where Q, P, G, and Y are as specified in + the public key [Schneier]: + + hash = SHA-1 ( data ) + + Generate random [RFC 1750] K such that 0 < K < Q. (Never sign + two different messages with the same K. K should be chosen + from a very large space: If an opponent learns a K value for + a single signature, the user's signing key is compromised, + and a forger can sign arbitrary messages. There is no harm + in signing the same message multiple times with the same key + or different keys.) + + + + +R. Schroeppel, et al [Page 11] + + +INTERNET-DRAFT ECC in the DNS + + + R = (the W-coordinate of ( K*G on the elliptic curve )) + interpreted as an integer, and reduced (mod Q). (R must not + be 0. In this astronomically unlikely event, generate a new + random K and recalculate R.) + + S = ( K^(-1) * (hash + X*R) ) mod Q. + + S must not be 0. In this astronomically unlikely event, + generate a new random K and recalculate R and S. + + If S > Q/2, set S = Q - S. + + The pair (R,S) is the signature. + + Another party verifies the signature as follows: + + Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a + valid EC sigature. + + hash = SHA-1 ( data ) + + Sinv = S^(-1) mod Q. + + + U1 = (hash * Sinv) mod Q. + + U2 = (R * Sinv) mod Q. + + (U1 * G + U2 * Y) is computed on the elliptic curve. + + V = (the W-coordinate of this point) interpreted as an integer + and reduced (mod Q). + + The signature is valid if V = R. + + The reason for requiring S < Q/2 is that, otherwise, both (R,S) and + (R,Q-S) would be valid signatures for the same data. Note that a + signature that is valid for hash(data) is also valid for hash(data)+Q + or hash(data)-Q, if these happen to fall in the range [0,2^160-1]. + It's believed to be computationally infeasible to find data that + hashes to an assigned value, so this is only a cosmetic blemish. The + blemish can be eliminated by using Q > 2^160, at the cost of having + slightly longer signatures, 42 octets instead of 40. + + We must specify how a field-element E ("the W-coordinate") is to be + interpreted as an integer. The field-element E is regarded as a + radix-P integer, with the digits being the coefficients in the + polynomial basis representation of E. The digits are in the ragne + [0,P-1]. In the two most common cases, this reduces to "the obvious + thing". In the (mod P) case, E is simply a residue mod P, and is + + +R. Schroeppel, et al [Page 12] + + +INTERNET-DRAFT ECC in the DNS + + + taken as an integer in the range [0,P-1]. In the GF[2^D] case, E is + in the D-bit polynomial basis representation, and is simply taken as + an integer in the range [0,(2^D)-1]. For other fields GF[P^D], it's + necessary to do some radix conversion arithmetic. + + + +6. Performance Considerations + + Elliptic curve signatures use smaller moduli or field sizes than RSA + and DSA, so signature generation is significantly faster. Creation + of a curve is slow, but not done very often. Key generation is + faster than RSA or DSA. Signature verification is faster than DSA, + but slower than RSA. + + Current DNS implementations are optimized for small transfers, + typically less than 512 octets including DNS overhead. While larger + transfers will perform correctly and work is underway to make larger + transfers more efficient, it is still advisable at this time to make + reasonable efforts to minimize the size of KEY RR sets stored within + the DNS consistent with adequate security. Keep in mind that in a + secure zone, an authenticating SIG RR will also be returned. + + + +7. Security Considerations + + Many of the general security consideration in [RFC 2535] apply. Some + specific key generation considerations are given above. Of course, + the elliptic curve key stored in the DNS for an entity should not be + trusted unless it has been obtain via a trusted DNS resolver that + vouches for its security or unless the application using the key has + done a similar authentication. + + + +8. IANA Considerations + + Assignment of meaning to the remaining ECC KEY flag bit or to values + of fields outside the ranges for which meaning in defined in this + document requires an IETF consensus as defined in [RFC 2434]. + + + + + + + + + + + +R. Schroeppel, et al [Page 13] + + +INTERNET-DRAFT ECC in the DNS + + +References + + [RFC 1034] - P. Mockapetris, "Domain names - concepts and + facilities", 11/01/1987. + + [RFC 1035] - P. Mockapetris, "Domain names - implementation and + specification", 11/01/1987. + + [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness + Recommendations for Security", 12/29/1994. + + [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", March 1997. + + [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", October 1998. + + [RFC 2535] - D. Eastlake,"Domain Name System Security Extensions", + March 1999. + + [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", 1996, John Wiley and Sons + + [Menezes] - Alfred Menezes, "Elliptic Curve Public Key + Cryptosystems", 1993 Kluwer. + + [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves", + 1986, Springer Graduate Texts in mathematics #106. + + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 14] + + +INTERNET-DRAFT ECC in the DNS + + +Authors' Addresses + + Rich Schroeppel + 500 S. Maple Drive + Woodland Hills, Utah 84653 USA + + Telephone: 1-801-423-7998(h) + 1-505-844-9079(w) + Email: rcs@cs.arizona.edu + rschroe@sandia.gov + + + Donald E. Eastlake 3rd + IBM + 65 Shindegan Hill Road + Carmel, NY 10512 USA + + Telephone: +1 914-276-2668(h) + +1 914-784-7913(w) + FAX: +1 914-784-3833(w) + EMail: dee3@us.ibm.com + + + +Expiration and File Name + + This draft expires in April 2000. + + Its file name is draft-schroeppel-dnsind-ecc-00.txt. + + + + + + + + + + + + + + + + + + + + + + + +R. Schroeppel, et al [Page 15] +