From b0a1fa9b209f8963dfbc96d123a792e8279102fd Mon Sep 17 00:00:00 2001 From: Andreas Gustafsson Date: Mon, 19 Nov 2001 20:52:23 +0000 Subject: [PATCH] updated drafts --- .../draft-esibov-dnsext-dynupdtld-00.txt | 219 - .../draft-esibov-dnsext-dynupdtld-01.txt | 20 + doc/draft/draft-ietf-dnsext-edns0dot5-02.txt | 338 -- doc/draft/draft-ietf-dnsext-edns0dot5-03.txt | 20 + .../draft-ietf-dnsext-not-existing-rr-01.txt | 953 ---- .../draft-ietf-dnsext-not-existing-rr-02.txt | 19 + doc/draft/draft-ietf-dnsop-parent-sig-00.txt | 211 - doc/draft/draft-ietf-dnsop-parent-sig-01.txt | 21 + ...xt => draft-ietf-enum-e164-gstn-np-02.txt} | 154 +- doc/draft/draft-ietf-enum-operation-02.txt | 945 ---- doc/draft/draft-ietf-enum-operation-03.txt | 20 + doc/draft/draft-ietf-idn-amc-ace-m-00.txt | 1741 ------- doc/draft/draft-ietf-idn-amc-ace-m-01.txt | 19 + doc/draft/draft-ietf-idn-brace-00.txt | 1053 ----- doc/draft/draft-ietf-idn-brace-01.txt | 19 + doc/draft/draft-ietf-idn-dnsii-mdnp-02.txt | 794 ---- doc/draft/draft-ietf-idn-dnsii-mdnp-03.txt | 20 + doc/draft/draft-ietf-idn-dnsii-mdnr-01.txt | 841 ---- doc/draft/draft-ietf-idn-dnsii-mdnr-02.txt | 20 + doc/draft/draft-ietf-idn-dnsii-trace-00.txt | 636 --- doc/draft/draft-ietf-idn-dnsii-trace-01.txt | 20 + doc/draft/draft-ietf-idn-idna-03.txt | 379 -- doc/draft/draft-ietf-idn-idna-04.txt | 550 +++ doc/draft/draft-ietf-idn-lace-01.txt | 859 ---- doc/draft/draft-ietf-idn-lace-02.txt | 20 + doc/draft/draft-ietf-idn-mua-00.txt | 374 -- doc/draft/draft-ietf-idn-mua-01.txt | 19 + doc/draft/draft-ietf-idn-race-03.txt | 588 --- doc/draft/draft-ietf-idn-race-04.txt | 19 + ...udns-02.txt => draft-ietf-idn-udns-03.txt} | 172 +- doc/draft/draft-ietf-idn-uri-00.txt | 269 -- doc/draft/draft-ietf-idn-uri-01.txt | 19 + doc/draft/draft-ietf-idn-utf6-00.txt | 451 -- doc/draft/draft-ietf-idn-utf6-01.txt | 20 + doc/draft/draft-ietf-idn-version-00.txt | 254 - doc/draft/draft-ietf-idn-version-01.txt | 19 + ...ft-ietf-ipngwg-default-addr-select-06.txt} | 544 ++- .../draft-ietf-ipngwg-prefix-rr-disc-00.txt | 224 - .../draft-ietf-ipngwg-prefix-rr-disc-01.txt | 19 + doc/draft/draft-ietf-ipngwg-rfc2292bis-02.txt | 4141 ----------------- doc/draft/draft-ietf-ipngwg-rfc2292bis-03.txt | 21 + doc/draft/draft-ietf-ipngwg-rfc2553bis-03.txt | 2044 -------- doc/draft/draft-ietf-ipngwg-rfc2553bis-04.txt | 22 + ...-macgowan-dnsext-label-intel-manage-00.txt | 802 ---- ...-macgowan-dnsext-label-intel-manage-01.txt | 19 + ...raft-msawyer-dnsext-edns-attributes-00.txt | 283 -- ...raft-msawyer-dnsext-edns-attributes-01.txt | 21 + ...aft-sawyer-dnsext-edns0-zone-option-00.txt | 221 - ...aft-sawyer-dnsext-edns0-zone-option-01.txt | 21 + 49 files changed, 1590 insertions(+), 18887 deletions(-) delete mode 100644 doc/draft/draft-esibov-dnsext-dynupdtld-00.txt create mode 100644 doc/draft/draft-esibov-dnsext-dynupdtld-01.txt delete mode 100644 doc/draft/draft-ietf-dnsext-edns0dot5-02.txt create mode 100644 doc/draft/draft-ietf-dnsext-edns0dot5-03.txt delete mode 100644 doc/draft/draft-ietf-dnsext-not-existing-rr-01.txt create mode 100644 doc/draft/draft-ietf-dnsext-not-existing-rr-02.txt delete mode 100644 doc/draft/draft-ietf-dnsop-parent-sig-00.txt create mode 100644 doc/draft/draft-ietf-dnsop-parent-sig-01.txt rename doc/draft/{draft-ietf-enum-e164-gstn-np-01.txt => draft-ietf-enum-e164-gstn-np-02.txt} (94%) delete mode 100644 doc/draft/draft-ietf-enum-operation-02.txt create mode 100644 doc/draft/draft-ietf-enum-operation-03.txt delete mode 100644 doc/draft/draft-ietf-idn-amc-ace-m-00.txt create mode 100644 doc/draft/draft-ietf-idn-amc-ace-m-01.txt delete mode 100644 doc/draft/draft-ietf-idn-brace-00.txt create mode 100644 doc/draft/draft-ietf-idn-brace-01.txt delete mode 100644 doc/draft/draft-ietf-idn-dnsii-mdnp-02.txt create mode 100644 doc/draft/draft-ietf-idn-dnsii-mdnp-03.txt delete mode 100644 doc/draft/draft-ietf-idn-dnsii-mdnr-01.txt create mode 100644 doc/draft/draft-ietf-idn-dnsii-mdnr-02.txt delete mode 100644 doc/draft/draft-ietf-idn-dnsii-trace-00.txt create mode 100644 doc/draft/draft-ietf-idn-dnsii-trace-01.txt delete mode 100644 doc/draft/draft-ietf-idn-idna-03.txt create mode 100644 doc/draft/draft-ietf-idn-idna-04.txt delete mode 100644 doc/draft/draft-ietf-idn-lace-01.txt create mode 100644 doc/draft/draft-ietf-idn-lace-02.txt delete mode 100644 doc/draft/draft-ietf-idn-mua-00.txt create mode 100644 doc/draft/draft-ietf-idn-mua-01.txt delete mode 100644 doc/draft/draft-ietf-idn-race-03.txt create mode 100644 doc/draft/draft-ietf-idn-race-04.txt rename doc/draft/{draft-ietf-idn-udns-02.txt => draft-ietf-idn-udns-03.txt} (87%) delete mode 100644 doc/draft/draft-ietf-idn-uri-00.txt create mode 100644 doc/draft/draft-ietf-idn-uri-01.txt delete mode 100644 doc/draft/draft-ietf-idn-utf6-00.txt create mode 100644 doc/draft/draft-ietf-idn-utf6-01.txt delete mode 100644 doc/draft/draft-ietf-idn-version-00.txt create mode 100644 doc/draft/draft-ietf-idn-version-01.txt rename doc/draft/{draft-ietf-ipngwg-default-addr-select-05.txt => draft-ietf-ipngwg-default-addr-select-06.txt} (88%) delete mode 100644 doc/draft/draft-ietf-ipngwg-prefix-rr-disc-00.txt create mode 100644 doc/draft/draft-ietf-ipngwg-prefix-rr-disc-01.txt delete mode 100644 doc/draft/draft-ietf-ipngwg-rfc2292bis-02.txt create mode 100644 doc/draft/draft-ietf-ipngwg-rfc2292bis-03.txt delete mode 100644 doc/draft/draft-ietf-ipngwg-rfc2553bis-03.txt create mode 100644 doc/draft/draft-ietf-ipngwg-rfc2553bis-04.txt delete mode 100644 doc/draft/draft-macgowan-dnsext-label-intel-manage-00.txt create mode 100644 doc/draft/draft-macgowan-dnsext-label-intel-manage-01.txt delete mode 100644 doc/draft/draft-msawyer-dnsext-edns-attributes-00.txt create mode 100644 doc/draft/draft-msawyer-dnsext-edns-attributes-01.txt delete mode 100644 doc/draft/draft-sawyer-dnsext-edns0-zone-option-00.txt create mode 100644 doc/draft/draft-sawyer-dnsext-edns0-zone-option-01.txt diff --git a/doc/draft/draft-esibov-dnsext-dynupdtld-00.txt b/doc/draft/draft-esibov-dnsext-dynupdtld-00.txt deleted file mode 100644 index beb066ce96..0000000000 --- a/doc/draft/draft-esibov-dnsext-dynupdtld-00.txt +++ /dev/null @@ -1,219 +0,0 @@ - - -DNSEXT Working Group Levon Esibov -INTERNET-DRAFT Stuart Kwan -Category: Best Current Practice Microsoft - -February 22, 2001 - - - Dynamic DNS Update of the Top Level Domain and Root Zones - -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. - - - -Status of this Memo - -This document specifies an Internet Best Current Practices for the -Internet Community, and requests discussion and suggestions for -improvements. Distribution of this memo is unlimited. - - -Copyright Notice - -Copyright (C) The Internet Society (2001). All Rights Reserved. - -Abstract - -With an increasing number of implementations where the DNS client is -capable of performing dynamic DNS updates, an increase in the number of -the dynamic DNS updates sent to the servers hosting top level domain -zones has been observed. The purpose of this document is to recommend -DNS client configuration that prevents sending dynamic DNS updates for -the top level domain zones and root zones. - - - - - - -Esibov & Kwan BCP [Page 1] - -INTERNET-DRAFT Dynamic Update of the TLD DNS Zones 22 February 2001 - - - -1. Introduction - -RFC 2136 [1] specifies Dynamic Updates in DNS, but does not -consider updates of the top level domain zones (e.g. "com", "edu", "ca", -"uk", etc...) and the root zone as a special case. Usually requests to -perform dynamic updates of the top level domain zones and the root zone -are expected to fail because these zones (on the Internet) are -configured to prohibit any dynamic updates. The same is true for most -organizations' private internal DNS infrastructures. The unnecessary -load of the dynamic updates sent by DNS clients attempting dynamic -updates of these zones consumes the resources of the DNS servers -authoritative for these zones and consumes network bandwidth. - -With an increasing number of implementations where the DNS client is -capable of performing dynamic DNS updates, an increase in the number of -the dynamic DNS updates sent to the servers hosting top level domain -zones has been observed. The purpose of this document is to recommend -DNS client configuration that prevents sending dynamic DNS updates for -the top level domain zones and root zones. - -In this document, the key words "MAY", "MUST, "MUST NOT", "optional", -"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as -described in [2]. - - - -2. Dynamic updates of the top level domain zones and root zones. - -To prevent dynamic DNS update requests to the top level domain zones and -root zone, it is recommended that DNS clients are configured by default -to suppress dynamic DNS updates of the top level domain zones and the -root zone. - -To address the needs of the organizations using top level domain zones -and/or the root zone in their private internal DNS infrastructures, and -to allow dynamic updates of such zones, DNS clients MAY be configured to -allow dynamic DNS updates to be sent to the top level domain zones. - - - -3. IANA Considerations - -IANA's consideration is not required. - - - -4. Security Considerations - -This draft does not introduce any additional security concerns. - - - -Esibov & Kwan BCP [Page 2] - -INTERNET-DRAFT Dynamic Update of the TLD DNS Zones 22 February 2001 - - -5. Acknowledgements - -Authors would like to thank Aristotle Balogh and Mark Kosters for -bringing to our attention the raising volume of the dynamic update -requests sent to the top level domain zones. We would also like to thank -Michael Cretzman for review of this document. - - - -6. Authors' Addresses - -Levon Esibov -Microsoft Corporation -One Microsoft Way -Redmond, WA 98052 - -EMail: levone@microsoft.com - - - -Stuart Kwan -Microsoft Corporation -One Microsoft Way -Redmond, WA 98052 - -EMail: skwan@microsoft.com - - -7. References - -[1] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates - in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. - -[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - -8. Intellectual Property Statement - -The IETF takes no position regarding the validity or scope of any -intellectual property or other rights that might be claimed to pertain -to the implementation or use of the technology described in this -document or the extent to which any license under such rights might or -might not be available; neither does it represent that it has made any -effort to identify any such rights. Information on the IETF's -procedures with respect to rights in standards-track and standards- -related documentation can be found in BCP-11. Copies of claims of -rights made available for publication and any assurances of licenses to -be made available, or the result of an attempt made to obtain a general -license or permission for the use of such proprietary rights by -implementors or users of this specification can be obtained from the -IETF Secretariat. - -Esibov & Kwan BCP [Page 3] - -INTERNET-DRAFT Dynamic Update of the TLD DNS Zones 22 February 2001 - - -The IETF invites any interested party to bring to its attention any -copyrights, patents or patent applications, or other proprietary rights -which may cover technology that may be required to practice this -standard. Please address the information to the IETF Executive -Director. - - - -9. Full Copyright Statement - -Copyright (C) The Internet Society (2001). 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." - -10. Expiration Date - -This memo is filed as , and -expires August 22, 2001. - - - - -Esibov & Kwan BCP [Page 4] - - diff --git a/doc/draft/draft-esibov-dnsext-dynupdtld-01.txt b/doc/draft/draft-esibov-dnsext-dynupdtld-01.txt new file mode 100644 index 0000000000..13d1f97e73 --- /dev/null +++ b/doc/draft/draft-esibov-dnsext-dynupdtld-01.txt @@ -0,0 +1,20 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +S. Kwan: skwan@microsoft.com +L. Esibov: levone@microsoft.com + + diff --git a/doc/draft/draft-ietf-dnsext-edns0dot5-02.txt b/doc/draft/draft-ietf-dnsext-edns0dot5-02.txt deleted file mode 100644 index 098da810b6..0000000000 --- a/doc/draft/draft-ietf-dnsext-edns0dot5-02.txt +++ /dev/null @@ -1,338 +0,0 @@ - - - - - - -Network Working Group R. Austein -draft-ietf-dnsext-edns0dot5-02.txt InterNetShare.com, Inc. - H. Alvestrand - Cisco Systems - November 2000 - - - A Proposed Enhancement to the EDNS0 Version Mechanism - - -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 mailing list . - -Motivation and Scope - - EDNS0 [EDNS0] specifies a general framework for extending the packet - format used by the Domain Name System protocols. The framework - includes a simple version numbering scheme to allow the parties in a - DNS protocol exchange to determine which extension features the other - party understands. While having the advantage of simplicity, the - version numbering scheme as specified has drawbacks: - - - It provides no way to deprecate a protocol feature; - - - It provides no way to deploy experimental protocol features. - - - - - -Austein & Alvestrand Expires 22 May 2001 [Page 1] - -draft-ietf-dnsext-edns0dot5-02.txt November 2000 - - - This note proposes to augument the monolithic version numbering - mechanism with a mechanism for listing an explicit set of protocol - features that a particular implementation supports. We retain - version numbering as a way of abbreviating the feature sets that we - expect to see in common use. - -Model - - Our revised extension model for the DNS is designed with three goals - in mind: - - - We want the protocol to be as simple as possible for the common - case of a client or server that implements "mainstream standard - DNS"; - - - We want to provide a safe way to experiment with new protocol - features, both inside and outside the deployed DNS; - - - We want to provide a safe way to deprecate protocol features. - - Our revised extension model has two parts, both of which are carried - in the OPT pseudo-RR: the VERSION, which stored in the second octet - of the TTL field of the OPT RR, and a variable-length list of - FEATURES, stored in the variable part of the OPT RR. - - All FEATUREs are extensions of the DNS. We reserve the range of - FEATURE numbers from 1 to 100 for describing features of the original - RFC 1034/1035 DNS specification that we might eventually choose to - deprecate. - - Any query/response pair can be described as using a set of DNS - FEATUREs. Such features might for instance be: - - - Domain binary labels according to [BINARY-LABELS]; - - - Extended RCODEs (the general principle, not specific values); - - - Multi-packet UDP response; - - - Increased maximum UDP payload size; - - - Character set identification in DNS labels; - - - SIG record parsing and checking; - - FEATURE numbers are handed out by IANA on a first-come-first-served - basis within their appropriate ranges. Any revised specification of - a format or function should have its own FEATURE number; in the IETF - - - -Austein & Alvestrand Expires 22 May 2001 [Page 2] - -draft-ietf-dnsext-edns0dot5-02.txt November 2000 - - - process, any significantly changed Internet-Draft should have a new - FEATURE number assigned for experimentation. - - An assigned VERSION number names a set of FEATUREs. VERSION numbers - are assigned by the IETF through a standards action. - - Normally, any VERSION number encompasses every FEATURE of all lower - VERSION numbers, but the possibility of removing FEATUREs exists for - two reasons: - - - To remove the need for supporting FEATUREs that turned out to be a - Really Bad Idea; - - - To allow replacing a badly specified FEATURE with a better - specified FEATURE performing the same function that has a new - FEATURE number. - -Mechanism - - We transport explicit feature sets as lists of integers carried in - the variable RDATA portion of the EDNS0 OPT pseudo-RR. - - The OPTION-CODE for FEATURES is [TBD]. - - The OPTION-DATA for FEATURES is an ordered list of "feature numbers"; - a feature number is represented as a big-endian 16-bit unsigned - integer, and the list is sorted into numerically increasing order. - - Each feature number names a particular protocol feature that is - supported by the implementation that generated this OPT pseudo-RR. - -Usage - - In most respects, the FEATURE mechanism is used symmetrically by - clients and servers; exceptions to this rule are stated after the - general explanation. - - When composing a DNS message, a client or server includes an OPT - record indicating a set of FEATUREs that: - - - MUST include all FEATUREs that the client or server believes are - relevant to this message; - - - MAY include all FEATURES that the client or server is prepared to - receive. - - This set is expressed as a VERSION and any additional FEATURES - required. - - - -Austein & Alvestrand Expires 22 May 2001 [Page 3] - -draft-ietf-dnsext-edns0dot5-02.txt November 2000 - - - In general, we expect that a client or server will include an OPT - pseudo-RR that indicates: - - - The highest VERSION number that the entity generating the message - supports; and - - - A small (possibly empty) set of additional FEATUREs not encompassed - by the VERSION that the entity deems necessary or desirable. - - The above symmetry notwithstanding, we impose one important - constraint on the server: while a server is allowed to indicate - whatever FEATUREs it believes are relevant or useful, a server MUST - NOT make use of any FEATURE in a response that is not within the set - of FEATUREs indicated by the client that generated the corresponding - request. That is, a response may say "I support FEATURE FOO" - regardless of what the client supports, but the rest of the response - must not use FEATURE FOO unless the client also supports it. - - As a special case, if a client explicitly queries for the OPT RR of - the root zone, the server returns an OPT record including all - FEATUREs that the server supports. This functionality is provided - strictly for diagnostic purposes. - -Life Cycle - - We expect the life cycle of new features to proceed as follows: - - - VERSION X is defined and deployed. - - - A new FEATURE is defined and experimentally implemented. All - clients and servers taking part in the experiment use FEATURE to - indicate support. - - - Community consensus is reached that this FEATURE is genuinely - useful. - - - VERSION X+1 is defined, encompassing all FEATUREs from VERSION X, - plus the new FEATURE (and perhaps others). - - - The next generation of DNS software supports VERSION X+1, and never - use FEATURE. - -Risks - - While we have tried to provide the ability to deprecate old bad - protocol features, such an ability should be used only rarely, if at - all, since by any realistic estimate it takes years (decades?) to - upgrade all the DNS implementations already in the field. - - - -Austein & Alvestrand Expires 22 May 2001 [Page 4] - -draft-ietf-dnsext-edns0dot5-02.txt November 2000 - - - A flexible extension mechanism of this type increases the risk that - some implementors might chose to deploy features designed to hinder - interoperability (so-called "labeled noninteroperability"). - -Security Considerations - - We do not believe that this protocol enhancement adds any major new - security risks, but we do believe that it would be helpful in getting - complicated DNS extensions such as [DNSSEC] deployed more quickly. - - As with any enhancement to or complication of the DNS protocol, this - enhancement offers attackers yet another way to increase the load on - a name server. Root, TLD and other "major" name servers should view - excessively complicated FEATURE sets with suspicion, and should not - allow themselves to be tricked into performing more work than is - really necessary. - -IANA Considerations - - IANA will need to allocate an EDNS0 option code for FEATURES. - - IANA will need to create a new registry of feature numbers. - -Acknowledgments - - The authors would like to thank the following people for their help - in improving this document: Randy Bush, Patrik Faltstrom, Olafur - Gudmundsson, Bob Halley, and XXX. - -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. - - [BINARY-LABELS] Crawford, M., "Binary Labels in the Domain Name - System", RFC 2673 August 1999. - - - - - - -Austein & Alvestrand Expires 22 May 2001 [Page 5] - -draft-ietf-dnsext-edns0dot5-02.txt November 2000 - - -Author's addresses: - - Rob Austein - InterNetShare.com, Inc. - 505 West Olive Ave., Suite 321 - Sunnyvale, CA 94086 - USA - - sra@hactrn.net - - Harald Tveit Alvestrand - Cisco Systems - Weidemanns vei 27 - N-7043 Trondheim - NORWAY - - +47 73 50 33 52 - Harald@Alvestrand.no - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Austein & Alvestrand Expires 22 May 2001 [Page 6] diff --git a/doc/draft/draft-ietf-dnsext-edns0dot5-03.txt b/doc/draft/draft-ietf-dnsext-edns0dot5-03.txt new file mode 100644 index 0000000000..dbe92a4e95 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-edns0dot5-03.txt @@ -0,0 +1,20 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +H. Alvestrand: harald@alvestrand.no +R. Austein: sra@hactrn.net + + diff --git a/doc/draft/draft-ietf-dnsext-not-existing-rr-01.txt b/doc/draft/draft-ietf-dnsext-not-existing-rr-01.txt deleted file mode 100644 index fbc9506e93..0000000000 --- a/doc/draft/draft-ietf-dnsext-not-existing-rr-01.txt +++ /dev/null @@ -1,953 +0,0 @@ - - -Network Working Group S. Josefsson -Internet-Draft RSA Security -Expires: May 25, 2001 November 24, 2000 - - - Authenticating denial of existence in DNS with minimum disclosure - (or; An alternative to DNSSEC NXT records) - draft-ietf-dnsext-not-existing-rr-01 - -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. - - This Internet-Draft will expire on May 25, 2001. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - This draft present an alternative to NXT records, used to achieve - authenticated denial of existence of a domain name, class and type. - Problems with NXT records, as specified in RFC 2535, are identified. - One solution, the NO record, is presented. - - The NO record differ from the NXT record by using a cryptographic - hash value instead of the domain name. This prevent an adversery - from collecting information by "chaining" through a zone. It also - remove delegation point concerns that was a side effect of NXT - records. The document also describe hash truncation and record - merging that reduces storage/network load. - - - -Josefsson Expires May 25, 2001 [Page 1] - -Internet-Draft The NO Record November 2000 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. The NO Resource Record . . . . . . . . . . . . . . . . . . 4 - 3.1 Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3.2 NO RDATA Format . . . . . . . . . . . . . . . . . . . . . 4 - 3.3 NO RDATA on-the-wire format example . . . . . . . . . . . 6 - 3.4 Owner Names . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.5 Additional Complexity Due To Wildcards . . . . . . . . . . 7 - 3.6 No Considerations at Delegation Points . . . . . . . . . . 7 - 3.7 Hash Truncation and Dynamic Updates . . . . . . . . . . . 8 - 3.8 Reducing Number of Records . . . . . . . . . . . . . . . . 9 - 3.9 Hash Collisions . . . . . . . . . . . . . . . . . . . . . 9 - 3.10 Authenticating Denial of NO Records . . . . . . . . . . . 9 - 3.11 Case Considerations . . . . . . . . . . . . . . . . . . . 10 - 3.12 Presentation Format . . . . . . . . . . . . . . . . . . . 10 - 3.13 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.13.1 Adding NO Records to a Zone . . . . . . . . . . . . . . . 10 - 3.13.2 Simple NO creating entity . . . . . . . . . . . . . . . . 11 - 3.13.3 Advanced NO creating entity . . . . . . . . . . . . . . . 11 - 3.13.4 Resolver Query for Non-existing Domain . . . . . . . . . . 11 - 3.13.5 Resolver Query for Non-existing Type At Existing Domain . 12 - 4. Comparing NO and NXT . . . . . . . . . . . . . . . . . . . 13 - 4.1 Denial Of Existence Of Non-Existing Names . . . . . . . . 13 - 4.2 Denial Of Types Of Existing Names . . . . . . . . . . . . 13 - 4.3 Information disclosure (chain problem) . . . . . . . . . . 13 - 4.4 Delegation problem . . . . . . . . . . . . . . . . . . . . 13 - 4.5 Zone size (Bytes) . . . . . . . . . . . . . . . . . . . . 13 - 4.6 Zone size (Number Of Records) . . . . . . . . . . . . . . 13 - 4.7 Zone size (Number Of Owner names) . . . . . . . . . . . . 14 - 4.8 SIG Labels field and Wildcard records . . . . . . . . . . 14 - 4.9 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 14 - 5. Security Considerations . . . . . . . . . . . . . . . . . 15 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 15 - References . . . . . . . . . . . . . . . . . . . . . . . . 16 - Author's Address . . . . . . . . . . . . . . . . . . . . . 16 - Full Copyright Statement . . . . . . . . . . . . . . . . . 17 - - - - - - - - - - - - - -Josefsson Expires May 25, 2001 [Page 2] - -Internet-Draft The NO Record November 2000 - - -1. Introduction - - "Domain Name Security Extensions", RFC 2535 [1], specifies several - extensions to DNS that provides data integrity and authentication. - Among them is the NXT record, used to achieve authenticated denial - of existence of domains, and authenticated denial of existence on - certain class/types on existing domains. - - As a consequence of NXT records it is possible to "chain" through a - zone secured by DNS security extensions, collecting all names and/or - records in the zone. NXT records also introduce a complication at - delegation points. These are the main problems that motivated this - draft. - -2. Context - - There have been arguments that the "chain" problem of NXT records is - a non-issue. Often used is the argument that information in DNS is - public, and if you wish to keep information private, you shouldn't - publish it in DNS. This might be true, but nonetheless major - service providers and companies are restricting access to zone - transfers. Also, people have debated whether NXT records should be - part of DNSSEC at all because of this problem [5]. - - Another aspect exist. When DNS is used to store certificates, as - described in RFC 2538 [2], certificates can identify individuals - and/or carry authentication information for special purposes. This - context has been the motivation for developing this draft. - - The "chain" problem is not the only concern with NXT records. The - delegation considerations for NXT records (different RRsets in the - parent and child for the same domain) has also been regarded as a - flaw of the NXT records. - - - - - - - - - - - - - - - - - - -Josefsson Expires May 25, 2001 [Page 3] - -Internet-Draft The NO Record November 2000 - - -3. The NO Resource Record - - This section describe the NO Resource Record. - -3.1 Idea - - A straight-forward extension to the NXT record that minimize - disclosure of information is to store a one-way function value - instead of the actual domain name. This is similar to NXT records; - where NXT records secure a interval where no existing domain names - are to be found, NO records secure a interval where no one-way value - of existing domain names are to be found. - - The benefit, of course, is that an adversary does not yield any - useful information from the record. Specifically, "chaining" - through a zone to collect all records is no longer possible. - - This idea has been extended in this document into allowing (but not - requiring) one record to deny existence of several records, and - truncating the hash value to the shortest unique prefix to preserve - space. - -3.2 NO RDATA Format - - The RDATA for a NO RR consists of one or more fields with the - following structure. The structure have the following elements: a - zero-terminated list of RR types, a hash length specifier, and a - hash value, as shown below. Both the "RR type" list and the "next - hash value" fields are of variable width. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / owner RR type list / - / | - +---------------+-----------------------------------------------+ - | # hash octets | SHA-1 hash value / - +---------------+ / - / / - +---------------------------------------------------------------+ - - Replacing the NXT RR "type bit map" field is a variable length list - of RR types. Each RR type is 16 bits. As the list is of variable - length, a end-of-list indicator is require. End of the list is - signalled by a all-zero RR type. Each element is a 2 byte RR type. - The list MUST be sorted in RR type order. The change from NXT's - bitmap field removes the limit of authenticating only the first 127 - RR types. - - -Josefsson Expires May 25, 2001 [Page 4] - -Internet-Draft The NO Record November 2000 - - - The RR type list indicates what types exist at the previous hash - value -- i.e. the first RR type list in the RRdata of a NO record - indicate what RR types exist at the domain name that hashes to the - owner name of that NO record. The second RR type list, if any, in - the RRdata of a NO record indicate what RR types exist at the domain - name that hashes the first SHA-1 value in the RRdata. And so on. - See below for a complete example of the on-the-wire-format of a NO - record with hash truncation and record merging and its - interpretation. - - Length of the hash value field is denoted by the # hash octets - fields, it is a unsigned integer ranging from 0 to 255. The meaning - of a zero length integer is reserved. - - The SHA-1 hash value field is a variable length field containing the - actual hash value. - - The NO RRs for a zone SHOULD be automatically calculated and added - to the zone when SIGs are added. The NO RR's TTL SHOULD NOT exceed - the zone minimum TTL. - - The type number for the NO RR is TBD. - - NO RR's MUST only be signed by zone level keys [7]. - - - - - - - - - - - - - - - - - - - - - - - - - - - -Josefsson Expires May 25, 2001 [Page 5] - -Internet-Draft The NO Record November 2000 - - -3.3 NO RDATA on-the-wire format example - - The following is a example of the on-the-wire-format of a complete - NO resource record were hash truncation and record merging is used. - It is the on-the-wire format of the NO record in section 3.13.1.2. - - 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 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | RR type 1 (A) | RR type 0 (end-of-list) | - +---------------+-----------------------------------------------+ - | 1 hash octet | Hash 0x22 | RR type 2 (NS) | - +---------------+---------------+-------------------------------+ - | RR type 6 (SOA) | RR type 15 (MX) | - +-------------------------------+---------------+---------------+ - | RR type 0 (end-of-list) | 1 hash octet | Hash 0x83 | - +-------------------------------+---------------+---------------+ - | RR type 1 (A) | RR type 0 (end-of-list) | - +---------------+-----------------------------------------------+ - | 1 hash octet | Hash 0x90 | RR type 1 (A) | - +---------------+---------------+-------------------------------+ - | RR type 16 (TXT) | RR type 0 (end-of-list) | - +---------------+---------------+-------------------------------+ - | 1 hash octet | Hash 0x1b | - +-------------------------------+ - - The intepretation here is that the domain that corresponds with the - NO owner name ("1b._no.example.org.", not shown above) have a A - record, that the domain that hash to 0x22 (truncated to one octet) - have a NS, SOA and MX record, that the domain that hash to 0x83 - (truncated to 1 octet) have a A record etc. Note that the last hash - value of NO RRdata does not have a RR type list in the same record. - -3.4 Owner Names - - As the previous NO RR format describe, the "next domain name" of NXT - records is replaced by its hash value. This removes the possibility - of chaining both backwards and forwards through a zone. - - But without also modifying the owner names of NO records it is still - not difficult to chain through a zone. Consider querying a server - for (say) "m._no.example.org", the reply could contain a NO record - for "g._no.example.org", now an adversary can lookup records for - "g._no.example.org", and then issue a query for a domain that would - sort (in "the canonical order" described in RFC 2535) just before - "g._no.example.org". Applying the technique over and over again, all - records in the zone can still be collected. - - To prevent this, the owner names of NO records is replaced by its - - -Josefsson Expires May 25, 2001 [Page 6] - -Internet-Draft The NO Record November 2000 - - - hash value. As DNS places limits on what characters can be used in - owner names, the owner name uses a base 16 "hex" encoding [6]. - - In order to remove the (very small) chance of generated NO record - names colliding with existing, "real", domains, all NO records MUST - be stored directly in the "_no" domain of the zone. I.e., a zone - "example.org." store its NO records as, say, - "35a4d1._no.example.org.". - - This change in owner names also make sure that the delegation point - concerns of NXT records does not occur in NO records. - -3.5 Additional Complexity Due To Wildcards - - Proving that a non-existent name response is correct, or that a - wildcard expansion response is correct, makes things a little more - complex. - - In particular, when a non-existent name response is returned, an NO - must be returned showing that the exact name did not exist and, in - general, one or more additional NO need to be returned to also prove - that there wasn't a wildcard whose expansion should have been - returned. (There is no need to return multiple copies of the same - NO.) These NOs, if any, are returned in the authority section of the - response. - - Furthermore, if a wildcard expansion is returned in a response, in - general one or more NOs needs to also be returned in the authority - section to prove that no more specific name (including possibly more - specific wildcards in the zone) existed on which the response should - have been based. - -3.6 No Considerations at Delegation Points - - When NXT records are used to deny existance, there exists a special - case at delegation points. Namely, that two distinct RRsets exist - for the same owner name, one in the parent zone and one in the child - zone. - - $ORIGIN parent.example.org. - @ SOA - NS - NXT child SOA NS SIG NXT - child NS foo - NXT next NS SIG NXT - next A 127.0.0.2 - - - - - -Josefsson Expires May 25, 2001 [Page 7] - -Internet-Draft The NO Record November 2000 - - - $ORIGIN child.parent.example.org. - @ SOA - NS - NXT name SOA NS SIG NXT - name A 127.0.2.1 - NXT child.parent.example.org. - - With NO records, the parent would deny existance of domains in - "_no.parent.example" and the child in - "_no.child.parent.example.org". Thus no NO RRset collision occur. - -3.7 Hash Truncation and Dynamic Updates - - Entities that create NO records MAY truncate the hash field. It - MUST NOT truncate hash fields so they are no longer unique - throughout a zone. Hash truncations MUST only be done to octet - offsets. Truncation MUST be such that less significant bits are - truncated, i.e. higher-order bits are preserved (see the examples). - - Zones that are dynamically updated will have to calculate and add NO - records on-the-fly. If hash truncation is used, adding a new name - to the zone will require updating (and signing) NO records for the - conflicting name(s). - - Since truncation (and also "compression" described in the next - section) make it impossible to predict the corresponding NO record - given a domain name, resolvers should not ask for a hashed NO record - (aaaa._no.example.org. IN NO) for a known domain name if they want - to find out what types exist at the domain. Instead, a resolver - might ask for NO records on the original name (www.example.org. IN - NO). Such records will never exist, and the correct NO record will - be returned by the server. - - To summarize, the behaviour of hash truncation should be - configurable in the entity that creates NO records, to accomodate - different usage-patterns. If the zone is intended to be dynamicly - updated, hash truncation may be considered not worth the extra - on-the-fly processing required. - - - - - - - - - - - - - -Josefsson Expires May 25, 2001 [Page 8] - -Internet-Draft The NO Record November 2000 - - -3.8 Reducing Number of Records - - Entitities that create NO records MAY deny existence for several - records per NO record. Entities that create NO records should take - care so that each resulting NO record is not "too large". [Comments - on this? Should there be a specific limit? It might be left as a - DNS Operational consideration] - - Merging several NO records into one record also place more work on - the resolver. Instead of parsing two hash values for each NO record - to determine if it's applicaple, a resolver will have to parse - several hash values and compare each. - - The NO RR record consist of one or more RR type list / hash values, - described above, and a resolver need to parse the entire record to - collect each individual field. I.e., a NO parse algorithm could - looke like: read RRs, stop when you read a zero RR type, read hash - length indicator, read hash size, if the entire record is read stop, - otherwise read RRs, stop when you read a zero RR type, etc.. - -3.9 Hash Collisions - - Hash value collisions are expected not to occur. For SHA-1, the - probability that this should happen is 1 out of 2^80 on average. - - However, collisions are actually only a problem if the domain names - producing the same hash value have different sets of existing types. - - Consider the following records - - ; SHA-1(one.example.org) = SHA-1(two.example.org) - - one.example.org. IN A 1.2.3.4 - two.example.org. IN A 5.6.7.8 - - Given that no other RR types exist for neither domain, both - "one.example.org" and "two.example.org" would be authenticated not - to exist by the same NO record. - -3.10 Authenticating Denial of NO Records - - NO records (together with SIG records) authenticate denial for other - types in a zone. Unlike NXT records that re-use the namespace in - the zone, NO records are not intended to authenticate denial of - other NO records. - - - - - - -Josefsson Expires May 25, 2001 [Page 9] - -Internet-Draft The NO Record November 2000 - - -3.11 Case Considerations - - Before calculating SHA-1 hash values, domain names MUST be converted - into canonical format as described in RFC 2535. This is to make hash - comparisons possible. - -3.12 Presentation Format - - NO RRs do not appear in original unsigned zone master files since - they should be derived from the zone as it is being signed. - - If a signed file with NO records is printed or NO records are - printed by debugging code, they appear as a list of unsigned - integers or RR mnemonics, and the hash value in base 16 hex - representation [6] with "0x" prepended (to distinguish it from - integer RR codes). The zero RR that terminate the list of RR types, - and the hash value length indicator, does not appear. - - See the next section for examples of printed NO RRs. - -3.13 Examples - - This section contain examples of NO records, using the reserved - domain exmaple.org [3]. - -3.13.1 Adding NO Records to a Zone - - Consider the following zone file. - - $ORIGIN example.org. - @ IN SOA ... - @ IN NS ns - @ IN MX 0 server - ns IN A ... - www IN A ... - sERVEr IN A ... - sERVEr IN TXT "text" - - ; SHA1(example.org.) = 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 - ; SHA1(ns.example.org.) = 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5 - ; SHA1(www.example.org.) = 0x839ebd4386c0b26d81f147421b5b7036e61438cf - ; SHA1(server.example.org.) = 0x906a0ad5e604b1905828499dc8672ecb8de73e2f - - Note that hash values are calculcated on the canonical form. - - The following two sections describe two valid ways of adding NO - records to a zone. - - - - -Josefsson Expires May 25, 2001 [Page 10] - -Internet-Draft The NO Record November 2000 - - -3.13.2 Simple NO creating entity - - A simple NO creator entity might not implement truncation or provide - the possibility to deny more than one records per NO record. In - this case, the following would be added to the zone file. - - $ORIGIN _no.example.org. - 1b7838c69a66eb50cc215f66ee4554d0c4c940a5 - IN NO A 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 - 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1 - IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf - 839ebd4386c0b26d81f147421b5b7036e61438cf - IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f - 906a0ad5e604b1905828499dc8672ecb8de73e2f - IN NO A TXT 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5 - -3.13.3 Advanced NO creating entity - - A more advanced NO creator entity might append the following - instead, using both truncation and "compression". - - $ORIGIN _no.example.org - 1b IN NO A 0x22 NS SOA MX 0x83 A 0x90 A TXT 0x1b A - - Note that this contain 5 hash values while the zone only contain 4 - records, the last value in the line above is in fact the first hash - value in the zone, closing the circular NO chain. - -3.13.4 Resolver Query for Non-existing Domain - - Consider a client looking up the non-existant domain name - "baz.example.org.", using the zone file from the previous section. - First, we note the following calculations. - - SHA-1(baz.example.org.) = 0xd5d0f98783eec6e9943750f35904304bd1a4090e - SHA-1(*.example.org.) = 0x7ab3776e3b529eb42467cc5d279c88ec951cf021 - - A server would reply with an RCODE of NXDOMAIN and the authority - section data including the following: - - - - - - - - - - - - -Josefsson Expires May 25, 2001 [Page 11] - -Internet-Draft The NO Record November 2000 - - - ; backwards compatibility - example.org. IN SOA - - ; prove no baz.example.org - 906a0ad5e604b1905828499dc8672ecb8de73e2f._no.example.org. - IN NO A TXT 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5 - 906a0ad5e604b1905828499dc8672ecb8de73e2f._no.example.org. IN SIG NO - - ; prove no *.example.org: - 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1._no.example.org. - IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf - 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1._no.example.org. IN SIG NO - - In order for a client to verify the authenticity of this reply, in - addition of verifying the SIG record, it will also need to calculate - the one-way hash of "baz.example.org." and verify it is contained - inside the interval of any NO record in the authority section. - Also, to prove there are no wildcard records for baz.example.org., - NO records for possible wildcard expansions are returned. A client - should similarily calculate hash values of possible wildcards and - compare them to the authority section. - - Of course, if the zone was generated with the more advanced NO - creating entity, only the NO record from the previous section would - have to be returned. - -3.13.5 Resolver Query for Non-existing Type At Existing Domain - - Consider a client looking up TXT records for the existing domain - "www.example.org.", again, using the same zone file as previous. A - server would reply with an authority section like the following: - - 839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org. - IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f - 839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org. IN SIG NO - - The resolver verifies the signature and make sure - SHA-1("bar.example.org.") hashes correctly. - - - - - - - - - - - - - -Josefsson Expires May 25, 2001 [Page 12] - -Internet-Draft The NO Record November 2000 - - -4. Comparing NO and NXT - - To ease comparison between NXT and NO records, this section - summarize (mis-)features of the NXT and the NO record formats. The - intent here is to address all operational differences between NO and - NXT records. - -4.1 Denial Of Existence Of Non-Existing Names - - Both NXT and NO provide strong data non-existance for non-existing - names. - - NXT records authenticate data non-existance up to the probability of - finding a collision in the signature algorithm (1 in 2^64 for - RSA/MD5). NO records authenticate data non-existance up to the - probability of finding a collision in the signature algorithm (1 in - 2^64 for RSA/MD5) and the NO record hash value (varies due to - truncation). If the RSA/MD5 scheme is used, hash values in NO - records may be truncated to 64 bits. - -4.2 Denial Of Types Of Existing Names - - Both NXT and NO provide strong data non-existance of types for - existing names. The previous discussion also apply here. - -4.3 Information disclosure (chain problem) - - NXT records make it possible to collect all names (and records) in a - zone. NO records prohibit this. - -4.4 Delegation problem - - NXT records require a special case where two different RRsets exist - at the same owner name, class and type. NO records does not have - this problem. - -4.5 Zone size (Bytes) - - The size difference is due to changing complete domain names with - hash values (SHA1 20 bytes). Without truncation, NO records are - probably larger than most NXT records. With truncation, NO records - uses a few byte per hash value instead of the (possibly compressed) - complete owner name. - -4.6 Zone size (Number Of Records) - - When NO compression is not used, NXT and NO uses the same number of - records. - - - -Josefsson Expires May 25, 2001 [Page 13] - -Internet-Draft The NO Record November 2000 - - - However, NO compression can greatly reduce the number of records. - As an example, considering a zone with records of 100.000 different - names. NXT uses 200.000 records (NXT+SIG). Using NO compression - with 10 hash values on each reduce this number to 20.000 records - (NO+SIG). - -4.7 Zone size (Number Of Owner names) - - NO uses twice the amount of owner names as NXT. - - However, NO compression can be used to reduce this to a fraction of - the normal amount. From the previous example with 10 hash values - per NO record, it will uses 10.000 additional owner names in a zone - with 100.000 names - -4.8 SIG Labels field and Wildcard records - - It is marginally faster to verify signatures for NXT records when - wildcard records are involved -- the SIG "Label fields" hints can be - used to determine the canonical name. With NO records this hint - cannot be used, because it relies on knowing the full name whereas - only the hash is available. One need to try a few SHA1 hashes to - find the correct canonical name. The number of hashes required to - try depend on the number of labels in the name, and scale linearly. - - N.B. This penalty only apply to wildcard records. - -4.9 Dynamic Updates - - Resigning dynamically updated records is required both with NXT and - NO records. - - However, when NO truncation and compression is used, the additional - penalty of re-hashing might also be required. - - - - - - - - - - - - - - - - - -Josefsson Expires May 25, 2001 [Page 14] - -Internet-Draft The NO Record November 2000 - - -5. Security Considerations - - Chaining through all NO records is still technically possible, - altough it cannot be used to collect names and/or records in the - zone (other than NO records themself). - - The security of NO record hash values is dependent on the security - of the SHA-1 hash functions used. Truncation may affect this, but - the birthday-paradox argument does not apply. One must find a hash - collision given an existing hash value -- not simply find any hash - collision. It is thus reasonably to truncate NO records to half the - hash length used in the signature scheme (this would mean 64 bits in - the RSA/MD5 case). - - It should be pointed out that given this scheme, it is easy to - estimate the number of records within a zone, considering hash - values are supposed to be equally distributed. This can be foiled - by adding any number of bogus records in the zone. - - The authentication of NO records is provided by DNS SIG records, as - specified in RFC 2535. The security considerations of RFC 2535 is - not affected by this document, and should also be considered. - -6. IANA Considerations - - The NO RR type number should be selected by the IANA from the normal - RR type space. - - The meaning of a zero hash length value can only be assigned by a - standards action. - -Acknowledgement - - The idea of encrypting names, that later evolved into just hashing - them, was originally proposed by Jonas Holmerin in private - discussions about DNS Security. Magnus Nystr÷m proposed truncating - the hash values. - - Thanks to John Linn and Magnus Nystr÷m for comments on a early - version of this draft. - - Olafur Gudmundsson pointed out delegation point issues, suggested - the use of a "_no" subdomain, and suggested replacing the type bit - map field with a sorted list. From the namedroppers mailing list, - I'd like to thank Alan Barrett, Andrew Draper, Andreas Gustafsson, - Peter Koch and Brian Wellington for comments and suggestions. Ed - Lewis noted that truncation to shortest unique prefix would not work. - - - - -Josefsson Expires May 25, 2001 [Page 15] - -Internet-Draft The NO Record November 2000 - - -References - - [1] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [2] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the - Domain Name System (DNS)", RFC 2538, March 1999. - - [3] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC - 2606, June 1999. - - [4] NIST, , "Secure Hash Standard", FIPS PUB 180-1, April 1995. - - [5] Massey, D., Lehman, T. and E. Lewis, "DNSSEC Implementation in - the CAIRN Testbed.", I.D. draft-ietf-dnsop-dnsseccairn-00.txt, - October 1999. - - [6] Josefsson, S.A. (editor), "Base 64, 32 and 16 Encodings", I.D. - draft-josefsson-base-encoding-00.txt, August 2000. - - [7] Wellington, B, "Domain Name System Security (DNSSEC) Signing - Authority", I.D. draft-ietf-dnsext-signing-auth-01.txt, May - 2000. - - -Author's Address - - Simon Josefsson - RSA Security - Arenav„gen 29 - Stockholm 121 29 - Sweden - - Phone: +46 8 7250914 - EMail: sjosefsson@rsasecurity.com - - - - - - - - - - - - - - - - -Josefsson Expires May 25, 2001 [Page 16] - -Internet-Draft The NO Record November 2000 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING - BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION - HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF - MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Acknowledgement - - Funding for the RFC editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Josefsson Expires May 25, 2001 [Page 17] - - diff --git a/doc/draft/draft-ietf-dnsext-not-existing-rr-02.txt b/doc/draft/draft-ietf-dnsext-not-existing-rr-02.txt new file mode 100644 index 0000000000..a0d2809498 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-not-existing-rr-02.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +S. Josefsson: sjosefsson@rsasecurity.com + + diff --git a/doc/draft/draft-ietf-dnsop-parent-sig-00.txt b/doc/draft/draft-ietf-dnsop-parent-sig-00.txt deleted file mode 100644 index a776183533..0000000000 --- a/doc/draft/draft-ietf-dnsop-parent-sig-00.txt +++ /dev/null @@ -1,211 +0,0 @@ - Parent's SIG over child's KEY - draft-ietf-dnsop-parent-sig-00.txt - - Miek Gieben, Ted Lindgreen - - -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 - 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 - - When dealing with large amounts of keys the procedures to update a zone and - to sign a zone need to be clearly defined and practically possible. - The current idea is to have the KEY RR and the parent's SIG to reside in the - child's zone and perhaps also in the parent's zone. We feel that this would - lead to very complicated procedures for large TLD's. We propose a alternative - scheme in which the parent zone stores the parent's signature over the child's - key and also a copy of the child's key itself. - - The advantage of this proposal is that all signatures signed by a key are in - the same zone file as the producing key. This allows for a simple key - rollover and resigning mechanism. For large TLD's this is extremely important. - - We further discuss the impact on a secure aware resolver/forwarder. - - -Table of Contents - - Status of This Document.................................... - Abstract................................................... - - Table of Contents.......................................... - 1 Introduction............................................. - 2 Proposal................................................. - 3 Impact on a secure aware resolver/forwarder.............. - 3.1 Impact of key rollovers on resolver/forwarder.......... - 4 Key rollovers............................................ - 4.1 Scheduled key rollover................................. - 4.2 Unscheduled key rollover............................... - 5 Zone resiging............................................ - - - References................................................ - - Authors' Addresses........................................ - References................................................ - - -1. Introduction - Within a CENTR working group NLnet Labs is researching the impact of - DNSSEC on the ccTLDs and gTLDs. - - In this document we are considering a secure zone, somewhere under a secure - entry point and on-tree [1] validation between the secure entry point and the - zone in question. The resolver we are considering is security aware and is - preconfigured with the KEY of the secure entry point. - - RFC 2535 [2] states that a zone key must be present in the apex of a zone. - This can be in the at the delegation point in the parent's zonefile - (normally the case for null keys), or in the child's zonefile, or in both. - This key is only valid if it is signed by the parent, so there is also the - question where this signature is located. - - The original idea was to have the KEY RR and the parent's SIG to reside - in the child's zone and perhaps also in the parent's zone. There is a - draft proposal [3], that describes how a keyrollover can be handled. - - At NLnet Labs we found that storing the parent's signature over the - child's key in the child's zone: - - makes resigning a KEY by the parent difficult - - makes a scheduled keyrollover very complicated - - makes an unscheduled keyrollover virtually impossible - - We propose an alternative scheme in which the parent's signature over the - child's key is only stored in the parent's zone, i.e. where the signing key - resides. This would solve the above problems. - - -2. Proposal - The core of the new proposal is that the parent zone stores the parent's - signature over the child's key and also a copy of the child's key itself. - The child zone also contains its zonekey, where it is selfsigned. - - The advantage of this proposal is that all signatures signed by a key are in - the same zone file as the producing key. This allows for a simple key - rollover and resigning mechanism. For large TLD's this is extremely important. - - A disadvantage would be that not all the information concerning one zone is - stored at that zone, namely the (parent) SIG RR. Note that the same argument - can be applied to a zone's NULL key, which is also stored at the parent. - - -3. Impact on a secure aware resolver/forwarder - The resolver must be aware of the fact that the parent is more authoritative - than a child when it comes to deciding whether a zone is secured or not. - - Without caching and with on-tree validation, a resolver will always start - its search at a secure entry point. In this way it can determine whether it - must expect SIG records or not. - - Considering caching in a secure aware resolver or forwarder. If information - of a secure zone is cached, its validated KEY should also be cached. - - If the KEY record expires, because the KEY TTL expires or because the SIG is - no longer valid, the KEY should be discarded. The resolver or forwarder - should then also discard other data concerning the zone because it is no - longer validated and possible bad data should not be cached. - -3.1. Impact of key rollovers on resolver/forwarder - When a zone is in the process of a key rollover, there could be a discrepancy - between the KEY and the SIG in the apex of the zone and the KEY and SIG that - are stored in the cache of a resolver. - - Suppose a resolver has cached the NS, KEY and SIG records of a zone. Next a - request comes for an A record in that zone. Also the zone is in the process - of a keyrollover and already has new keys in its zone. The resolver receives - an answer consisting of the A record and a SIG over the A record. It uses - the tag field in the SIG to determine if it has a KEY which is suitable to - validate the SIG. If it does not has such a KEY the resolver must ask the - parent of the zone for a new KEY and then try it again. Now the resolver - has 2 keys for the zone, according to the tag field in the SIG it can use - either one. - - If the new key also does not validate the SIG the zone is marked bad. If the - KEY found at the parent is the NULL key the resolver knows that the child is - considered insecure. This could for instance be in the case the private key - of the zone is stolen. - -4. Key rollovers - Private keys can be stolen or a key can become over used. In both - cases a new a new key must be signed and distributed. This event is - called keyrollover. We further distinguish between a scheduled and an - unscheduled key rollover. A scheduled rollover is announced before hand. - An unscheduled key rollover is needed when a private key is compromised. - -4.1. Scheduled key rollover - When the signatures, produced by the key to be rolled over, are all - in one zone file, there are two parties involved. Let us look at an - example where a TLD rolls over its zone key. The new key needs to be - signed with the root's key before it can be used to sign the TLD zone - and the zone keys of the TLD's children. The steps that need to be taken - by TLD and root are: - - the TLD adds the new key to its keyset in its zonefile. This - zone and keyset are signed with the old zonekey - - then the TLD signals the parent - - the root copies the new keyset, consisting of the both new - and the old key, in its zonefile, resigns it and signals the TLD - - the TLD removes the old key from its keyset, resigns its zone - with the new key, and signals the the root - - the root copies the new keyset, now consisting of the new key - only, and resigns it - -4.2. Unscheduled key rollover - Although nobody hopes that this will ever happen, we must be able to - cope with possible key compromises. When such an event occurs, an - immediate keyrollover is needed and must be completed in the shortest - possible time. With two parties involved, it will still be awkward, but - not impossible to update two zonefiles overnight. "Out-of-band" - communication between the two parties will be necessary, since the - compromised old key can not be trusted. We think that between two - parties this is doable, but this complicated procedure is beyond the - scope of this document. [4] - -5. Zone resigning - Resigning a TLD is necessary before the current signatures expire. - When all SIG records, produced by the TLD's zone key are kept in the - TLD's zonefile, and only there, such a resign session is trivial, as - only one party (the TLD) and one zonefile is involved. - - -Authors' Addresses - - R. Gieben - Stichting NLnet Labs - Kruislaan 419 - 1098 VA Amsterdam - miek@nlnetlabs.nl - - T. Lindgreen - Stichting NLnet Labs - Kruislaan 419 - 1098 VA Amsterdam - ted@nlnetlabs.nl - -References - - [1] Lewis, E. "DNS Security Extension Clarification on Zone Status", - http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-04.txt - [2] Eastlake, D. "DNS Security Extensions", RFC 2535 - http://www.ietf.org/rfc/rfc2535.txt?number=2535 - [3] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security Key Rollover" - http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt - [4] Gieben, R. "Chain of trust" - http://secnl.nlnetlabs.nl/thesis/thesis.html diff --git a/doc/draft/draft-ietf-dnsop-parent-sig-01.txt b/doc/draft/draft-ietf-dnsop-parent-sig-01.txt new file mode 100644 index 0000000000..7056cac3b5 --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-parent-sig-01.txt @@ -0,0 +1,21 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +M. Gieben: miek@nlnetlabs.nl +T. Lindgreen: ted@nlnetlabs.nl +R. Gieben: miek@nlnetlabs.nl + + diff --git a/doc/draft/draft-ietf-enum-e164-gstn-np-01.txt b/doc/draft/draft-ietf-enum-e164-gstn-np-02.txt similarity index 94% rename from doc/draft/draft-ietf-enum-e164-gstn-np-01.txt rename to doc/draft/draft-ietf-enum-e164-gstn-np-02.txt index b976270b8b..46fc05fa80 100644 --- a/doc/draft/draft-ietf-enum-e164-gstn-np-01.txt +++ b/doc/draft/draft-ietf-enum-e164-gstn-np-02.txt @@ -2,9 +2,9 @@ Mark Foster Internet Draft Tom McGarry -Document: James Yu +Document: James Yu NeuStar, Inc. -Category: Informational February 9, 2001 +Category: Informational October 19, 2001 Number Portability in the GSTN: An Overview @@ -56,9 +56,9 @@ Status of this Memo the later to the former. In addition, there are various regulatory - Informational - Expiration in August 9, 2001 [1] + Informational - Expiration in April 19, 2002 1 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 constraints that establish relevant parameters for NP @@ -115,9 +115,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address. NP - Informational - Expiration in August 9, 2001 2 + Informational - Expiration in April 19, 2002 2 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 implementations attempt to encapsulate the impacts to the GSTN and @@ -153,7 +153,7 @@ Number Portability in the GSTN: An Overview February 9, 2000 constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony work-in-progress at IETF. - + This document describes three types of number portability and the four schemes that have been standardized to support SPNP for geographic E.164 numbersspecifically. Following that, specific @@ -174,9 +174,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 - Informational - Expiration in August 9, 2001 3 + Informational - Expiration in April 19, 2002 3 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 3. Abbreviations and Acronyms @@ -233,9 +233,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 PCS Personal Communication Services PNTI Ported Number Translation Indicator - Informational - Expiration in August 9, 2001 4 + Informational - Expiration in April 19, 2002 4 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 PODP Public Office Dialing Plan @@ -292,9 +292,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 old telephone service to Integrated Services Digital Network (ISDN) services) while keeping the same phone number is called service - Informational - Expiration in August 9, 2001 5 + Informational - Expiration in April 19, 2002 5 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 portability. Another aspect of service portability is to allow the @@ -351,9 +351,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 below on number pooling, as this enhancement to NP further - Informational - Expiration in August 9, 2001 6 + Informational - Expiration in April 19, 2002 6 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 bifurcates the role of donor network into two (the number range or @@ -410,9 +410,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 (3) The Originating Network uses the routing number to route the call to the new serving network. - Informational - Expiration in August 9, 2001 7 + Informational - Expiration in April 19, 2002 7 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 @@ -469,9 +469,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 number. - Informational - Expiration in August 9, 2001 8 + Informational - Expiration in April 19, 2002 8 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 (5) The Originating Network uses the routing number to route the @@ -528,9 +528,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 Figure 4 - Onward Routing (OR) Scheme. - Informational - Expiration in August 9, 2001 9 + Informational - Expiration in April 19, 2002 9 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 @@ -587,9 +587,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 Similarly, in other national E.164 numbering plans, number ranges cover a contiguous range of numbers within that range. Once a - Informational - Expiration in August 9, 2001 10 + Informational - Expiration in April 19, 2002 10 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 number within that range has ported away from the donor network, all @@ -646,9 +646,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 of the protocol stack that includes the ANSI MTP Levels 1 - Informational - Expiration in August 9, 2001 11 + Informational - Expiration in April 19, 2002 11 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 through 3, ANSI SCCP, and ANSI TCAP. This interface can be used @@ -705,9 +705,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 One of the following three interfaces can be used to query an NPDB: - Informational - Expiration in August 9, 2001 12 + Informational - Expiration in April 19, 2002 12 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 @@ -764,9 +764,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 for the Dropback scheme). For the ACQ, QoR and Dropback schemes, it is the Originating Network that has the routing information and is - Informational - Expiration in August 9, 2001 13 + Informational - Expiration in April 19, 2002 13 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 ready to route the call. For the OR scheme, it is the donor network @@ -823,9 +823,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 been performed. All the switches in the downstream will not perform the NPDB query if the PNTI bit is set. - Informational - Expiration in August 9, 2001 14 + Informational - Expiration in April 19, 2002 14 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 @@ -882,9 +882,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 In addition to the addition of the routing prefix to the CdPN parameter, some other information may be added/modified as is listed - Informational - Expiration in August 9, 2001 15 + Informational - Expiration in April 19, 2002 15 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 in the draft ITU-T Recommendation Q.769.1 [ISUP]. Those @@ -941,9 +941,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 concatenated with the DN in the CdPN parameter. - Informational - Expiration in August 9, 2001 16 + Informational - Expiration in April 19, 2002 16 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 If MNP-SRF is supported, the Gateway Mobile Services Switching @@ -1000,9 +1000,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 + + on-switch solution. + +-------------+----------------------------------------------------+ - Informational - Expiration in August 9, 2001 17 + Informational - Expiration in April 19, 2002 17 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 + Austria + Uses onward routing at the donor network. Routing + @@ -1059,9 +1059,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 + + where "xxxxx" identifies the recipient switch. + - Informational - Expiration in August 9, 2001 18 + Informational - Expiration in April 19, 2002 18 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 + + Telecom Italia uses IN solution and other operators+ @@ -1118,9 +1118,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 - Informational - Expiration in August 9, 2001 19 + Informational - Expiration in April 19, 2002 19 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 9. Number Conservation Methods Enabled by NP @@ -1177,9 +1177,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 assigns individual telephone numbers to operators. Using the North - Informational - Expiration in August 9, 2001 20 + Informational - Expiration in April 19, 2002 20 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 American example, one block of 10,000 TNs can be divided into 10,000 @@ -1236,9 +1236,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 - Informational - Expiration in August 9, 2001 21 + Informational - Expiration in April 19, 2002 21 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 IP-based networks can handle the domestic calls between two GSTNs. @@ -1259,7 +1259,7 @@ Number Portability in the GSTN: An Overview February 9, 2000 dip indicator may not be present because there are cases where routing number is added for routing the call even if NP is not involved. One issue is how to transport the NP related information - via SIP. The SIP Universal Resource Locator (URL) is one mechanism. + via SIP. The SIP Uniform Resource Locator (URL) is one mechanism. Another better choice may be to add an extension to the "tel" URL [TEL] that is also supported by SIP. If the called directory is +1- 202-533-1234, and its associated routing number is +1-202-544-0000, @@ -1285,7 +1285,7 @@ Number Portability in the GSTN: An Overview February 9, 2000 present in the "tel" URL in the SIP INVITE message, it instead of the called directory number should be used for making routing decisions. If "rn" is not present, then the dialed directory number - can be used as the routing number for making routing decisions. + can be used as the routing number for making routing decisions. Telephony Routing Information Protocol (TRIP) [TRIP] is a policy driven inter-administrative domain protocol for advertising the @@ -1295,9 +1295,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 routing number, if present, not the called directory number that - Informational - Expiration in August 9, 2001 22 + Informational - Expiration in April 19, 2002 22 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 should be used to check against the TRIP tables for making the @@ -1315,7 +1315,7 @@ Number Portability in the GSTN: An Overview February 9, 2000 does not handle the overlap signaling and collect the complete called directory number. - The IETF enum working group is defining the use of Domain Name + The IETF enum working group has defined the use of Domain Name System (DNS) for identifying available services associated with a particular E.164 number [ENUM]. [ENUMPO] outlines the principles for the operation of a telephone number service that resolves @@ -1351,19 +1351,19 @@ Number Portability in the GSTN: An Overview February 9, 2000 be to assign a special routing number so that the call to an end user currently served by an IP entity is routed to the nearest GSTN gateway. The called directory number then is used to locate the IP- - entity that serves that dialed directory number. Then a mechanism - is developed for the IP-based network to locate the IP entity that + entity that serves that dialed directory number. Then some + mechanisms are needed for the IP-based network to locate the IP - Informational - Expiration in August 9, 2001 23 + Informational - Expiration in April 19, 2002 23 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 - serves a particular dialed directory number. Many other types of - networks use E.164 numbers to identify the end users or terminals in - those networks. Number portability among GSTN, IP-based network and - those various types of networks may also need to be supported in the - future. + entity that serves a particular dialed directory number. ENUM can + be one of the mechanisms. Many other types of networks use E.164 + numbers to identify the end users or terminals in those networks. + Number portability among GSTN, IP-based network and those various + types of networks may also need to be supported in the future. 11. References @@ -1390,12 +1390,12 @@ Number Portability in the GSTN: An Overview February 9, 2000 [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916. [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific - Provisioning: Principles of Operations," April 27, 2000. + Provisioning: Principles of Operations," draft-ietf-enum- + operation-02.txt, February 23, 2001. [GSM] GSM 09.02: "Digital cellular telecommunications system (Phase 2+); Mobile Application Part (MAP) specification". - - + [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for Wireless Number Portability Phase II (December 1998)"Number Portability Network Support," April 1998. @@ -1413,9 +1413,9 @@ Number Portability in the GSTN: An Overview February 9, 2000 - Informational - Expiration in August 9, 2001 24 + Informational - Expiration in April 19, 2002 24 -Number Portability in the GSTN: An Overview February 9, 2000 +Number Portability in the GSTN: An Overview October 19, 2001 [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- @@ -1424,16 +1424,15 @@ Number Portability in the GSTN: An Overview February 9, 2000 [TEL] A. Vaha-Sipila, RFC2806, "URLs for Telephone Calls," April 2000. - [TELNP] J. Yu, draft-yu-tel-url-02.txt, "Extensions to the "tel" and + [TELNP] J. Yu, draft-yu-tel-url-03.txt, "Extensions to the "tel" and "fax" URLs to support Number Portability and Freephone - Service," February 9, 2001. + Service," November 1, 2001. [SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, RFC 2543, "SIP: Session Initiation Protocl," March 1999. - [TRIP] J. Rosenberg, H. Salama and M. Squire, draft-ietf-iptel-trip- - 02.txt, "Telephony Routing Information Protocol (TRIP)," May - 2000. + [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC XXX, "Telephony + Routing Information Protocol (TRIP)," September 2001. 12. Acknowledgments @@ -1471,13 +1470,13 @@ Number Portability in the GSTN: An Overview February 9, 2000 NeuStar, Inc. 1120 Vermont Avenue, NW, Suite 550 - - Informational - Expiration in August 9, 2001 25 - -Number Portability in the GSTN: An Overview February 9, 2000 - - Washington, D.C. 20005 + + Informational - Expiration in April 19, 2002 25 + +Number Portability in the GSTN: An Overview October 19, 2001 + + United States Phone: +1-202-533-2814 @@ -1530,8 +1529,9 @@ Full Copyright Statement + - Informational - Expiration in August 9, 2001 26 - + Informational - Expiration in April 19, 2002 26 + \ No newline at end of file diff --git a/doc/draft/draft-ietf-enum-operation-02.txt b/doc/draft/draft-ietf-enum-operation-02.txt deleted file mode 100644 index f47c68f1c0..0000000000 --- a/doc/draft/draft-ietf-enum-operation-02.txt +++ /dev/null @@ -1,945 +0,0 @@ - - -Telephone Number Mapping A. Brown -Internet Draft Nortel Networks -Document: Greg Vaudreuil - Lucent Technologies - February 23, 2001 - - - ENUM Service Reference Model - - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026 [1]. - - 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. Abstract - - This document outlines the principles for the operation of a - telephone number directory service. This service provides for the - resolution of telephone numbers into Internet domain name addresses - and service specific directory discovery. - - - - - - - - - - - - - - - - - - - - - - -Brown, Vaudreuil Expires August 2001 1 - ENUM Reference Model February 23, 2001 - - - Table of Contents - - 1. Abstract........................................................1 - 2. Introduction....................................................2 - 3. Scope...........................................................2 - 4. Overview........................................................4 - - 4.1 Relationship with Dynamic Services.............................4 - 4.2 Number Portability.............................................5 - 5. The ENUM Service................................................5 - 5.1 First Tier: Determining the Service Registrar..................5 - 5.2 Second Tier: Retrieving Resource records.......................6 - 5.3 Third Tier: Service-Specific Queries...........................6 - 6. Interesting Numbering Topologies...............................8 - 6.1 Sub-addressing.................................................8 - - 6.2 Default and Range-based Service Records........................9 - 6.3 Permissive dialing for dialing plan transitions...............9 - 7 Illustrative System Examples....................................10 - 7.1 Example: Hypothetical Reachme Service.........................10 - 7.2 Example: SIP Call Setup Service Request.......................11 - 8. Security Considerations........................................12 - 9. References.....................................................13 - - 10. Acknowledgments...............................................13 - 11. Author's Addresses............................................13 - 12. Full Copyright Statement......................................14 - Appendix:.........................................................15 - Changes from draft-ietf-enum-operations-00.txt....................15 - Changes from draft-ietf-enum-operations-01.txt....................15 - - -2. Introduction - - This document outlines the principles for the operation of a - telephone number directory service. This service provides for the - resolution of telephone numbers into the address of a service - specific directory or where applicable for a given service, directly - into a service-specific endpoint addresses. - - This directory service uses the algorithms and methods described in - RFC 2916. - - Please send comments on this document to the ENUM working group. - -3. Scope - - This document defines the reference architecture behind the ENUM - protocols necessary to implement a telephone number-based Internet - directory system. This solution enables an extensible set of - services to be provided for a given telephone number. Example - services may include IP telephony, store and forward or real-time - Internet Fax, VPIM voice messaging, Internet paging, geographic - phone location, and many others. Each service is to be separately - defined and identified using a unique, registered service - identifier. - - - - Brown, Vaudreuil Expires August 2001 2 - ENUM Reference Model February 23, 2001 - - - This document does not specify the particulars of any telephone - number-based service. In particular, it does not describe how phone - calls are placed, routed, or terminated or how voice, fax, pager, or - email messages are routed. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brown, Vaudreuil Expires August 2001 3 - ENUM Reference Model February 23, 2001 - - -4. Overview - - This telephone number-based directory system implements a three-tier - information model; the first two constituting the ENUM service. - This abstract model is based on analysis of pre-existing - administrative structures, generalized service requirements, and the - capabilities of candidate protocols. This model does not itself - specify an administrative model, but provides a reference to guide - implementers or conforming clients and servers. - The mechanics of the ENUM service are specified in [ENUM]. - - The first tier is the mapping of the telephone number delegation - tree to the service registrar. Conceptually, this delegated - authority knows nothing about service-specific information - associated with the telephone number but provides a reference to - the service registrar that does know the specific information. Where - this services registrar is different from the delegated authority, a - query redirection from the delegated authority to the name server of - the service registrar for a given telephone number is necessary. - - - The second tier is the set of service records themselves. The - service records indicate which of several services may be available - for a given telephone number. Multiple records indicating redundant - or competitive service providers may be provided. The set of records - may be provided or modified by any number of service providers. The - ENUM service defines these records to be NAPTR records yielding a - valid URL for a potentially useful service. It is up to the client - initiating the service request to sort through the set of NAPTR - records to determine which services are appropriate for the intended - action. - - The service registrar is conceptually responsible for maintaining - the set of service records for a given telephone number. Because - there may be multiple service providers for a given telephone - number, conceptually this registrar of services assumes a role of - managing service registrations and arbitrating conflicts between - service providers. - - If necessary, an additional service-specific tier of information can - be provided by the service provider itself. This tier provides - specific attributes including any necessary attributes to place a - call, route a message, validate capabilities, or other data - necessary for that service that are known only by the provider of - that specific service. - -4.1 Relationship with Dynamic Services - - The telephone number delegation information changes infrequently. - However, when a change to this data is made, the information must be - rapidly propagated through the directory system. Inconsistencies - between the authoritative data and cached data may result in loss of - service, misrouting of communications, and/or service loops. An - effective ENUM service requires that DNS time-to-live fields be set - to an appropriate value consistent with the telephone number - reassignment policies and service record update intervals. - - Use of the ENUM system to implement time-of-day and other highly - dynamic services is discouraged. Where such a service is desired, - Brown, Vaudreuil Expires August 2001 4 - ENUM Reference Model February 23, 2001 - - - it is recommended that itself be implemented as part of a service - indicated by the service records. - -4.2 Number Portability - - The concept of number portability generally refers to the ability of - a subscriber to change service providers, service types, or - locations without changing their telephone number. For a full - discussion of number portability, see [PORT]. In support of number - portability, the ENUM service provides mechanism at the three - conceptual tiers of the ENUM service. - - 1. If the telephone number has been re-delegated to another - authority, and that authority also provides the Tier-1 ENUM - service, the telephone number can be re-delegated in the ENUM - service by changing the name server "NS" records to point to the - new authority. This may be the case where numbers are re- - delegated from the incumbent service provider to another or to a - portability authority. The immediately higher delegated authority - coordinates the transfer. - - 2. The service registrar may be reassigned. This may be the case - where an individual or corporation changes telephony service - providers and wishes that telephony service provider to also - provide service registrar functions. The new service registrar - would recreate the appropriate service specific NAPTR records and - the delegated authority would coordinate the transfer from one - registrar to the other. - - 3. If a specific service for a given telephone number was changed - from one provider to another, such as switching telephone - answering / voice messaging providers, the NATPR record indicating - the specific service would change. The service registrar would - coordinate the deletion of the record for the previous service - provider and the insertion of a record for the new service - provider. - - It is anticipated that in the early stages of an ENUM deployment, - the delegated authority and the service registrar may be the same - entity. - -5. The ENUM Service - -5.1 First Tier: Determining the Service Registrar - - The first tier is the mapping of an E.164-formatted international - telecommunication number into the identity of the service registrar - for that number. This may or may not involve more than one referral - in DNS. - - The delegation of telephone numbers from the root authority (the - ITU) down to individuals is a well-established system. While there - are differing Tier-1 administrative models, to a client they each - aim to represent in a single tree the trusted relationship between - the delegated carriers and subsidiary registrars; a necessary - precondition to ensure protection against various attacks. The - delegated authority, sub-delegated authority, or individual may - arrange to have a third-party (e.g., a service provider) list their - - Brown, Vaudreuil Expires August 2001 5 - ENUM Reference Model February 23, 2001 - - - information. In this case the service provider's domain would be - returned in the ENUM query. - - The Internet Domain Name System provides an ideal technology for the - first-tier directory due to its hierarchical structure, fast - connectionless queries, and distributed administrative model. - Earlier experimentation with the TPC.INT remote printing experiment - has shown how the hierarchical assignment of telephone numbers can - be mapped directly to the hierarchy of domains within the DNS. The - ENUM directory uses that approach to map any arbitrary telephone - number into a single domain name. - - ITU standard E.164 defines the structure of the public telephone - number as follows: country code, followed by nationally significant - part, followed by sub-address. The country code may be from one to - three digits, and the total length may be up to 15 digits. The - nationally significant portion may be arbitrarily divided on any - number boundary. In many countries numbering plans, the divisions - are not uniform, that is, the "area codes" or "city codes" may be of - varying lengths within a single country and the total number of - digits may be variable. Where supported by the relevant service, an - optional sub-address of up to four digits may be utilized to - designate an extension telephone number. Note that while sub- - addressing is not well supported in GSTN calling, it is more widely - supported for voice messaging. It is important to note that the - national long-distance access or international dialing prefix - sequence is not part of the canonical E.164 number. - - Within this delegation flexibility, it is always the case that the - delegation of authority is always done left-to-right. With this - assumption, a numbering tree can be built on a digit-by-digit basis - that can represent any arbitrary hierarchical structure. DNS - permits the delegation of authority on arbitrary boundaries such - that a delegation to country code "1", "44", and "972" can all - coexist under a single numbering plan root. The same applies for - "service selectors", "area codes", "city codes", "line number", or - "additional address information " within numbering plans. - -5.2 Second Tier: Retrieving Resource records. - - The second tier is the request for NAPTR RRs to discover the URL of - the appropriate service-specific directory such as an LDAP directory - server, H.323 gatekeeper, or specific endpoint addresses. - - The service registrar is responsible for ensuring that multiple - services may be provided on behalf of a single telephone number, - potentially by different service providers. This function includes - an arbiter function to ensure that there is a deterministic instance - of any given service assigned to a single telephone number. The - service-specific directory locator function is a new service modeled - upon existing telco service provisioning models. Long-distance - carrier selection within the United States is one well-known example - of a service-specific registration requiring an arbiter function - within the current network. - -5.3 Third Tier: Service-Specific Queries - - An additional tier of query may be used to a service-specific - directory for service-specific information. As indicated in the - Brown, Vaudreuil Expires August 2001 6 - ENUM Reference Model February 23, 2001 - - - URI, such a query may include a SIP query to a designated gatekeeper - or an LDAP query to a designated directory server. This tier is - specific to the service and is to be described in service-specific - documents. The service-specific directory is expected to be - dynamic. It is important that as little coordination as possible be - required between the directories of innovative and potentially - competing service-specific providers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brown, Vaudreuil Expires August 2001 7 - ENUM Reference Model February 23, 2001 - - -6. Interesting Numbering Topologies - - The following numbering uses require special consideration in the - provision and use of ENUM services. - -6.1 Sub-addressing - - The E.164 standard provides for sub-addressing through "additional - information" within the 16 digits of an E.164 number. This - information is passed through many telecommunications networks to be - used by terminal equipment to select between alternate services or - terminal devices. The sub-address digits are not processed by the - switching system and are not used by intermediate processes to - select services or route calls. In many cases, the network- - numbering infrastructure may be unaware of the existence or use of - sub-addressing by a given endpoint. Within ENUM, sub-addressing may - be supported in two ways. The service registrar may explicitly - provision NAPTR records for each sub-address, or the service - registrar may provision default records for a range of sub- - addresses. - - Using common DNS server implementations, the registrar may provision - default records for a block of sub-addresses. A combination of - explicit entries and default entries may be provided in common DNS - server implementations using a longest-match algorithm. It is - important to note that if a NAPTR or any other RR is provisioned for - a sub-address, then all NAPTR records that are useful for that sub- - address must also be provisioned. - - It is also important to note that numbers with optional sub- - addresses may be queried without the sub-address component. For - example, it may be useful to dial an address when placing a PSTN - telephone call. The telephone number may terminate on an automated - attendant application that can prompt for the appropriate internal - extension. However, when placing a SIP call using IP telephony, the - address plus the sub-address may be queried. - - The following set of records for company.com illustrate one - configuration where a PSTN caller will be directed to the automated - attendant application whether they dial the number or the number - plus a sub-address, and whether the sub-address is explicitly - provisioned or not. Calling using SIP to the explicitly provisioned - sub-address will result in a direct call to the intended recipient. - - Example: - - 1.2.3.4.5.6.7.8.9.e164.arpa - IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654321!" . - IN NAPTR 10 10 "u" "sip+E2U" "!+(.*)!sip:AA@company.com!" . - - *.1.2.3.4.5.6.7.8.9.e164.arpa - IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654321!" . - IN NAPTR 10 10 "u" "sip+E2U" "!+(.*)!sip:AA@company.com!" . - - 1.0.1.1.2.3.4.5.6.7.8.9.e164.arpa - IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:joe@company.com!" . - IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654321!" . - - - Brown, Vaudreuil Expires August 2001 8 - ENUM Reference Model February 23, 2001 - - -6.2 Default and Range-based Service Records - - It is envisioned that a corporation or service provider not subject - to number portability may wish to maintain a set of default NAPTR - records for all E.164 telephone numbers within a delegation block. - Similar to sub-addressing, a service registrar may provision a set - of NAPTR records for a set of E.164 numbers with similar service - requirements. - - Example: - - *.3.4.5.6.7.8.9.164.arpa - IN NAPTR 102 10 "u" "tel+E2U" "!+(.*)!Tel:+\1" . - IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:AA@company.com!" . - IN NAPTR 10 10 "U" "mailto+E2U" \ - "!+(.*)!mailto:+\1@company.com!" . - - 1.0.3.4.5.6.7.8.9.164.arpa - IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654310!" . - IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:AA@company.com!" . - - 2.2.3.4.5.6.7.8.9.164.arpa - IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654322!" . - IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:joe@company.com!" . - IN NAPTR 10 10 "U" "mailto+E2U" \ - "!^.*$!tel:+987654322@company.com!" . - - In this example, mail sent to the phone number +987654311 using - 1.1.3.4.5.6.7.8.9.164.arpa will be sent to +987654311@company.com. - Mail is explicitly not accepted at the automated attendant number as - indicted by the lack of a mailto service record. Because extension - 22 has an explicit NAPTR record for inbound calls via the tel - record, it must also have an explicit mailto: URL in a NAPTR record. - -6.3 Permissive dialing for dialing plan transitions - - In the real-world environment, the telephone number hierarchy is - modified as necessary to prevent number exhaustion and to facilitate - new services. These re-numberings either insert additional digits - at arbitrary parts of the previous telephone number or result in the - re-assignment of a sub-tree of numbers to a new prefix. To avoid - the operational and social disruption involved with a _flash cut_, a - practice of _permissive dialing_ has been created. Permissive - dialing enables and end-user to use either the previous or new - telephone number for a period of time. During this time, there may - be two different telephone numbers pointing to the same set of - service records, or a duplicate set of service records for the new - and previous number. - - - - - - - - - - - - Brown, Vaudreuil Expires August 2001 9 - ENUM Reference Model February 23, 2001 - - -7 Illustrative System Examples - -7.1 Example: Hypothetical Reachme Service - - The following hypothetical service enables an end-user to discover - the various means by which she can reach a recipient represented by - their corporate telephone number +1 613-555-1212 using the - hypothetical "reachme" service. This service is hosted by directly - by the recipient's corporation. - - The telephone number is transformed into a domain name form to be - used in a DNS query. - - 2.1.2.1.5.5.5.3.1.6.1.e164.arpa - - Sample configuration file for the top tier delegations from ITU: - - 1.e164.arpa. IN NS ns.NANP.phone.net. ;for NANP - 3.3.e164.arpa. IN NS ns.FR.phone.net. ; for France - 2.7.9.e164.arpa. IN NS ns.il.phone.net. ; for Israel - - Sample configuration file for numbers delegated from the NANP node - in the DNS tree: - - 5.5.5.3.1.6.1.e164.arpa. IN NS ns.Zcorporation.com. - ;for +1 613 555 XXXX - Zcorporation is the designated service registrar for the block of - 100 numbers +1 613 555 12XX. Zcorporation provides the following - service specific record for all telephone numbers within it's 100 - number block: - - *.2.1.5.5.5.3.1.6.1.e164.arpa. - IN NAPTR 100 10 "u" "ldap+E2U"\ - "$!ldap://ldap1.Zcorporation.com/cn=\1!" . - - Assuming the resolver is using non-extended DNS, the query using - telephone number +1 613 555 1212 for the_reachme service is as - follows: - - QueryType: NAPTR - QueryName: _ 2.1.2.1.5.5.5.3.1.6.1.e164.arpa. - Response: - IN NAPTR 10 10 "u" "Reachme+E2U" \ - "!LDAP:\\ldap1.zcorporation.com\cn=\1!" . - - The client can then apply the regular expression to yield an LDAP - URI of LDAP:\\ldap1.zcorporation.com\cn=16135551212 and then use - LDAP with the reachme schema to determine the set of communications - technologies available for +1 613 555 1212. - - - - - - - - - - - Brown, Vaudreuil Expires August 2001 10 - ENUM Reference Model February 23, 2001 - - -7.2 Example: SIP Call Setup Service Request - - This example provides resolution of a telephone number to the - identifier for the SIP gatekeeper designated to support real-time - calling (Sipphonecall) to 972 555 1313. The telephone number is - part of a block of ported telephone numbers that have been ported - out of the donor carriers block to another carrier. - - The telephone number is transformed into a domain name form to be - used in a DNS query. - - Sample configuration file for the top tier delegations from ITU: - - 1.e164.arpa. IN NS ns.NANP.phone.net. ;for NANP - 3.3.e164.arpa. IN NS ns.FR.phone.net. ; for France - 2.7.9.e164.arpa. IN NS ns.il.phone.net. ; for Israel - - Sample DNS configuration file for the ported number block serviced - by the 972 555 number portability authority delegated from the NANP - node in the DNS tree: - - 5.5.5.2.7.9.1.e164.arpa. IN NS ns.972555Port.NANP.phone.net. - ;for 972 555 - - The number portability authority manages the delegation on a per- - telephone number basis. Logically, the ns.972555Port.NANP.phone.net - has the following record for the telephone number. - - 3.1.3.1.5.5.5.2.7.9.1.e164.arpa. IN NS ns.ServiceProviderB.net. - ;for 972 555 1313 - - ServiceProviderB provides service registrar functions directly for - the telephone number. The following configuration entry is provided - for +1 972 555 1313. - - - 3.1.3.1.5.5.2.7.9.1.ServiceProviderB.net. - IN NAPTR 10 10 "u" "sip+E2U"\ - "!^.*$!sip:19725551313@ServiceProviderB.net!" . - The DNS Query and response using telephone number +1 972 555 1313: - - QueryType: NAPTR - QueryName: 3.1.3.1.5.5.5.2.7.9.1.e164.arpa - Result: - IN NAPTR 10 10 "u" "sip+E2U" \ - "!^.*$!sip:19725551313@ServiceProviderB.net!" . - - The client can now use the SIP protocols to contact the SIP gateway - to initiate a phone call. - - - - - - - - - - - Brown, Vaudreuil Expires August 2001 11 - ENUM Reference Model February 23, 2001 - - -8. Security Considerations - - The following are known security issues taken into consideration in - the definition of this directory service. - - 1. Service provider customer information is very sensitive, - especially in this time of local phone competition. Service - providers require the maximum flexibility to protect this data. - - 2. Registration of a domain name for the telephone numbers - delegated to another carrier may result in messages being - misdirected to the wrong carrier. As subdelegations are - implemented, the risk that phone numbers delegated to one - enterprise may be incorrectly pointed at another will increase. - - 3. Service providers operate in a regulated environment where - certain information about subscribers must not be disclosed. - Telephony services and Voice Messaging are subject to caller-ID - blocking restrictions, restrictions normally enforced in the - telephony network. No such protection is available on the - Internet. The protection of this data is essential, but is up - to the individual service providers to not disclose this - information outside of their control. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brown, Vaudreuil Expires August 2001 12 - ENUM Reference Model February 23, 2001 - - -9. References - - [DNS1] Mockapetris, P., "Domain names - implementation and - specification", RFC1035, Nov 1987. - - [DNS2] Mockapetris, P., "Domain names - concepts and facilities", - RFC 1034, Nov 1987. - - [SRV] Arnt Gulbrandsen, Paul Vixie, Levon Esibov, "A DNS RR for - specifying the location of services (DNS SRV)", Work in Progress - - [E164] ITU, "CCITT Recommendation E.164 (1991), Telephone Network - and ISDN Operation, Numbering, Routing and Mobile Service - - Numbering Plan for the ISDN Era." - - [TPC1] Malamud, Carl, Rose, Marshall, "Principles of Operation for - the TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC - 1530, October 1993. - - [VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet - Mail, Version 2", RFC 2421, September 1998. - - [SRV] Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the - location of services (DNS SRV)", RFC 2052, October 1996. - - [REQ] Brown, Anne, "ENUM Requirements", work-in-progress, November - 1999 - - [ENUM] Faltstrom, Patrick, "E.164 number and DNS", RFC 2916, - September 2000. - - [NAPTR] M. Mealling, R. Daniel _The Naming Authority Pointer (NAPTR) - DNS Resource Record_, RFC 2915, September 2000. - - [PORT] M. Foster, T. McGarry, j. Yu, _Number Portability in the - GSTN: An Overview_, Work-in-Progress, July 2000. - -10. Acknowledgments - -11. Author's Addresses - - Anne R. Brown - Nortel Networks - P.O. Box 3511, Station C - Ottawa, ON K1Y 4H7 - Canada - Phone: +1-613-765-5274 - Fax: +1-613-763-2697 - Email: ARBrown@NortelNetworks.com - - Gregory M. Vaudreuil - Lucent Technologies, - Communications Application Group - 17080 Dallas Parkway - Dallas, TX 75248-1905 - United States - Phone/Fax: +1-972-733-2722 - Email: GregV@IEEE.org - - Brown, Vaudreuil Expires August 2001 13 - ENUM Reference Model February 23, 2001 - - - -12. Full Copyright Statement - - "Copyright (C) The Internet Society (2001). 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 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brown, Vaudreuil Expires August 2001 14 - ENUM Reference Model February 23, 2001 - - -Appendix: - -Changes from draft-ietf-enum-operations-00.txt - - o Discussion of interesting numbering topologies was added - - o Retrieval of NAPTR records are now described in a separate step - from the determination of a service registrar. - - o A new example was created to illustrate ENUM using sub-addressing. - -Changes from draft-ietf-enum-operations-01.txt - - O Changed the title to more clearly reflect the intent of the - document. - - o Collapsed Level 1 and 2 into a single tier. Aligned the document - to use the _tier_ terminology. - - o Added missing text for dynamic updates. - - o Reworked the examples to eliminate all references to the - controversial DNAME and CNAME redirection. - - o Generalized descriptions of the administrative model to avoid - exclusion of any particular tier-1 approach. - - o Corrected various errors in the examples. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brown, Vaudreuil Expires August 2001 15 - \ No newline at end of file diff --git a/doc/draft/draft-ietf-enum-operation-03.txt b/doc/draft/draft-ietf-enum-operation-03.txt new file mode 100644 index 0000000000..8a73140bd7 --- /dev/null +++ b/doc/draft/draft-ietf-enum-operation-03.txt @@ -0,0 +1,20 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +G. Vaudreuil: gregv@lucent.com +A. Brown: arbrown@nortel.ca + + diff --git a/doc/draft/draft-ietf-idn-amc-ace-m-00.txt b/doc/draft/draft-ietf-idn-amc-ace-m-00.txt deleted file mode 100644 index a2401e5d8d..0000000000 --- a/doc/draft/draft-ietf-idn-amc-ace-m-00.txt +++ /dev/null @@ -1,1741 +0,0 @@ -INTERNET-DRAFT Adam M. Costello -draft-ietf-idn-amc-ace-m-00.txt 2001-Feb-12 -Expires 2001-Aug-14 - - AMC-ACE-M version 0.1.0 - -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 - - Distribution of this document is unlimited. Please send comments - to the author at amc@cs.berkeley.edu, or to the idn working - group at idn@ops.ietf.org. A non-paginated (and possibly - newer) version of this specification may be available at - http://www.cs.berkeley.edu/~amc/charset/amc-ace-m - -Abstract - - AMC-ACE-M is a reversible map from a sequence of Unicode [UNICODE] - characters to a sequence of letters (A-Z, a-z), digits (0-9), and - hyphen-minus (-), henceforth called LDH characters. Such a map - (called an "ASCII-Compatible Encoding", or ACE) might be useful for - internationalized domain names [IDN], because host name labels are - currently restricted to LDH characters by [RFC952] and [RFC1123]. - - AMC-ACE-M is a cross between BRACE [BRACE00] (which is efficient - but complex) and DUDE [DUDE00] (which is simple and provides case - preservation). AMC-ACE-M is much simpler than BRACE but similarly - efficient, and provides case preservation like DUDE. - - Besides domain names, there might also be other contexts where it is - useful to transform Unicode characters into "safe" (delimiter-free) - ASCII characters. (If other contexts consider hyphen-minus to be - unsafe, a different character could be used to play its role, like - underscore.) - -Contents - - Features - Name - Overview - Base-32 characters - Encoding procedure - Decoding procedure - Signature - Case sensitivity models - Comparison with RACE, BRACE, LACE, and DUDE - Example strings - Security considerations - References - Author - Example implementation - -Features - - Uniqueness: Every Unicode string maps to at most one LDH string. - - Completeness: Every Unicode string maps to an LDH string. - Restrictions on which Unicode strings are allowed, and on length, - may be imposed by higher layers. - - Efficient encoding: The ratio of encoded size to original size is - small for all Unicode strings. This is important in the context - of domain names because [RFC1034] restricts the length of a domain - label to 63 characters. - - Simplicity: The encoding and decoding algorithms are reasonably - simple to implement. The goals of efficiency and simplicity are at - odds; AMC-ACE-M aims at a good balance between them. - - Case-preservation: If the Unicode string has been case-folded prior - to encoding, it is possible to record the case information in the - case of the letters in the encoding, allowing a mixed-case Unicode - string to be recovered if desired, but a case-insensitive comparison - of two encoded strings is equivalent to a case-insensitive - comparison of the Unicode strings. This feature is optional; see - section "Case sensitivity models". - - Readability: The letters A-Z and a-z and the digits 0-9 appearing - in the Unicode string are represented as themselves in the label. - This comes for free because it usually the most efficient encoding - anyway. - -Name - - AMC-ACE-M is a working name that should be changed if it is adopted. - (The M merely indicates that it is the thirteenth ACE devised by - this author. BRACE was the third. D through L did not deliver - enough efficiency to justify their complexity.) Rather than waste - good names on experimental proposals, let's wait until one proposal - is chosen, then assign it a good name. Suggestions (assuming the - primary use is in domain names): - - UniHost - UTF-A ("A" for "ASCII" or "alphanumeric", - but unfortunately UTF-A sounds like UTF-8) - UTF-H ("H" for "host names", - but unfortunately UTF-H sounds like UTF-8) - UTF-D ("D" for "domain names") - NUDE (Normal Unicode Domain Encoding) - -Overview - - AMC-ACE-M maps characters to characters--it does not consume or - produce code points, code units, or bytes, although the algorithm - makes use of code points, and implementations will of course need to - represent the input and output characters somehow, usually as bytes - or other code units. - - Each character in the Unicode string is represented by an - integral number of characters in the encoded string. There is no - intermediate bit string or octet string. - - The encoded string alternates between two modes: literal mode and - base-32 mode. LDH characters in the Unicode string are encoded - literally, except that hyphen-minus is doubled. Non-LDH characters - in the Unicode string are encoded using base-32, in which each - character of the encoded string represents five bits (a "quintet"). - A non-paired hyphen-minus in the encoded string indicates a mode - change. - - In base-32 mode a group of one to five quintets are used to - represent a number, which is added to an offset to yield a - Unicode code point, which in turn represents a Unicode character. - (Surrogates, which are code units used by UTF-16 in pairs to - refer to code points, are not used and not allowed in AMC-ACE-M.) - Similarities between the code points are exploited to make the - encoding more compact. - -Base-32 characters - - "a" = 0 = 0x00 = 00000 "s" = 16 = 0x10 = 10000 - "b" = 1 = 0x01 = 00001 "t" = 17 = 0x11 = 10001 - "c" = 2 = 0x02 = 00010 "u" = 18 = 0x12 = 10010 - "d" = 3 = 0x03 = 00011 "v" = 19 = 0x13 = 10011 - "e" = 4 = 0x04 = 00100 "w" = 20 = 0x14 = 10100 - "f" = 5 = 0x05 = 00101 "x" = 21 = 0x15 = 10101 - "g" = 6 = 0x06 = 00110 "y" = 22 = 0x16 = 10110 - "h" = 7 = 0x07 = 00111 "z" = 23 = 0x17 = 10111 - "i" = 8 = 0x08 = 01000 "2" = 24 = 0x18 = 11000 - "j" = 9 = 0x09 = 01001 "3" = 25 = 0x19 = 11001 - "k" = 10 = 0x0A = 01010 "4" = 26 = 0x1A = 11010 - "m" = 11 = 0x0B = 01011 "5" = 27 = 0x1B = 11011 - "n" = 12 = 0x0C = 01100 "6" = 28 = 0x1C = 11100 - "p" = 13 = 0x0D = 01101 "7" = 29 = 0x1D = 11101 - "q" = 14 = 0x0E = 01110 "8" = 30 = 0x1E = 11110 - "r" = 15 = 0x0F = 01111 "9" = 31 = 0x1F = 11111 - - The digits "0" and "1" and the letters "o" and "l" are not used, to - avoid transcription errors. - - All decoders must recognize both the uppercase and lowercase - forms of the base-32 characters. The case may or may not convey - information, as described in section "Case sensitivity models". - -Encoding procedure - - The encoder first examines the Unicode string and chooses some - parameters. It writes these parameters into the output string, then - proceeds to encode each Unicode character, one at a time. The exact - sequence of steps is given below. All ordering of bits and quintets - is big-endian (most significant first). The >> and << operators - used below mean bit shift, as in C. For >> there is no question of - logical versus arithmetic shift because AMC-ACE-M makes no use of - negative numbers. - - 0) Determine the Unicode code point for each non-LDH character in - the Unicode string. Since LDH characters are encoded literally, - their code points are not needed. Depending on how the Unicode - string is presented to the encoder, this step may be a no-op. - - 1) Verify that there are are no invalid code points in the input; - that is, none exceed 0x10FFFF (the highest code point in the - Unicode code space) and none are in the range D800..DFFF - (surrogates). - - 2) Determine the most populous row: Row n is defined as the 256 - code points starting with n << 8, except that this definition - would makes rows D8..DF useless, because they would contain only - surrogates. Therefore AMC-ACE-M defines rows D8..DF to be the - following non-aligned blocks of 256 code points: - - row D8 = 0020..001F - row D9 = 005B..015A - row DA = 007B..017A - row DB = 00A0..019F - row DC = 00C0..01BF - row DD = 00DF..01DE - row DE = 0134..0233 - row DF = 0270..036F - - (Rationale: Whereas almost every small script is confined to - a single row, the Latin script is split across a few rows, - and the row boundaries are not especially convenient for many - languages.) - - Determine the row containing the most non-LDH input code points, - breaking ties in favor of smaller-numbered rows. (If a code - point appears multiple times in the input, it counts multiple - times. This applies to steps 3 and 4 also.) Call it row B. - Let offsetB be the first code point of row B. - - 3) Determine the most populous 16-window: For each n in 0..31 let - offset = ((offsetB >> 3) + n) << 3 and count the number of code - points in the range offset through offset + 0xF. Let A be the - value of n that maximizes this count, breaking ties in favor - of smaller values of n, and let offsetA be the corresponding - offset. - - 4) Determine the most populous 20k-window: If the input is empty, - then let C = 0. Otherwise, for each input code point, let n = - code_point >> 11, and count the number of non-LDH input code - points that are not in row B and are in the range (n << 11) - through (n << 11) + 0x4FFF. Determine the value of n that - maximizes the count, breaking ties in favor of smaller values of - n, and let C be that value. - - 5) Choose a style: One of the base-32 codes used in step 7.3 has - two variants, and so base-32 mode is subdivided into two styles, - narrow and wide, depending on which variant is used. Compute - the total number of base-32 characters that would be produced - if narrow style were used, and the number if wide style were - used. The easiest way to do this is to mimic the logic of steps - 6 and 7.3. Use whichever style would produce fewer base-32 - characters. In case of a tie, use narrow style. - - 6) Encode the parameters. If narrow style is used, then let - offsetC = (offsetB >> 12) << 12, and encode B and A as three or - four base-32 characters: - - 00bbb bbbbb aaaaa if B <= 0xFF - 01bbb bbbbb bbbbb aaaaa otherwise - - If wide style is used, then let offsetC = C << 11, and encode B - and C as three or five base-32 characters: - - 10bbb bbbbb ccccc if B <= 0xFF and C <= 0x1F - 11bbb bbbbb bbbbb ccccc ccccc otherwise - - 7) Encode each input character in turn, using the first of the - following cases that applies. The mode is initially base-32. - - 7.1) The character is a hyphen-minus (U+002D). Encode it as - two hyphen-minuses. - - 7.2) The character is an LDH character. If in base-32 mode - then output a hyphen-minus and switch to literal mode. - Copy the character to the output. - - 7.3) The character is a non-LDH character. If in literal - mode then output a hyphen-minus and switch to base-32 - mode. Encode the character's code point using the - first of the following cases that applies. Square - brackets enclose quintets that can be used to record - the upper/lowercase attribute of the Unicode character - (because the corresponding base-32 characters are - guaranteed to be letters rather than digits) (see section - "Case sensitivity models"). - - 7.3.1) Narrow style was chosen and the code point is in - the range offsetA through offsetA + 0xF. Subtract - offsetA and encode the difference as a single - base-32 character: - - [0xxxx] - - 7.3.2) The code point is in the range offsetB through - offsetB + 0xFF. Subtract offsetB and encode the - difference as two base-32 characters: - - 1xxxx [0xxxx] - - 7.3.3) The code point is in the range offsetC through - offsetC + 0xFFF. Subtract offsetC and encode the - difference as three base-32 characters: - - 1xxxx 1xxxx [0xxxx] - - 7.3.4) Wide style was chosen and the code point is in - the range offsetC + 0x1000 through offsetC + - 0x4FFF. Subtract offsetC + 0x1000 and encode the - difference as three base-32 characters: - - [0xxxx] xxxxx xxxxx - - 7.3.5) The code point is in the range 0 through 0xFFFF. - Encode it as four base-32 characters: - - 1xxxx 1xxxx 1xxxx [0xxxx] - - 7.3.6) If we've come this far, the code point must be - in the range 0x10000 through 0x10FFFF. Subtract - 0x10000 and encode the difference as five base-32 - characters: - - 1xxxx 1xxxx 1xxxx 1xxxx [0xxxx] - -Decoding procedure - - The details of the decoding procedure are implied by the encoding - procedure. The overall sequence of steps is as follows. - - 1) Undo the encoder's step 6: From the first few base-32 - characters, determine whether narrow or wide style is used, and - determine the offsets. - - 2) Set the mode to base-32. For each remaining input character, use - the first of the following cases that applies: - - 2.1) The character is a hyphen-minus, and the following - character is also a hyphen-minus. Consume them both and - output a hyphen-minus. - - 2.2) The character is a hyphen-minus. Consume it and toggle - the mode flag. - - 2.3) The current mode is literal. Consume the input character - and output it. - - 2.4) Interpret the input character and up to four of its - successors as base-32. Consume characters until one is - found whose value has the form 0xxxx. That is the one - that carries the upper/lowercase information. Remember - the length of the code. If the length is one and wide - style is being used, consume two more characters. - Decode the base-32 characters into an integer, add the - appropriate offset (which depends on the remembered code - length), and output the Unicode character corresponding to - the resulting code point. - - If the case-flexible or case-preserving model is being - used (see section "Case sensitivity models"), the decoder - must either perform the case conversion as it is decoding, - or construct a separate record of the case information to - accompany the output string. - - 3) Before returning the output (be it a string or a string plus - case information), the decoder must invoke the encoder on it, - and compare the result to the input string. The comparison - must be case-sensitive if the case-sensitive or case-flexible - model is being used, case-insensitive if the case-insensitive - or case-preserving model is being used. If the two strings do - not match, it is an error. This check is necessary to guarantee - the uniqueness property (there cannot be two distinct encoded - strings representing the same Unicode string). - - If the decoder at any time encounters an unexpected character, or - unexpected end of input, then the input is invalid. - -Signature - - The issue of how to distinguish ACE strings from unencoded strings - is largely orthogonal to the encoding scheme itself, and is - therefore not specified here. In the context of domain name labels, - a standard prefix and/or suffix (chosen to be unlikely to occur - naturally) would presumably be attached to ACE labels. (In that - case, it would probably be good to forbid the encoding of Unicode - strings that appear to match the signature, to avoid confusing - humans about whether they are looking at a Unicode string or an ACE - string.) - - In order to use AMC-ACE-M in domain names, the choice of signature - must be mindful of the requirement in [RFC952] that labels never - begin or end with hyphen-minus. The raw encoded string will never - begin with a hyphen-minus, and will end with a hyphen-minus iff the - Unicode string ends with a hyphen-minus. The easiest solution is - to use a suffix as the signature. Alternatively, if the Unicode - strings were forbidden from ending with a hyphen-minus, a prefix - could be used. - - It appears that "---" is extremely rare in domain names; among the - four-character prefixes of all the second-level domains under .com, - .net, and .org, "---" never appears at all. Therefore, perhaps the - signature should be of the form ?--- (prefix) or ---? (suffix), - where ? could be "u" for Unicode, or "i" for internationalized, or - "a" for ACE, or maybe "q" or "z" because they are rare. - -Case sensitivity models - - The higher layer must choose one of the following four models. - - Models suitable for domain names: - - * Case-insensitive: Before a string is encoded, all its non-LDH - characters must be case-folded so that any strings differing - only in case become the same string (for example, strings could - be forced to lowercase). Folding LDH characters is optional. - The case of base-32 characters and literal-mode characters is - arbitrary and not significant. Comparisons between encoded - strings must be case-insensitive. The original case of non-LDH - characters cannot be recovered from the encoded string. - - * Case-preserving: The case of the Unicode characters is not - considered significant, but it can be preserved and recovered, - just like in non-internationalized host names. Before a string - is encoded, all its non-LDH characters must be case-folded - as in the previous model. LDH characters are naturally able - to retain their case attributes because they are encoded - literally. The case attribute of a non-LDH character is - recorded in one of the base-32 characters that represent - it (section "Encoding procedure" tells which one). If the - base-32 character is uppercase, it means the Unicode character - is caseless or should be forced to uppercase after being - decoded (which is a no-op if the case folding already forces - to uppercase). If the base-32 character is lowercase, it - means the Unicode character is caseless or should be forced to - lowercase after being decoded (which is a no-op if the case - folding already forces to lowercase). The case of the other - base-32 characters in a multi-quintet encoding is arbitrary - and not significant. Only uppercase and lowercase attributes - can be recorded, not titlecase. Comparisons between encoded - strings must be case-insensitive, and are equivalent to - case-insensitive comparisons between the Unicode strings. The - intended mixed-case Unicode string can be recovered as long as - the encoded characters are unaltered, but altering the case of - the encoded characters is not harmful--it merely alters the case - of the Unicode characters, and such a change is not considered - significant. - - In this model, the input to the encoder and the output of the - decoder can be the unfolded Unicode string (in which case the - encoder and decoder are responsible for performing the case - folding and recovery), or can be the folded Unicode string - accompanied by separate case information (in which case the - higher layer is responsible for performing the case folding and - recovery). Whichever layer performs the case recovery must - first verify that the Unicode string is properly folded, to - guarantee the uniqueness of the encoding. - - It is easy to extend the nameprep algorithm [NAMEPREP02] to - remember case information. It merely requires an additional - bit to be associated with each output code point in the mapping - table. - - The case-insensitive and case-preserving models are interoperable. - If a domain name passes from a case-preserving entity to a - case-insensitive entity, the case information will be lost, but - the domain name will still be equivalent. This phenomenon already - occurs with non-internationalized domain names. - - Models unsuitable for domain names, but possibly useful in other - contexts: - - * Case-sensitive: Unicode strings may contain both uppercase and - lowercase characters, which are not folded. Base-32 characters - must be lowercase. Comparisons between encoded strings must be - case-sensitive. - - * Case-flexible: Like case-preserving, except that the choice - of whether the case of the Unicode characters is considered - significant is deferred. Therefore, base-32 characters must - be lowercase, except for those used to indicate uppercase - Unicode characters. Comparisons between encoded strings may be - case-sensitive or case-insensitive, and such comparisons are - equivalent to the corresponding comparisons between the Unicode - strings. - -Comparison with RACE, BRACE, LACE, and DUDE - - In this section we compare AMC-ACE-M and four other ACEs: RACE - [RACE03], BRACE [BRACE00], LACE [LACE01], and Extended DUDE - [DUDE00]. We do not include SACE [SACE], UTF-5 [UTF5], or UTF-6 - [UTF6] in the comparison, because SACE appears obviously too - complex, UTF-5 appears obviously too inefficient, and UTF-6 can - never be more efficient than its similarly simple successor, DUDE. - - Case preservation support: - - DUDE, AMC-ACE-M: all characters - BRACE: only the letters A-Z, a-z - RACE, LACE: none - - RACE, BRACE, and LACE transform the Unicode string to an - intermediate bit string, then into a base-32 string, so there is no - particular alignment between the base-32 characters and the Unicode - characters. DUDE and AMC-ACE-M do not have this intermediate stage, - and enforce alignment between the base-32 characters and the Unicode - characters, which facilitates the case preservation. - - Complexity is hard to measure. This author would subjectively - describe the complexity of the algorithms as: - - RACE, LACE, DUDE: fairly simple but not trivial - AMC-ACE-M: moderate - BRACE: complex - - The complexity of AMC-ACE-M is in the number of rules, but the - individual rules are not very complex, and they are generally - non-interacting. - - The relative efficiency of the various algorithms is suggested - by the sizes of the encodings in section "Example strings". For - each ACE there is a graph below showing a horizontal bar for - each example string, representing the ACE length divided by the - minimum length among all the ACEs for that example string (so the - ratio is at least 1). Example R is excluded because it violates - nameprep [NAMEPREP02]. The other example strings all use different - languages, except that there are several Japanese examples. To - avoid skewing the results, each graph collapses all the Japanese - ratios into a single bar representing the median ratio. A ratio r - is represented by a bar of length r/0.04 characters. Since the bar - will always be at least 1/0.04 = 25 characters long, we show the - first 25 characters as "O" and the rest as "@". The bars are sorted - so that the graph looks like a cummulative distribution. Each bar - is labeled with the language of the corresponding example string. - (The difference between the Chinese and Taiwanese strings is that - the former uses simplified characters.) - - RACE: - Hindi OOOOOOOOOOOOOOOOOOOOOOOOO@@@ - Korean OOOOOOOOOOOOOOOOOOOOOOOOO@@@ - Arabic OOOOOOOOOOOOOOOOOOOOOOOOO@@@@ - Taiwanese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@ - Hebrew OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@ - Russian OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@ - Japanese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@ - Spanish OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@ - Chinese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@@ - Vietnamese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@@@@@@@@ - Czech OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@@@@@@@@@@@@@@@@@ - - LACE: - Korean OOOOOOOOOOOOOOOOOOOOOOOOO@@@ - Hindi OOOOOOOOOOOOOOOOOOOOOOOOO@@@@ - Taiwanese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@ - Arabic OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@ - Hebrew OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@ - Chinese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@ - Japanese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@ - Russian OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@ - Spanish OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@@ - Vietnamese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@@@@@@ - Czech OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@@@@@@@@@@ - - DUDE: - Russian OOOOOOOOOOOOOOOOOOOOOOOOO - Arabic OOOOOOOOOOOOOOOOOOOOOOOOO - Hebrew OOOOOOOOOOOOOOOOOOOOOOOOO@@ - Vietnamese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@ - Chinese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@ - Japanese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@ - Korean OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@ - Spanish OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@ - Czech OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@ - Hindi OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@ - Taiwanese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@ - - AMC-ACE-M: - Czech OOOOOOOOOOOOOOOOOOOOOOOOO - Hebrew OOOOOOOOOOOOOOOOOOOOOOOOO - Japanese OOOOOOOOOOOOOOOOOOOOOOOOO - Korean OOOOOOOOOOOOOOOOOOOOOOOOO - Russian OOOOOOOOOOOOOOOOOOOOOOOOO - Spanish OOOOOOOOOOOOOOOOOOOOOOOOO - Taiwanese OOOOOOOOOOOOOOOOOOOOOOOOO - Vietnamese OOOOOOOOOOOOOOOOOOOOOOOOO - Chinese OOOOOOOOOOOOOOOOOOOOOOOOO@ - Arabic OOOOOOOOOOOOOOOOOOOOOOOOO@@@ - Hindi OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@ - - BRACE: - Chinese OOOOOOOOOOOOOOOOOOOOOOOOO - Hindi OOOOOOOOOOOOOOOOOOOOOOOOO - Japanese OOOOOOOOOOOOOOOOOOOOOOOOO - Spanish OOOOOOOOOOOOOOOOOOOOOOOOO - Taiwanese OOOOOOOOOOOOOOOOOOOOOOOOO - Arabic OOOOOOOOOOOOOOOOOOOOOOOOO@ - Czech OOOOOOOOOOOOOOOOOOOOOOOOO@ - Vietnamese OOOOOOOOOOOOOOOOOOOOOOOOO@ - Hebrew OOOOOOOOOOOOOOOOOOOOOOOOO@@ - Korean OOOOOOOOOOOOOOOOOOOOOOOOO@@ - Russian OOOOOOOOOOOOOOOOOOOOOOOOO@@@ - - These results suggest that DUDE is preferrable to RACE and LACE, - because it has similar simplicity, better support for case - preservation, and is somewhat more efficient. - - The results also suggest that AMC-ACE-M is preferrable to BRACE, - because it has similar efficiency, better support for case - preservation, and is simpler. - - DUDE and AMC-ACE-M have equal support for case preservation, but - AMC-ACE-M offers significantly better efficiency, at the cost of - significantly greater complexity, so choosing between them entails a - value judgement. - -Example strings - - In the ACE encodings below, signatures (like "bq--" for RACE) are - not shown. Non-LDH characters in the Unicode string are forced to - lowercase before being encoded using BRACE, RACE, and LACE. For - RACE and LACE, the letters A-Z are likewise forced to lowercase. - UTF-8 and UTF-16 are included for length comparisons, with non-ASCII - bytes shown as "?". AMC-ACE-M is abbreviated AMC-M. Backslashes - show where line breaks have been inserted in ACE strings too long - for one line. The RACE and LACE encodings are courtesy of Mark - Davis's online UTF converter [UTFCONV] (slightly modified to remove - the length restrictions). - - The first several examples are all names of Japanese music artists, - song titles, and TV programs, just because the author happens to - have them handy (but Japanese is useful for providing examples - of single-row text, two-row text, ideographic text, and various - mixtures thereof). - - (A) 3B (Japanese TV program title) - - = U+5E74 (kanji) - = U+7D44 (kanji) - = U+91D1 U+516B U+5148 U+751F (kanji) - - UTF-16: ???????????????? - UTF-8: 3???B??????????????? - AMC-M: utk-3-8ze-B-hkenqtymwifi9 - BRACE: u-3-ygj-b-ynb6gjc7pp4k5p5w - DUDE: j3le74G062nd44p1d1l16bk8n51f - RACE: 3aadgxtuabrh2rer2fiwwukioupq - LACE: 74adgxtuabrh2rer2fiwwukioupq - - (B) -with-SUPER-MONKEYS (Japanese music group name) - - = U+5B89 U+5BA4 U+5948 U+7F8E U+6075 (kanji) - - UTF-8: ??????????????????-with-SUPER-MONKEYS - AMC-M: u5m2j4etwif6q2zf---with--SUPER--MONKEYS - BRACE: uvj7fuaqcahy982xa---with--SUPER--MONKEYS - DUDE: lb89q4p48nf8em075-g077m9n4m8-N3LGM5N2-MdVURLN9J - UTF-16: ???????????????????????????????????????????????? - LACE: ajnytjablfeac74oafqhkeyafv3qm5difvzxk4dfoiww233onnsxs4y - RACE: 3bnysw5elfeh7dtaouac2adxabuqa5aanaac2adtab2qa4aamuaheab\ - nabwqa3yanyagwadfab4qa4y - - (C) Hello-Another-Way- (Japanese song title) - - = U+305D U+308C U+305E U+308C U+306E (hiragana) - = U+5834 U+6240 (kanji) - - UTF-8: Hello-Another-Way-????????????????????? - BRACE: ji7-Hello--Another--Way---v3jhaefvd2ufj62 - AMC-M: bsk-Hello--Another--Way---p2nq2nyqx2veyuwa - DUDE: M8lssv-Huvn4m8ln2-Nm1n9-j05docleocmel834m240 - UTF-16: ?????????????????????????????????????????????????? - LACE: ciagqzlmnrxs2ylon52gqzlsfv3wc6jnauyf3dc6rrxacwbuafrea - RACE: 3aagqadfabwaa3aan4ac2adbabxaa3yaoqagqadfabzaaliao4agcad\ - zaawtaxjqrqyf4memgbxfqndcia - - (D) 2 (Japanese TV program title) - - = U+3072 U+3068 U+3064 (hiragana) - = U+5C4B U+6839 (kanji) - = U+306E (hiragana) - = U+4E0B (kanji) - - UTF-16: ???????????????? - UTF-8: ?????????????????????2 - AMC-M: bsnzciex6wmy2vjqw8sm-2 - BRACE: ji96u56uwbhf2wqxnw4s-2 - DUDE: j072m8klc4bm839j06eke0bg032 - RACE: 3ayhemdigbsfys3iheyg4tqlaaza - LACE: 74yhemdigbsfys3iheyg4tqlaaza - - (E) MajiKoi5 (Japanese song title) - - = U+3067 (hiragana) - = U+3059 U+308B (hiragana) - = U+79D2 U+524D (kanji) - - UTF-8: Maji???Koi??????5?????? - UTF-16: ?????????????????????????? - AMC-M: bsm-Maji-r-Koi-b2m-5-z37cxuwp - BRACE: ji8-Maji-g-Koi-qe7x-5-wx7p6ma - DUDE: Mdhqpj067G06bvpj059obg035n9d2l24d - RACE: 3aag2adbabvaa2jqm4agwadpabutawjqrmadk6oskjgq - LACE: 74ag2adbabvaa2jqm4agwadpabutawjqrmadk6oskjgq - - (F) de (Japanese song title) - - = U+30D1 U+30D5 U+30A3 U+30FC (katakana) - = U+30EB U+30F3 U+30D0 (katakana) - - UTF-16: ?????????????? - BRACE: 3iu8pazt-de-pygi - AMC-M: bs3jp4d9n-de-8m9di - RACE: gdi5li7475sp6zpl6pia - DUDE: j0d1lq3vcg064lj0ebv3t0 - UTF-8: ????????????de????????? - LACE: aqyndvnd7qbaazdfamyox46q - - (G) (Japanese song title) - - = U+305D U+306E (hiragana) - = U+30B9 U+30D4 U+30FC U+30C9 (katakana) - = U+3067 (hiragana) - - RACE: gbow5oou7tewo - UTF-16: ?????????????? - BRACE: bidprdmp9wt7mi - LACE: a4yf23vz2t6mszy - AMC-M: bsmfyq5j7e9n6jr - DUDE: j05dmer9t4vcs9m7 - UTF-8: ????????????????????? - - The next several examples are all translations of the sentence "Why - can't they just speak in ?" (courtesy of Michael Kaplan's - "provincial" page [PROVINCIAL]). Word breaks and punctuation have - been removed, as is often done in domain names. - - (H) Arabic (Egyptian): - U+0644 U+064A U+0647 U+0645 U+0627 U+0628 U+062A U+0643 U+0644 - U+0645 U+0648 U+0634 U+0639 U+0631 U+0628 U+064A U+061F - - DUDE: m44qnli7oqk3kloj4phi8kahf - BRACE: 28akcjwcmp3ciwb4t3ngd4nbaz - AMC-M: agiekhfuhuiukdefivevjvbuiktr - RACE: azceur2fe4ucuq2eivediojrfbfb6 - LACE: cedeisshiutsqksdircuqnbzgeueuhy - UTF-16: ?????????????????????????????????? - UTF-8: ?????????????????????????????????? - - (I) Chinese (simplified): - U+4ED6 U+4EEC U+4E3A U+4EC0 U+4E48 U+4E0D U+8BF4 U+4E2D U+6587 - - UTF-16: ?????????????????? - BRACE: kgcqqsgp26i5h4zn7req5i - AMC-M: uqj7g8nvk6awispn9wupdnh - DUDE: ked6ucjas0k8gdobf4ke2dm587 - UTF-8: ??????????????????????????? - LACE: azhnn3b2ybea2aml6qau4libmwdq - RACE: 3bhnmtxmjy5e5qcojbha3c7ujywwlby - - (J) Czech: Proprostnemluvesky - - = U+010D - = U+011B - = U+00ED - - UTF-8: Pro??prost??nemluv????esky - AMC-M: g26-Pro-p-prost-9m-nemluv-6pp-esky - BRACE: i32-Pro-u-prost-8y-nemluv-29f3n-esky - DUDE: N0imfh0dg70imfn3kh1bg6eltsn5mudh0dg65n3mbn9 - UTF-16: ???????????????????????????????????????????? - LACE: amaha4tpaeaq2biaobzg643uaearwbyanzsw23dvo3wqcainaqagk43\ - lpe - RACE: ah7xb73s75xq373q75zp6377op7xig77n37wl73n75wp65p7o3762dp\ - 7mx7xh73l754q - - (K) Hebrew: - U+05DC U+05DE U+05D4 U+05D4 U+05DD U+05E4 U+05E9 U+05D5 U+05D8 - U+05DC U+05D0 U+05DE U+05D3 U+05D1 U+05E8 U+05D9 U+05DD U+05E2 - U+05D1 U+05E8 U+05D9 U+05EA - - AMC-M: af4nqeep8e8jfinaqdb8ijp8cb8ij8k - DUDE: ldcukktu4pt5osgujhu8t9tu2t1u8t9ua - BRACE: 27vkyp7bgwmbpfjgc4ynx5nd8xsp5nd9c - RACE: axon5vgu3xsotvoy3tin5u6r5dm53ywr5dm6u - LACE: cyc5zxwu2to6j2ov3donbxwt2huntxpc2hunt2q - UTF-8: ???????????????????????????????????????????? - UTF-16: ???????????????????????????????????????????? - - (L) Hindi: - U+092F U+0939 U+0932 U+094B U+0917 U+0939 U+093F U+0928 U+094D - U+0926 U+0940 U+0915 U+094D U+092F U+094B U+0902 U+0928 U+0939 - U+0940 U+0902 U+092C U+094B U+0932 U+0938 U+0915 U+0924 U+0947 - U+0939 U+0948 U+0902 (Devanagari) - - BRACE: 2b7xtenqdr7zc6uma2pmcz7ibage237kdemicnk9gei32 - RACE: bextsmslc44t6kcnezabktjpjmbcqokaaiwewmrycuseookiai - LACE: dyes6ojsjmltspzijuteafknf5fqekbziabcyszshaksirzzjaba - AMC-M: ajhurbvcwmthbhuiwpugitfwpurwmscuibiscunwmvcatfuerbwisc - DUDE: p2fj9ikbh7j9vi8kdi6k0h5kdifkbg2i8j9k0g2ickbj2oh5i4k7j9k\ - 8g2 - UTF-16: ???????????????????????????????????????????????????????\ - ????? - UTF-8: ???????????????????????????????????????????????????????\ - ??????????????????????????????????? - - (M) Korean: - U+C138 U+ACC4 U+C758 U+BAA8 U+B4E0 U+C0AC U+B78C U+B4E4 U+C774 - U+D55C U+AD6D U+C5B4 U+B97C U+C774 U+D574 U+D55C U+B2E4 U+BA74 - U+C5BC U+B9C8 U+B098 U+C88B U+C744 U+AE4C (Hangul syllables) - - UTF-16: ???????????????????????????????????????????????? - UTF-8: ???????????????????????????????????????????????????????\ - ????????????????? - AMC-M: yhxcj2w6exiaxi68acfn92n68ezehk6xypdpwam6zehmwhk648eavwd\ - p6aqi23ieemweywn - BRACE: y394qebjusrcndbs82pkvstf96sxufcr7ffr4vbgdwsxufcx8pdktgb\ - gmnsqydmk7im56arju6pt82 - LACE: 77atrlgey5mlvkfu4dakzn4mwtsmo5gvlsww3rnuxf6mo5gvotkvzmx\ - exj2mlpfzzcyjrsely5ck4ta - RACE: 3datrlgey5mlvkfu4dakzn4mwtsmo5gvlsww3rnuxf6mo5gvotkvzmx\ - exj2mlpfzzcyjrsely5ck4ta - DUDE: s138qcc4s758raa8ke0s0acr78cke4s774t55cqd6ds5b4r97cs774t\ - 574lcr2e4q74s5bcr9c8g98s88bn44qe4c - - (N) Russian: - U+041F U+043E U+0447 U+0435 U+043C U+0443 U+0436 U+0435 U+043E - U+043D U+0438 U+043D U+0435 U+0433 U+043E U+0432 U+043E U+0440 - U+044F U+0442 U+043F U+043E U+0440 U+0443 U+0441 U+0441 U+043A - U+0438 (Cyrillic) - - DUDE: K3fuk7j5sk3j6lutotljuiuk0vijfuk0jhhjao - AMC-M: aehHgrvfemvgvfgfafvfvdgvcgiwrkhgimjjca - BRACE: 269xyjvcyafqfdwyr3xfd8z8byi6z39xyi692s7ug2 - RACE: aq7t4rzvhrbtmnj6hu4d2njthyzd4qcpii7t4qcdifatuoa - LACE: dqcd6pshgu6egnrvhy6tqpjvgm7depsaj5bd6psainaucory - UTF-16: ???????????????????????????????????????????????????????\ - ??? - UTF-8: ??????????????????????????????????????????????????????? - ??? - - (O) Spanish: PorqunopuedensimplementehablarenEspaol - - = U+00E9 - = U+00F1 - - UTF-8: Porqu??nopuedensimplementehablarenEspa??ol - AMC-M: aa7-Porqu-b-nopuedensimplementehablarenEspa-j-ol - BRACE: 22x-Porqu-9-nopuedensimplementehablarenEspa-j-ol - DUDE: N0mfn2hlu9mevn0lm5klun3m9tn0mcltlun4m5ohishn2m5uLn3gm1v\ - 1mfs - RACE: abyg64troxuw433qovswizloonuw24dmmvwwk3tumvugcytmmfzgk3t\ - fonygd4lpnq - LACE: faaha33sof26s3tpob2wkzdfnzzws3lqnrsw2zloorswqylcnrqxezl\ - omvzxayprn5wa - UTF-16: ???????????????????????????????????????????????????????\ - ????????????????????????? - - (P) Taiwanese: - U+4ED6 U+5011 U+7232 U+4EC0 U+9EBD U+4E0D U+8AAA U+4E2D U+6587 - - UTF-16: ?????????????????? - UTF-8: ??????????????????????????? - AMC-M: uqj7g2tbgtu6a385pspnxkupdnh - BRACE: kgcqui49gatc2wyrn8y7cndgte9 - RACE: 3bhnmuaroize5qe6xvha3cvkjywwlby - LACE: 75hnmuaroize5qe6xvha3cvkjywwlby - DUDE: ked6l011n232kec0pebdke0doaaake2dm587 - - (Q) Vietnamese: - Taisaohokhngthchi\ - noitingVit - - = U+0323 - = U+00F4 - = U+00EA - = U+0309 - = U+0301 - - UTF-8: Ta??isaoho??kh??ngth????chi??no??iti????ngVi????t - AMC-M: ada-Ta-ud-isaoho-ud-kh-s9e-ngth-s8kj-chi-j-no-b-iti-s8k\ - b-ngVi-s8kud-t - BRACE: i54-Ta-8-isaoho-ay-kh-29n-ngth-s2xa6i-chi-k-no-2g-iti-2\ - 9c29-ngVi-25p48-t - UTF-16: ???????????????????????????????????????????????????????\ - ????????????????????? - DUDE: N4m1j23g69n3m1vovj23g6bov4menn4m8uaj09g63opj09g6evj01g6\ - 9n4m9uaj01g6enN6m9uaj23g74 - LACE: aiahiyibamrqmadjonqw62dpaebsgcaannupi3thoruouaidbebqay3\ - ineaqgcicabxg6aidaecaa2lunhvacaybauag4z3wnhvacazdaeahi - RACE: ap7xj73bep7wt73t75q76377nd7w6i77np7wr77u75xp6z77ot7wr77\ - kbh7wh73i75uqt73o75xqd73j752p62p75ia763x7m77xn73j77vch7\ - 3u - - The last example is an ASCII string that breaks not only the - existing rules for host name labels but also the rules proposed in - [NAMEPREP02] for internationalized domain names. - - (R) -> $1.00 <- - - UTF-8: -> $1.00 <- - DUDE: -jei0kj1iej0gi0jc- - RACE: aawt4ibegexdambahqwq - LACE: bmac2praeqys4mbqea6c2 - UTF-16: ?????????????????????? - AMC-M: aae--vqae-1-q-00-avn-- - BRACE: 229--t2b4-1-w-00-i9i-- - -Security considerations - - Users expect each domain name in DNS to be controlled by a single - authority. If a Unicode string intended for use as a domain label - could map to multiple ACE labels, then an internationalized domain - name could map to multiple ACE domain names, each controlled by - a different authority, some of which could be spoofs that hijack - service requests intended for another. Therefore AMC-ACE-M is - designed so that each Unicode string has a unique encoding. - - However, there can still be multiple Unicode representations of the - "same" text, for various definitions of "same". This problem is - addressed to some extent by the Unicode standard under the topic - of canonicalization, but some text strings may be misleading or - ambiguous to humans when used as domain names, such as strings - containing dots, slashes, at-signs, etc. These issues are being - further studied under the topic of "nameprep" [NAMEPREP02]. - -References - - [ACEID01] Yoshiro Yoneya, Naomasa Maruyama, "Proposal for - a determining process of ACE identifier", 2000-Dec-19, - draft-ietf-idn-aceid-01. - - [BRACE00] Adam Costello, "BRACE: Bi-mode Row-based - ASCII-Compatible Encoding for IDN version 0.1.2", 2000-Sep-19, - draft-ietf-idn-brace-00. - - [DUDE00] Brian Spolarich, Mark Welter, "DUDE: Differential Unicode - Domain Encoding", 2000-Nov-21, draft-ietf-idn-dude-00. - - [IDN] Internationalized Domain Names (IETF working group), - http://www.i-d-n.net/, idn@ops.ietf.org. - - [LACE01] Paul Hoffman, Mark Davis, "LACE: Length-based ASCII - Compatible Encoding for IDN", 2001-Jan-05, draft-ietf-idn-lace-01. - - [NAMEPREP02] Paul Hoffman, Marc Blanchet, "Preparation - of Internationalized Host Names", 2001-Jan-17, - draft-ietf-idn-nameprep-02. - - [PROVINCIAL] Michael Kaplan, "The 'anyone can be provincial!' page", - http://www.trigeminal.com/samples/provincial.html. - - [RACE03] Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding - for IDN", 2000-Nov-28, draft-ietf-idn-race-03. - - [RFC952] K. Harrenstien, M. Stahl, E. Feinler, "DOD Internet Host - Table Specification", 1985-Oct, RFC 952. - - [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities", - 1987-Nov, RFC 1034. - - [RFC1123] Internet Engineering Task Force, R. Braden (editor), - "Requirements for Internet Hosts -- Application and Support", - 1989-Oct, RFC 1123. - - [SACE] Dan Oscarsson, "Simple ASCII Compatible Encoding (SACE)", - draft-ietf-idn-sace-*. - - [UNICODE] The Unicode Consortium, "The Unicode Standard", - http://www.unicode.org/unicode/standard/standard.html. - - [UTF5] James Seng, Martin Duerst, Tin Wee Tan, "UTF-5, a - Transformation Format of Unicode and ISO 10646", draft-jseng-utf5-*. - - [UTF6] Mark Welter, Brian W. Spolarich, "UTF-6 - Yet Another - ASCII-Compatible Encoding for IDN", draft-ietf-idn-utf6-*. - - [UTFCONV] Mark Davis, "UTF Converter", - http://www.macchiato.com/unicode/convert.html. - -Author - - Adam M. Costello - http://www.cs.berkeley.edu/~amc/ - - -Example implementation - - -/******************************************/ -/* amc-ace-m.c 0.1.0 (2001-Feb-12-Mon) */ -/* Adam M. Costello */ -/******************************************/ - -/* This is ANSI C code implementing AMC-ACE-M version 0.1.*. */ - - -/************************************************************/ -/* Public interface (would normally go in its own .h file): */ - -#include - -enum amc_ace_status { - amc_ace_success, - amc_ace_invalid_input, - amc_ace_output_too_big -}; - -enum case_sensitivity { case_sensitive, case_insensitive }; - -#if UINT_MAX >= 0x10FFFF -typedef unsigned int u_code_point; -#else -typedef unsigned long u_code_point; -#endif - -int amc_ace_m_encode( - unsigned int input_length, - const u_code_point *input, - const unsigned char *uppercase_flags, - unsigned int *output_size, - unsigned char *output ); - - /* amc_ace_m_encode() converts Unicode to AMC-ACE-M. The input */ - /* must be represented as an array of Unicode code points */ - /* (not code units; surrogate pairs are not allowed), and the */ - /* output will be represented as null-terminated ASCII. The */ - /* input_length is the number of code points in the input. The */ - /* output_size is an in/out argument: the caller must pass */ - /* in the maximum number of characters that may be output */ - /* (including the terminating null), and on successful return */ - /* it will contain the number of characters actually output */ - /* (including the terminating null, so it will be one more than */ - /* strlen() would return, which is why it is called output_size */ - /* rather than output_length). The uppercase_flags array must */ - /* hold input_length boolean values, where nonzero means the */ - /* corresponding Unicode character should be forced to uppercase */ - /* after being decoded, and zero means it is caseless or should */ - /* be forced to lowercase. Alternatively, uppercase_flags may */ - /* be a null pointer, which is equivalent to all zeros. The */ - /* letters a-z and A-Z are always encoded literally, regardless */ - /* of the corresponding flags. The encoder always outputs */ - /* lowercase base-32 characters except when nonzero values */ - /* of uppercase_flags require otherwise, so the encoder is */ - /* compatible with any of the case models. The return value */ - /* may be any of the amc_ace_status values defined above; if */ - /* not amc_ace_success, then output_size and output may contain */ - /* garbage. On success, the encoder will never need to write an */ - /* output_size greater than input_length*5+6, because of how the */ - /* encoding is defined. */ - -int amc_ace_m_decode( - enum case_sensitivity case_sensitivity, - unsigned char *scratch_space, - const unsigned char *input, - unsigned int *output_length, - u_code_point *output, - unsigned char *uppercase_flags ); - - /* amc_ace_m_decode() converts AMC-ACE-M to Unicode. The input */ - /* must be represented as null-terminated ASCII, and the output */ - /* will be represented as an array of Unicode code points. */ - /* The case_sensitivity argument influences the check on the */ - /* well-formedness of the input string; it must be case_sensitive */ - /* if case-sensitive comparisons are allowed on encoded strings, */ - /* case_insensitive otherwise (see also section "Case sensitivity */ - /* models" of the AMC-ACE-M specification). The scratch_space */ - /* must point to space at least as large as the input, which will */ - /* get overwritten (this allows the decoder to avoid calling */ - /* malloc()). The output_length is an in/out argument: the */ - /* caller must pass in the maximum number of code points that */ - /* may be output, and on successful return it will contain the */ - /* actual number of code points output. The uppercase_flags */ - /* array must have room for at least output_length values, or it */ - /* may be a null pointer if the case information is not needed. */ - /* A nonzero flag indicates that the corresponding Unicode */ - /* character should be forced to uppercase by the caller, while */ - /* zero means it is caseless or should be forced to lowercase. */ - /* The letters a-z and A-Z are output already in the proper case, */ - /* but their flags will be set appropriately so that applying the */ - /* flags would be harmless. The return value may be any of the */ - /* amc_ace_status values defined above; if not amc_ace_success, */ - /* then output_length, output, and uppercase_flags may contain */ - /* garbage. On success, the decoder will never need to write */ - /* an output_length greater than the length of the input (not */ - /* counting the null terminator), because of how the encoding is */ - /* defined. */ - - -/**********************************************************/ -/* Implementation (would normally go in its own .c file): */ - -#include - -/* Character utilities: */ - -/* is_ldh(codept) returns 1 if the code point represents an LDH */ -/* character (ASCII letter, digit, or hyphen-minus), 0 otherwise. */ - -static int is_ldh(u_code_point codept) -{ - if (codept == 45) return 1; - if (codept < 48) return 0; - if (codept <= 57) return 1; - if (codept < 65) return 0; - if (codept <= 90) return 1; - if (codept < 97) return 0; - if (codept <= 122) return 1; - return 0; -} - -/* is_AtoZ(c) returns 1 if c is an */ -/* uppercase ASCII letter, zero otherwise. */ - -static unsigned char is_AtoZ(unsigned char c) -{ - return c >= 65 && c <= 90; -} - -/* special_row_offset[n] holds the offset of the */ -/* bottom of special row 0xD8 + n, where n is in 0..7. */ - -static u_code_point special_row_offset[] = - { 0x0020, 0x005B, 0x007B, 0x00A0, 0x00C0, 0x00DF, 0x0134, 0x0270 }; - -/* base32[n] is the lowercase base-32 character representing */ -/* the number n from the range 0 to 31. Note that we cannot */ -/* use string literals for ASCII characters because an ANSI C */ -/* compiler does not necessarily use ASCII. */ - -static const unsigned char base32[] = { - 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, /* a-k */ - 109, 110, /* m-n */ - 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, /* p-z */ - 50, 51, 52, 53, 54, 55, 56, 57 /* 2-9 */ -}; - -/* base32_decode(c) returns the value of a base-32 character, in the */ -/* range 0 to 31, or the constant base32_invalid if c is not a valid */ -/* base-32 character. */ - -enum { base32_invalid = 32 }; - -static unsigned int base32_decode(unsigned char c) -{ - if (c < 50) return base32_invalid; - if (c <= 57) return c - 26; - if (c < 97) c += 32; - if (c < 97 || c == 108 || c == 111 || c > 122) return base32_invalid; - return c - 97 - (c > 108) - (c > 111); -} - -/* unequal(case_sensitivity,a1,a2,n) returns 0 if the arrays */ -/* a1 and a2 are equal in the first n positions, 1 otherwise. */ -/* If case_sensitivity is case_insensitive, then ASCII A-Z are */ -/* considered equal to a-z respectively. */ - -static int unequal( - enum case_sensitivity case_sensitivity, - const unsigned char *a1, - const unsigned char *a2, - unsigned int n ) -{ - const unsigned char *end; - unsigned char c1, c2; - - if (case_sensitivity != case_insensitive) return memcmp(a1,a2,n); - - for (end = a1 + n; a1 < end; ++a1, ++a2) { - c1 = *a1; - c2 = *a2; - if (c1 >= 65 && c1 <= 90) c1 += 32; - if (c2 >= 65 && c2 <= 90) c2 += 32; - if (c1 != c2) return 1; - } - - return 0; -} - - -/* Encoder: */ - -int amc_ace_m_encode( - unsigned int input_length, - const u_code_point *input, - const unsigned char *uppercase_flags, - unsigned int *output_size, - unsigned char *output ) -{ - unsigned int literal, wide; /* boolean */ - u_code_point codept, n, diff, morebits; - u_code_point A, B, C, offsetA, offsetB, offsetC, offset; - const u_code_point *input_end, *p, *pp; - unsigned int count, max, next_in, next_out, max_out, codelen, i; - unsigned char c; - - input_end = input + input_length; - - /* 1) Verify that only valid code points appear: */ - - for (p = input; p < input_end; ++p) { - if (*p >> 11 == 0x1B || *p > 0x10FFFF) return amc_ace_invalid_input; - } - - /* 2) Determine the most populous row: B and offsetB */ - - /* first check the special rows: */ - - B = 0xD8; - offsetB = special_row_offset[0]; - max = 0; - - for (n = 0; n < 8; ++n) { - offset = special_row_offset[n]; - count = 0; - - for (p = input; p < input_end; ++p) { - if (*p - offset <= 0xFF && !is_ldh(*p)) ++count; - } - - if (count > max) { - B = 0xD8 + n; - offsetB = offset; - max = count; - } - } - - /* now check the regular rows: */ - - for (pp = input; pp < input_end; ++pp) { - n = *pp >> 8; - count = 0; - - for (p = input; p < input_end; ++p) { - if (*p >> 8 == n && !is_ldh(*p)) ++count; - } - - if (count > max || (count == max && n < B)) { - B = n; - offsetB = n << 8; - max = count; - } - } - - /* 3) Determine the most populous 16-window: A and offsetA */ - - A = 0; - max = 0; - - for (n = 0; n <= 0x1F; ++n) { - offset = ((offsetB >> 3) + n) << 3; - count = 0; - - for (p = input; p < input_end; ++p) { - if (*p - offset <= 0xF && !is_ldh(*p)) ++count; - } - - if (count > max) { - A = n; - offsetA = offset; - max = count; - } - } - - /* 4) Determine the most populous 20k-window: C */ - - C = 0; - max = 0; - - for (pp = input; pp < input_end; ++pp) { - count = 0; - n = *pp >> 11; - offset = n << 11; - - for (p = input; p < input_end; ++p) { - if (*p - offset <= 0x4FFF && !is_ldh(*p)) ++count; - - if (count > max || (count == max && n < C)) { - C = n; - max = count; - } - } - } - - /* 5) Determine the style to use: wide or narrow */ - - /* if narrow style were used: */ - - offsetC = (offsetB >> 12) << 12; - count = 3 + (B > 0xFF); - - for (p = input; p < input_end; ++p) { - if (is_ldh(*p)) { } - else if (*p - offsetA <= 0xF) count += 1; - else if (*p - offsetB <= 0xFF) count += 2; - else if (*p - offsetC <= 0xFFF) count += 3; - else if (*p <= 0xFFFF) count += 4; - else count += 5; - } - - max = count; - - /* if wide style were used: */ - - offsetC = C << 11; - count = B <= 0xFF && C <= 0x1F ? 3 : 5; - - for (p = input; p < input_end; ++p) { - if (is_ldh(*p)) { } - else if (*p - offsetB <= 0xFF) count += 2; - else if (*p - offsetC <= 0x4FFF) count += 3; - else if (*p <= 0xFFFF) count += 4; - else count += 5; - } - - wide = (count < max); - - /* 6) Initialize offsetC, and encode the style and offsets: */ - - max_out = *output_size; - next_out = 0; - - if (wide) { - offsetC = C << 11; - - if (B <= 0xFF && C <= 0x1F) { - if (max_out - next_out < 3) return amc_ace_output_too_big; - output[next_out++] = base32[0x10 | (B >> 5)]; - output[next_out++] = base32[B & 0x1F]; - output[next_out++] = base32[C]; - } - else { - if (max_out - next_out < 5) return amc_ace_output_too_big; - output[next_out++] = base32[0x18 | (B >> 10)]; - output[next_out++] = base32[(B >> 5) & 0x1F]; - output[next_out++] = base32[B & 0x1F]; - output[next_out++] = base32[C >> 5]; - output[next_out++] = base32[C & 0x1F]; - } - } - else { - offsetC = (offsetB >> 12) << 12; - - if (B <= 0xFF) { - if (max_out - next_out < 3) return amc_ace_output_too_big; - output[next_out++] = base32[B >> 5]; - output[next_out++] = base32[B & 0x1F]; - } - else { - if (max_out - next_out < 4) return amc_ace_output_too_big; - output[next_out++] = base32[8 | (B >> 10)]; - output[next_out++] = base32[(B >> 5) & 0x1F]; - output[next_out++] = base32[B & 0x1F]; - } - - output[next_out++] = base32[A]; - } - - /* 7) Main encoding loop: */ - - literal = 0; - - for (next_in = 0; next_in < input_length; ++next_in) { - codept = input[next_in]; - - if (codept == 45 /* hyphen-minus */) { - /* case 7.1 */ - if (max_out - next_out < 2) return amc_ace_output_too_big; - output[next_out++] = 45; - output[next_out++] = 45; - continue; - } - - if (is_ldh(codept)) { - /* case 7.2 */ - if (!literal) { - if (max_out - next_out < 1) return amc_ace_output_too_big; - output[next_out++] = 45; - literal = 1; - } - - if (max_out - next_out < 1) return amc_ace_output_too_big; - output[next_out++] = codept; - continue; - } - - /* case 7.3 */ - - if (literal) { - if (max_out - next_out < 1) return amc_ace_output_too_big; - output[next_out++] = 45; - literal = 0; - } - - if (!wide) { - diff = codept - offsetA; - - if (diff <= 0xF) { - /* case 7.3.1 */ - codelen = 1; - goto encoder_base32_bottom; - } - } - - diff = codept - offsetB; - - if (diff <= 0xFF) { - /* case 7.3.2 */ - codelen = 2; - goto encoder_base32_bottom; - } - - diff = codept - offsetC; - - if (diff <= 0xFFF) { - /* case 7.3.3 */ - codelen = 3; - goto encoder_base32_bottom; - } - - if (wide) { - diff = codept - offsetC - 0x1000; - - if (diff <= 0x3FFF) { - /* case 7.3.4 */ - codelen = 1; - morebits = diff & 0x3FF; - diff >>= 10; - goto encoder_base32_bottom; - } - } - - if (codept <= 0xFFFF) { - /* case 7.3.5 */ - diff = codept; - codelen = 4; - goto encoder_base32_bottom; - } - - /* case 7.3.6 */ - diff = codept - 0x10000; - codelen = 5; - - encoder_base32_bottom: /* output diff as n base-32 digits: */ - if (max_out - next_out < codelen) return amc_ace_output_too_big; - i = codelen - 1; - c = base32[diff & 0xF]; - if (uppercase_flags && uppercase_flags[next_in]) c -= 32; - output[next_out + i] = c; - - while (i > 0) { - diff >>= 4; - output[next_out + --i] = base32[0x10 | (diff & 0xF)]; - } - - next_out += codelen; - - if (wide && codelen == 1) { - /* case 7.3.4 */ - if (max_out - next_out < 2) return amc_ace_output_too_big; - output[next_out++] = base32[morebits >> 5]; - output[next_out++] = base32[morebits & 0x1F]; - } - } - - /* null terminator: */ - if (max_out - next_out < 1) return amc_ace_output_too_big; - output[next_out++] = 0; - *output_size = next_out; - return amc_ace_success; -} - - -/* Decoder: */ - -int amc_ace_m_decode( - enum case_sensitivity case_sensitivity, - unsigned char *scratch_space, - const unsigned char *input, - unsigned int *output_length, - u_code_point *output, - unsigned char *uppercase_flags ) -{ - unsigned int literal, wide, large; /* boolean */ - const unsigned char *next_in; - unsigned char c; - unsigned int next_out, max_out, codelen, input_size, scratch_size; - u_code_point q, B, offsets[6], diff, offset; - enum amc_ace_status status; - - /* 1) Decode the style and offsets: */ - - next_in = input; - q = base32_decode(*next_in++); - if (q == base32_invalid) return amc_ace_invalid_input; - wide = q >> 4; - large = (q >> 3) & 1; - B = q & 7; - q = base32_decode(*next_in++); - if (q == base32_invalid) return amc_ace_invalid_input; - B = (B << 5) | q; - - if (large) { - q = base32_decode(*next_in++); - if (q == base32_invalid) return amc_ace_invalid_input; - B = (B << 5) | q; - } - - /* offsets[codelen] is for base-32 codes with codelen characters */ - /* (not counting the extra two in wide-style 0xxxx xxxxx xxxxx) */ - - offsets[2] = B >> 3 == 0x1B ? special_row_offset[B & 7] : B << 8; - q = base32_decode(*next_in++); - if (q == base32_invalid) return amc_ace_invalid_input; - - if (!wide) { - offsets[1] = ((offsets[2] >> 3) + q) << 3; - offsets[3] = (offsets[2] >> 12) << 12; - } - else { - offset = q << 11; - - if (large) { - q = base32_decode(*next_in++); - if (q == base32_invalid) return amc_ace_invalid_input; - offset = (offset << 5) | q; - } - - offsets[3] = offset; - offsets[1] = offset + 0x1000; - } - - offsets[4] = 0; - offsets[5] = 0x10000; - - /* 2) Main decoding loop: */ - - max_out = *output_length; - next_out = 0; - literal = 0; - - for (;;) { - c = *next_in++; - if (!c) break; - - if (c == 45 /* hyphen-minus */) { - if (*next_in == 45) { - /* case 2.1: "--" decodes to "-" */ - ++next_in; - if (max_out - next_out < 1) return amc_ace_output_too_big; - if (uppercase_flags) uppercase_flags[next_out] = 0; - output[next_out++] = 45; - continue; - } - - /* case 2.2: unpaired hyphen-minus toggles mode */ - literal = !literal; - continue; - } - - if (!is_ldh(c)) return amc_ace_invalid_input; - if (max_out - next_out < 1) return amc_ace_output_too_big; - - if (literal) { - /* case 2.3: literal letter/digit */ - if (uppercase_flags) uppercase_flags[next_out] = is_AtoZ(c); - output[next_out++] = c; - continue; - } - - /* case 2.4: base-32 sequence */ - - diff = 0; - codelen = 1; - - for (;;) { - q = base32_decode(c); - if (q == base32_invalid) return amc_ace_invalid_input; - diff = (diff << 4) | (q & 0xF); - if ((q & 0x10) == 0) break; - if (++codelen > 5) return amc_ace_invalid_input; - c = *next_in++; - } - - /* Now codelen is the number of input characters read, */ - /* and c is the character holding the uppercase flag. */ - - if (wide && codelen == 1) { - q = base32_decode(*next_in++); - if (q == base32_invalid) return amc_ace_invalid_input; - diff = (diff << 5) | q; - q = base32_decode(*next_in++); - if (q == base32_invalid) return amc_ace_invalid_input; - diff = (diff << 5) | q; - } - - offset = offsets[codelen]; - if (uppercase_flags) uppercase_flags[next_out] = is_AtoZ(c); - output[next_out++] = offset + diff; - } - - /* 3) Re-encode the output and compare to the input: */ - - input_size = next_in - input; - scratch_size = input_size; - status = amc_ace_m_encode(next_out, output, uppercase_flags, - &scratch_size, scratch_space); - if (status != amc_ace_success || - scratch_size != input_size || - unequal(case_sensitivity, scratch_space, input, input_size) - ) return amc_ace_invalid_input; - *output_length = next_out; - return amc_ace_success; -} - - -/******************************************************************/ -/* Wrapper for testing (would normally go in a separate .c file): */ - -#include -#include -#include -#include - -/* For testing, we'll just set some compile-time limits rather than */ -/* use malloc(), and set a compile-time option rather than using a */ -/* command-line option. */ - -enum { - unicode_max_length = 256, - ace_max_size = 256, - test_case_sensitivity = case_insensitive -}; - - -static void usage(char **argv) -{ - fprintf(stderr, - "%s -e reads big-endian UTF-32 and writes AMC-ACE-M ASCII.\n" - "%s -d reads AMC-ACE-M ASCII and writes big-endian UTF-32.\n" - "UTF-32 is extended: bit 31 is used as force-to-uppercase flag.\n" - , argv[0], argv[0]); - exit(EXIT_FAILURE); -} - - -static void fail(const char *msg) -{ - fputs(msg,stderr); - exit(EXIT_FAILURE); -} - -static const char too_large[] = - "input or output is too large, recompile with larger limits\n"; - -static const char invalid_input[] = "invalid input\n"; - -int main(int argc, char **argv) -{ - enum amc_ace_status status; - - if (argc != 2) usage(argv); - if (argv[1][0] != '-') usage(argv); - if (argv[1][2] != '\0') usage(argv); - - if (argv[1][1] == 'e') { - u_code_point input[unicode_max_length]; - unsigned char uppercase_flags[unicode_max_length]; - unsigned char output[ace_max_size]; - unsigned int input_length, output_size; - int c0, c1, c2, c3; - - /* Read the UTF-32 input string: */ - - input_length = 0; - - for (;;) { - c0 = getchar(); - c1 = getchar(); - c2 = getchar(); - c3 = getchar(); - - if (c1 == EOF || c2 == EOF || c3 == EOF) { - if (c0 != EOF) fail("input not a multiple of 4 bytes\n"); - break; - } - - if (input_length == unicode_max_length) fail(too_large); - - if ((c0 != 0 && c0 != 0x80) - || c1 < 0 || c1 > 0x10 - || c2 < 0 || c2 > 0xFF - || c3 < 0 || c3 > 0xFF ) { - fail(invalid_input); - } - - input[input_length] = ((u_code_point) c1 << 16) | - ((u_code_point) c2 << 8) | (u_code_point) c3; - uppercase_flags[input_length] = (c0 >> 7); - ++input_length; - } - - /* Encode, and output the result: */ - - output_size = ace_max_size; - status = amc_ace_m_encode(input_length, input, uppercase_flags, - &output_size, output); - if (status == amc_ace_invalid_input) fail(invalid_input); - if (status == amc_ace_output_too_big) fail(too_large); - assert(status == amc_ace_success); - fputs((char *) output, stdout); - return EXIT_SUCCESS; - } - - if (argv[1][1] == 'd') { - unsigned char input[ace_max_size], scratch[ace_max_size]; - u_code_point output[unicode_max_length], codept; - unsigned char uppercase_flags[unicode_max_length]; - unsigned int output_length, i; - size_t n; - - /* Read the AMC-ACE-M ASCII input string: */ - - n = fread(input, 1, ace_max_size, stdin); - if (n == ace_max_size) fail(too_large); - input[n] = 0; - - /* Decode, and output the result: */ - - output_length = unicode_max_length; - status = amc_ace_m_decode(test_case_sensitivity, scratch, input, - &output_length, output, uppercase_flags); - if (status == amc_ace_invalid_input) fail(invalid_input); - if (status == amc_ace_output_too_big) fail(too_large); - assert(status == 0); - - for (i = 0; i < output_length; ++i) { - putchar(uppercase_flags[i] ? 0x80 : 0); - codept = output[i]; - putchar(codept >> 16); - putchar((codept >> 8) & 0xFF); - putchar(codept & 0xFF); - } - - return EXIT_SUCCESS; - } - - usage(argv); - return EXIT_SUCCESS; /* not reached, but quiets a compiler warning */ -} - - - - INTERNET-DRAFT expires 2001-Aug-12 diff --git a/doc/draft/draft-ietf-idn-amc-ace-m-01.txt b/doc/draft/draft-ietf-idn-amc-ace-m-01.txt new file mode 100644 index 0000000000..367b4c9b10 --- /dev/null +++ b/doc/draft/draft-ietf-idn-amc-ace-m-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +A. Costello: amc@cs.berkley.edu + + diff --git a/doc/draft/draft-ietf-idn-brace-00.txt b/doc/draft/draft-ietf-idn-brace-00.txt deleted file mode 100644 index be93f6a91a..0000000000 --- a/doc/draft/draft-ietf-idn-brace-00.txt +++ /dev/null @@ -1,1053 +0,0 @@ -INTERNET-DRAFT Adam M. Costello -draft-ietf-idn-brace-00.txt 2000-Sep-14 -Expires 2001-Mar-14 - - BRACE: Bi-mode Row-based ASCII-Compatible Encoding for IDN - version 0.1.2 - -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 - - Distribution of this document is unlimited. Please send comments - to the author at amc@cs.berkeley.edu, or to the idn working group - at idn@ops.ietf.org. A newer version of this specification may be - available at http://www.cs.berkeley.edu/~amc/charset/brace - -Abstract - - BRACE is a reversible function from Unicode (UTF-16) [UNICODE] - text strings to host name labels. Host name labels are defined by - [RFC952] and [RFC1123] as case-insensitive strings of ASCII letters, - digits, and hyphens, neither beginning nor ending with a hyphen. - [RFC1034] restricts the length of labels to 63 characters. - -Contents - - Primary goals - Secondary goals - Overview - Encoding procedure - Base-32 characters - Encoding styles - Decoding procedure - Comparison with RACE - Example strings - Security considerations - References - Author - Example implementation - -Primary goals - - Efficient encoding: Small ratio of encoded size to original size, - for all UTF-16 strings. - - Uniqueness: Every UTF-16 string maps to at most one label. - - Completeness: Every UTF-16 string maps to a label, provided it is - not too long. Restrictions on which UTF-16 strings are allowed is - purely a matter of policy. - - Degeneration: All valid host name labels that do not end with the - BRACE signature "-8Q9" (or "-8q9") are the BRACE encodings of their - own UTF-16 representations. - -Secondary goals - - Conceptual simplicity: This has been somewhat compromised for the - sake of efficient encoding. - - Readability: ASCII letters and digits in the original string are - represented literally in the encoded string. This comes for free - because it is the most efficient encoding anyway. - -Overview - - The encoded string alternates between two modes. ASCII letters, - digits, and hyphens in the Unicode string (which will henceforth be - called LDH characters) are encoded literally, except that hyphens - are doubled. Non-LDH codes in the Unicode string are encoded - using base-32 mode, in which each character of the encoded string - represents five bits. Single hyphens in the encoded string indicate - mode changes. - - The base-32 mode uses exactly one of four styles. Half-row style is - used for Unicode strings in which all the non-LDH codes belong to - a single half-row (have the same upper 9 bits). Full-row style is - used for Unicode strings in which all the non-LDH codes belong to a - single row (have the same upper 8 bits) but not all the same half. - Mixed style is used when when many of the non-LDH characters (but - not all of them) belong to the same row. No-row style is used for - all other strings. - -Encoding procedure - - If the UTF-16 string contains more than 63 16-bit codes, it's too - long, so abort. - - If the upper bytes are all zero, and the string formed by the lower - bytes is a valid host name label and does not end with "-8Q9" or - "-8q9", output the low bytes and stop. - - The encoder needs a bit queue capable of holding up to 22 bits, a - buffer of LDH characters capable of holding up to 124 characters, - and a 4-value encoding style indicator. The LDH buffer is initially - empty. The initial contents of the bit queue, and the value of the - style indicator, depend on which encoding style is chosen (which - is explained below). Bit strings are enqueued and dequeued in - big-endian order (most significant bit first). - - After choosing the style and initializing the bit queue, perform the - following actions: - - while the bit queue contains at least 5 bits - dequeue 5 bits - output the corresponding base-32 character - endwhile - - for each 16-bit code of the UTF-16 string (in order) do - if the code is 0x002D ("-", ASCII hyphen) then - append two hyphens to the ASCII buffer - else if the code is an LDH character then - if the LDH buffer contains no non-hyphens then - append one hyphen to the LDH buffer - endif - - append the code to the LDH buffer - else (the code is not an LDH character) - if the LDH buffer contains any non-hyphens then - append one hyphen to the LDH buffer - endif - - if the bit queue is empty then - output the LDH buffer and reset it to empty - endif - - enqueue the bit string corresponding to the code - (the bit string depends on the encoding style) - dequeue 5 bits - output the corresponding base-32 character - output the LDH buffer and reset it to empty - - while the bit queue contains at least 5 bits - dequeue 5 bits - output the corresponding base-32 character - endwhile - endif - endfor - - if the bit queue is not empty - enqueue zero bits until it contains 5 bits - dequeue 5 bits - output the corresponding base-32 character - endif - - output the LDH buffer - output the LDH characters "-8Q9" - - If the total number of characters output was greater than 63, the - string is too long for a host name label. - - Notice that a group of LDH characters appears in the output as soon - as all the bits of the preceeding non-LDH codes have appeared. The - base-32 character that appears just before the switch to literal - mode may contain at most four bits of information from the first - non-LDH character that comes after the LDH group. - -Base-32 characters - - "2" = 0 = 00000 - "3" = 1 = 00001 - "4" = 2 = 00010 - "5" = 3 = 00011 - "6" = 4 = 00100 - "7" = 5 = 00101 - "8" = 6 = 00110 - "9" = 7 = 00111 - "A" = 8 = 01000 - "B" = 9 = 01001 - "C" = 10 = 01010 - "D" = 11 = 01011 - "E" = 12 = 01100 - "F" = 13 = 01101 - "G" = 14 = 01110 - "H" = 15 = 01111 - "I" = 16 = 10000 - "J" = 17 = 10001 - "K" = 18 = 10010 - "M" = 19 = 10011 - "N" = 20 = 10100 - "P" = 21 = 10101 - "Q" = 22 = 10110 - "R" = 23 = 10111 - "S" = 24 = 11000 - "T" = 25 = 11001 - "U" = 26 = 11010 - "V" = 27 = 11011 - "W" = 28 = 11100 - "X" = 29 = 11101 - "Y" = 30 = 11110 - "Z" = 31 = 11111 - - The digits "0" and "1" and the letters "O" and "L" ("l") are not - used, to avoid transcription errors. - - The base-32 characters, like all characters in host name labels, are - case-insensitive, so they must be recognized in both upper and lower - case. However, since existing LDH labels are usually stored in - lower case, it is recommended that the base-32 portions of encoded - names be stored in upper case, to help humans easily pick out the - literal portions. - -Encoding styles - - The choice of encoding style depends only on the codes in the UTF-16 - string that are not LDH characters. It in no way depends on any LDH - codes that may be present. - - Each code belongs to a particular half-row, which is given by its - upper 9 bits. If all of the non-LDH codes belong to the same - half-row, use half-row style: Initialize the bit queue by enqueuing - two 0 bits followed by the designated half-row number (the 9-bit - half-row number shared by all the codes). During the encoding - procedure the bit string corresponding to each code is its lower 7 - bits. - - If not all the non-LDH codes belong to the same half-row, but they - all belong to the same row (same upper 8 bits), use full-row style: - Initialize the bit queue by enqueuing a 0 bit, then a 1 bit, then - the designated row number (the 8-bit row number shared by all the - codes). During the encoding procedure the bit string corresponding - to each code is its lower 8 bits. - - If not all non-LDH codes belong to the same row, then consider - using mixed style, which chooses a priviledged half-row. For each - half-row used by the non-LDH codes, count the number of codes that - belong to that half-row. Then, for each half-row, calculate M, the - number of base-32 characters that would be required if that half row - were chosen: - - N = total number of non-LDH codes - H = number of non-LDH codes in the candidate half-row - C = number of non-LDH codes in the complementary half-row (the - one with the opposite lowest bit) - M = (2 + 9 + 18*(N - H - C) + 8*H + 9*C + 4) / 5 - = 3 + (18*N - 10*H - 9*C) / 5 - - (The division is integer division, which discards any remainder.) - - Choose the half-row with the smallest M, breaking ties in favor of - lower-numbered half-rows. Compare this M with M', the number of - base-32 characters that would be required if no-row style were used: - - M' = (2 + 16*N + 4) / 5 = (6 + 16*N) / 5 - - If M' <= M, use no-row style: Initialize the bit queue by - enqueueing two 1 bits. There is no designated row number. During - the encoding procedure the bit string corresponding to each code is - the full 16-bit code itself. - - If M < M', use mixed style: Initialize the bit queue by enqueueing - a 1 bit, then a 0 bit, then the designated 9-bit half-row number - (the one chosen above). During the encoding procedure the bit - string corresponding to each code is: - - 0 followed by the lower 7 bits if the code belongs to the chosen - half-row; - - 10 followed by the lower 7 bits if the code belongs to the - complementary half-row; - - 11 followed by the whole 16-bit code otherwise. - -Decoding procedure - - The following description assumes that UTF-16 output is desired. - - If the input string does not end with "-8Q9" or "-8q9", output the - input string (converted from ASCII to UTF-16) and stop. - - The decoder needs a bit queue capable of holding up to 22 bits. It - is initially empty. It also needs a literal-mode flag, which is - initially unset, and a 4-value style indicator. - - Perform the following actions: - - read the first character and enqueue its base-32 quintet - dequeue two bits and use them to set the style indicator - - if the style uses a designated full/half row number then - while the queue does not contain enough bits to represent it - read the next character and enqueue its base-32 - endwhile - - dequeue enough bits to set the designated row (or half-row) - endif - - for each remaining input character except the last four do - if the character is an ASCII hyphen then - if the next character is also an ASCII hyphen then - skip it - output an ASCII hyphen (converted to UTF-16) - else - toggle the literal-mode flag - endif - else if the literal-mode flag is set then - output the character (converted to UTF-16) - else (the literal-mode flag is clear) - enqueue the character's base-32 quintet - - if the bit queue contains enough bits to represent a - UTF-16 code (which depends on the style indicator) - then - dequeue just enough bits to represent one code - output the code - endif - endif - endfor - - At the end the bit queue may contain up to four 0 bits. If it - contains anything else, the input was invalid. - -Comparison with RACE - - BRACE is an extension of RACE [RACE01]. For Unicode strings - that contain no LDH characters and use the full-row or no-row - encoding styles, BRACE is virtually identical to RACE. For other - strings, BRACE produces a smaller encoding than RACE. For example, - the encoding is substantially more compact for Unicode strings - containing a substantial number of LDH characters, or containing - many Japanese kana with some kanji. - - Unlike RACE, any LDH characters present in the Unicode string are - represented literally in the BRACE-encoded string. This may or may - not be useful, but it happens to be the most compact way to encode - LDH characters. - - Whereas RACE uses a signature prefix, BRACE uses a signature suffix. - This makes it easy to guarantee that the encoded label never ends - with a hyphen, even if the original UTF-16 string does. (Whether - such a UTF-16 string should be allowed is a matter of policy, not - technical capability). - - The main drawback of BRACE is its greater complexity. - -Example strings - - All of these examples use Japanese text, merely because that is the - only kind of non-English text that the author has lying around. - - Example of no-row style: - - An actual music group name coerced into the usual format for - host name labels: - - AMURONAMIE-with-super-monkeys - - AMURONAMIE stands for five kanji whose Unicode values are (in - order): - - U+5B89 U+5BA4 U+5948 U+7F8E U+6075 - - The BRACE encoding is: - - UVJ7FUAQCAHY982XA---with--super--monkeys-8Q9 - - (Note that the RACE encoding would have been 79 characters long, - and hence unusable.) - - Example of mixed style: - - An actual song title coerced into the usual format for host name - labels: - - hello-another-way-SOREZORENOBASHO - - SOREZORENOBASHO stands for five hiragana followed by two kanji, - whose Unicode values are (in order): - - U+305D U+308C U+305E U+308C U+306E U+5834 U+6240 - - The BRACE encoding is: - - JI7-hello--another--way---V3JHAEFVD2UFJ62-8Q9 - - Example of full-row style: - - An actual song title, SONOSUPIIDODE, which stands for two - hiragana followed by four katakana followed by one hiragana, - whose Unicode values are: - - U+305D U+306E U+30B9 U+30D4 U+30FC U+30C9 U+3067 - - The BRACE encoding is: - - BIDPRDMP9WT7MI-8Q9 - - Example of half-row style: - - An actual song title: - - PAFIIdeRUNBA - - PAFII stands for four katakana whose Unicode values are: - - U+30D1 U+30D5 U+30A3 U+30FC - - RUNBA stands for three katakana whose Unicode values are: - - U+30EB U+30F3 U+30D0 - - The BRACE encoding is: - - 3IU8PAZT-de-PYGI-8Q9 - - Example of an ASCII string that breaks all the rules of host name - labels: - - -> $1.00 <- - - The BRACE encoding is: - - 229--T2B4-1-W-00-I9I---8Q9 - -Security considerations - - Users expect each host name in DNS to be controlled by a single - authority. If a UTF-16 string could map to multiple labels, then - a UTF-16 host name could map to multiple real host names, each - controlled by a different authority, some of which could be spoofs - that hijack service requests intended for another. Therefore BRACE - is designed so that each UTF-16 string maps to a unique label. - - However, there can still be multiple UTF-16 representations - of the "same" text, for various definitions of "same". This - problem is addressed by the Unicode standard under the topic of - canonicalization, but the issue needs to be studied further in the - context of host names. - - Also, some text strings may be misleading or ambiguous to humans, - such as strings containing dots, slashes, at-signs, etc. Policies - for allowable Unicode strings need to be developed. - -References - - [IDN] Internationalized Domain Names (IETF working group), - http://www.i-d-n.net/, idn@ops.ietf.org. - - [RACE01] Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding - for IDN", 2000-Aug-31, draft-ietf-idn-race-01. - - [RFC952] K. Harrenstien, M. Stahl, E. Feinler, "DOD Internet Host - Table Specification", 1985-Oct, RFC 952. - - [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities", - 1987-Nov, RFC 1034. - - [RFC1123] Internet Engineering Task Force, R. Braden (editor), - "Requirements for Internet Hosts -- Application and Support", - 1989-Oct, RFC 1123. - - [SACE] Dan Oscarsson, "Simple ASCII Compatible Encoding (SACE)", - draft-ietf-idn-sace. - - [UNICODE] The Unicode Consortium, "The Unicode Standard", - http://www.unicode.org/unicode/standard/standard.html. - - [UTF5] James Seng, Martin Duerst, Tin Wee Tan, "UTF-5, a - Transformation Format of Unicode and ISO 10646", draft-jseng-utf5. - -Author - - Adam M. Costello - http://www.cs.berkeley.edu/~amc/ - - -Example implementation - - -/* brace.c 0.1.1 (2000-Sep-09-Sat) */ -/* Adam M. Costello */ - -/* This is ANSI C code implementing BRACE version 0.1.*. */ - -/* Public interface (would normally go in its own .h file): */ - -enum { - brace_encoder_in_max = 63, - brace_encoder_out_max = 4 + (6 + 16 * brace_encoder_in_max) / 5 + 1, - brace_decoder_in_max = 63 + 1, - brace_decoder_out_max = brace_decoder_in_max - 1 -}; - - /* The above constants are the maximum array sizes */ - /* that the encoder/decoder will accept/produce */ - /* (including null terminators for ASCII strings). */ - -void brace_encode( - unsigned int input_length, - unsigned short *input, - char output[brace_encoder_out_max] ); - - /* brace_encode() converts UTF-16 input to null-terminated */ - /* BRACE-encoded ASCII output. The input_length must not */ - /* exceed brace_encoder_in_max, and the output array must */ - /* have at least the size indicated below. Under those */ - /* constraints, this function never fails. */ - -int brace_decode( - char *input, - unsigned int *output_length, - unsigned short output[brace_decoder_out_max] ); - - /* brace_decode() converts null-terminated BRACE-encoded ASCII */ - /* input to UTF-16 output. The input length (including the null */ - /* terminator) must not exceed brace_encoder_in_max, and output */ - /* array must have at least the size indicated below. Returns 1 */ - /* on success, 0 if the input was malformed. If 0 is returned */ - /* the output array may contain garbage, but *output_length will */ - /* not have been affected. */ - - -/* Implementation (would normally go in its own .c file): */ - -#include - -static const char base32[] = { - 50, 51, 52, 53, 54, 55, 56, 57, 65, 66, 67, 68, 69, 70, 71, 72, - 73, 74, 75, 77, 78, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90 -}; - -/* We can't use string literals for ASCII characters because */ -/* an ANSI C compiler does not necessarily use ASCII. */ - -enum encoding_style { - half_row_style = 0, - full_row_style = 1, - mixed_style = 2, - no_row_style = 3 -}; - -/* is_ldh(code) returns 1 if the UTF-16 code represents an LDH */ -/* character (ASCII letter, digit, or hyphen), 0 otherwise. */ - -static int is_ldh(unsigned short code) -{ - if (code == 45) return 1; - if (code < 48) return 0; - if (code <= 57) return 1; - if (code < 65) return 0; - if (code <= 90) return 1; - if (code < 97) return 0; - if (code <= 122) return 1; - return 0; -} - -void brace_encode( - unsigned int input_length, - unsigned short *input, - char output[brace_encoder_out_max] ) -{ - unsigned long queue; - enum encoding_style style; - unsigned short half_rows[brace_encoder_in_max], - half_row_counts[brace_encoder_in_max]; - unsigned int num_nonldh, num_half_rows, i, half_row, j, queue_length, - best_half_row, next_literal_position, non_hyphen_flag, - next_base32_position, code; - - assert(input_length <= brace_encoder_in_max); - - /* Count the non-LDH codes and half-rows: */ - - num_nonldh = 0; - num_half_rows = 0; - - for (i = 0; i < input_length; ++i) { - if (is_ldh(input[i])) continue; - ++num_nonldh; - half_row = input[i] >> 7; - - for (j = 0; j < num_half_rows; ++j) { - if (half_rows[j] == half_row) { - ++half_row_counts[j]; - break; - } - } - - if (j == num_half_rows) { - half_rows[num_half_rows] = half_row; - half_row_counts[num_half_rows] = 1; - ++num_half_rows; - } - } - - /* If the input is already a valid label and does not end */ - /* with the BRACE signature, output it and we're done: */ - - if (num_nonldh == 0 && /* all codes are LDH and */ - input[0] != 45 && /* first not hyphen and */ - input[input_length - 1] != 45 && /* last not hyphen and */ - !( input[input_length - 1] == 57 && /* last four not -8Q9 */ - ( input[input_length - 2] == 81 || - input[input_length - 2] == 113 ) && /* (or -8q9) */ - input[input_length - 3] == 56 && - input[input_length - 4] == 45 ) ) { - for (i = 0; i < input_length; ++i) output[i] = input[i]; - output[input_length] = 0; /* null terminator */ - return; - } - - /* Choose an encoding style and initialize the bit queue: */ - - if (num_half_rows == 1) { - style = half_row_style; - queue_length = 11; - queue = half_rows[0]; - } - else if ( num_half_rows == 2 && - (half_rows[0] >> 1) == (half_rows[1] >> 1) ) { - style = full_row_style; - queue_length = 10; - queue = (1 << 8) | (half_rows[0] >> 1); - } - else { - unsigned int M, H, C, Mprime, best_M = 230; /* M is always < 230 */ - - /* Find the best half-row for mixed style: */ - - best_half_row = 512; /* half_row is always < 512 */ - - for (i = 0; i < num_half_rows; ++i) { - half_row = half_rows[i]; - H = half_row_counts[i]; - C = 0; - - for (j = 0; j < num_half_rows; ++j) { - if (j != i && (half_rows[j] >> 1) == (half_row >> 1)) { - C = half_row_counts[j]; - break; - } - } - - M = 3 + (18 * num_nonldh - 10*H - 9*C) / 5; - - if (M < best_M || (M == best_M && half_row < best_half_row)) { - best_M = M; - best_half_row = half_row; - } - } - - /* Compare mixed style to no-row style: */ - - Mprime = (6 + 16 * num_nonldh) / 5; - - if (Mprime <= best_M) { - style = no_row_style; - queue_length = 2; - queue = 3; - } - else { - style = mixed_style; - queue_length = 11; - queue = (1 << 10) | best_half_row; - } - } - - /* Flush the bit queue: */ - - next_base32_position = 0; - - while (queue_length >= 5) { - queue_length -= 5; - output[next_base32_position++] = - base32[(queue >> queue_length) & 0x1f]; - } - - /* To avoid unnecessary copies, we use the output */ - /* array itself for the LDH buffer. The following */ - /* equalities should hold whenever the buffer is empty: */ - - next_literal_position = next_base32_position + (queue_length > 0); - non_hyphen_flag = 0; /* set whenever buffer contains a non-hyphen */ - - /* Main encoding loop: */ - - for (i = 0; i < input_length; ++i) { - code = input[i]; - - if (code == 45) { - /* Encode a hyphen as two hyphens into the buffer: */ - output[next_literal_position++] = 45; - output[next_literal_position++] = 45; - } - else if (is_ldh(code)) { - if (!non_hyphen_flag) { - /* Indicate a change to literal mode: */ - output[next_literal_position++] = 45; - non_hyphen_flag = 1; - } - - /* Encode the LDH character literally: */ - output[next_literal_position++] = code; - } - else { /* non-LDH code */ - if (non_hyphen_flag) { - /* Indicate a change to base-32 mode: */ - output[next_literal_position++] = 45; - non_hyphen_flag = 0; /* we will empty the buffer */ - } - - /* If the bit queue is empty, flush the LDH buffer: */ - - if (queue_length == 0) { - next_base32_position = next_literal_position; - } - - /* Enqueue the bit string corresponding to the code: */ - - if (style == half_row_style) { - queue = (queue << 7) | (code & 0x7f); - queue_length += 7; - } - else if (style == full_row_style) { - queue = (queue << 8) | (code & 0xff); - queue_length += 8; - } - else if (style == no_row_style) { - queue = (queue << 16) | code; - queue_length += 16; - } - else /* style == mixed_style */ { - if ((code >> 7) == best_half_row) { - queue = (queue << 8) | (code & 0x7f); - queue_length += 8; - } - else if ((code >> 8) == (best_half_row >> 1)) { - queue = (queue << 9) | (1 << 8) | (code & 0x7f); - queue_length += 9; - } - else { - queue = (queue << 18) | (3ul << 16) | code; - queue_length += 18; - } - } - - /* Output one base-32 character: */ - queue_length -= 5; - output[next_base32_position] = - base32[(queue >> queue_length) & 0x1f]; - - if (next_base32_position == next_literal_position) { - /* LDH buffer is already empty. */ - ++next_base32_position; - } - else { - /* Flush the LDH buffer: */ - next_base32_position = next_literal_position; - } - - /* next_literal_position is momentarily invalid, */ - /* but we know the LDH buffer is empty. */ - - /* Flush the bit queue: */ - - while (queue_length >= 5) { - queue_length -= 5; - output[next_base32_position++] = - base32[(queue >> queue_length) & 0x1f]; - } - - /* Fix next_literal_position: */ - next_literal_position = next_base32_position + (queue_length > 0); - } - - assert(next_literal_position < brace_encoder_out_max); - } - - /* Flush the bit queue: */ - - if (queue_length > 0) { - assert(queue_length < 5); - output[next_base32_position] = - base32[(queue << (5 - queue_length)) & 0x1f]; - } - - /* Flushing the LDH buffer at this point is a no-op. */ - - /* Output "-8Q9" and the null terminator: */ - - assert(next_literal_position + 4 < brace_encoder_out_max); - output[next_literal_position++] = 45; - output[next_literal_position++] = 56; - output[next_literal_position++] = 81; - output[next_literal_position++] = 57; - output[next_literal_position] = 0; -} - -/* base32_decode() converts a base-32 character to a value from */ -/* 0 to 31. If the character is valid, its value is written to */ -/* *quintet and 1 is returned. Otherwise, *value is not changed */ -/* and 0 is returned. */ - -static int base32_decode(char c, unsigned int *quintet) -{ - if (c < 50) return 0; - if (c <= 57) { *quintet = c - 50; return 1; } - if (c < 65) return 0; - if (c >= 97) c -= 32; - if (c <= 75) { *quintet = c - 57; return 1; } - if (c == 76) return 0; - if (c <= 78) { *quintet = c - 58; return 1; } - if (c == 79) return 0; - if (c <= 90) { *quintet = c - 59; return 1; } - return 0; -} - -int brace_decode( - char *input, - unsigned int *output_length, - unsigned short output[brace_decoder_out_max] ) -{ - unsigned long queue; - unsigned int i, input_length, queue_length, literal_mode_flag, - quintet, n, next_code_position; - enum encoding_style style; - unsigned short common_prefix; - char c; - - /* Check whether input ends with "-8Q9": */ - - for (i = 0; input[i]; ++i) assert(i < brace_decoder_in_max); - - if (!(input[i-1] == 57 && input[i-3] == 56 && - input[i-4] == 45 && (input[i-2] == 81 || input[i-2] == 113))) { - - /* Copy input to output and we're done: */ - - for (i = 0; input[i]; ++i) output[i] = input[i]; - assert(i <= brace_decoder_out_max); - *output_length = i; - return 1; - } - - /* Initialize using the first base-32 character: */ - - input_length = i; - i = 0; - if (!base32_decode(input[i], &quintet)) return 0; - queue = quintet; - queue_length = 3; - literal_mode_flag = 0; - style = quintet >> 3; - - /* Determine common_prefix: */ - - if (style == no_row_style) n = 0; - else if (style == full_row_style) n = 8; - else n = 9; - - while (queue_length < n) { - if (!base32_decode(input[++i], &quintet)) return 0; - queue = (queue << 5) | quintet; - queue_length += 5; - } - - common_prefix = (queue >> (queue_length - n)) << (16 - n); - queue_length -= n; - - /* Main decoding loop: */ - - next_code_position = 0; - - while (++i < input_length - 4) { - c = input[i]; - - if (c == 45) { - if (input[i+1] == 45) { - ++i; - output[next_code_position++] = 45; /* "--" means "-" */ - } - else literal_mode_flag ^= 1; /* "-" toggles literal mode */ - } - else if (literal_mode_flag) { /* literal non-hyphen */ - output[next_code_position++] = c; - } - else { /* base-32 character */ - /* Enqueue the corresponding quintet: */ - if (!base32_decode(c, &quintet)) return 0; - queue = (queue << 5) | quintet; - queue_length += 5; - - /* If the queue contains enough bits for a UTF-16 code, */ - /* dequeue them, decode them, and output the code: */ - - if (style == no_row_style && queue_length >= 16) { - output[next_code_position++] = - (queue >> (queue_length - 16)) & 0xffff; - queue_length -= 16; - } - else if (style == full_row_style && queue_length >= 8) { - output[next_code_position++] = - common_prefix | ((queue >> (queue_length - 8)) & 0xff); - queue_length -= 8; - } - else if (style == half_row_style && queue_length >= 7) { - output[next_code_position++] = - common_prefix | ((queue >> (queue_length - 7)) & 0x7f); - queue_length -= 7; - } - else if (style == mixed_style) { - n = (queue >> (queue_length - 2)) & 3; /* top 2 bits */ - - if (n <= 1 && queue_length >= 8) { - output[next_code_position++] = - common_prefix | ((queue >> (queue_length - 8)) & 0x7f); - queue_length -= 8; - } - else if (n == 2 && queue_length >= 9) { - output[next_code_position++] = (common_prefix ^ 0x80) | - ((queue >> (queue_length - 9)) & 0x7f); - queue_length -= 9; - } - else if (n == 3 && queue_length >= 18) { - output[next_code_position++] = - (queue >> (queue_length - 18)) & 0xffff; - queue_length -= 18; - } - } - } - } - - assert(next_code_position <= brace_decoder_out_max); - - /* Check that the bit queue contains only zeros, at most four: */ - - if (queue_length > 4) return 0; - if ((queue & ((1 << queue_length) - 1)) != 0) return 0; - - /* Set the output length and we're done: */ - - *output_length = next_code_position; - return 1; -} - - -/* Wrapper for testing (would normally go in a separate .c file): */ - -#include -#include -#include - -static void usage(char **argv) -{ - fprintf(stderr, - "%s -e reads big-endian UTF-16 and writes BRACE-format ASCII.\n" - "%s -d reads BRACE-format ASCII and writes big-endian UTF-16.\n" - , argv[0], argv[0]); - exit(EXIT_FAILURE); -} - -static void fail(const char *msg) -{ - fputs(msg,stderr); - exit(EXIT_FAILURE); -} - -static const char input_too_large[] = "input is too large\n"; - -int main(int argc, char **argv) -{ - unsigned int input_length; - - if (argc != 2) usage(argv); - if (argv[1][0] != '-') usage(argv); - if (argv[1][2] != '\0') usage(argv); - - if (argv[1][1] == 'e') { - unsigned short input[brace_encoder_in_max]; - char output[brace_encoder_out_max]; - int hi, lo; - - /* Read the UTF-16 input string: */ - - input_length = 0; - - for (;;) { - hi = getchar(); - lo = getchar(); - - if (lo == EOF) { - if (hi != EOF) fail("input contained an odd number of bytes\n"); - break; - } - - if (input_length == brace_encoder_in_max) fail(input_too_large); - - if (hi > 0xff || lo > 0xff) { - fail("input bytes do not fit in 8 bits\n"); - } - - input[input_length++] = - (unsigned short) hi << 8 | (unsigned short) lo; - } - - /* Encode, and output the result: */ - - brace_encode(input_length, input, output); - if (strlen(output) > brace_decoder_in_max) fail(input_too_large); - fputs(output,stdout); - return EXIT_SUCCESS; - } - - if (argv[1][1] == 'd') { - char input[brace_decoder_in_max]; - unsigned short output[brace_decoder_out_max]; - unsigned int output_length, i; - size_t n; - - /* Read the BRACE-encoded ASCII input string: */ - - n = fread(input, 1, brace_decoder_in_max, stdin); - if (n == brace_decoder_in_max) fail(input_too_large); - input[n] = 0; - - /* Decode, and output the result: */ - - if (!brace_decode(input, &output_length, output)) { - fail("input was malformed\n"); - } - - for (i = 0; i < output_length; ++i) { - putchar(output[i] >> 8); - putchar(output[i] & 0xff); - } - - return EXIT_SUCCESS; - } - - usage(argv); - return EXIT_SUCCESS; /* not reached, but quiets compiler warning */ -} - - - - INTERNET-DRAFT expires 2001-Mar-14 diff --git a/doc/draft/draft-ietf-idn-brace-01.txt b/doc/draft/draft-ietf-idn-brace-01.txt new file mode 100644 index 0000000000..367b4c9b10 --- /dev/null +++ b/doc/draft/draft-ietf-idn-brace-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +A. Costello: amc@cs.berkley.edu + + diff --git a/doc/draft/draft-ietf-idn-dnsii-mdnp-02.txt b/doc/draft/draft-ietf-idn-dnsii-mdnp-02.txt deleted file mode 100644 index aad4f69e5c..0000000000 --- a/doc/draft/draft-ietf-idn-dnsii-mdnp-02.txt +++ /dev/null @@ -1,794 +0,0 @@ - -IDN Working Group Edmon Chung & David Leung -Internet Draft Neteka Inc. - February 2001 - - - The DNSII Multilingual Domain Name Protocol - - -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 reader is cautioned not to depend on the values that appear in - examples to be current or complete, since their purpose is primarily - educational. Distribution of this memo is unlimited. - - 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. - - A copy of this particular draft is also archived at - http://www.dnsii.org. - - -Abstract - - The core thinking for DNSII is that multilingual DNS requests SHOULD - be signaled within a DNS label whether by way of a binary tag or an - alphanumeric prefix, and that compatibility to legacy client - applications SHOULD be taken into concern alongside legacy server - implementations. - - Besides the original specifications, four alternatives including the - use of EDNS are included for discussion purposes in this document. - - Historically, the DNS is capable of handling only names within the - basic English alphanumeric character set (plus the hyphen), yet the - standards were so elegantly and openly designed that the extension of - the DNS into a multilingual and symbols based system proves to be - possible with simple adjustments. - - These adjustments will be made on both the client side and the server - side. However, DNSII works on the principal that it is preferable to - make the transition to multilingual domain names seamless and - - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - - transparent to the end-user. Which means initially the server SHOULD - take the primary responsibility for the technical implementation of - the changes required for a multilingual Internet. - - The DNSII protocol is designed to allow the preservation of - interoperability, consistency and simplicity of the original DNS, - while being expandable and flexible for the handling of any character - or symbol used for the naming of an Internet domain. DNSII intends - to provide a platform for the implementation of multilingual domain - names. - -Table Of Contents - - 1. Introduction....................................................2 - 1.1 Terminology....................................................2 - 1.2 DNSII..........................................................3 - 2. DNSII Protocol..................................................3 - 2.1 InPacket DNSII Identifier......................................3 - 2.2 InPacket Label Encoding Type (ILET)............................4 - 2.3 The Rationale for using ILET...................................5 - 2.4 Considerations for Specific Requests...........................6 - 2.4.1 PTR Records..................................................6 - 3. Alternate Implementations.......................................7 - 3.1 Restricted ILET Values.........................................7 - 3.2 Reduced ILET Bit Allocation....................................8 - 3.3 DNSII over EDNS................................................9 - 3.3.1 DNSII Identifier using EDNS..................................9 - 3.3.2 ILET using EDNS OPT RRs.....................................10 - 4. Implementation & Deployment Strategies.........................11 - 5. IDN Requirements Considerations................................12 - 6. DNSSEC, EDNS and IPv6 Considerations...........................12 - 7. Intellectual Property Considerations...........................13 - 8. References.....................................................13 - - -1. Introduction - - This Internet-draft describes details of the DNSII Multilingual - Domain Name protocol. The Internet-Draft assumes that the reader is - familiar with the concepts discussed in the widely distributed RFCs - "Domain Names Concepts and Facilities" [RFC 1034] and "Domain Names - Implementation and Specification" [RFC 1035]. - - -1.1 Terminology - - The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", - and "MAY" in this document are to be interpreted as described in RFC - 2119 [RFC2119]. - - A number of multilingual characters are used in this document for - examples. Please select your view encoding type to UTF-8 for it to - be displayed properly. - - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - - -1.2 DNSII - - The DNSII specifications takes a radically different approach: it - successfully identifies the difference between original DNS and DNSII - packets within the labels and at the same time allows the use of - multiple charsets to be easily incorporated in a standardized manner. - It causes no harm to the current DNS because it embraces the original - format for DNS laid out in RFC1035, complemented with the ideas - incorporated in EDNS [RFC2671]. - - -2. DNSII Protocol - - The DNSII Protocol consists mainly of two parts: the InPacket DNSII - Identifier and the InPacket Label Encoding Type. In addition, there - are several special considerations for specific record types. - - -2.1 InPacket DNSII Identifier - - In the DNSII specifications, an InPacket DNSII Identifier MUST be - inserted before a label to signify that it contains extended - characters that are not supported by the current DNS. - - This DNSII flag, which is the first two bits of a label, effectively - distinguishes a DNSII compliant request from the existing format, - without having to conduct a guess from a name check whether the - incoming packet is multilingual aware. This is a substantial - improvement over character encoding schemes and multilingual - implementations in which it is almost impossible to determine the - language of an incoming request. The DNSII flag makes the process - clear and simple. - - Currently: - "00" regular label [RFC1035] - "11" a redirection for DNS compression [RFC1035] - "01" indicates the use of EDNS for multiple UDP packets [RFC2671] - - DNSII calls for the use of the bit sequence "10" to identify that the - querying node is DNSII aware. This will mean that all the possible - variations at top two label bits will be used. Therefore, in - consideration, following two bits MUST be reserved for future - flagging use. The 2 bits SHOULD be arbitrarily set to "00". This - effectively opens up 3 more possible implementations for future - enhancements. - - The motivation for this approach is the belief there should be no - ambiguity in name resolution. Any name that the client wishes to - resolve, should resolve, regardless of the client side-encoding - scheme. - - - - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - -2.2 InPacket Label Encoding Type (ILET) - - Immediately following the 2 assigned DNSII flag and the 2 reserved - bits are 12 bits assigned to determine the InPacket Label Encoding - Type (ILET). - - The ILET is a 12-bit number that is used to determine the encoding - scheme used by the characters of the label. The MIBenum numbers - [RFC1700] SHOULD be used in this field. The allocation of 12 bits - aligns perfectly with the MIBenum specification, of which the value - goes up to over 2200. With 12 bits, the total possible values would - be 4096 (with 11 bits, the largest value that can be represented is - only 2047, slightly short of the specification). The reason for the - adoption of MIBenum is to make use of the existing list of encoding - numbering schemes rather than re-inventing the wheel. - - The value in the ILET field SHOULD only be allowed for the valid - encoding schemes defined in the MIBenum list. After identifying the - encoding type, the regular count-label scheme of the DNS resumes. - The resulting label should look like this: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +---+---+-------+---------------+ - |1 0| z | ILET | - +---------------+---------------+ - | COUNT | characters... | - +---------------+---------------+ - - To minimize the size of a DNS packet, if the entire label is - constituted in characters only from the ANSI table, the DNS label - will appear identical to current implementations. The first two bits - will remain "00". - For example, using the DNSII format the label for "dns" MAY be - represented as: - - 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | 1 0| 0 0| 0 0 0 0 0 0 0 0 0 0 1 1| MIBenum 3 = ANSI - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | 3 | 6 4 | "d"=64 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | 6 E | 7 3 | "n"=6E "s"=73 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - Or, the same domain label "dns" MAY also be represented as: - - 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | 3 | d | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | n | s | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - -Chung & Leung [Page 4] - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - - With a multilingual domain name ns.…––…Éì‡þ©‡´˜.tld as an example: - - 1 1 1 1 1 1 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +---------------------------------------------------------------+ - |1 0| z | ANSI=3 | 2 | n | - +---------------------------------------------------------------+ - | s |1 0|0 0| UCS-2=1000 | 4 | - +---------------------------------------------------------------+ - | …–– (U+57DF) | …Éì (U+540D) | - +---------------------------------------------------------------+ - | ‡þ© (U+7CFB) | ‡´˜ (U+7D71) | - +---------------------------------------------------------------+ - |0 0| 3 | t | l | d | - +---------------------------------------------------------------+ - | 0 | - +---------------+ - From the above example, we can see that the DNSII format is used for - the first label "ns", as well as for the second label, which is in - Chinese (the MIBenum for UCS-2 or ISO 10646 [Unicode] is 1000). The - third label "tld" however uses the current format. - - In any case, the count-label-count-label mechanism is largely - preserved. Especially in the case of extended characters where in - other proposals, the "count" no longer represents the character - count. In the above example, the domain is still represented as 2ns4 - …––…Éì‡þ©‡´˜3t ld0, exactly in line with the original specifications. - - Note that the first label in any query could be represented in DNSII - format to alert the destination server that it is DNSII aware. This - is not required but is specifically configured for the considerations - with CNAME, A6, DNAME and PTR records. - - This approach is used to ensure that there is no confusion about the - encoding format of the label. ILET allows the capability of - employing all existing encoding schemes (UTF-7, UTF-8, ISO 10646 - [UCS-2], ISO 10646 [UCS-4]). ILET also allows the flexibility of - employing future encoding schemes. - - -2.3 The Rationale for using ILET - - Besides being able to preserve the count-label-count-label structure, - which in itself is actually a very important part because of the - problematic non-uniform byte encoding schemes, the use of ILET aligns - perfectly with previous IETF specifications as well as beneficial for - tricky case folding and canonicalization issues. - - We know that all protocols MUST identify, for all character data, - which charset is in use [RFC2277], therefore it is necessary to - specify whatever encoding scheme, whether it be UTF-8, UTF-7, 16-bit - UCS-2 or ISO 8859 that is being used. In essence, we understand that - - -Chung & Leung [Page 5] - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - - it is paramount that a charset be clearly identified, especially in - situation like the DNS where no direct communication is established. - - At times and in specific cases, language information may be required - to achieve a particular level of quality for the purpose of - displaying a text stream. For example, UTF-8 encoded Han may require - transmission of a language tag to select the specific glyphs to be - displayed at a particular level of quality. - - Note that information other than language may be used to achieve the - required level of quality in a display process. In particular, a - font tag is sufficient to produce identical results. However, the - association of a language with a specific block of text has - usefulness far beyond its use in display. In particular, as the - amount of information available in multiple languages on the World - Wide Web grows, it becomes critical to specify which language is in - use in particular documents, to assist automatic indexing and - retrieval of relevant documents._ [RFC2130] - In effect, this means for different languages, it is beneficial to be - able to identify the language in order to perform specific functions - to the characters, including case folding. With ILET, the local - encoding scheme could be used and with them there are well defined - folding methods. Therefore, the use of ILET enables an optimized - folding mechanism brought about by the preservation of local encoding - schemes, which is otherwise very difficult or virtually impossible to - do if only UTF-8 is used. - - For the DNS however, a language tag is less feasible because if a - name is consisted of multiple languages, it would be very difficult - for tagging to be performed. The possibility of having multiple - languages is very sound, and is used frequently as trademarks around - the world. For example the famous Toys"ϯ"Us name, uses a character - from the Cyrillic language set. - - -2.4 Considerations for Specific Requests - - For certain requests, an ANSI only name could result in a - multilingual domain as an answer. These include PTR, CNAME, A6 and - DNAME requests. Special considerations are made within the DNSII - protocol to make sure that non-DNSII aware servers will not be fed - with a DNSII format packet. - - -2.4.1 PTR Records - - For all PTR requests, the first label of the query MUST use DNSII - format to alert the destination server. Upon which, a DNSII packet - will be replied should the name contain extended characters. - - If the DNSII format is not used, and the PTR record stumbles upon a - multilingual domain name, one of the following responses SHOULD be - given: - -Chung & Leung [Page 6] - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - - a. The implementer of DNSII MAY chose to reject the request; - - or - - b. An ACE format domain with a "for.ref.only" suffix MAY be returned; - - or - - c. A DNSII compliant server MAY return an 8-bit format of the - requested domain. - - Since the PTR record is usually used for display purposes only, the - rejection (the IP address will then be used) or ACE format is - acceptable. If the response is however used for further resolution, - an ACE format MUST not be used. - - -2.4.2 CNAME, A6 & DNAME - - For queries concerning the record types CNAME, A6 or DNAME, a DNSII - aware server should first check to see if the incoming request is - DNSII compliant (flagged by the "10" bits in the first label): - - If so, and the domain to be returned includes extended characters, - the response SHOULD be in DNSII format. - - If not, any multilingual domains returned should be in an 8 bit form. - - For the above record types it is strongly RECOMMENDED not to - associate an alphanumeric label to a multilingual label as the - RDATA. However, it is permissible to associate a multilingual label - with an alphanumeric label as the RDATA. - - -3. Alternate Implementations - - The DNSII-MDNP is intended to be a framework for the implementation - of multilingual domain names. While the core concepts and the design - principles remain consistent, it is possible to contemplate - alternative implementations. The four alternatives introduced here - include the arbitrary restriction of ILET values, the reduction of - ILET bit allocation for reflecting ISO 10646 transformations only, - and finally two implementations using DNSII over EDNS. - - -3.1 Restricted ILET Values - - One possible implementation guideline is for the ILET to be - restricted to values only representing ISO 10646 transformations - including UCS-2, UCS-4, UTF-7, UTF-8, UTF-16 and other as they become - available and included as a standard MIBenum. - - - -Chung & Leung [Page 7] - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - - Although this takes away some of the benefits of keeping the local - encoding scheme which includes the issues of case folding, - canonicalization and other related concerns, it creates a system that - on one hand contains only encoding schemes from ISO 10646, but on the - other hand still provides the flexibility of deploying new encoding - schemes that stem from ISO 10646, such as the 32-bit format that is - due to be used soon. - - We understand it is specified that in protocols, which up to now have - used US-ASCII only, UTF-8 forms a simple upgrade path; however, its - use should be negotiated either by negotiating a protocol version or - by negotiating charset usage, and a fallback to UTF-7 MUST be - available. [RFC2130] With DNSII, the required fallback to UTF-7 - could easily be done by setting the ILET value to reflect UTF-7. - - -3.2 Reduced ILET Bit Allocation - - Furthering the restriction of the ILET to ISO 10646 transformations - only, the ILET bit allocations could also be reduced from 12 bit to 5 - bit. This successfully creates a total of 32 possible values. The - reserved bits are also reduced to one. - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +---+-+---------+---------------+ - |1 0|z| ILET | COUNT | - +---------------+---------------+ - | characters... | - +---------------+ - - For example, the label "…––…Éì‡þ©‡´˜" will now be reflected in DNS packets - in the following form: - - 1 1 1 1 1 1 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +---------------------------------------------------------------+ - |1 0|z| ILET=1 | 4 | …–– (U+57DF) | - +---------------------------------------------------------------+ - | …Éì (U+540D) | ‡þ© (U+7CFB) | - +---------------------------------------------------------------+ - | ‡´˜ (U+7D71) | - +--------------------------------+ - - To start off with, the ILET values MAY be determined as follows: - - 0 = reserved for ANSI 1 = UTF-7 - 2 = UCS-2 3 = UTF-8 - 4 = UCS-4 5 = UTF-16 - 6 = 6 octets per character 7 = 7 octets per character - 8 = UCS-8 (8 octets per character) 9 = UTF-31 - etc. - - -Chung & Leung [Page 8] - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - - The ILET number will be the number of octets that should be read each - time, with exceptions at 0,3,5,9 or any number that is just after a - full UCS. ILET=3 corresponds to UTF8 because ILET=2 = UCS2 and UTF-8 - is a compatibility transformation for UCS-2 (in 16bit) in 8bit. A - possible future expansion to UCS-8 is also included to make the - schema truly future prove. - - This arrangement opens up opportunity and versatility of the use of - private schemes that make use of odd byte length characters or - symbols such as 6, 7 or even 18octet representations without the need - for the DNS to update or adjust to, while maintaining the integrity - and unique nature of domain names. - - -3.3 DNSII over EDNS - - While DNSII and EDNS could coexist, it is possible to implement the - DNSII concept onto an EDNS based platform. It is however preferable - to use both EDNS and the DNSII scheme together as described in - Section 6, because EDNS(0) compliant servers may have trouble when - the label count exceeds the value of 63 (and smaller than 127) - because then, the EDNS mechanism MAY be reiterated. - - Nevertheless, it is possible to utilize EDNS to act as a DNSII - Identifier. The short-comings and pit-falls are however further laid - in another draft DNSII-EDNS. - - -3.3.1 DNSII Identifier using EDNS - - EDNS could simply be used in place of the DNSII Identifier. Assuming - that the reduced ILET values introduced in Section 3.2 is used, the - ILET will fit nicely into one octet immediately following the ELT - portion. The resulting representation for the domain "host.…––…Éì‡þ©‡´˜ - .tld" would be as follows: - - 1 1 1 1 1 1 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +---------------------------------------------------------------+ - 20|0 0| 4 | h | o | s | - +---------------------------------------------------------------+ - | t |0 1|0 0 0 0 1 0| ILET=UCS-2=2 | 4 | - +---------------------------------------------------------------+ - | …–– (U+57DF) | …Éì (U+540D) | - +---------------------------------------------------------------+ - | ‡þ© (U+7CFB) | ‡´˜ (U+7D71) | - +---------------------------------------------------------------+ - |0 0| 3 | t | l | d | - +---------------------------------------------------------------+ - | 0 | - +---------------+ - - - -Chung & Leung [Page 9] - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - - The OPT RR could be used not only for version control but also as a - notification for the destination server on the level of conformance - of the inquirer. This is especially beneficial when considering the - issues raised in Section 2.4 where ANSI only requests my result in a - multilingual response. - - Proposed identifications within the OPT RR (used in this document for - discussion purposes): - ELT = 0b000010 - EDNS-VERSION = 2 (DNSII) - OPTION-CODE = 1 (IDN) - OPTION-DATA = conformance level (defined in DNSII-MDNR Section 4) - Plus other information if required - - The conformance level SHOULD be included in the first octet of the - OPTION-DATA field and reflect the value corresponding to: - - BASIC conformance = 1 - INTERMEDIATE conformance = 2 - FULL conformance = 3 - - A resulting DNSII OPT RR from a fully compliant inquirer SHOULD be in - the form: - - 1 1 1 1 1 1 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +---------------------------------------------------------------+ - | NAME=0 | TYPE = OPT = 41 | Sender's UDP | - +---------------------------------------------------------------+ - | Payload Size |EXTENDED-RCODE=0|EDNS-VERSION=2| z | - +---------------------------------------------------------------+ - | z | RDLENGTH = 5 | OPTION-CODE = | - +---------------------------------------------------------------+ - | IDN = 1 | OPTION-LENGTH = 1 | Conformance=3 | - +---------------------------------------------------------------+ - - -3.3.2 ILET using EDNS OPT RRs - - Instead of using the OPT RR only as a notification of DNSII - awareness, it utilized to indicate the type of encoding that is being - used in the labels. In other words, the ILET value could be included - in the OPT RR instead of within the label. - - The ILET value will be included right after the conformance level - octet in the OPTION-DATA field within the OPT RR RDATA. - - - - - - - - -Chung & Leung [Page 10] - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - - The resulting QNAME labels and OPT RR for the domain "www.…––…Éì‡þ©‡´˜ - .tld" from a fully compliant inquirer sending the name in UCS-2 - would become: - - 1 1 1 1 1 1 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +---------------------------------------------------------------+ - |0 0| 3 | w | w | w | - +---------------------------------------------------------------+ - |0 1|0 0 0 0 1 0| 4 | …–– (U+57DF) | - +---------------------------------------------------------------+ - | …Éì (U+540D) | ‡þ© (U+7CFB) | - +---------------------------------------------------------------+ - | ‡´˜ (U+7D71) |0 0| 3 | t | - +---------------------------------------------------------------+ - | l | d | 0 | - +-----------------------------------------------+ - - (OPT RR containing ILET information) - : : - / / - +---------------------------------------------------------------+ - | NAME=0 | TYPE = OPT = 41 | Sender's UDP | - +---------------------------------------------------------------+ - | Payload Size |EXTENDED RCODE=0|EDNS-VERSION=2| z | - +---------------------------------------------------------------+ - | z | RDLENGTH = 9 | OPTION-CODE = | - +---------------------------------------------------------------+ - | IDN = 1 | OPTION-LENGTH = 4 | Conformance=3 | - +---------------------------------------------------------------+ - | 1 | 0 | 0 | 0 | - +---------------------------------------------------------------+ - - - Note that instead of allocating only 12 bits for the ILET, the - MIBenum value is expressed over 4 octets with each octet carrying a - numeric value. Since UCS-2 is used and the MIBenum value for UCS-2 = - 1000, the 4 octets corresponds to the values 1, 0, 0, 0 respectively. - - If the reduced ILET values are used, only 1 octet is required to - reflect the encoding scheme being used. - - -4. Implementation & Deployment Strategies - - The first step in any multilingual domain name implementation should - be to encourage an 8-bit clean approach to DNS. However, even when - the system is 8-bit clean the problem with conflicting characters - still exists. This is where the DNSII protocol becomes most - valuable. - - Although the DNSII protocol could be implemented at any level of the - DNS, the following phased rollout is contemplated. - -Chung & Leung [Page 11] - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - - - (1) Registry Level - The most meaningful starting point for - deployment would be at the registry level since this creates the - demand from the end users to use multilingual and extended character - domain names for Second Level Domains. - - (2) Host Level - At the same time, registrants of the new extended - domain names could start to implement DNSII to host these special - kinds of domain names. All other hosts that do not wish to use - extended characters do not have to migrate to the DNSII. - - (3) Client Level - Once the multilingual aspect and the DNSII - specifications become mainstream, the user level resolvers will begin - to migrate. This will include both the client resolver as well as - the ISP's DNS. - - (4) Root Level - Eventually, as the DNSII is proven to be stable and - beneficial for the Internet at large, it could be used in the Root - Level so that new multilingual TLDs could be created. - - -5. IDN Requirements Considerations - - The DNSII protocol specification is in line with most if not all of - the requirements identified by the IDN work group. - - -6. DNSSEC, EDNS and IPv6 Considerations - - The use of DNSII should not require any adjustments with the - implementation of DNSSEC, EDNS or IPv6. EDNS as well as compression - in fact will be done exactly the same as the existing system. - For example, the domain host.dns.…––…Éì‡þ©‡´˜.tld running with EDNS as - well as compression after host will look as follows: - - - 1 1 1 1 1 1 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +---------------------------------------------------------------+ - 20|0 1| ELT |0 0| 3 | d | n | - +---------------------------------------------------------------+ - | s |1 0|0 0| UCS-2=1000 | 4 | - +---------------------------------------------------------------+ - | …–– (U+57DF) | …Éì (U+540D) | - +---------------------------------------------------------------+ - | ‡þ© (U+7CFB) | ‡´˜ (U+7D71) | - +---------------------------------------------------------------+ - |0 0| 3 | t | l | d | - +---------------------------------------------------------------+ - | 0 | - +---------------+ - - -Chung & Leung [Page 12] - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - - : : - / / - +---------------------------------------------------------------+ - |0 0| 4 | h | o | s | - +---------------------------------------------------------------+ - | t |1 1| 21 | - +-----------------------------------------------+ - - -7. Intellectual Property Considerations - - It is the intention of Neteka to submit the DNSII protocol and other - elements of the multilingual domain name server software to IETF for - review, comment or standardization. - - Neteka Inc. has applied for one or more patents on the technology - related to multilingual domain name server software and multilingual - email server software suite. If a standard is adopted by IETF and - any patents are issued to Neteka with claims that are necessary for - practicing the standard, any party will be able to obtain the right - to implement, use and distribute the technology or works when - implementing, using or distributing technology based upon the - specific specifications under fair, reasonable and non-discriminatory - terms. - - Other DNSII related documents and discussions could be found at - http://www.dnsii.org. - -8. References - - [DNSII-MDNR] E. Chung, D. Leung, _DNSII Multilingual Domain Name - Resolution_, August 2000 - - [RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, - October 1994. - - [ISO10646] ISO/IEC 10646-1:2000. International Standard - - Information technology -- Universal Multiple-Octet Coded - Character Set (UCS) - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and - Facilities," STD 13, RFC 1034, USC/ISI, November 1987 - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification," STD 13, RFC 1035, USC/ISI, November 1987 - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119, March 1997 - - [RFC2130] C. Weider, et al. _The Report of the IAB Character Set - Workshop held 29 February - 1 March, 1996_ RFC 2130, - April 1997 - - -Chung & Leung [Page 13] - DNSII-MDNP Multilingual Domain Name Protocol August 2000 - - [RFC2277] H. Alvestrand, _IETF Policy on Character Sets and - Languages_ RFC 2277, January 1998 - - [RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)", - August 1999, RFC 2671. - - - - Authors: - - Edmon Chung - Neteka Inc. - 2462 Yonge St. Toronto, - Ontario, Canada M4P 2H5 - edmon@neteka.com - - David Leung - Neteka Inc. - 2462 Yonge St. Toronto, - Ontario, Canada M4P 2H5 - david@neteka.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Chung & Leung [Page 14] diff --git a/doc/draft/draft-ietf-idn-dnsii-mdnp-03.txt b/doc/draft/draft-ietf-idn-dnsii-mdnp-03.txt new file mode 100644 index 0000000000..e21b0ca633 --- /dev/null +++ b/doc/draft/draft-ietf-idn-dnsii-mdnp-03.txt @@ -0,0 +1,20 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +E. Chung: edmon@neteka.com +D. Leung: david@neteka,com + + diff --git a/doc/draft/draft-ietf-idn-dnsii-mdnr-01.txt b/doc/draft/draft-ietf-idn-dnsii-mdnr-01.txt deleted file mode 100644 index d38aecdd4b..0000000000 --- a/doc/draft/draft-ietf-idn-dnsii-mdnr-01.txt +++ /dev/null @@ -1,841 +0,0 @@ - -IDN Working Group Edmon Chung & David Leung -Internet Draft Neteka Inc. - February 2001 - - - - DNSII Multilingual Domain Name Resolution - - -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 reader is cautioned not to depend on the values that appear in - examples to be current or complete, since their purpose is primarily - educational. Distribution of this memo is unlimited. - - 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. - - A copy of this particular draft is also archived at - http://www.dnsii.org. - - -Abstract - - This document outlines a resolution process that forms a framework - for the resolution of multilingual domain names. Additionally, a - tunneling mechanism utilizing additional RRs is introduced for the - transition to a fully multilingual capable name space. - - The Internet-Draft for DNSII-MDNP was focused purely on discussing - the ultimate packet protocol that is being sent around the Internet - for multilingual domain names. This paper complements the previous - paper by outlining the contemplated resolution process with the DNSII - protocol throughout the DNS name resolution process. - - Whether the DNSII protocol is implemented exactly as specified in - DNSII-MDNP is less relevant, rather it is the idea of having a - multilingual packet identifier and the fall back process that - matters. The DNSII-MDNR successfully addresses the transitional - issues at each node of the DNS resolution process providing a clear - migration path and strategy for the deployment of a multilingual - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - - enabled DNS system. It also outlines the conformance levels required - for basic or complete implementations for applications, resolvers and - name servers. - - -Table of Contents - - 1. Introduction....................................................2 - 1.1 Terminology....................................................2 - 1.2 Multilingual Domain Name Resolution............................3 - 1.2 DNSII-MDNR.....................................................3 - 2. DNSII Proposal with respect to the DNS Layers...................3 - 3. The Resolution Process..........................................5 - 3.1 Steady State Resolution........................................5 - 3.2 Client-End or Inquirer Transitional Fall-Back Strategy.........6 - 3.2.1 Tunneling MDNP through DNSII RR..............................6 - 3.2.2 Tunneling ILET RRs...........................................8 - 3.3 Resolvers & Server-End Transitional Fallback Strategy..........9 - 3.3.1 Tunneling MDNP Responses through DNSII ANS RR................9 - 3.3.2 Reinsertion of ILET and DNSII Identifier....................10 - 4. DNSII Conformance Levels.......................................10 - 4.1 Application Conformance Levels................................11 - 4.2 Resolver Conformance Levels...................................11 - 4.3 Authoritative Server Conformance Levels.......................11 - 5. Transition Schedule & Strategy.................................12 - 6. Summary of Discussion..........................................12 - 6.1 Client/Application Resolution Strategy........................13 - 6.2 Resolver Resolution Strategy..................................13 - 6.3 Authoritative Name Server Resolution Strategy.................13 - 7. Security Considerations........................................14 - 8. Intellectual Property Considerations...........................14 - 9. References.....................................................14 - - -1. Introduction - - This Internet-Draft describes details of the contemplated resolution - process after the deployment of DNSII-MDNP, or other multilingual - domain name efforts containing a bit flag multilingual packet - identifier or otherwise InPacket identifications for that matter. - - The reader is assumed to be familiar with the concepts discussed in - the DNSII-MDNP Internet-Draft . - - -1.1 Terminology - - The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", - and "MAY" in this document are to be interpreted as described in RFC - 2119 [RFC2119]. - - - - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - - A number of multilingual characters are used in this document for - examples. Please select your view encoding type to Big-5 - (Traditional Chinese) for them to be displayed properly. - - - - -1.2 Multilingual Domain Name Resolution - - The original specifications for the DNS were designed to be open - enough for simple implementation of a multilingual naming system with - slight adjustments as laid out in DNSII-MDNP. The transition and - especially its resolution process during migration is however a - tricky problem. Several things that MUST be kept in mind is that - there is a initial phase, an intermediate phase and an ultimate - steady state phase. DNSII-MDNP only described the ideal protocol at - steady state, with incorporated flexibility for transition from the - present to multilingual as well as again towards future unknown - grounds. - - It is important to remember that the ultimate form SHOULD be - determined and then the transition scheme laid out. While an ASCII - translation system might seem favorable in the short-run, it - effectively creates an alternative universe which is counter to the - spirit of the DNS. However an ASCII translation is implemented, it - immediately creates a "human-multilingual" universe and a "machine- - ASCII" universe. This document introduces a tunneling mechanism to - transition the DNS from today's monolingual system, through an 8-bit - or 7-bit migration scheme towards a truly sustainable multilingual - name space, arriving at a DNSII type system. - - -1.2 DNSII-MDNR - - While DNSII-MDNP describes the framework for the ultimate protocol - format of a multilingual DNS, DNSII-MDNR will discuss how the packet - SHOULD be transported and interpreted throughout the DNS. The - document will describe both the intended resolution process as well - as part of the transition strategy from the existing DNS to a DNSII - enabled system. - - -2. DNSII Proposal with respect to the DNS Layers - - The following diagram illustrates the use of DNSII-MDNP at a steady - state. Section 3 will discuss the fallback strategies while Section - 4 will talk about issues on conformance levels. - - - - - - - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - - +---------------+ - | | NamePrep: - | Application | Canonicalize in Form C/KC - | | Insert DNSII Identifier +---------------------+ - | | Insert appropriate ILET | (Base data) | - +---------------+ +---------------------+ - | | - | DNS Packet with DNSII | (no standard) - | Identifier & ILET | RECOMMENDS - | | UCS-2/4 - +---------------+ | - | Resolver | Canonicalize, Case Fold +---------------------+ - | | (for cache lookup) or | Auth DNS server | - +---------------+ leave as is & Resolve | (Canonicalize, | - | | Case Fold & Lookup) | - | Pass Along without +---------------------+ - | Altering Case or Canonicalization | - | | - | <----- DNS service interface -----> | - +------------------------------------------------------------------+ - | DNS service | - | +-----------------------+ +--------------------+ | - | | Forwarding DNS server | | Caching DNS server | | - | +-----------------------+ +--------------------+ | - | | - | +-------------------------+ | - | | Parent-zone DNS servers | | - | +-------------------------+ | - | | - | +-------------------------+ | - | | Root DNS servers | | - | +-------------------------+ | - | | - +------------------------------------------------------------------+ - - Please note that at each level, the domain name is being - canonicalized. This is to ensure that at the end, characters that - can be represented by a single code point will not be otherwise - compared resulting in inconsistent reply to a humanly identical name. - It is RECOMMENDED that applications SHOULD conduct canonicalization - while servers MUST. Duplicating the process is fine because if a - character is already composed, it will not compose again with another - character. - - This arrangement is very similar to the ASCII case folding - experienced in the DNS today. In the original specifications, it was - RECOMMENDED that query sent be left as they are and case folding done - only at the server end. Some application implementations however do - perform the case folding at the user end. As the query arrives at - the server, it is still case folded. - - - - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - - Case folding for multilingual domain names should follow the existing - implementations for ASCII names, where the application SHOULD and the - server MUST. - - -3. The Resolution Process - - It is inevitable that at the end of the day, the entire DNS chain - SHOULD be updated in order for multilingual domain names to be as - efficiently resolved as names under the current DNS. DNSII strives - to provide a schema that ultimately brings the system to a desirable - steady state while carefully giving considerations to all the - transition issues. These include the considerations that at the - application end, there is already a preference and an installed base - of character encoding that may or may not conform to the desires of - the server end operations. The use of ILET is therefore highly - desirable and essential. - - -3.1 Steady State Resolution - - At steady state, the resolution process of multilingual domain names - SHOULD be identical to the existing system. Additional steps of - going through alphanumeric translation are unnecessary and - undesirable. - - With DNSII, the contemplated steady state process resembles the well- - known DNS model laid out in RFC1035. - - - Local Host | Foreign - | - +---------+ +----------+ | +---------+ - | | user queries | |queries | | | - | |(DNSII identifier | | | | | - | | ILET=UCS without | | | | | - | User | Transformation) | | | | Foreign | - | Program |------------------>| Resolver |---------|->| Name | - | | | | | | Server | - | |<------------------| |<--------|--| | - | | user responses | |responses| | | - | | | | | | | - +---------+ +----------+ | +---------+ - | ^ | - cache additions | | references | - v | | - +----------+ | - | cache | | - +----------+ | - - - Eventually, an ISO 10646 UCS without transformation is desired as the - common format. The benefits of having a uniform byte length encoding - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - - far exceeds the seemingly easier transformation solution. Especially - considering that the DNS requires a label count that should reflect - the number of characters in a label. Of course there exists - combination characters in the ISO 10646 specifications as well, but - after canonicalization, only the ones that must use combinations - remain and they are usually meaningful depictions. - - The importance of this count value is further demonstrated by - scrambling efforts to extend the size of this field or to compress - character encoding to accommodate multilingual characters. With - DNSII, this no longer constitutes an issue because any language will - be able to share the same number of characters thanks to the use of - ISO 10646. As a matter of fact, the desire to use uniform byte - length characters formed part of the original intent of the ISO 10646 - initiative anyway. - -3.2 Client-End or Inquirer Transitional Fall-Back Strategy - - For a DNSII aware Client, it will be able to create DNSII packets - which provides precise character data of the domain name in question. - However, if it encounters a non-compliant resolver, it MUST be able - to fallback to a format acceptable by current resolvers. - - - +---------+ +----------+ - | | (1) user queries | | (2) if Resolver is - | | (DNSII identifier | | DNSII compliant, - | | ILET=UCS without | | Packet is resolved - | User | Transformation) | | accordingly. If - | Program |----------------------->| Resolver | not fallback to (3) - | | | | - | |<-----------------------| | - | | (3) Upon the detection | | - | | of the DNSII Flag | | - | | resolver will reply | | - | | with _Format Error_ | | - | | | | - | |----------------------->| | (5) Current resolu- - | | (4) Send QNAME using | | tion process begins - | | local encoding or | | with the DNSII RR - | | UTF-8 with or without | | passed along as an - | | Additional DNSII RR | | Additional RR - +---------+ +----------+ - - -3.2.1 Tunneling MDNP through DNSII RR - - An additional DNSII RR would be tunneled through using the format of - a TXT RR with the RDATA part containing the multilingual labels in a - DNSII compliant format. The TTL of the RR MUST be set to zero to - avoid caching. - - - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - - It is not feasible to have a new RR type just for DNSII because the - resolver might reject RRs with unknown types. For the name used in - the QNAME as well as the NAME field of the DNSII RR UTF-8 MAY be used - as the default fallback encoding. However, an arbitrary ASCII name - MAY also be used just for the purpose of tunneling. The TTL for - responses to tunneled requests MUST be set to zero to avoid caching - at any level in the DNS. More detailed description in Section 3.4. - - For older DNS servers, requests with a non-empty additional - information section MAY produce error returns, however since the - deployment of DNSSEC, especially for TSIG considerations, this no- - longer constitutes a problem. Basic security prepared servers such - as BIND 4 or 8 is already capable of bearing the tunneled DNSII RR. - - It is possible to use ACE/RACE type translations at this level, - however it is more advisable to use a truly arbitrary label such as - _-for-tunneling-only-_. So doing requires only reserving one - arbitrary name while ACE/RACE creates one more arbitrary name for - each new multilingual name registered, which will eventually - contribute to the fracturing of the DNS. - - As an example, a tunneling packet for the domain name: host. —ŒªW¿t™ð - .tld. (4host4—ŒªW¿t™ð3 tld0) will be represented as: - - (in the QNAME field) - - 1 1 1 1 1 1 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +---------------------------------------------------------------+ - 12|0 0| 4 | h | o | s | - +---------------------------------------------------------------+ - 16| t | 20 | - | f | - +---------------------------------------------------------------+ - 20| 0 | r | - | t | - +---------------------------------------------------------------+ - 24| u | n | n | e | - +---------------------------------------------------------------+ - 28| l | i | n | g | - +---------------------------------------------------------------+ - 32| - | o | n | l | - +---------------------------------------------------------------+ - 36| y | - | 3 | t | - +---------------------------------------------------------------+ - 40| l | d | 0 |... - +-----------------------------------------------+ - - - - - - - - - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - - (The Additional DNSII RR Tunneled in TXT RR form) - - : : - / / - +---------------------------------------------------------------+ - 80|1 1| 12 | TYPE = TXT = 16 | - +---------------------------------------------------------------+ - 84| CLASS = IN = 1 | TTL | - +---------------------------------------------------------------+ - 88| = 0 | RDLENGTH = 22 | - +---------------------------------------------------------------+ - 92|0 0| 4 | h | o | s | - +---------------------------------------------------------------+ - 96| t |1 0|0 0| UCS-2=1000 | 4 | - +---------------------------------------------------------------+ - 100|1 1| 13 |1 0|z| ILET=2 | 4 | - +---------------------------------------------------------------+ - 104| —Œ (U+57DF) | ªW (U+540D) | - +---------------------------------------------------------------+ - 108| ¿t (U+7CFB) | ™ð (U+7D71) | - +---------------------------------------------------------------+ - 112|1 1| 38 | - +-------------------------------+ - - - The reason a DNSII RR is attached is to alert the authoritative DNS - server that the query is DNSII compliant while being able to tunnel - the request through non-compliant resolvers without any loss of - information. - -3.2.2 Tunneling ILET RRs - - Another fallback strategy is to tunnel just the ILET instead of the - entire DNSII label. If UTF-8 or a local encoding is used as the - QNAME, then the arbitrary ASCII label is no longer necessary. The - tunneled RR therefore need only consist of an ILET indicating the - encoding format used. - - Within the RDATA of an ILET RR masked as a TXT RR the first 4 bytes - will be used to indicate that it is an ILET and the following 4 bytes - to reflect the MIBenum of the encoding used. - - - - - - - - - - - - - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - - Following the example given in 3.2.1, the QNAME would be in UTF-8 - (MIBenum = 106), while the additional ILET RR would be in the form: - - : : - / / - +---------------------------------------------------------------+ - 80|1 1| 12 | TYPE = TXT = 16 | - +---------------------------------------------------------------+ - 84| CLASS = IN = 1 | TTL | - +---------------------------------------------------------------+ - 88| = 0 | RDLENGTH = 22 | - +---------------------------------------------------------------+ - 92| I | L | E | T | - +---------------------------------------------------------------+ - 96| 0 | 1 | 0 | 6 | - +---------------------------------------------------------------+ - - -3.3 Resolvers & Server-End Transitional Fallback Strategy - - The tunneling scheme described in Section 3.2 assumes that the - authoritative server is fully DNSII compliant. This assertion is - laid out in Section 4.3 where it is discussed that only fully - compliant servers SHOULD serve multilingual names directly under - their authoritative zone. In any other case, the arbitrary domain - "-for-tunneling-only-" should result in an NXDomain response. - - For security aware servers, an NXT RR of the last name wrapped by its - first name in the zone records will be returned because of the - leading "-" for the tunneling label. - - If the application end is not DNSII compliant, the fallback - resolution strategy for resolvers would simply be to pass along the - labels in their 8-bit format and determine the existence of the - requested name as usual. If a tunneled DNSII RR is detected, by way - of a label constituting entirely of _-for-tunneling-only-_ and the - existence of a valid DNSII RR, the resolver should attempt to resolve - the name according to the DNSII specification and tunnel the answer - back to the inquirer. - - -3.3.1 Tunneling MDNP Responses through DNSII ANS RR - - To tunnel a DNSII compliant answer through a non-compliant resolver, - another DNSII ANS RR is tunneled. Also using the TXT RR format as a - mask. TXT RRs are best used because it is a valid RR and its RDATA - is an unrestricted byte stream determined only by the RDLENGTH. The - RDATA for a DNSII ANS RR would be the entire content of a regular - response RR attached to a DNSII format name. - - Continuing on the example given in Section 3.2, suppose an A record - is requested and the IP address returned for the domain host.—ŒªW¿t™ð - - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - - .tld. is 123.4.5.6, then an additional DNSII ANS RR (TXT) in the - following form will be included: - - : : - / / - +---------------------------------------------------------------+ - 114|1 1| 12 | TYPE = TXT = 16 | - +---------------------------------------------------------------+ - 118| CLASS = IN = 1 | TTL | - +---------------------------------------------------------------+ - 122| = 0 | RDLENGTH = 16 | - +---------------------------------------------------------------+ - 126|1 1| 92 | TYPE = A = 1 | - +---------------------------------------------------------------+ - 130| CLASS = IN = 1 | TTL | - +---------------------------------------------------------------+ - 134| = 3600 | RDLENGTH = 4 | - +---------------------------------------------------------------+ - 138| 123 | 4 | 5 | 6 | - +---------------------------------------------------------------+ - - Note that compression is available in the DNSII RRs. While the - tunneling TXT mask uses the ASCII tunneling name and therefore points - back to the QNAME at offset 12, the tunneled A Record response uses - the offset corresponding to the DNSII compliant labels at 92. While - the TTL of the TXT mask MUST be zero, the tunneled A Record RR - contains a regular TTL, in this case 3600. - - -3.3.2 Reinsertion of ILET and DNSII Identifier - - When a resolver receives an incoming query with a tunneled DNSII/ILET - RR, it SHOULD reconfigure the query into a fully compliant format - before engaging in further resolution. If a "00" query is received, - the resolver should convert the label into UTF-8, set the DNSII - identifier "10" on and set the ILET to UTF-8. - - In the scenario where the client end is not DNSII compliant, either a - local encoding 8-bit stream or a UTF-8 encoded stream without the - DNSII flag nor ILET will be transported. During the transition - period, should this occur, the above forced UTF-8 conversion and ILET - insertion would take place and it would be up to the authoritative - server to determine the existence of the requested domain. InZone - DNSII handling mechanism will serve to take care of these - transitional exceptions. - - -4. DNSII Conformance Levels - - DNSII is designed for a smooth transition from the existing ASCII - based DNS to a multilingual capable DNS. Therefore, it is not - necessary for all servers and applications to be switched to - multilingual capable before starting the deployment. - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - - - -4.1 Application Conformance Levels - - The BASIC compliancy for applications would be to remove validity - checks for domain names. The resolution process will determine a - non-existing domain name, so there really is no need to prevent a DNS - packet with multilingual labels to be sent through the wires. - - The INTERMEDIATE compliancy for applications involves the insertion - of the DNSII identifier as well as the ILET according to the local - inputting and screen scheme. If a user is using a JIS format scheme, - it should set the ILET to reflect it being used. At the same time, - the tunneling mechanism discussed in Section 3.2 MUST also be in - place. - - FULLY compliant applications will send all DNS packets with the DNSII - identifier and the ILET set to UCS-2/4. The fallback scheme discussed - in Section 3.2 MUST also be in place. InZone DNSII mechanisms SHOULD - also be available to deal with local encoding exceptions. - - -4.2 Resolver Conformance Levels - - The BASIC compliancy for resolvers would be to allow an 8-bit clean - approach to name resolution. Also, it should be made sure that the - additional DNSII RR (TXT) will not be truncated during resolution. - - The INTERMEDIATE compliant resolvers MUST understand how to process - the DNSII identifier as well as not reject the ILET. Interpretation - of the name is not required so it is NOT necessary for the resolvers - to be able to map all or any of the ILET values (with the alternative - approach in DNSII-MDNP, the ILET value corresponds to the byte length - of the characters contained in the label, which makes the count - workable even if the ILET value is not known by the resolver). In - this scenario caching will be for exact comparison only (label to - label with ILET intact). The important criteria is for the resolver - to be able to pass along the DNS query to the corresponding - authoritative server and obtain a correct response. - - FULLY compliant resolvers will be able to process the DNSII identifer - and know all the ILET values for full function name mapping. Cache - name lookup will be fully enabled and inquiry fallback mechanism - discussed in Section 3.2.2 SHOULD be performed in the event of - encountering a non-compliant server. - - -4.3 Authoritative Server Conformance Levels - - Authoritative servers MUST be fully compliant before attempting to - serve multilingual sub-domains under its authoritative zone. They - should however prepare for the transition towards a multilingual name - space even if they do not intend to deploy it right away. - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - - - The BASIC compliancy for authoritative name servers is to allow an 8- - bit clean approach towards sub-domains that are not directly under - its authority (i.e. sub-sub-domains). - - The INTERMEDIATE compliant name server will be able to process the - DNSII identifier and ILET without rejecting the query. The - authoritative zone as well as its direct sub-domains however SHOULD - not include the use of the DNSII flags because ILET values are not - understood at this compliancy level. - - FULLY compliant name servers will be able to handle DNSII compliant - label formats at its sub-domain levels. That is, fully compliant - root servers will be able to serve multilingual TLDs, fully compliant - TLD servers will be able to serve multilingual SLDs, etc. - - -5. Transition Schedule & Strategy - - DNSII is designed to allow a gradual adoption of multilingual domain - names on the Internet. The transition strategy is therefore geared - to be demand-pull instead of a technology-push incentive. However, - to provide a platform for a demand-pull approach, it is required for - operators to first safeguard their system. The simple approach as - laid out in Section 4 is to propose that servers take a 8-bit clean - approach on name resolution. - - As discussed in DNSII-MDNP, it is reasonable for the deployment of - DNSII-MDNP at the registry level first to draw demand for the service - and let the host level DNSs with multilingual names to begin - migration first. DNS operators around the world should however - prepare for the transition and begin the deployment of DNSII - depending on their interest in serving multilingual domain names, - according to the conformance levels laid out in Section 4, beginning - from BASIC compliancy for operators that are least interested to a - FULLY compliant server for operators who wishes to provide - multilingual capabilities for their users. - - The root servers could easily be adjusted to be a BASIC compliant - authoritative name server. Once the demand is proven and the - stability of the system tested, they too could transition to fully - compliant authoritative servers so that multilingual TLDs could be - rolled out. - - -6. Summary of Discussion - - This document introduces the contemplated transition and steady state - resolution process for multilingual domain names with a DNSII - compliant format. Two tunneling mechanisms using the TXT RR was - introduced for the preservation of information during transitional - resolution. - - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - -6.1 Client/Application Resolution Strategy - - Send Query in DNSII format - IF RCODE = Format Error - THEN send query in UTF-8/Local Encoding AND append DNSII RR - IF RCODE = Format Error - THEN send Query in ASCII with _-for-tunneling-only-_ label - AND append DNSII RR - AND check for DNSII ANS RR in response - ELSE proceed and check for DNSII ANS RR in response - ELSE proceed as usual - - -6.2 Resolver Resolution Strategy - - (*)IF incoming request is in pure DNSII format - THEN resolve according to ILET in cache and by recursive lookup - IF encounter RCODE = Format Error - THEN send query in UTF-8 AND append DNSII RR - IF RCODE = Format Error - THEN send query in ASCII with _-for-tunneling-only-_ - label - AND append DNSII RR - AND check for DNSII ANS RR in response - ELSE proceed and check for DNSII ANS RR in response - ELSE proceed as usual with pure DNSII Format (*) - AND respond in pure DNSII format - ELSE IF incoming request has tunneled MDNP information - THEN resolve using the information in the appended DNSII RR - Reset Query using DNSII Format and go through (*) - AND convert back to tunneling format before responding to query - With DNSII ANS RR appended to response - AND set TTL for regular RRs in the Answer field to be = 0 - ElSE IF incoming request is in the original "00" label format - AND no tunneled information is included - AND the label contains characters beyond A-z, 0-9 or "-" - THEN force convert all labels to UTF-8 - AND query using DNSII Format and go through (*) - ELSE proceed as usual (existing ASCII based names) - - -6.3 Authoritative Name Server Resolution Strategy - - IF incoming request is in pure DNSII format - THEN resolve according to ILET - AND respond in pure DNSII format - ELSE IF incoming request has tunneled MDNP information - THEN resolve using the information in the appended DNSII RR - AND convert back to tunneling format before responding to query - With DNSII ANS RR appended to response - AND set TTL for regular RRs in the Answer field to be = 0 - ELSE use InZone DNSII mechanisms AND use 8-bit clean approach - - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - -7. Security Considerations - - DNSII RRs will be secured through transaction authentication, while - DNSII ANS RRs could have their own SIG RRs. In general, the DNSII- - MDNR should not constitute any extra burden on DNS security. - - -8. Intellectual Property Considerations - - It is the intention of Neteka to submit the DNSII protocol and other - elements of the multilingual domain name server software to IETF for - review, comment or standardization. - - Neteka Inc. has applied for one or more patents on the technology - related to multilingual domain name server software and multilingual - email server software suite. If a standard is adopted by IETF and - any patents are issued to Neteka with claims that are necessary for - practicing the standard, any party will be able to obtain the right - to implement, use and distribute the technology or works when - implementing, using or distributing technology based upon the - specific specifications under fair, reasonable and non-discriminatory - terms. - - Other DNSII related documents and discussions could be found at - http://www.dnsii.org. - -9. References - - [DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name - Protocol", August 2000 - - [RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC - 1700, October 1994. - - [ISO10646] ISO/IEC 10646-1:2000. International Standard -- - Information technology -- Universal Multiple-Octet Coded - Character Set (UCS) - - [RFC1034] Mockapetris, P., "Domain Names - Concepts and - Facilities," STD 13, RFC 1034, USC/ISI, November 1987 - - [RFC1035] Mockapetris, P., "Domain Names - Implementation and - Specification," STD 13, RFC 1035, USC/ISI, November - 1987 - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119, March 1997 - - - - - - - - DNSII-MDNR Multilingual Domain Name Resolution August 2000 - - Authors: - - Edmon Chung - Neteka Inc. - 2462 Yonge St. Toronto, - Ontario, Canada M4P 2H5 - edmon@neteka.com - - David Leung - Neteka Inc. - 2462 Yonge St. Toronto, - Ontario, Canada M4P 2H5 - david@neteka.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/doc/draft/draft-ietf-idn-dnsii-mdnr-02.txt b/doc/draft/draft-ietf-idn-dnsii-mdnr-02.txt new file mode 100644 index 0000000000..e21b0ca633 --- /dev/null +++ b/doc/draft/draft-ietf-idn-dnsii-mdnr-02.txt @@ -0,0 +1,20 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +E. Chung: edmon@neteka.com +D. Leung: david@neteka,com + + diff --git a/doc/draft/draft-ietf-idn-dnsii-trace-00.txt b/doc/draft/draft-ietf-idn-dnsii-trace-00.txt deleted file mode 100644 index c6b1e69e53..0000000000 --- a/doc/draft/draft-ietf-idn-dnsii-trace-00.txt +++ /dev/null @@ -1,636 +0,0 @@ -Working Group Edmon Chung & David Leung -Internet Draft Neteka Inc. - September 2000 - - - DNSII Transitional Reflexive ASCII Compatible Encoding (TRACE) - - -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 reader is cautioned not to depend on the values that appear in - examples to be current or complete, since their purpose is primarily - educational. Distribution of this memo is unlimited. - - 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 - - ASCII Compatible Encoding (ACE) schemes should only be used as a - transitional strategy with a well-defined way forward to the eventual - enabling of a truly multilingual name space for the DNS. - - The previous DNSII documents surrounding multilingual domain names - have focused on the ultimate form with the DNSII-MDNR suggesting - possible tunneling techniques where ACE may be used. This document - furthers the discussion on an ACE system, which not only provides a - pathway towards the ultimate DNSII scheme but also an interim - solution taking care of the immediate needs. - - A reflexive CNAME process RENAME is introduced where non-ASCII - incoming queries will be automatically CNAMEd to its ASCII - counterpart without requiring an actual lookup. The resolver will - then be responsible for recursively looking up the corresponding - translated alphanumeric name. - - This document does not attempt to create another ACE scheme, instead - it discusses the way an ACE scheme could be used as a transition - towards the ultimate goal of a true multilingual name on the wire. - - -Chung & Leung [Page 1] - - DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 - -Table of Contents - - 1. Introduction....................................................2 - 1.1 Terminology....................................................2 - 2. TRACE - Introduced with Due Obsolescence........................3 - 2.1 Problems & Benefits of ACE.....................................3 - 2.2 TRACE Format...................................................3 - 2.3 TRACE Identifier...............................................3 - 2.4 TRACE Zone Handling............................................4 - 3. REflexive CNAME (RENAME)........................................4 - 3.1 Non-Recursive Name Servers with RENAME-ON......................5 - 3.1 Recursive Name Servers (Resolvers) with RENAME-ON..............6 - 3.2 Benefits of RENAME.............................................6 - 3.3 Problems with RENAME...........................................7 - 4. Use of RENAME with Respect to DNS Hierarchy.....................7 - 4.1 General Rules for using RENAME.................................8 - 4.2 Transitioning towards Identification Based DNSII...............8 - 5. Security Considerations.........................................9 - 6. Conclusion......................................................9 - 7. Intellectual Property Considerations...........................10 - 8. References.....................................................10 - - -1. Introduction - - ACE usage should be limited to machine read only and steps should be - taken to avoid the user being able to easily input the names through - an application onto the wire. This is a well-understood concept - because without this requirement, the creation of an ACE system - effectively creates an alternate universe model that is counter to - the spirit of the DNS. In essence, if an ACE scheme could easily be - typed in, people who are typing that sequence of characters may be - unexpectedly be brought to another site which happens to have the - same "code". - - TRACE outlines a scheme that uses an ACE scheme but is identified in - a 7-bit format that could not easily be typed in by a user. Thereby - preventing an inconsistent expectation of a domain name. Beyond the - specification of an identifier a RENAME function for an ACE - resolution process is also introduced. - - -1.1 Terminology - - The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", - and "MAY" in this document are to be interpreted as described in RFC - 2119 [RFC2119]. - - A number of characters used in this document are in a Big-5 encoding, - you could select your view encoding type to traditional Chinese or - Big-5 for it to be displayed properly. - - - -Chung & Leung [Page 2] - - DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 - -2. TRACE - Introduced with Due Obsolescence - - TRACE is designed to be a transitional scheme with due obsolescence - once a full-fledged DNSII mode is attained. - - -2.1 Problems & Benefits of ACE - - One of the major problems with ACE is the evident result of creating - an extra layer on top of the DNS. DNS was designed to be the human - friendly machine identifier with its names human readable. With ACE, - it is certain that an added layer is required to decode a domain - name. This also effectively results in a quasi-alternate universe - mode whereby the actual characters represent a translation into the - existing domain name space. - - However, ACE has its benefits as well and the most prominent one is - that host servers need not migrate to new name servers. Also it will - ensure that there is a lengthy enough migration period for other - applications to start adapting to the new DNS specifications. - - -2.2 TRACE Format - - TRACE does not intend to introduce a new type of encoding. Rather, - it is concerned with using a 7-bit compatible identifier and a - reflexive mechanism for switching from regular DNS packets to TRACE. - - -2.3 TRACE Identifier - - In other ACE proposals, identifiers are often created from - alphanumeric characters, which end users can easily type in. The - problem with this approach is easy to understand, for each - multilingual name, one alphanumeric name must be reserved simply for - the use of the multilingual conversion and will not be available for - normal usage. - - For example from Paul Hoffman's draft [RACE-01], the sample - conversion for a value 0x3a27 would result in a string "bq--hitq". - The name "bq--hitq" which is a perfectly usable name on its own must - now be reserved for a multilingual name. Also, 4 character spaces - will be wasted just for the identifier. - - Instead of using an alphanumeric identifier, a single 7-bit compliant - control character is used. The proposed character is the control - character with the value 0x7F. With this character, a multilingual - name part could be effectively identified while it would be very - difficult for the average user to enter the character into an - application, thereby avoiding the issue discussed above. - - In any case, an ACE form name is not intended for an end user to type - in. The only reason for ACE is that the current name servers could - -Chung & Leung [Page 3] - - DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 - - easily handle them. TRACE provides a simple and effective way which - is 7-bit compliant and a string that is could not be easily imitated. - - -2.4 TRACE Zone Handling - - A zone administrator could also easily enter the TRACE Identifier - into the zone file. To insert the TRACE Identifier in a BIND server, - the administrator could simply append the string "\127" before the - ACE label. Current BIND servers will understand that "\127" calls - for the character with the value 127 and therefore load it into - memory accordingly. The BIND should also be reconfigured to set the - options for "check-names" to "ignore". - - In the following examples, the ACE format used is simply the hex - value of the corresponding character encoding. RACE or other ACE - formats or hex of other encoding schemes may be used. - - To set up an NS record to ns1.trace.tld and an A record to 123.4.5.6 - for the name "ñññ…" in a BIND server, using UTF-8 - (E4B8AD E69687) the following lines are included into the zone file: - - \127e4b8ade69687 IN NS ns1.trace.tld. - \127e4b8ade69687 IN A 123.4.5.6 - - Section 4.3 will discuss a method to prepare the zone file for the - transition into a fully DNSII compliant mode. - - -3. REflexive CNAME (RENAME) - - To complement an ACE transition, a reflexive mechanism is introduced. - REflexive CNAME (RENAME) successfully creates a scheme whereby child - DNS nodes could keep using their BIND name servers while be capable - of hosting multilingual domain names. - - RENAME is simply a mechanism that attaches an incoming multilingual - name to its ACE counterpart as it enters a RENAME-ON name server. - When to use RENAME is discussed in Section 4. - - As an example, if an incoming query contains a the domain name "ññ - ñ….tld" .tld in UTF-8 encoding reaches a RENAME-ON - name server, the following automatic response will be created: - - ñññ….tld IN CNAME \127e4b8ade69687.tld - - If the server is in non-recursive mode, the RENAMEd name will now be - used for a lookup within the zone and the corresponding response - returned to the inquirer, including the CNAME process. If the server - is in recursive mode, the RENAMEd name will be used for lookup within - cache and passed on through the DNS hierarchy when not found. - - - -Chung & Leung [Page 4] - - DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 - -3.1 Non-Recursive Name Servers with RENAME-ON - - The two basic modes for a name server includes a non-recursive mode, - which are usually used by registries, root or authoritative host - servers; and a recursive mode, which are usually resolvers installed - in ISPs. - - A non-recursive mode server with RENAME-ON would upon receiving a - multilingual name label, automatically CNAME the name to an ACE - format. If a complete match is found, the response will be passed - back to the inquirer including the CNAME record. If no direct match - is found, it will pass along either an authoritative NXDomain or the - nearest NS Record in ACE format so that the inquirer may continue its - recursive request. - - The following diagram and descriptions details the resolution process - for the domain "www.ñññ….ñññ….tld" or . - .tld, with a DNSII TRACE RENAME-ON server installed at the - Parent domain "ñññ….tld" and a BIND server installed at the Child DNS - domain "ñññ….ñññ….tld": - - (3) - +--------+ +------------+ +---------------+ - | | (1) | | (2) | | - | Client |-------->| Resolver |-------->| Parent Domain | ñññ….tld - | |<--------| |<--------| (RENAME-ON) | - | | (8) | | (4) | | - +--------+ +------------+ +---------------+ - ^ | - | | (6) - | | (5) +--------------+ - | +-------->| | - +-----------| Child Domain | ñññ….ñññ….tld - (7) | (using BIND) | - | | - +--------------+ - - - (1) A user enters a query for the A record of "www.ñññ….ñññ….tld" or - ..tld using an ISO10646 encoding - input. - - (2) The DNS recursive resolver arrives at the parent domain "ññ - ñ….tld" .tld - - (3) With RENAME-ON and detection that the incoming query is non-ASCII, - the server reflexively assigns the CNAME to the domain: - - www.ñññ….ñññ….tld. IN CNAME www.\127e4b8ade69687. - \127e4b8ade69687.tld. - - - - -Chung & Leung [Page 5] - - DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 - - (4) Since a direct match is not found in the Parent DNS, the closest - NS record is returned to the Resolver, with the CNAME part - included: - - www.ñññ….ñññ….tld. IN CNAME www.\127e4b8ade69687. - \127e4b8ade69687.tld. - - \127e4b8ade69687.\127e4b8ade69687.tld. IN NS - ns1.\127e4b8ade69687.\127e4b8ade69687.tld. - - ns1.\127e4b8ade69687.\127e4b8ade69687.tld. IN A 123.5.6.7 - - (5) The recursive resolver passes on the request using the CNAME - record to the Child DNS as: - - www.\127e4b8ade69687.\127e4b8ade69687.tld. - - Asking for an A record for the corresponding domain. - - (6) The Child DNS simply does a regular look up for the domain with - the corresponding response. - - (7) Assuming that the correct IP address for www.ñññ….ñññ….tld is - 123.6.7.8, the response would be: - - www.\127e4b8ade69687.\127e4b8ade69687.tld. IN A 123.6.7.8 - - (8) The resolver will then respond to the client request accordingly, - including the CNAME record. - - -3.1 Recursive Name Servers (Resolvers) with RENAME-ON - - If the recursive resolver is DNSII compatible and have switched the - RENAME-ON, then both the parent and child DNSs could still run BIND - and be able to serve multilingual names. As the request goes through - the resolver, it is automatically CNAMEd to the corresponding ACE - format name and passed along for further resolution. - - When the corresponding response is obtained, the definite answer - including the CNAME record will both be passed to the client. - - -3.2 Benefits of RENAME - - The immediate benefit for using RENAME is that once it is deployed at - a particular DNS level, all its child, or sub-level DNSs could - continue to run a BIND-based or current name server while still be - capable of serving multilingual domain names. - - Most ACE implementations expect the client application to begin - migration first. This is unfortunately would take a long time - because we understand that client end migration may take years to - -Chung & Leung [Page 6] - - DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 - - complete. With RENAME however, the migration could be dynamic. - Section 4 explains further how and when RENAME should be used to - complement and facilitate the resolution of multilingual names even - when some of the components are not fully multilingual aware. - - -3.3 Problems with RENAME - - RENAME effectively creates an ACE based name space which is - ultimately undesired. Also, wherever the RENAME function is located, - it will intensify the processing requirements for the machine to - handle the conversion of the incoming multilingual label into an ACE - format and package the CNAME record accordingly. - - -4. Use of RENAME with Respect to DNS Hierarchy - - For the discussion within this document, the DNS hierarchy is - summarized into four nodes, beginning with the client end - application, through the resolver, to the root or NIC servers then - finally at the authoritative host for a second-level domain. This - more or less summarizes the DNS process from the initiation of a - request to the authoritative host. - - All together, there are 16 combinations with the basic DNS - environments. The following chart outlines the different - combinations with the denotations as: - - - B = B-DNS = Current Bind-based DNS - D = DNSII = DNSII Compliant Name Servers - RENAME(X-X-X-X) = RENAME(Client/application-Resolver-Root/NIC-Host) - with X = ON = RENAME-ON - FF = RENAME-OFF - OP = Optional ON/OFF - NA = Not Applicable - - Scenario | Client |Resolver|Root/NIC| Host | RENAME(ON/OFF) - ---------+--------+--------+--------+--------+--------------------- - 1) BBBB | B-DNS | B-DNS | B-DNS | B-DNS | existing system - +--------+--------+--------+--------+ - 2) BBBD | B-DNS | B DNS | B-DNS | DNSII | RENAME(NA-NA-NA-FF) - +--------+--------+--------+--------+ - 3) BBDB | B-DNS | B DNS | DNSII | B-DNS | RENAME(NA-NA-ON-NA) - +--------+--------+--------+--------+ - 4) BDBB | B-DNS | DNSII | B DNS | B-DNS | RENAME(NA-ON-NA-NA) - +--------+--------+--------+--------+ - 5) DBBB | DNSII | B-DNS | B-DNS | B-DNS | RENAME(ON-NA-NA-NA) - +--------+--------+--------+--------+ - 6) BBDD | B-DNS | B-DNS | DNSII | DNSII | RENAME(NA-NA-FF-FF) - +--------+--------+--------+--------+ - 7) DNND | B-DNS | DNSII | DNSII | B-DNS | RENAME(NA-OP-ON-NA) - +--------+--------+--------+--------+ - -Chung & Leung [Page 7] - - DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 - - Scenario | Client |Resolver|Root/NIC| Host | RENAME(ON/OFF) - ---------+--------+--------+--------+--------+--------------------- - 8) DDBB | DNSII | DNSII | B-DNS | B-DNS | RENAME(OP-ON-NA-NA) - +--------+--------+--------+--------+ - 9) DBBD | DNSII | B-DNS | B-DNS | DNSII | RENAME(ON-NA-NA-FF) - +--------+--------+--------+--------+ - 10) BDBD | B-DNS | DNSII | B-DNS | DNSII | RENAME(NA-ON-NA-FF) - +--------+--------+--------+--------+ - 11) DBDB | DNSII | B-DNS | DNSII | B-DNS | RENAME(ON-NA-OP-NA) - +--------+--------+--------+--------+ - 12) BDDD | B-DNS | DNSII | DNSII | DNSII | RENAME(NA-FF-FF-FF) - +--------+--------+--------+--------+ - 13) DDDB | DNSII | DNSII | DNSII | B-DNS | RENAME(OP-OP-ON-NA) - +--------+--------+--------+--------+ - 14) DDBD | DNSII | DNSII | B-DNS | DNSII | RENAME(OP-ON-NA-FF) - +--------+--------+--------+--------+ - 15) DBDD | DNSII | B-DNS | DNSII | DNSII | RENAME(ON-NA-FF-FF) - +--------+--------+--------+--------+ - 16) DDDD | DNSII | DNSII | DNSII | DNSII | Full DNSII mode - +--------+--------+--------+--------+ - - -4.1 General Rules for using RENAME - - As a general rule, RENAME should be turned on whenever there is an - anticipation that further down the DNS hierarchy or resolution - process, a host has not been migrated and is still using existing - name server software. For example, Scenario(3),(4) or (5) and their - equivalents. - - If it is known that the entire set of child hosts is DNSII compliant, - then RENAME is optional even if there exists child sub-sub-domain - host beneath the sub-domain level that uses existing name servers. - For example, Scenario(7) and the sample given in Section 3. - - The end host without any more child sub-domains SHOULD never turn on - RENAME. This consideration is given to reduce the amount of - transition traffic created due to the reflexive answer where no - further resolution is required. - - -4.2 Transitioning towards Identification Based DNSII - - Following the DNSII-MDNP recommendations, TRACE could smooth the - transition into a multilingual name space by starting at the registry - level and without requiring the host DNSs to migrate. - - As the user-end applications or recursive ISP resolvers began the - migration, new multilingual TLDs could also be introduced even before - the root servers begin any migration. - - Eventually, when the root servers migrate, they should be enabled - with both the full DNSII capability with the InPacket Identifier, - -Chung & Leung [Page 8] - - DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 - - ILET as well as TRACE as a fallback should there be any host DNS - still using existing servers. - - From the general rules, we understand that if the entire child DNSs - are DNSII enabled, then the RENAME function of the parent DNS could - be turned off. This therefore makes way for a very sensible - migration strategy owing to the hierarchical structure of the DNS. - Since a parent DNS must know a glue record for its immediate - children, it is easy for the zone administrator to determine whether - it could turn off the RENAME function for its zone. - - While it is understood that gradually, all name servers should - migrate to be DNSII capable and that multilingual names, TRACE - creates a very effective way of monitoring the migration by - encouraging child DNSs to begin transition first followed by upper - and more important levels, up to the root. - - A fully DNSII aware server should also be prepared for DNSII queries. - That is, it should be able to process requests containing the DNSII - Identifier and ILET. As a working example, a Neteka Enhanced BIND - (for a demo copy please mailto:netekare@neteka.com) has been - developed as a demonstration. To enter a full DNSII label, in the - product, simply duplicate the TRACE identifier and insert a - corresponding ILET. As an example, for "ñññ….tld" - .tld with ILET = 1000 = Unicode, an A record for the IP - address 123.4.5.6 could be added to the zone file as: - - \127\12710004e2d6587.tld. IN A 123.4.5.6 - - In such an environment, DNSII aware queries will be answered - accordingly utilizing the "\127\127" record. - - -5. Security Considerations - - The implementation of TRACE constitutes no further security burden on - the DNS. DNSSEC could be used in parallel with TRACE resolution and - records. RENAME records will be secured through transaction - authentication, while authoritative records will have their own SIG - RRs. - - Moreover, the TRACE identifier actually increases the security for - multilingual names over other ACE implementations by using the 0x7F - character, which is difficult for an end user to key in, thereby - reducing the possible confusions. - - -6. Conclusion - - With any implementation, the first step towards universal deployment - of a multilingual aware name space should be an 8-bit clean approach. - For current BIND servers it is a simple configuration matter, which - could be set as an option for checknames to be ignored. - -Chung & Leung [Page 9] - - DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 - - - With TRACE, the migration from the current system could be dynamic. - While it is encouraged that the registries begin the migration first - because it is most sensible, client end or recursive resolvers could - also begin the migration. - - The use of the control character 0x7F also solves two problems at - once: 1) a 7-bit identifier to avoid disruption of other applications - using DNS; and, 2) an identifier that is not easily input by a client - end user to prevent confusion between a multilingual name and an - English alphanumeric only name. - - RENAME successfully creates an environment where host level DNSs - could hold on to their existing BIND based name servers while being - able to host multilingual domains, thereby relieving the migration - stress for hosting facilities and ISPs. - - -7. Intellectual Property Considerations - - It is the intention of Neteka to submit the DNSII protocol and other - elements of the multilingual domain name server software to IETF for - review, comment or standardization. - - Neteka Inc. has applied for one or more patents on the technology - related to multilingual domain name server software and multilingual - email server software suite. If a standard is adopted by IETF and - any patents are issued to Neteka with claims that are necessary for - practicing the standard, any party will be able to obtain the right - to implement, use and distribute the technology or works when - implementing, using or distributing technology based upon the - specific specifications under fair, reasonable and non-discriminatory - terms. - - -8. References - - [DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name - Protocol", August 2000 - - [RACE] P. Hoffman "RACE: Row-based ASCII Compatible Encoding for - IDN", August 31, 2000 - - [RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC - 1700, October 1994. - - [ISO10646] ISO/IEC 10646-1:2000. International Standard -- - Information technology -- Universal Multiple-Octet Coded - Character Set (UCS) - - [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119, March 1997 - - -Chung & Leung [Page 10] - - DNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000 - - - Authors: - - Edmon Chung - Neteka Inc. - 2462 Yonge St. Toronto, - Ontario, Canada M4P 2H5 - edmon@neteka.com - - David Leung - Neteka Inc. - 2462 Yonge St. Toronto, - Ontario, Canada M4P 2H5 - david@neteka.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Chung & Leung [Page 11] diff --git a/doc/draft/draft-ietf-idn-dnsii-trace-01.txt b/doc/draft/draft-ietf-idn-dnsii-trace-01.txt new file mode 100644 index 0000000000..e21b0ca633 --- /dev/null +++ b/doc/draft/draft-ietf-idn-dnsii-trace-01.txt @@ -0,0 +1,20 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +E. Chung: edmon@neteka.com +D. Leung: david@neteka,com + + diff --git a/doc/draft/draft-ietf-idn-idna-03.txt b/doc/draft/draft-ietf-idn-idna-03.txt deleted file mode 100644 index c9a5bd7168..0000000000 --- a/doc/draft/draft-ietf-idn-idna-03.txt +++ /dev/null @@ -1,379 +0,0 @@ -Internet Draft Patrik Faltstrom -draft-ietf-idn-idna-03.txt Cisco -July 20, 2001 Paul Hoffman -Expires in six months IMC & VPNC - - Internationalizing Host Names In Applications (IDNA) - -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 - -The current DNS infrastructure does not provide a way to use -internationalized host names (IDN). This document describes a mechanism -that requires no changes to any DNS server or resolver that will allow -internationalized host names to be used by end users with changes only -to applications. It allows flexibility for user input and display, and -assures that host names that have non-ASCII characters are not sent to -DNS servers or resolvers. - - -1. Introduction - -In the discussion of IDN solutions, a great deal of discussion has -focused on transition issues and how IDN will work in a world where not -all of the components have been updated. Earlier proposed solutions -require that user applications, resolvers, and DNS servers to be updated -in order for a user to use an internationalized host name. Instead of -this requirement for widespread updating of all components, the current -proposal is that only user applications be updated; no changes are -needed to the DNS protocol or any DNS servers or the resolvers on user's -computers. - -This document is being discussed on the ietf-idna@mail.apps.ietf.org -mailing list. To subscribe, send a message to -ietf-idna-request@mail.apps.ietf.org with the single word "subscribe" in -the body of the message. - -1.1 Design philosophy - -Many proposals for IDN protocols have required that DNS servers be -updated to handle internationalized host names. Because of this, the -person who wanted to use an internationalized host name had to be sure -that their request went to a DNS server that was updated for IDN. -Further, that server could only send queries to other servers that had -been updated for IDN because the queries contain new protocol elements -to differentiate IDN name parts from current host parts. In addition, -these proposals require that resolvers must be updated to use the new -protocols, and in most cases the applications would need to be updated -as well. - -These proposals would require that the application protocols that use -host names as protocol elements to change. This is due to the -assumptions and requirements made in those protocols about the -characters that have always been used for host names, and the encoding -of those characters. Other proposals for IDN protocols do not require -changes to DNS servers but still require changes to most application -protocols to handle the new names. - -Updating all (or even a significant percentage) of the existing servers -in the world will be difficult, to say the least. Updating applications, -application gateways, and clients to handle changes to the application -protocols is also daunting. Because of this, we have designed a protocol -that requires no updating of any name servers. IDNA still requires the -updating of applications, but only for input and display of names, not -for changes to the protocols. Once a user has updated these, she or he -could immediately start using internationalized host names. The cost of -implementing IDN may thus be much lower, and the speed of implementation -could be much higher. - -1.2 Terminology - -The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and -"MAY" in this document are to be interpreted as described in RFC 2119 -[RFC2119]. - - -2. Structural Overview - -In IDNA, users' applications are updated to perform the processing -needed to input internationalized host names from users, display -internationalized host names that are returned from the DNS to users, -and process the inputs and outputs from the DNS. - -2.1 Interfaces between DNS components in IDNA - -The interfaces in IDNA can be represented pictorially as: - - +------+ - | User | - +------+ - ^ - |Input and display: local interface methods - |(pen, keyboard, glowing phosphorus, ...) - +-----------------|------------------------------+ - | v | - | +--------------------------+ | - | | Application | | - | +--------------------------+ | - | ^ ^ | - | Call to resolver:| |Application-specific | - | nameprepped ACE| |protocol: | - | v |predefined by the | End system - | +----------+ |protocol or defaults | - | | Resolver | |to nameprepped ACE | - | +----------+ | | - | ^ | | - +---------------|----------|---------------------+ - DNS protocol:| | - nameprepped ACE| | - v v - +-------------+ +---------------------+ - | DNS servers | | Application servers | - +-------------+ +---------------------+ - -This document uses the generic term "ACE" for an ASCII-compatible -encoding. After the IDN Working Group has chosen a specific ACE, this -document will be updated to refer to just that single ACE. Until that -time, an implementor creating experimental software must choose an ACE -to use, such as RACE or LACE or DUDE. - -2.1.1 Entry and display in applications - -Applications can accept host names using any character set or sets -desired by the application developer, and can display host names in any -charset. That is, this protocol does not affect the interface between -users and applications. - -An IDNA-aware application can accept and display internationalized host -names in two formats: the internationalized character set(s) supported -by the application, and in an ACE. Applications MAY allow ACE input and -output, but are not encouraged to do so except as an interface for -special purposes, possibly for debugging. ACE encoding is opaque and -ugly, and should thus only be exposed to users who absolutely need it. -The optional use, especially during a transition period, of ACE -encodings in the user interface is described in section 3. Because name -parts encoded with ACE can be rendered either as the encoded ASCII -characters or the proper decoded characters, the application MAY have an -option for the user to select the preferred method of display; if it -does, rendering the ACE SHOULD NOT be the default. - -Host names are often stored and transported in many places. For example, -they are part of documents such as mail messages and web pages. They are -transported in the many parts of many protocols, such as both the -control commands and the RFC 2822 body parts of SMTP, and the headers -and the body content in HTTP. - -In protocols and document formats that define how to handle -specification or negotiation of charsets, IDN host name parts can be -encoded in any charset allowed by the protocol or document format. If a -protocol or document format only allows one charset, IDN host name parts -must be given in that charset. In any place where a protocol or document -format allows transmition of the characters in IDN host name parts, IDN -host name parts SHOULD be transmitted using whatever character encoding -and escape mechanism that the protocol or document format uses at that -place. - -All protocols that have host names as protocol elements already have the -capacity for handling host names in the ASCII charset. Thus, IDN host -name parts can be specified in those protocols in the ACE charset, which -is a superset of the ASCII charset that uses the same set of octets. - -2.1.2 Applications and resolvers - -Applications communicate with resolver libraries through a programming -interface (API). Typically, the IETF does not standardize APIs, although -there are non-standard APIs specified for IPv6. This protocol does not -specify a specific API, but instead specifies only the input and output -formats of the host names to the resolver library. - -Before converting the name parts into ACE, the application MUST prepare -each name part as specified in [NAMEPREP]. The application MUST use ACE -for the name parts that are sent to the resolver, and will always get -name parts encoded in ACE from the resolver. - -IDNA-aware applications MUST be able to work with both -non-internationalized host name parts (those that conform to [STD13] and -[STD3]) and internationalized host name parts. An IDNA-aware application -that is resolving a non-internationalized host name part MUST NOT do -any preparation or conversion to ACE on any non-internationalized name -part. - -2.1.3 Resolvers and DNS servers - -An operating system might have a set of libraries for converting host -names to nameprepped ACE. The input to such a library might be in one or -more charsets that are used in applications (UTF-8 and UTF-16 are likely -candidates for almost any operating system, and script-specific charsets -are likely for localized operating systems). The output would be either -the unchanged name part (if the input already conforms to [STD13] and -[STD3]), or the nameprepped, ACE-encoded name part. - -DNS servers MUST use the ACE format for internationalized host name -parts. - -If a signalling system which makes negotiation possible between old and -new DNS clients and servers is standardized in the future, the encoding -of the query in the DNS protocol itself can be changed from ACE to -something else, such as UTF-8. The question whether or not this should -be used is, however, a separate problem and is not discussed in this -memo. - -2.1.4 Avoiding exposing users to the raw ACE encoding - -All applications that might show the user a host name that was received -from a gethostbyaddr or other such lookup SHOULD update as soon as -possible in order to prevent users from seeing the ACE. However, this is -not considered a big problem because so few applications show this type -of resolution to users. - -If an application decodes an ACE name but cannot show all of the -characters in the decoded name, such as if the name contains characters -that the output system cannot display, the application SHOULD show the -name in ACE format instead of displaying the name with the replacement -character (U+FFFD). This is to make it easier for the user to transfer -the name correctly to other programs. Programs that by default show the -ACE form when they cannot show all the characters in a name part SHOULD -also have a mechanism to show the name with as many characters as -possible and replacement characters in the positions where characters -cannot be displayed. In many cases, the application doesn't know exactly -what the underlying rendering engine can or cannot display. - -In addition to the condition above, if an application decodes an ACE -name but finds that the decoded name was not properly prepared according -to [NAMEPREP] (for example, if it has illegal characters in it), the -application SHOULD show the name in ACE format and SHOULD NOT display -the name in its decoded form. This is to avoid security issues described -in [NAMEPREP]. - -2.1.5 Automatic detection of ACE - -An application which receives a host name SHOULD verify whether or not -the host name is in ACE. This is possible by verifying the prefix in -each of the labels, and seeing whether or not the label is in ACE. This -MUST be done regardless of whether or not the communication channel used -(such as keyboard input, cut and paste, application protocol, -application payload, and so on) is encoding with ACE. - -The reason for this requirement is that many applications are not -ACE-aware. Applications that are not ACE-aware will send host names in -ACE but mark the charset as being US-ASCII or some other charset which -has the characters that are valid in [STD13] as a subset. - -2.1.6 Bidirectional text - -In IDNA, text storage and display follows the rules in the Unicode standard -[Unicode3.1]. In particular, all Unicode text is stored in logical order; -the Unicode standard has an extensive discussion of how to deal with reorder -glyphs for display when dealing with bidirectional text such as Arabic or -Hebrew. See [UAX9] for more information. - - -3. Name Server Considerations - -It is imperative that there be only one encoding for a particular host -name. ACE is an encoding for host name parts that use characters outside -those allowed for host names [STD13]. Thus, a primary master name server -MUST NOT contain an ACE-encoded name that decodes to a host name that is -allowed in [STD13] and [STD3]. - -Name servers MUST NOT have any records with host names that contain -internationalized name parts unless those name parts have be prepared -according to [NAMEPREP]. If names that are not legal in [NAMEPREP] are -passed to an application, it will result in an error being passed to the -application with no error being reported to the name server. Further, no -application will ever ask for a name that is not legal in [NAMEPREP] -because requests always go through [NAMEPREP] before getting to the DNS. -Note that [NAMEPREP] describes how to handle versioning of unallocated -codepoints. - -The host name data in zone files (as specified by section 5 of RFC 1035) -MUST be both nameprepped and ACE encoded. - - -4. Root Server Considerations - -Because there are no changes to the DNS protocols, adopting this -protocol has no effect on the DNS root servers. - - -5. Security Considerations - -Much of the security of the Internet relies on the DNS. Thus, any change -to the characteristics of the DNS can change the security of much of the -Internet. - -This memo describes an algorithm which encodes characters that are not -valid according to STD3 and STD13 into octet values that are valid. No -security issues such as string length increases or new allowed values -are introduced by the encoding process or the use of these encoded -values, apart from those introduced by the ACE encoding itself. - -When detecting an ACE-encoded host name, and decoding the ACE, care must -be taken that the resulting value(s) are valid characters which can be -handled by the application. This is described in more detail in section -2.1.4. - -Host names are used by users to connect to Internet servers. The -security of the Internet would be compromised if a user entering a -single internationalized name could be connected to different servers -based on different interpretations of the internationalized host name. - -Because this document normatively refers to [NAMEPREP], it includes the -security considerations from that document as well. - - -6. References - -[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of -Internationalized Host Names", draft-ietf-idn-nameprep. - -[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate -Requirement Levels", March 1997, RFC 2119. - -[STD3] Bob Braden, "Requirements for Internet Hosts -- Communication -Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application -and Support" (RFC 1123), STD 3, October 1989. - -[STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC -1034) and "Domain names - implementation and specification" (RFC 1035, -STD 13, November 1987. - -[UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm. -http://www.unicode.org/unicode/reports/tr9/ - -[Unicode3.1] The Unicode Standard, Version 3.1.0: The Unicode -Consortium. The Unicode Standard, Version 3.0. Reading, MA, -Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5, as amended -by: Unicode Standard Annex #27: Unicode 3.1 -. - - - -B. Changes from the -02 draft - -Editorial changes throughout - -2.1.1: Major changes to the second paragraph. Added major text to fourth -paragraph. - -2.1.4: Added to the end of the second paragraph. Added the third -paragraph. - -2.1.6: Complete change. - -6: Added [Unicode3.1] and [UAX9]. - - -C. Authors' Addresses - -Patrik Faltstrom -Cisco Systems -Arstaangsvagen 31 J -S-117 43 Stockholm Sweden -paf@cisco.com - -Paul Hoffman -Internet Mail Consortium and VPN Consortium -127 Segre Place -Santa Cruz, CA 95060 USA -phoffman@imc.org \ No newline at end of file diff --git a/doc/draft/draft-ietf-idn-idna-04.txt b/doc/draft/draft-ietf-idn-idna-04.txt new file mode 100644 index 0000000000..9b69467c40 --- /dev/null +++ b/doc/draft/draft-ietf-idn-idna-04.txt @@ -0,0 +1,550 @@ +Internet Draft Patrik Faltstrom +draft-ietf-idn-idna-04.txt Cisco +November 8, 2001 Paul Hoffman +Expires in six months IMC & VPNC + Adam M. Costello + UC Berkeley + + Internationalizing Host Names in Applications (IDNA) + +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 + +Until now, there has been no standard way for host names to use +characters outside the ASCII repertoire. This document describes a +mechanism called IDNA that enables internationalized host names, +that is, host names that use characters drawn from a much larger +repertoire. (The "D" in the name originally stood for "domain", +but the work is actually focused on host names, so the word +"host" is used throughout this document.) + + +1. Introduction + +IDNA works by allowing applications to use certain ASCII name labels +(beginning with a special prefix) to represent non-ASCII name labels. +Lower-layer protocols need not be aware of this; therefore IDNA does not +require changes to any infrastructure. In particular, IDNA does not +require any changes to DNS servers, resolvers, or protocol elements, +because the ASCII name service provided by the existing DNS is entirely +sufficient. + +This document does not require any applications to conform to IDNA, +but applications can elect to use IDNA in order to support IDN while +maintaining interoperability with existing infrastructure. Adding IDNA +support to an existing application entails changes to the application +only, and leaves room for flexibility in the user interface. + +A great deal of the discussion of IDN solutions has focused on +transition issues and how IDN will work in a world where not all of the +components have been updated. Other proposals would require that user +applications, resolvers, and DNS servers be updated in order for a user +to use an internationalized host name. Rather than require widespread +updating of all components, IDNA requires only user applications to be +updated; no changes are needed to the DNS protocol or any DNS servers or +the resolvers on user's computers. + +This document is being discussed on the ietf-idna@mail.apps.ietf.org +mailing list. To subscribe, send a message to +ietf-idna-request@mail.apps.ietf.org with the single word "subscribe" in +the body of the message. + + + +2 Terminology + +[[ Editor's note: the author's are considering changing "host name" to +"domain name" throughout the document after discussing this further +with the DNS experts. ]] + +The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and +"MAY" in this document are to be interpreted as described in RFC 2119 +[RFC2119]. + +A code point is an integral value associated with a character in a coded +character set. + +Unicode [UNICODE] is a coded character set containing tens of thousands +of characters. A single Unicode code point is denoted by "U+" followed +by four to six hexadecimal digits, while a range of Unicode code points +is denoted by two hexadecimal numbers separated by "..", with no +prefixes. + +ASCII means US-ASCII, a coded character set containing 128 characters +associated with code points in the range 0..7F. Unicode is an extension +of ASCII: it includes all the ASCII characters and associates them with +the same code points. + +The term "LDH code points" is defined in this document to mean the code +points associated with ASCII letters, digits, and the hyphen-minus; that +is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an abbreviation for +"letters, digits, hyphen". + +A host label is an individual part of a host name. Host labels are +usually shown separated by dots; for example, the host name +"www.example.com" is composed of three host labels: "www", "example", +and "com". In IDNA, not all text strings can be host labels. A string +can be a host label if and only if the ToASCII operation (see section 4) +does not fail when applied to it. (The zero-length root label that is +implied in host names, as described in [STD13], is not considered a +label in this specification.) + +An "ACE label" is defined in this document to be a host label that +contains only ASCII characters but represents a label containing +non-ASCII characters (ACE stands for "ASCII-compatible encoding"). +Internationalized host labels generally contain non-ASCII characters, +but for every host label that cannot be directly represented in ASCII +there is an equivalent ACE label. The conversion of host labels to and +from the ACE form is specified in section 4. + +The "ACE prefix" is defined in this document to be a string of ASCII +characters that appears at the beginning of every ACE label. It is +specified in section 5. + +A "host name slot" is defined in this document to be a protocol element +or a function argument or a return value (and so on) explicitly +designated for carrying a host name. Examples of host name slots +include: the QNAME field of a DNS query; the name argument of the +gethostbyname() library function; the part of an email address following +the at-sign (@) in the From: field of an email message header; and the host +portion of the URI in the src attribute of an HTML tag. +General text that just happens to contain a host name is not a host name +slot; for example, a host name appearing in the plain text body of an +email message is not occupying a host name slot. + +An "internationalized host name slot" is defined in this document to be +a host name slot explicitly designated for carrying an internationalized +host name as described in this document. The designation may be static +(for example, in the specification of the protocol or interface) or +dynamic (for example, as a result of negotiation in an interactive +session). + +A "generic host name slot" is defined in this document to be any host +name slot that is not an internationalized host name slot. Obviously, +this includes any host name slot whose specification predates IDNA. + + +3. Requirements + +IDNA conformance means adherence of the following three rules: + +1) Whenever a host name is put into a generic host name slot, every +label MUST contain only ASCII characters. Given any host name, an +equivalent host name satisfying this requirement can be obtained by +applying the ToASCII operation (see section 4) to each label. + +2) ACE labels SHOULD be hidden from users whenever possible. Therefore, +before a host name is displayed to a user or is output into a context +likely to be viewed by users, the ToUnicode operation (see section 4) +SHOULD be applied to each label. When requirements 1 and 2 both apply, +requirement 1 takes precedence. + +3) Whenever two host labels are compared, they MUST be considered to +match if and only if their ASCII forms (obtained by applying ToASCII) +match using a case-insensitive ASCII comparison. + + +4. Conversion operations + +This section specifies the ToASCII and ToUnicode operations. Each one +operates on a sequence of Unicode code points (but remember that all +ASCII code points are also Unicode code points). When host names are +represented using character sets other than Unicode and ASCII, they will +need to first be transcoded to Unicode before these operations can be +applied, and might need to be transcoded back afterwards. + +4.1 ToASCII + +The ToASCII operation takes a sequence of Unicode code points and +transforms it into a sequence of code points in the ASCII range (0..7F). +The original sequence and the resulting sequence are equivalent host +labels. + +ToASCII fails if any step of it fails. Failure means that the original +sequence cannot be used as a host label. + +ToASCII never alters a sequence of code points that are all in the ASCII +range to begin with (although it may fail). + +ToASCII consists of the following steps: + + 1. If all code points in the sequence are in the ASCII range (0..7F) + then skip to step 3. + + 2. Perform the steps specified in [NAMEPREP]. + + 3. Host-specific restrictions: + Host names have additional restrictions: + + * Verify the absence of non-LDH ASCII code points; that is, the + absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. + + * Verify the absence of leading and trailing hyphen-minus; that + is, the absence of U+002D at the beginning and end of the + sequence. + + 4. If all code points in the sequence are in the ASCII range (0..7F), + then skip to step 8. + + 5. Verify that the sequence does NOT begin with the ACE prefix. + + 6. Encode the sequence using the encoding algorithm in [AMC-ACE-Z]. + + 7. Prepend the ACE prefix. + + 8. Verify that the number of code points is in the range 1 to 63 + inclusive. + +4.2 ToUnicode + +The ToUnicode operation takes a sequence of Unicode code points and +returns a sequence of Unicode code points. If the input sequence is a +host label in ACE form, then the result is an equivalent host label +that is not in ACE form, otherwise the original sequence is returned +unaltered. + +ToUnicode never fails. If any step fails, then the original input +sequence is returned immediately in that step. + + 1. If all code points in the sequence are in the ASCII range (0..7F) + then skip to step 3. + + 2. Perform the steps specified in [NAMEPREP]. (If step 3 + of ToASCII is also performed here, it will not affect the + overall behavior of ToUnicode, but it is not necessary.) + + 3. Verify that the sequence begins with the ACE prefix, and save a + copy of the sequence. + + 4. Remove the ACE prefix. + + 5. Decode the sequence using decoding algorithm in [AMC-ACE-Z]. Save + a copy of the result of this step. + + 6. Apply ToASCII. + + 7. Verify that the sequence matches the saved copy from step 3, using + a case-insensitive ASCII comparison. + + 8. Return the saved copy from step 5. + + +5. ACE prefix + +The ACE prefix, used in the conversion operations (section 4), will +be specified in a future revision of this document. It will be two +alphanumeric ASCII characters followed by two hyphen-minuses. It MUST +be recognized in a case-insensitive manner. + +For example, the eventual ACE prefix might be the string "jk--". In this +case, an ACE label might be "jk--r3c2a-qc902xs", where "r3c2a-qc902xs" +is the part of the ACE label that is generated by the encoding steps in +[AMC-ACE-Z]. + + +6. Implications for typical applications using DNS + +In IDNA, applications perform the processing needed to input +internationalized host names from users, display internationalized +host names to users, and process the inputs and outputs from DNS and +other protocols that carry host names. + +The components and interfaces between them can be represented +pictorially as: + + +------+ + | User | + +------+ + ^ + | Input and display: local interface methods + | (pen, keyboard, glowing phosphorus, ...) + +-------------------|-------------------------------+ + | v | + | +-----------------------------+ | + | | Application | | + | | (conversion between local | | + | | character set and Unicode | | + | | is done here) | | + | +-----------------------------+ | + | ^ ^ | End system + | | | | + | Call to resolver: | | Application-specific | + | ACE | | protocol: | + | v | predefined by the | + | +----------+ | protocol or defaults | + | | Resolver | | to ACE | + | +----------+ | | + | ^ | | + +-----------------|----------|----------------------+ + DNS protocol: | | + ACE | | + v v + +-------------+ +---------------------+ + | DNS servers | | Application servers | + +-------------+ +---------------------+ + +6.1 Entry and display in applications + +Applications can accept host names using any character set or sets +desired by the application developer, and can display host names in any +charset. That is, the IDNA protocol does not affect the interface +between users and applications. + +An IDNA-aware application can accept and display internationalized host +names in two formats: the internationalized character set(s) supported +by the application, and as an ACE label. Applications MAY allow input +and display of ACE labels, but are not encouraged to do so except as an +interface for special purposes, possibly for debugging. ACE encoding is +opaque and ugly, and should thus only be exposed to users who absolutely +need it. The optional use, especially during a transition period, of ACE +encodings in the user interface is described in section 6.4. Because +name labels encoded as ACE name labels can be rendered either as the +encoded ASCII characters or the proper decoded characters, the +application MAY have an option for the user to select the preferred +method of display; if it does, rendering the ACE SHOULD NOT be the +default. + +Host names are often stored and transported in many places. For example, +they are part of documents such as mail messages and web pages. They are +transported in the many parts of many protocols, such as both the +control commands and the RFC 2822 body parts of SMTP, and the headers +and the body content in HTTP. It is important to remember that host +names appear both in host name slots and in the content that is passed +over protocols. + +In protocols and document formats that define how to handle +specification or negotiation of charsets, IDN host name labels can be +encoded in any charset allowed by the protocol or document format. If a +protocol or document format only allows one charset, IDN host name +labels MUST be given in that charset. In any place where a protocol or +document format allows transmission of the characters in IDN host name +labels, IDN host name labels SHOULD be transmitted using whatever +character encoding and escape mechanism that the protocol or document +format uses at that place. + +All protocols that have generic host name slots already have the +capacity for handling host names in the ASCII charset. Thus, IDN host +name labels that have been processed with the ToASCII operation can +inherently be handled by those protocols. + +6.2 Applications and resolvers + +Applications communicate with resolver libraries through a programming +interface (API). Typically, the IETF does not standardize APIs, although +there are non-standard APIs specified for IPv6. This protocol does not +specify a specific API, but instead specifies the operations that must +be used for input to and output from the resolver library. + +An application MUST prepapre name parts that are sent in the DNS +protocol using the ToASCII operation. Internationalized labels received +from the resolver will always be in ACE form. IDNA-aware applications +MUST be able to work with both non-internationalized host name labels +(those that conform to [STD13] and [STD3]) and internationalized host +name labels. + +6.3 Resolvers and DNS servers + +An operating system might have a set of libraries for performing the +ToASCII operation. The input to such a library might be in one or more +charsets that are used in applications (UTF-8 and UTF-16 are likely +candidates for almost any operating system, and script-specific charsets +are likely for localized operating systems). + +DNS servers MUST use the ACE format for internationalized host labels. +All internationalized names stored in DNS servers must be valid names +that have been processed with the ToASCII operation. + +If a signalling system which makes negotiation possible between old and +new DNS clients and servers is standardized in the future, the encoding +of the query in the DNS protocol itself can be changed from ACE to +something else, such as UTF-8. The question whether or not this should +be used is, however, a separate problem and is not discussed in this +memo. + +6.4 Avoiding exposing users to the raw ACE encoding + +All applications that might show the user a host name that was received +from a gethostbyaddr or other such lookup SHOULD update as soon as +possible in order to prevent users from seeing the ACE. However, this is +not considered a big problem because so few applications show this type +of resolution to users. + +If an application decodes an ACE name using ToUnicode but cannot show +all of the characters in the decoded name, such as if the name contains +characters that the output system cannot display, the application SHOULD +show the name in ACE format instead of displaying the name with the +replacement character (U+FFFD). This is to make it easier for the user +to transfer the name correctly to other programs. Programs that by +default show the ACE form when they cannot show all the characters in a +name label SHOULD also have a mechanism to show the name that is +produced by the ToUnicode operation with as many characters as possible +and replacement characters in the positions where characters cannot be +displayed. In many cases, the application doesn't know exactly what the +underlying rendering engine can or cannot display. + +In addition to the condition above, if an application receives an ACE +host name after performing the ToUnicode operation, meaning that the +name was not properly prepared with ToASCII (for example, if it has +illegal characters in it), the application MUST show the name in ACE +format because the ToUnicode operation never fails, but returns the +original input if errors are detected at any step. + +6.5 Bidirectional text in host names + +The display of host names that contain bidirectional text is not covered +in this document. It may be covered in a future version of this +document, or may be covered in a different document. + +For developers interested in displaying host names that have +bidirectional text, the Unicode standard has an extensive discussion of +how to deal with reorder glyphs for display when dealing with +bidirectional text such as Arabic or Hebrew. See [UAX9] for more +information. In particular, all Unicode text is stored in logical order. + + +7. Name Server Considerations + +Internationalized host name data in zone files (as specified by section +5 of RFC 1035) MUST be processed with ToASCII before it is entered in +the zone files. + +It is imperative that there be only one ASCII encoding for a particular +host name. ACE is an encoding for host name labels that use non-ASCII +characters. Thus, a primary master name server MUST NOT contain an +ACE-encoded label that decodes to an ASCII label. The ToASCII operation +assures that no such names are ever output from the operation. + +Name servers MUST NOT have any records with host names that contain +internationalized name labels unless those name labels have be prepared +with the ToASCII operation. If names that are not processed by ToASCII +are passed to an application, it will result in unpredictable behavior. +Note that [NAMEPREP] describes how to handle versioning of unallocated +codepoints. + + +8. Root Server Considerations + +Because there are no changes to the DNS protocols, adopting this +protocol has no effect on the DNS root servers. + + +9. Security Considerations + +Much of the security of the Internet relies on the DNS. Thus, any change +to the characteristics of the DNS can change the security of much of the +Internet. + +This memo describes an algorithm which encodes characters that are not +valid according to STD3 and STD13 into octet values that are valid. No +security issues such as string length increases or new allowed values +are introduced by the encoding process or the use of these encoded +values, apart from those introduced by the ACE encoding itself. + +Host names are used by users to connect to Internet servers. The +security of the Internet would be compromised if a user entering a +single internationalized name could be connected to different servers +based on different interpretations of the internationalized host name. + +Because this document normatively refers to [NAMEPREP], it includes the +security considerations from that document as well. + + +A. References + +[AMC-ACE-Z] Adam Costello, "AMC-ACE-Z version 0.3.1", +draft-ietf-idn-amc-ace-z. + +[NAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of +Internationalized Host Names", draft-ietf-idn-nameprep. + +[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate +Requirement Levels", March 1997, RFC 2119. + +[STD3] Bob Braden, "Requirements for Internet Hosts -- Communication +Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application +and Support" (RFC 1123), STD 3, October 1989. + +[STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC +1034) and "Domain names - implementation and specification" (RFC 1035, +STD 13, November 1987. + +[UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm. +http://www.unicode.org/unicode/reports/tr9/ + +[UNICODE] The Unicode Standard, Version 3.1.0: The Unicode Consortium. +The Unicode Standard, Version 3.0. Reading, MA, Addison-Wesley +Developers Press, 2000. ISBN 0-201-61633-5, as amended by: Unicode +Standard Annex #27: Unicode 3.1 +. + + +B. Design philosophy + +Many proposals for IDN protocols have required that DNS servers be +updated to handle internationalized host names. Because of this, a +person who wanted to use an internationalized host name would have to be +sure that their request went to a DNS server that had been updated for +IDN. Further, that server could send queries only to other servers that +had been updated for IDN, because the queries contain new protocol +elements to differentiate IDN name labels from current host labels. In +addition, these proposals require that resolvers be updated to use the +new protocols, and in most cases the applications would need to be +updated as well. + +These proposals would require changes to the application protocols that +use host names as protocol elements, because of the assumptions and +requirements made in those protocols about the characters that have +always been used for host names, and the encoding of those characters. +Other proposals for IDN protocols do not require changes to DNS servers +but still require changes to most application protocols to handle the +new names. + +Updating all (or even a significant percentage) of the existing servers +in the world will be difficult, to say the least. Updating applications, +application gateways, and clients to handle changes to the application +protocols is also daunting. Because of this, we have designed a protocol +that requires no updating of any name servers. IDNA still requires the +updating of applications, but only for input and display of names, not +for changes to the protocols. Once users have updated the applications, +they can immediately start using internationalized host names. The cost +of implementing IDN may thus be much lower, and the speed of +implementation could be much higher. + + +C. Authors' Addresses + +Patrik Faltstrom +Cisco Systems +Arstaangsvagen 31 J +S-117 43 Stockholm Sweden +paf@cisco.com + +Paul Hoffman +Internet Mail Consortium and VPN Consortium +127 Segre Place +Santa Cruz, CA 95060 USA +phoffman@imc.org + +Adam M. Costello +University of California, Berkeley +idna-spec.amc @ nicemice.net \ No newline at end of file diff --git a/doc/draft/draft-ietf-idn-lace-01.txt b/doc/draft/draft-ietf-idn-lace-01.txt deleted file mode 100644 index 56ea433bf5..0000000000 --- a/doc/draft/draft-ietf-idn-lace-01.txt +++ /dev/null @@ -1,859 +0,0 @@ -Internet Draft Mark Davis -draft-ietf-idn-lace-01.txt IBM -January 5, 2001 Paul Hoffman -Expires July 5, 2001 IMC & VPNC - - LACE: Length-based ASCII Compatible Encoding for IDN - -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 transformation method for representing -non-ASCII characters in host name parts in a fashion that is completely -compatible with the current DNS. It is a potential candidate for an -ASCII-Compatible Encoding (ACE) for internationalized host names, as -described in the comparison document from the IETF IDN Working Group. -This method is based on the observation that many internationalized host -name parts will have a few substrings from a small number of rows of the -ISO 10646 repertoire. Run-length encoding for these types of -host names will be fairly compact, and is fairly easy to describe. - - -1. Introduction - -There is a strong world-wide desire to use characters other than plain -ASCII in host names. Host names have become the equivalent of business -or product names for many services on the Internet, so there is a need -to make them usable by people whose native scripts are not representable -by ASCII. The requirements for internationalizing host names are -described in the IDN WG's requirements document, [IDNReq]. - -The IDN WG's comparison document [IDNComp] describes three potential -main architectures for IDN: arch-1 (just send binary), arch-2 (send -binary or ACE), and arch-3 (just send ACE). LACE is an ACE, called -Length-based ACE or LACE, that can be used with protocols that match arch-2 -or arch-3. LACE specifies an ACE format as specified in ace-1 in -[IDNComp]. Further, it specifies an identifying mechanism for ace-2 in -[IDNComp], namely ace-2.1.1 (add hopefully-unique legal tag to the -beginning of the name part). - -In formal terms, LACE describes a character encoding scheme of the -ISO/IEC 10646 [ISO10646] coded character set (whose assignment of -characters is synchronized with Unicode [Unicode3]) and the rules for -using that scheme in the DNS. As such, it could also be called a -"charset" as defined in [IDNReq]. It can also be viewed as a specialized -UTF (transformation format), designed to work within the restrictions of -the DNS. - -The LACE protocol has the following features: - -- There is exactly one way to convert internationalized host parts to -and from LACE parts. Host name part uniqueness is preserved. - -- Host parts that have no international characters are not changed. - -- Names using LACE can include more internationalized characters than -with other ACE protocols that have been suggested to date. LACE-encoded -names are variable length, depending on the number of transitions -between rows in the ISO 10646 repertoire that appear in the name part. -Name parts that cannot be compressed using run-length encoding can have -up to 17 characters, and names that can be compressed can have up to 35 -characters. Further, a name that has just a few row transitions -typically can have over 30 characters. - -It is important to note that the following sections contain many -normative statements with "MUST" and "MUST NOT". Any implementation that -does not follow these statements exactly is likely to cause damage to -the Internet by creating non-unique representations of host names. - -1.1 Terminology - -The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and -"MAY" in this document are to be interpreted as described in RFC 2119 -[RFC2119]. - -Hexadecimal values are shown preceded with an "0x". For example, -"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are -shown preceded with an "0b". For example, a nine-bit value might be -shown as "0b101101111". - -Examples in this document use the notation for code points and names -from the Unicode Standard [Unicode3] and ISO 10646. For example, the -letter "a" may be represented as either "U+0061" or "LATIN SMALL LETTER -A". - -LACE converts strings with internationalized characters into -strings of US-ASCII that are acceptable as host name parts in current -DNS host naming usage. The former are called "pre-converted" and the -latter are called "post-converted". - -1.2 IDN summary - -Using the terminology in [IDNComp], LACE specifies an ACE format as -specified in ace-1. Further, it specifies an identifying mechanism for -ace-2, namely ace-2.1.1 (add hopefully-unique legal tag to the beginning -of the name part). - -LACE has the following length characteristics. - -- LACE-encoded names are variable length, depending on the number of -transitions between rows that appear in the name part. - -- Name parts that cannot be compressed using run-length encoding can -have up to 17 characters. - -- Names that can be compressed can have up to 35 characters. - --A name that has just a few row transitions typically can have over 30 -characters. - - -2. Host Part Transformation - -According to [STD13], host parts must be case-insensitive, start and -end with a letter or digit, and contain only letters, digits, and the -hyphen character ("-"). This, of course, excludes any internationalized -characters, as well as many other characters in the ASCII character -repertoire. Further, domain name parts must be 63 octets or shorter in -length. - -2.1 Name tagging - -All post-converted name parts that contain internationalized characters -begin with the string "lq--". (Of course, because host name parts are -case-insensitive, this might also be represented as "Lq--" or "lQ--" or -"LQ--".) The string "lq--" was chosen because it is extremely unlikely -to exist in host parts before this specification was produced. As a -historical note, in late October 2000, none of the second-level host -name parts in any of the .com, .edu, .net, and .org top-level domains -began with "lq--"; there are many tens of thousands of other strings of -three characters followed by a hyphen that have this property and could -be used instead. The string "lq--" will change to other strings with the -same properties in future versions of this draft. - -Note that a zone administrator might still choose to use "lq--" at the -beginning of a host name part even if that part does not contain -internationalized characters. Zone administrators SHOULD NOT create host -part names that begin with "lq--" unless those names are post-converted -names. Creating host part names that begin with "lq--" but that are not -post-converted names may cause two distinct problems. Some display -systems, after converting the post-converted name part back to an -internationalized name part, might display the name parts in a -possibly-confusing fashion to users. More seriously, some resolvers, -after converting the post-converted name part back to an -internationalized name part, might reject the host name if it contains -illegal characters. - -2.2 Converting an internationalized name to an ACE name part - -To convert a string of internationalized characters into an ACE name -part, the following steps MUST be preformed in the exact order of the -subsections given here. - -If a name part consists exclusively of characters that conform to the -host name requirements in [STD13], the name MUST NOT be converted to -LACE. That is, a name part that can be represented without LACE MUST NOT -be encoded using LACE. This absolute requirement prevents there from -being two different encodings for a single DNS host name. - -If any checking for prohibited name parts (such as ones that are -prohibited characters, case-folding, or canonicalization) is to be done, -it MUST be done before doing the conversion to an ACE name part. - -Characters outside the first plane of characters (those with codepoints -above U+FFFF) MUST be represented using surrogates, as described in -RFC 2781 [RFC2781]. - -The input name string consists of characters from the ISO 10646 -character set in big-endian UTF-16 encoding. This is the pre-converted -string. - -2.2.1 Check the input string for disallowed names - -If the input string consists only of characters that conform to the host -name requirements in [STD13], the conversion MUST stop with an error. - -2.2.2 Compress the pre-converted string - -The entire pre-converted string MUST be compressed using the compression -algorithm specified in section 2.4. The result of this step is the -compressed string. - -2.2.3 Check the length of the compressed string - -The compressed string MUST be 36 octets or shorter. If the compressed -string is 37 octets or longer, the conversion MUST stop with an error. - -2.2.4 Encode the compressed string with Base32 - -The compressed string MUST be converted using the Base32 encoding -described in section 2.5. The result of this step is the encoded string. - -2.2.5 Prepend "lq--" to the encoded string and finish - -Prepend the characters "lq--" to the encoded string. This is the host -name part that can be used in DNS resolution. - -2.3 Converting a host name part to an internationalized name - -The input string for conversion is a valid host name part. Note that if -any checking for prohibited name parts (such as prohibited characters, -case-folding, or canonicalization is to be done, it MUST be done after -doing the conversion from an ACE name part. - -If a decoded name part consists exclusively of characters that conform -to the host name requirements in [STD13], the conversion from LACE MUST -fail. Because a name part that can be represented without LACE MUST NOT -be encoded using LACE, the decoding process MUST check for name parts -that consists exclusively of characters that conform to the host name -requirements in [STD13] and, if such a name part is found, MUST -beconsidered an error (and possibly a security violation). - -2.3.1 Strip the "lq--" - -The input string MUST begin with the characters "lq--". If it does not, -the conversion MUST stop with an error. Otherwise, remove the characters -"lq--" from the input string. The result of this step is the stripped -string. - -2.3.2 Decode the stripped string with Base32 - -The entire stripped string MUST be checked to see if it is valid Base32 -output. The entire stripped string MUST be changed to all lower-case -letters and digits. If any resulting characters are not in Table 1, the -conversion MUST stop with an error; the input string is the -post-converted string. Otherwise, the entire resulting string MUST be -converted to a binary format using the Base32 decoding described in -section 2.5. The result of this step is the decoded string. - -2.3.3 Decompress the decoded string - -The entire decoded string MUST be converted to ISO 10646 characters -using the decompression algorithm described in section 2.4. The result -of this is the internationalized string. - -2.3.4 Check the internationalized string for disallowed names - -If the internationalized string consists only of characters that conform -to the host name requirements in [STD13], the conversion MUST stop with -an error. - -2.4 Compression algorithm - -The basic method for compression is to reduce a substring that consists -of characters all from a single row of the ISO 10646 repertoire to a -count octet followed by the row header followed by the lower octets of -the characters. If this ends up being longer than the input, the string -is not compressed, but instead has a unique one-octet header attached. - -Although the uncompressed mode limits the number of characters in a LACE -name part to 17, this is still generally enough for all names in almost -scripts. Also, this limit is close to the limits set by other encoding -proposals. - -Note that the compression and decompression rules MUST be followed -exactly. This requirement prevents a single host name part from having -two encodings. Thus, for any input to the algorithm, there is only one -possible output. An implementation cannot chose to use one-octet mode or -two-octet mode using anything other than the logic given in this -section. - -2.4.1 Compressing a string - -The input string is in the UTF-16 encoding (big-endian UTF-16 with no -byte order mark). - -Design note: No checking is done on the input to this algorithm. It is -assumed that all checking for valid ISO/IEC 10646 characters has already -been done by a previous step in the conversion process. - -1) If the length (measured in octets) of the input is not even, or is -less than 2, stop with an error. - -2) Set the input pointer, called IP, to the first octet of the input -string. - -3) Set the variable called HIGH to the octet at IP. - -4) Determine the number of contiguous pairs at or after IP that have -HIGH as the first octet; call this COUNT. - -5) Put into an output buffer the single octet for COUNT followed by the -single octet for HIGH, followed by all those low octets. Move IP to the -end of those pairs; that is, set IP to IP+(2*COUNT). - -6) If IP is not at the end of the input string, go to step 3. - -7) If the length of the output buffer is less than or equal to the -length of the input buffer (in octets, not in characters), emit the -output buffer. Otherwise, output the octet 0xFF followed by the input -buffer. Note that there can only be one possible representation for a -name part, so that outputting the wrong name part is a serious security -error. Decompression schemes MUST accept only the valid form and MUST -NOT accept invalid forms. - -2.4.2 Decompressing a string - -1. Set the input pointer, called IP, to the first octet of the input -string. If there is no first octet, stop with an error. - -2. If the octet at IP is 0xFF, set IP to IP+1, copy the rest of the -input buffer to the output buffer, and go to step 9. - -3. Get the octet at IP, call it COUNT. If COUNT equals zero or is -greater than 36, stop with an error. Set IP to IP+1. If IP is now at the -end of the input string, stop with an error. - -4. Get the octet at IP, call it HIGH. Set IP to IP+1. - -5. If IP is now at the end of the input string, stop with an error. Get -the octet at IP, call it LOW. Set IP to IP+1. - -6. Output HIGH, then LOW, to the output buffer. - -7. Decrement COUNT. If COUNT is greater than 0, go to step 5. - -8. If IP is not at the end of the input buffer, go to step 3. - -9. If the length of the output buffer is odd, stop with an error. -Compress the output buffer into a separate comparison buffer following -the steps for compression above. If the contents of the comparison -buffer does not equal the input to the compression step, stop with an -error. Otherwise, send out the output buffer and stop. - -2.4.3 Compression examples - -The five input characters are -represented in big-endian UTF-16 as the ten octets <30 E6 30 CB 30 B3 30 -FC 30 C9>. All the code units are in the same row (03). The output -buffer has seven octets <05 30 E6 CB B3 FC C9>, which is shorter than -the input string. Thus the output is <05 30 E6 CB B3 FC C9>. - -The four input characters are represented -in big-endian UTF-16 as the eight octets <01 2F 01 11 01 49 00 E5>. The -output buffer has eight octets <03 01 2F 11 49 01 00 E5>, which is the -same length as the input string. Thus, the output is <03 01 2F 11 49 01 -00 E5>. - -The three input characters are represented in -big-endian UTF-16 as the six octets <01 2F 00 E0 01 4B>. The output -buffer is nine octets <01 01 2F 01 00 E0 01 01 4B>, which is longer than -the input buffer. Thus, the output is . - -2.5 Base32 - -In order to encode non-ASCII characters in DNS-compatible host name parts, -they must be converted into legal characters. This is done with Base32 -encoding, described here. - -Table 1 shows the mapping between input bits and output characters in -Base32. Design note: the digits used in Base32 are "2" through "7" -instead of "0" through "6" in order to avoid digits "0" and "1". This -helps reduce errors for users who are entering a Base32 stream and may -misinterpret a "0" for an "O" or a "1" for an "l". - - Table 1: Base32 conversion - bits char hex bits char hex - 00000 a 0x61 10000 q 0x71 - 00001 b 0x62 10001 r 0x72 - 00010 c 0x63 10010 s 0x73 - 00011 d 0x64 10011 t 0x74 - 00100 e 0x65 10100 u 0x75 - 00101 f 0x66 10101 v 0x76 - 00110 g 0x67 10110 w 0x77 - 00111 h 0x68 10111 x 0x78 - 01000 i 0x69 11000 y 0x79 - 01001 j 0x6a 11001 z 0x7a - 01010 k 0x6b 11010 2 0x32 - 01011 l 0x6c 11011 3 0x33 - 01100 m 0x6d 11100 4 0x34 - 01101 n 0x6e 11101 5 0x35 - 01110 o 0x6f 11110 6 0x36 - 01111 p 0x70 11111 7 0x37 - -2.5.1 Encoding octets as Base32 - -The input is a stream of octets. However, the octets are then treated -as a stream of bits. - -Design note: The assumption that the input is a stream of octets -(instead of a stream of bits) was made so that no padding was needed. -If you are reusing this algorithm for a stream of bits, you must add a -padding mechanism in order to differentiate different lengths of input. - -1) Set the read pointer to the beginning of the input bit stream. - -2) Look at the five bits after the read pointer. If there are not five -bits, go to step 5. - -3) Look up the value of the set of five bits in the bits column of -Table 1, and output the character from the char column (whose hex value -is in the hex column). - -4) Move the read pointer five bits forward. If the read pointer is at -the end of the input bit stream (that is, there are no more bits in the -input), stop. Otherwise, go to step 2. - -5) Pad the bits seen until there are five bits. - -6) Look up the value of the set of five bits in the bits column of -Table 1, and output the character from the char column (whose hex value -is in the hex column). - -2.5.2 Decoding Base32 as octets - -The input is octets in network byte order. The input octets MUST be -values from the second column in Table 1. - -1) Count the number of octets in the input and divide it by 8; call the -remainder INPUTCHECK. If INPUTCHECK is 1 or 3 or 6, stop with an error. - -2) Set the read pointer to the beginning of the input octet stream. - -3) Look up the character value of the octet in the char column (or hex -value in hex column) of Table 1, and add the five bits from the bits -column to the output buffer. - -4) Move the read pointer one octet forward. If the read pointer is not -at the end of the input octet stream (that is, there are more octets in -the input), go to step 3. - -5) Count the number of bits that are in the output buffer and divide it -by 8; call the remainder PADDING. If the PADDING number of bits at the -end of the output buffer are not all zero, stop with an error. -Otherwise, emit the output buffer and stop. - -2.5.3 Base32 example - -Assume you want to encode the value 0x3a270f93. The bit string is: - -3 a 2 7 0 f 9 3 -00111010 00100111 00001111 10010011 - -Broken into chunks of five bits, this is: - -00111 01000 10011 10000 11111 00100 11 - -Padding is added to make the last chunk five bits: - -00111 01000 10011 10000 11111 00100 11000 - -The output of encoding is: - -00111 01000 10011 10000 11111 00100 11000 - h i t q 7 e y -or "hitq7ey". - - -3. Security Considerations - -Much of the security of the Internet relies on the DNS. Thus, any -change to the characteristics of the DNS can change the security of -much of the Internet. Thus, LACE makes no changes to the DNS -itself. - -Host names are used by users to connect to Internet servers. The -security of the Internet would be compromised if a user entering a -single internationalized name could be connected to different servers -based on different interpretations of the internationalized host -name. - -LACE is designed so that every internationalized host name part -can be represented as one and only one DNS-compatible string. If there -is any way to follow the steps in this document and get two or more -different results, it is a severe and fatal error in the protocol. - - -4. References - -[IDNComp] Paul Hoffman, "Comparison of Internationalized Domain Name Proposals", -draft-ietf-idn-compare. - -[IDNReq] James Seng, "Requirements of Internationalized Domain Names", -draft-ietf-idn-requirement. - -[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information -technology -- Universal Multiple-Octet Coded Character Set (UCS) -- -Part 1: Architecture and Basic Multilingual Plane. Five amendments and -a technical corrigendum have been published up to now. UTF-16 is -described in Annex Q, published as Amendment 1. 17 other amendments are -currently at various stages of standardization. [[[ THIS REFERENCE -NEEDS TO BE UPDATED AFTER DETERMINING ACCEPTABLE WORDING ]]] - -[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate -Requirement Levels", March 1997, RFC 2119. - -[RFC2781] Paul Hoffman and Francois Yergeau, "UTF-16, an encoding of ISO -10646", February 2000, RFC 2781. - -[STD13] Paul Mockapetris, "Domain names - implementation and -specification", November 1987, STD 13 (RFC 1035). - -[Unicode3] The Unicode Consortium, "The Unicode Standard -- Version -3.0", ISBN 0-201-61633-5. Described at -. - - -A. Acknowledgements - -Rick Wesson pointed out some error conditions that need to be -tested for. Scott Hollenbeck pointed out some errors in the -compression. - -Base32 is quite obviously inspired by the tried-and-true Base64 -Content-Transfer-Encoding from MIME. - - -B. Sample code - -The following is sample Javascript code for the LACE algorithm. -This code is believed to be correct, but there may be errors in -it. The code is provided as-is and comes with no warranty of -fitness, correctness, blah blah blah. - -/** - * Converts to LACE compression format (without Base32) from - * UTF-16BE array - * @parameter iArray Array of bytes in UTF16-BE - * @parameter iCount Number of elements. Must be 0..63 - * @parameter oArray Array for output of LACE bytes. - * Must be at least 100 octets long to provide internal working space - * @return Length of output array used - * @parameter parseResult output error value if any - * @author Mark Davis - */ - -function toLACE(iArray, iCount, oArray, parseResult) { -//debugger; - if (iCount < 1 || iCount > 62) ×{ - parseResult.set("Lace: count out of range", iCount); - return; - } - if ((iCount % 2) == 1) ×{ - parseResult.set("Lace: odd length, can't be UTF-16", iCount); - return; - } - var op = 0; ×// input index - var ip = 0; ×// output index - var lastHigh = -1; - var lenp = 0; - while (ip < iCount) { - var high = iArray[ip++]; - if (high != lastHigh) { - if (lastHigh != -1) { ×// store last length - var len = op - lenp - 2; - oArray[lenp] = len; - } × - lenp = op++; // reserve space - oArray[op++] = high; - lastHigh = high; - } - oArray[op++] = iArray[ip++]; - } - - // store last len - - var len = op - lenp - 2; - oArray[lenp] = len; - - // see if the input is short, and we should - // just copy - - if (op > iCount) { - if (op > 63) ×{ - parseResult.set("Lace: output too long", op); - return; - } - oArray[0] = 0xFF; - copyTo(iArray, 0, iCount, oArray, 1); - op = iCount + 1; - } - return op; -} - -/** - * Converts from LACE compressed format (without Base32) to - * UTF-16BE array - * @parameter iArray Array of bytes in LACE format - * @parameter iCount Number of elements - * @parameter oArray Array for output of bytes, UTF16-BE. - * Must be at least iCount+1 long - * @return Length of output array used - * @parameter parseResult output error value if any - * @author Mark Davis - */ - -function fromLACE(iArray, iCount, oArray, parseResult) { - var high; - if (iCount < 1 || iCount > 63) { - parseResult.set("fromLACE: count out of range", iCount); - return; - } - var op = 0; - var ip = 0; - var result = 0; - if (iArray[ip] == 0xFF) { ×// special case FF - copyTo(iArray, 1, iCount-1, oArray, 0); - result = iCount-1; - } else { - while (ip < iCount) { ×// loop over runs - var count = iArray[ip++]; - if (ip == iCount) { - parseResult.set("fromLACE: truncated before high", ip); - return; - } - high = iArray[ip++]; - for (var i = 0; i < count; ++i) { - oArray[op++] = high; - if (ip == iCount) ×{ - parseResult.set("fromLACE: truncated from count", ip); - return; - } - oArray[op++] = iArray[ip++]; - } - } - result = op; - } - - // check for uniqueness - - var checkArray = []; - var checkCount = toLACE(oArray, result, checkArray, parseResult); - if (!equals(iArray, iCount, checkArray, checkCount)) { - parseResult.set("fromLACE: illegal input form"); - return; - } × - return result; -} - -/** - * Utility routine for comparing arrays - * @parameter array1 first array to compare - * @parameter count1 number of elements to compare in first array - * @parameter array2 second array to compare - * @parameter count1 number of elements to compare in second array - * @return true iff counts are same, and elements from 0 to count-1 - * are the same - */ - -function equals(array1, count1, array2, count2) { - if (count1 != count2) return false; - for (var i = 0; i < count1; ++i) { - if (array1[i] != array2[i]) return false; - } - return true; -} - -/** - * Utility routine for getting array of bytes from UTF-16 string - * @parameter str source string - * @parameter oArray output array to fill in - * @return count of bytes put into oArray - */ - -function utf16FromString(str, oArray) { - var op = 0; - for (var i = 0; i < str.length; ++i) { - var code = str.charCodeAt(i); - oArray[op++] = (code >>> 8); ×// top byte - oArray[op++] = (code & 0xFF); // bottom byte - } - return op; -} - -/** - * Utility routine to see if string doesn't need LACE - * @parameter str source string - * @return true if ok already - */ - -function okAlready(str) { - for (var i = 0; i < str.length; ++i) { - var c = str.charAt(i); - if (c == '-' || 'a' <= c && c <= 'z' || '0' <= c && c <= '9') - continue; - return false; - } - return true -} - -/** - * Convert from bytes to base32 - * @parameter input Input buffer of bytes with values 00 to FF - * @parameter inputLength Length of input buffer - * @parameter output Output buffer, to be filled with with values from -a-z2-7. - * Must be of at least length input*8/5 + 1 - * @return Length of output buffer used - * @author Mark Davis - */ - -function toBase32(input, inputLength, output, parseResult) { - //debugger; - var bits = 0; - var bitCount = 0; - var ip = 0; - var op = 0; - var val = 0; - while (true) { - - // get bits if we don't have enough - - if (bitCount < 5) { - if (ip >= inputLength) break; - // get another input - bits <<= 8; - if (baseDebugTo) alert("byte: " + input[ip].toString(16) + ", - bitCount: " + (bitCount+8)); - - bits = bits | input[ip++]; - bitCount += 8; - } - - // emit and remove them - - bitCount -= 5; - val = (bits >> bitCount); - if (baseDebugTo) alert("Val: " + val.toString(16) + ", bitCount: " - + bitCount); - output[op++] = toLetter(val); - //if (baseDebugTo) alert("out: " + output[op-1].toString(16)); - bits &= ~(0x1F << bitCount); - } - - // add padding and output if necessary - - if (bitCount > 0) { - if (baseDebugTo) alert("bits*: " + bits.toString(16) + - ", bitCount: " + bitCount); - val = bits << (5 - bitCount); - if (baseDebugTo) alert("out*: " + val.toString(16)); - output[op++] = toLetter(val); - } - return op; -} - -/** - * Convert from base32 to bytes - * @parameter input Input buffer of bytes with values from a-z2-7 - * @parameter inputLength Length of input buffer - * @parameter output Output buffer, to be filled with bytes from - * 00 to FF - * Must be of at least length input*5/8 + 1 - * @return Length of output buffer used - * @author Mark Davis - */ - -function fromBase32(input, inputLength, output, parseResult) { - //debugger; - var inputCheck = inputLength % 8; - if (inputCheck == 1 || inputCheck == 3 || inputCheck == 6) { - parseResult.set("Base32 excess length", null, inputLength); - return; - } - var bits = 0; - var bitCount = 0; - var ip = 0; - var op = 0; - var val = 0; - while (ip < inputLength) { - - // get more bits - var val = input[ip++]; - val = fromLetter(val); - if (val < 0 || val > 0x3F) { - parseResult.set("Bad Base32 byte", val, ip-1); - return; - } - if (baseDebugFrom) alert("base32: " + val.toString(16)); - bits <<= 5; - bits = bits | val; - bitCount += 5; - if (baseDebugFrom) alert("from: " + val.toString(16) + - ", bitCount: " + bitCount); - - // emit & remove if we can - - if (bitCount >= 8) { - bitCount -= 8; - output[op++] = bits >> bitCount; - if (baseDebugFrom) alert("out2: " + (bits >> bitCount) + - ", bitCount: " + bitCount); - bits &= ~(0xFF << bitCount); - } - } - - // check that padding is with zero! - if (bits != 0) return -ip; - return op; -} - - -function toLetter(val) { - if (val > 25) return val - 26 + 0x32; - return val + 0x61; - // return val + (val < 26 ? 0x61 : 0x18); -} - -function fromLetter(val) { - if (val < 0x61) return val + 26 - 0x32; - return val - 0x61; -} - - - -C. Difrerences between -00 and -01 - -1: Minor typos. - -2.1: Changed the tag to 'lq--'. - -2.2 and 2.3: Added check for all-STD13 names in the steps. - -2.4.1: Clarified first sentence. Step 5: fixed the moving of the IP. - -2.4.2: Moved the last sentence of step 4 to be the first sentence of -step 5. Added the check for odd-length output. Changed the exit -comparision to doing a full comparison (instead of looking for lengths). - -2.5.2: Changed the sense of the test in step 3 and added step 4 to check -for malformed input. Also made the output a buffer. Also added new step -1. - -Changed Appendix B from IANA Considerations (of which there are none) to -Javascript code sample. - - -D. Author Contact Information - -Mark Davis -IBM -10275 N. De Anza Blvd -Cupertino, CA 95014 -mark.davis@us.ibm.com and mark.davis@macchiato.com - -Paul Hoffman -Internet Mail Consortium and VPN Consortium -127 Segre Place -Santa Cruz, CA 95060 USA -paul.hoffman@imc.org and paul.hoffman@vpnc.org diff --git a/doc/draft/draft-ietf-idn-lace-02.txt b/doc/draft/draft-ietf-idn-lace-02.txt new file mode 100644 index 0000000000..73ea166ddb --- /dev/null +++ b/doc/draft/draft-ietf-idn-lace-02.txt @@ -0,0 +1,20 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +P. Hoffman: paul.hoffman@vpnc.org +M. Davis: davismc@us.ibm.com + + diff --git a/doc/draft/draft-ietf-idn-mua-00.txt b/doc/draft/draft-ietf-idn-mua-00.txt deleted file mode 100644 index 45c71b1fe8..0000000000 --- a/doc/draft/draft-ietf-idn-mua-00.txt +++ /dev/null @@ -1,374 +0,0 @@ -Internet Draft Maynard Kang -draft-ietf-idn-mua-00.txt i-EMAIL.net -February 5, 2001 -Expires on August 5, 2001 - - Internationalizing Domain Names in Mail User Agents - -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 way where domain names used in Internet e-mail -can be internationalized by making changes only to end-user Mail User -Agents and, by doing so, avoid damaging other applications which handle -Internet e-mail, such as Message Transfer Agents and Delivery Agents. - -1. Introduction - -One of the proposed solutions for internationalized domain names (IDN) -involves only updating the user applications with no changes required -to the DNS protocol, servers and resolvers [IDNA] compared to other -solutions which require changes to be made to protocol, servers, -resolvers and applications. - -The underlying principle of [IDNA] may be similarly applied to the -Internet e-mail system today - by effecting changes to only the Mail -User Agent (MUA) component of the e-mail system. Thus, existing -Message Transfer Agents, Delivery Agents and other applications which -handle e-mail do not have to be changed at all. - -1.1 Definitions and Conventions - -Usage of terms related to the character encoding model are in -reference to Unicode Technical Report 17 [UTR17]. - -The terms "international character", "non-ASCII character" and -"multilingual character", which are used interchangeably, are taken -to mean any abstract character which is not included in the range -specified by [US-ASCII]. - -1.2 Terminology - -The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", -and "MAY" in this document are to be interpreted as described in RFC -2119 [RFC2119]. - -1.3. Design Philosophy - -As the Internet e-mail system is a diverse, distributed and -heterogeneous system with many vendors deploying a vast number of -applications, it is of utmost importance that interoperability amongst -these various components is maintained. Thus, the ideal solution would -be one which does not compromise or damage the operation of any of these -existing components once internationalized domain names are encountered. - -Also, solutions which call for changes to be made to many or even all -components of the Internet e-mail system would require far too much -time and effort to deploy, given that Internet e-mail has such a huge -installed base. - -This solution adheres to both of the above principles, in that -interoperability is preserved and that the cost and speed of -implementation is low. All that the user has to do to use IDNs in e-mail -is update his or her MUA. - -1.4. IDN Summary - -This solution specifies an IDN architecture of arch-3 (just send ACE) -and a transition strategy of trans-1 (always do current plus new -architecture) as described in [IDNCOMP]. The choice of ACE format is not -defined in this document, but MUST be the same as that specified in -[IDNA] in order to maintain uniqueness and consistency. - -1.5. E-mail Internationalization Summary - -As many Internet e-mail standards such as the SMTP protocol [RFC821] -and the e-mail message format [RFC822] only specify usage of the 7-bit -ASCII character set [US-ASCII], international characters which use octet- -based character encoding schemes (CES) cannot be used in e-mail -transmission, headers and bodies. - -Although this issue has been addressed in [RFC2045] for message bodies -and [RFC2047] for message headers through the use of a Transfer Encoding -Syntax (TES) such as Quoted-Printable or Base64, there is no similar -solution which extends the functionality of [RFC821] to include usage of -international characters, except for [RFC1652] which allows transmission -of 8-bit data passed by the DATA command in an SMTP session. - -[RFC1652] however, does not fully address the problem of using IDNs in -an SMTP session - the IDN may be used in areas within the SMTP session -other than the DATA command, such as the MAIL FROM and RCPT TO commands, -where an IDN may be part of the e-mail address(es) specified there. - -Hence, this would be a major stumbling block to deploying "just-send- -8bit" IDNs for use in Internet e-mail, as these IDNs would not be able -to be used in SMTP e-mail transmissions due to [RFC821] restrictions. - -2. Architectural Overview - -The end-user MUA may encounter IDNs in the scenarios below: - -(i) When specifying the transmission server (i.e. SMTP server) -(ii) When specifying the retrieval server (i.e. POP3/IMAP4/any other - retrieval mechanism) -(iii) When specifying e-mail addresses during composition of a message -(iv) When reading messages with e-mail addresses in it - -As with [IDNA], the MUA is updated in a similar fashion to process IDNs -which are input by users and process IDNs which are displayed to users, -in all of the scenarios above. - -For (i) and (ii), the IDN MUST be handled in the same manner as -specified in [IDNA]. The method of handling an IDN For (iii) and (iv) is -described below in 2.1. - -2.1 Interfaces between E-mail components when composing/reading a mail - -The interfaces between e-mail components can be pictorially represented -as shown below. - -The example assumes the setup of a POP3/IMAP4 retrieval client and -server, but the exact nature of end-to-end e-mail transmission may vary -accordingly (e.g. elm or pine would read directly from the mail store). -However, these variations do not impact an accurate description of this -solution to a large extent as no changes are required at these levels. - - +------+ +------+ - | User | | User | - +------+ +---^--| - | User Input: User Display: Characters/ | - | Keyboard/Pen/etc Glyphs on CRT or other | - +-----v---------------+ Representation (e.g. sound) | - | Input Method Editor | +------------|-----+ - +---------------------+ | Rendering Engine | - | Input: Any localized/ +---------^--------+ - | internationalized Output: Any localized/ | - | charset internationalized | - +----v-----------------+ charset | - | +------------------+ | +----------|-------------+ - | | Mail Composition | | | +--------------+ | - | | Interface | | Sender's | | Mail Reading | | - | +------------------+ | MUA | | Interface | | - | | | | +--------^-----+ | - | | Nameprepped ACE | Receiver's | | Nameprepped | - | v | MUA | | ACE | - | +-------------+ | | +-------------------+ | - | | SMTP Client | | | | POP3/IMAP4 Client | | - | +-------------+ | | +-------------------+ | - +----|-----------------+ +----------^-------------+ - | Nameprepped | Nameprepped - v ACE Nameprepped Nameprepped | ACE - +-------------+ ACE +------------+ ACE +-------------------+ - | SMTP Server | -----> | Mail Store | -----> | POP3/IMAP4 Server | - +-------------+ +------------+ +-------------------+ - -2.1.1 Interface between User and Input Method Editor - -For ASCII characters, input is straightforward: the user types on the -keyboard and whichever character that is pressed is sent to the -application. - -However, for international characters, the end-user has to use a script- -specific Input Method Editor (IME), which may or may not be built-into -the OS, to interpret what the user communicates to the system and -thereafter send the respective international characters to the -application. - -For example, for input of Chinese characters, some users use IMEs -which support the "Pinyin" input method. When a user types "zhongguo" -(in ASCII characters) on the keyboard and selects the characters which -represent "China" (in Chinese) from a list, the IME sends the -international characters to the application in a user-determined -charset (e.g. GB2312). - -2.1.2 Interface between Input Method Editor and MUA Composition - Interface - -The MUA mail composition interface (i.e. the "Compose Message" -function of the MUA) SHOULD be able to accept IDNs using 8-bit character -encoding schemes, including those represented in any localized (e.g. -GB2312) or internationalized (e.g. UTF-8) charsets. - -This input typically takes place where e-mail addresses are entered -such as the "From", "To", "Cc", "Bcc" fields, amongst others, as IDNs -may be used at the right-hand-side of the "@" sign in an e-mail address -(domain-parts). - -The mail composition interface MAY allow ACE input for the same -reasons as specified in [IDNA], but is not recommended as ACE is opaque -and ugly. - -2.1.3 Interface between MUA Composition Interface and SMTP Client - -The MUA composition interface communicates with the SMTP client in the -MUA typically through internal function calls within the software itself -or through an API. It is at this level where ACE conversion of any IDN -encountered by the MUA composition interface takes place. - -Before converting the name parts of the IDN into ACE, the MUA MUST -prepare each name part as specified in [NAMEPREP]. Thereafter, the MUA -MUST convert the name parts into ACE before passing any data to the SMTP -client. - -The SMTP client then prepares the e-mail for transmission using the -SMTP protocol [RFC821], and thereafter establishes an SMTP connection -with the user-specified SMTP server to transmit the e-mail. - -It is important to note that an IDN specified in the parameters of any -SMTP command MUST be represented in nameprepped ACE at this point in -time. This includes SMTP commands which require domain parameters (such -as the HELO and EHLO commands) and commands where e-mail addresses are -specified (such as the MAIL FROM, RCPT TO, DATA, VRFY, EXPN, SEND, SOML -and SAML commands). - -As for data passed by the DATA command, ACE conversion MUST be -performed when the "domain" portion of an "addr-spec" or when a "domain" -itself, within the context of [RFC822], is encountered. This is -necessary as an updated MUA may originate a message which is read by a -non-updated MUA. If this happens, the non-updated MUA may face -operational problems dealing with IDNs that appear in the "addr-spec" -which are not in ACE. - -Any transfer encoding syntax to be applied to the mail headers as -specified in [RFC2047] SHOULD be performed before nameprepped ACE -conversion. This is to reduce confusion between IDNs within "addr-spec" -and "domain" portions, in the context of [RFC822], and IDNs which appear -as arbitrary data in mail headers and bodies. - -2.1.4. Interface between POP3/IMAP4 client (or local mail store) and - Mail Reading Interface - -The MUA mail reading interface (i.e. "Read mail" function of an MUA) -typically displays e-mail data retrieved from either a POP3/IMAP4 -client or from a local mail store through internal function calls within -the MUA software or through an API. - -When e-mail containing an ACE-represented IDN is to be displayed, the -MUA SHOULD convert the ACE-represented IDN contained within the -"addr-spec" or "domain" portion specified in [RFC822] back into any -localized or internationalized charset of the user's choice, whenever -possible. In the event that it is impossible to achieve conversion back -into the selected localized charset (for example, conversion of RACE- -represented Hangeul characters into ISO-8859-1 is impossible), the MUA -should prompt the user with an error message. - -It may be possible to save and retrieve information about the original -charset of the ACE-converted IDN through the use of additional -[RFC822] mail headers, but that is not (yet) addressed by this memo. - -Although it is possible to render ACE into properly decoded glyphs and -display the actual abstract characters without any conversion to other -charsets, the MUA SHOULD NOT do this as it is not the primary function -of an MUA to render characters. This should be left to a rendering -engine which is separate from the MUA and typically embedded into the -OS. It is sufficient for the MUA to pass the appropriate charset to the -rendering engine for proper display. - -3. ACE Length Considerations - -As [RFC821] in Section 4.5.3 restricts the maximum total length of a -domain name to 64 characters, representation of IDNs using ACE may -pose a potential problem. Most ACEs typically require 3-4 ASCII -characters to represent one international character (especially in the -case of CJK characters, where compression is less effective). - -That would leave only about 16-24 characters for the whole IDN, -including all name parts and dots. This is highly undesirable as some -languages such as Arabic are unable to be abbreviated and the domain -names may require a larger length than that which is allowed by -[RFC821]. - -To further complicate matters, several mailing list software such as -ezmlm embed domain names into the local-parts portion of an e-mail -address during management of subscriptions, together with randomly- -generated subscription information. This would leave an even smaller -maximum ACE length, if interoperability with these mailing list software -were to be maintained, given that there is also a 64 character -restriction on local parts. - -4. Security Considerations - -As this memo is based on [IDNA], security considerations are similar -to that faced by [IDNA]. This includes security considerations from -[NAMEPREP] as well. - -5. Other Considerations - -Although this document addresses end-user MUAs (e.g. elm, mutt, pine, -Eudora, Outlook Express, etc) to a large extent, the definition of an -MUA could be extended to include web-based e-mail server software and -automated programs such as mailing list management software. - -End-user MUAs may also include additional functionality where IDNs may -be encountered, such as calendaring/scheduling, directory services and -digital certificate storage. This is not (yet) addressed in this memo. - -6. Future Extensions - -It is possible to achieve internationalization of the entire e-mail -address by representation of international characters in the local-parts -of an "addr-spec" using nameprepped ACE conversion in a similar fashion -as described in this memo. - -However, this is a different problem altogether and is currently beyond -the scope of this memo. - -7. References - -[IDNA] Paul Hoffman & Patrik Faltstrom, "Internationalizing Host Names -in Applications (IDNA)", draft-ietf-idn-idna. - -[UTR17] K. Whistler & M. Davis, Unicode Consortium, "Character Encoding -Model", Unicode Technical Report #17, -http://www.unicode.org/unicode/reports/tr17/ - -[US-ASCII] United States of America Standards Institute, "USA Code for -Information Interchange", X3.4, 1968. - -[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate -Requirement Levels", March 1997, RFC 2119. - -[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name -Proposals", draft-ietf-idn-compare. - -[RFC821] Jonathan B. Postel, "Simple Mail Transfer Protocol", August -1982, RFC 821. - -[RFC822] David H. Crocker, "Standard for the Format of ARPA Internet -Text Messages", August 1982, RFC 822. - -[RFC2045] N. Freed & N. Borenstein, "Multipurpose Internet Mail -Extensions (MIME) Part One: Format of Internet Message Bodies", -November 1996, RFC 2045. - -[RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions) -Part Three: Message Header Extensions for Non-ASCII Text", November -1996, RFC 2047. - -[RFC1652] J. Klensin et al., "SMTP Service Extension for 8bit- -MIMEtransport", July 1994, RFC 1652. - - -[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of -Internationalized Host Names", draft-ietf-idn-nameprep. - -A. Author's Address - -Maynard Kang -i-EMAIL.net Pte Ltd -1 Kim Seng Promenade #12-07 -Great World City West Tower -Singapore 237994 -E-mail: maynard@i-email.net \ No newline at end of file diff --git a/doc/draft/draft-ietf-idn-mua-01.txt b/doc/draft/draft-ietf-idn-mua-01.txt new file mode 100644 index 0000000000..73a21af5f2 --- /dev/null +++ b/doc/draft/draft-ietf-idn-mua-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +M. Kang: maynard@i-mail.net + + diff --git a/doc/draft/draft-ietf-idn-race-03.txt b/doc/draft/draft-ietf-idn-race-03.txt deleted file mode 100644 index 9b8db38f85..0000000000 --- a/doc/draft/draft-ietf-idn-race-03.txt +++ /dev/null @@ -1,588 +0,0 @@ -Internet Draft Paul Hoffman -draft-ietf-idn-race-03.txt IMC & VPNC -November 22, 2000 -Expires in six months - - RACE: Row-based ASCII Compatible Encoding for IDN - -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 transformation method for representing -non-ASCII characters in host name parts in a fashion that is completely -compatible with the current DNS. It is a potential candidate for an -ASCII-Compatible Encoding (ACE) for internationalized host names, as -described in the comparison document from the IETF IDN Working Group. -This method is based on the observation that many internationalized -host name parts will have all their characters in one row of the ISO -10646 repertoire. - - -1. Introduction - -There is a strong world-wide desire to use characters other than plain -ASCII in host names. Host names have become the equivalent of business -or product names for many services on the Internet, so there is a need -to make them usable by people whose native scripts are not representable -by ASCII. The requirements for internationalizing host names are -described in the IDN WG's requirements document, [IDNReq]. - -The IDN WG's comparison document [IDNComp] describes three potential -main architectures for IDN: arch-1 (just send binary), arch-2 (send -binary or ACE), and arch-3 (just send ACE). RACE is an ACE, called -Row-based ACE or RACE, that can be used with protocols that match arch-2 -or arch-3. RACE specifies an ACE format as specified in ace-1 in -[IDNComp]. Further, it specifies an identifying mechanism for ace-2 in -[IDNComp], namely ace-2.1.1 (add hopefully-unique legal tag to the -beginning of the name part). - -Author's note: although earlier drafts of this document supported the -ideas in arch-3, I no longer support that idea and instead only support -arch-2. Of course, someone else might right an IDN proposal that matches -arch-3 and use RACE as the protocol. - -In formal terms, RACE describes a character encoding scheme of the -ISO/IEC 10646 [ISO10646] coded character set (whose assignment of -characters is synchronized with Unicode [Unicode3]) and the rules for -using that scheme in the DNS. As such, it could also be called a -"charset" as defined in [IDNReq]. - -The RACE protocol has the following features: - -- There is exactly one way to convert internationalized host parts to -and from RACE parts. Host name part uniqueness is preserved. - -- Host parts that have no international characters are not changed. - -- Names using RACE can include more internationalized characters than -with other ACE protocols that have been suggested to date. Names in the -Han, Yi, Hangul syllables, or Ethiopic scripts can have up to 17 -characters, and names in most other scripts can have up to 35 -characters. Further, a name that consist of characters from one -non-Latin script but also contains some Latin characters such as digits -or hyphens can have close to 33 characters. - -It is important to note that the following sections contain many -normative statements with "MUST" and "MUST NOT". Any implementation that -does not follow these statements exactly is likely to cause damage to -the Internet by creating non-unique representations of host names. - -1.1 Terminology - -The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and -"MAY" in this document are to be interpreted as described in RFC 2119 -[RFC2119]. - -Hexadecimal values are shown preceded with an "0x". For example, -"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are -shown preceded with an "0b". For example, a nine-bit value might be -shown as "0b101101111". - -Examples in this document use the notation from the Unicode Standard -[Unicode3] as well as the ISO 10646 names. For example, the letter "a" -may be represented as either "U+0061" or "LATIN SMALL LETTER A". - -RACE converts strings with internationalized characters into -strings of US-ASCII that are acceptable as host name parts in current -DNS host naming usage. The former are called "pre-converted" and the -latter are called "post-converted". - -1.2 IDN summary - -Using the terminology in [IDNComp], RACE specifies an ACE format as -specified in ace-1. Further, it specifies an identifying mechanism for -ace-2, namely ace-2.1.1 (add hopefully-unique legal tag to the beginning -of the name part). - -RACE has the following length characteristics. In this list, "row" means -a row from ISO 10646. - -- If the characters in the input all come from the same row, up to 35 -characters per name part are allowed. - -- If the characters in the input come from two or more rows, neither of -which is row 0, up to 17 characters per name part are allowed. - -- If the characters in the input come from two rows, one of which is row -0, between 17 and 33 characters per name part are allowed. - - -2. Host Part Transformation - -According to [STD13], host parts must be case-insensitive, start and -end with a letter or digit, and contain only letters, digits, and the -hyphen character ("-"). This, of course, excludes any internationalized -characters, as well as many other characters in the ASCII character -repertoire. Further, domain name parts must be 63 octets or shorter in -length. - -2.1 Name tagging - -All post-converted name parts that contain internationalized characters -begin with the string "bq--". (Of course, because host name parts are -case-insensitive, this might also be represented as "Bq--" or "bQ--" or -"BQ--".) The string "bq--" was chosen because it is extremely unlikely -to exist in host parts before this specification was produced. As a -historical note, in late August 2000, none of the second-level host name -parts in any of the .com, .edu, .net, and .org top-level domains began -with "bq--"; there are many tens of thousands of other strings of three -characters followed by a hyphen that have this property and could be -used instead. The string "bq--" will change to other strings with the -same properties in future versions of this draft. - -Note that a zone administrator might still choose to use "bq--" at the -beginning of a host name part even if that part does not contain -internationalized characters. Zone administrators SHOULD NOT create host -part names that begin with "bq--" unless those names are post-converted -names. Creating host part names that begin with "bq--" but that are not -post-converted names may cause two distinct problems. Some display -systems, after converting the post-converted name part back to an -internationalized name part, might display the name parts in a -possibly-confusing fashion to users. More seriously, some resolvers, -after converting the post-converted name part back to an -internationalized name part, might reject the host name if it contains -illegal characters. - -2.2 Converting an internationalized name to an ACE name part - -To convert a string of internationalized characters into an ACE name -part, the following steps MUST be preformed in the exact order of the -subsections given here. - -If a name part consists exclusively of characters that conform to the -host name requirements in [STD13], the name MUST NOT be converted to -LACE. That is, a name part that can be represented without LACE MUST NOT -be encoded using LACE. This absolute requirement prevents there from -being two different encodings for a single DNS host name. - -If any checking for prohibited name parts (such as ones that are -prohibited characters, case-folding, or canonicalization) is to be done, -it MUST be done before doing the conversion to an ACE name part. - -Characters outside the first plane of characters (those with codepoints -above U+FFFF) MUST be represented using surrogates, as described in the -UTF-16 description in ISO 10646. - -The input name string consists of characters from the ISO 10646 -character set in big-endian UTF-16 encoding. This is the pre-converted -string. - -2.2.1 Check the input string for disallowed names - -If the input string consists only of characters that conform to the host -name requirements in [STD13], the conversion MUST stop with an error. - -2.2.2 Compress the pre-converted string - -The entire pre-converted string MUST be compressed using the compression -algorithm specified in section 2.4. The result of this step is the -compressed string. - -2.2.3 Check the length of the compressed string - -The compressed string MUST be 36 octets or shorter. If the compressed -string is 37 octets or longer, the conversion MUST stop with an error. - -2.2.4 Encode the compressed string with Base32 - -The compressed string MUST be converted using the Base32 encoding -described in section 2.5. The result of this step is the encoded string. - -2.2.5 Prepend "bq--" to the encoded string and finish - -Prepend the characters "bq--" to the encoded string. This is the host -name part that can be used in DNS resolution. - -2.3 Converting a host name part to an internationalized name - -The input string for conversion is a valid host name part. Note that if -any checking for prohibited name parts (such as prohibited characters, -case-folding, or canonicalization is to be done, it MUST be done after -doing the conversion from an ACE name part. - -If a decoded name part consists exclusively of characters that conform -to the host name requirements in [STD13], the conversion from LACE MUST -fail. Because a name part that can be represented without LACE MUST NOT -be encoded using LACE, the decoding process MUST check for name parts -that consists exclusively of characters that conform to the host name -requirements in [STD13] and, if such a name part is found, MUST -beconsidered an error (and possibly a security violation). - -2.3.1 Strip the "bq--" - -The input string MUST begin with the characters "bq--". If it does not, -the conversion MUST stop with an error. Otherwise, remove the characters -"bq--" from the input string. The result of this step is the stripped -string. - -2.3.2 Decode the stripped string with Base32 - -The entire stripped string MUST be checked to see if it is valid Base32 -output. The entire stripped string MUST be changed to all lower-case -letters and digits. If any resulting characters are not in Table 1, the -conversion MUST stop with an error; the input string is the -post-converted string. Otherwise, the entire resulting string MUST be -converted to a binary format using the Base32 decoding described in -section 2.5. The result of this step is the decoded string. - -2.3.3 Decompress the decoded string - -The entire decoded string MUST be converted to ISO 10646 characters -using the decompression algorithm described in section 2.4. The result -of this is the internationalized string. - -2.3.4 Check the internationalized string for disallowed names - -If the internationalized string consists only of characters that conform -to the host name requirements in [STD13], the conversion MUST stop with -an error. - -2.4 Compression algorithm - -The basic method for compression is to reduce a full string that -consists of characters all from a single row of the ISO 10646 -repertoire, or all from a single row plus from row 0, to as few octets -as possible. Any full string that has characters that come from two -rows, neither of which are row 0, or three or more rows, has all the -octets of the input string in the output string. - -If the string comes from only one row, compression is to one octet per -character in the string. If the string comes from only one row other -than row 0, but also has characters only from row 0, compression is to -one octet for the characters from the non-0 row and two octets for the -characters from row 0. Otherwise, there is no compression and the output -is a string that has two octets per input character. - -The compressed string always has a one-octet header. If the string comes -from only one row, the header octet is the upper octet of the -characters. If the string comes from only one row other than row 0, but -also has characters only from row 0, the header octet is the upper octet -of the characters from the non-0 row. Otherwise, the header octet is -0xD8, which is the upper octet of a surrogate pair. Design note: It is -impossible to have a legal stream of UTF-16 characters that has all the -upper octets being 0xD8 because a character whose upper octet is 0xD8 -must be followed by one whose upper octet is in the range 0xDC through -0xDF. - -Although the two-octet mode limits the number of characters in a RACE -name part to 17, this is still generally enough for almost all names in -almost scripts. Also, this limit is close to the limits set by other -encoding proposals. - -Note that the compression and decompression rules MUST be followed -exactly. This requirement prevents a single host name part from having -two encodings. Thus, for any input to the algorithm, there is only one -possible output. An implementation cannot chose to use one-octet mode or -two-octet mode using anything other than the logic given in this -section. - -2.4.1 Compressing a string - -The input string is in big-endian UTF-16 encoding with no byte order -mark. - -Design note: No checking is done on the input to this algorithm. It is -assumed that all checking for valid ISO/IEC 10646 characters has already -been done by a previous step in the conversion process. - -Design note: In step 5, 0xFF was chosen as the escape character because -it appears in the fewest number of scripts in ISO 10646, and therefore -the "escaped escape" will be needed the least. 0x99 was chosen as the -second octet for the "escaped escape" because the character U+0099 has -no value, and is not even used as a control character in the C1 controls -or in ISO 6429. - -1) Starting at the beginning of the input, read each pair of octets in -the input stream, comparing the upper octet of each. Reset the input -pointer to the beginning of the input again. If all of the upper octets -(called U1) are the same, go to step 4. Note that if the input is only -one character, this test will always be true. - -2) Read each pair of octets in the input stream, comparing the upper -octet of each. Reset the input pointer to the beginning of the input -again. If all of the upper octets are either 0x00 or one single other -value (called U1), go to step 4. - -3) Output 0xD8, followed by the entire input stream. Finish. - -4) If U1 is in the range 0xD8 to 0xDC, stop with an error. Otherwise, -output U1. - -5) If you are at the end of the input string, finish. Otherwise, read -the next octet, called U2, and the octet after that, called N1. If U2 is -0x00 and N1 is 0x99, stop with an error. - -6) If U2 is equal to U1, and N1 is not equal to 0xFF, output N1, and go -to step 5. - -7) If U2 is equal to U1, and N1 is equal to 0xFF, output 0xFF followed -by 0x99, and go to step 5. - -8) Output 0xFF followed by N1. Go to step 5. - -2.4.2 Decompressing a string - -1) Read the first octet of the input string. Call the value of the first -octet U1. If there are no more octets in the input string (that is, if -the input string had only one octet total), stop with an error. If U1 is -0xD8, go to step 8. - -2) If you are at the end of the input string, go to step 11. Otherwise, -read the next octet in the input string, called N1. If N1 is 0xFF, go to -step 5. - -3) If U1 is 0x00 and N1 is 0x99, stop with an error. - -4) Put U1 followed by N1 in the output buffer. Go to step 2. - -5) If you are at the end of the input string, stop with an error. - -6) Read the next octet of the input string, called N1. If N1 is 0x99, -put U1 followed by 0xFF in the output buffer, and go to step 2. - -7) Put 0x00 followed by N1 in the output buffer. Go to step 2. - -8) Read the rest of the input stream into a temporary string called -LCHECK. If the length of LCHECK is an odd number, stop with an error. - -9) Perform the checks from steps 1 and 2 of the compression algorithm in -section 2.4.1 on LCHECK. If either checks pass (that is, if either would -have created a compressed string), stop with an error because the input -to the decompression is in the wrong format. - -10) If the length of LCHECK is odd, stop with and error. Otherwise, -output LCHECK and finish. - -11) If the length of the output buffer is odd, stop with and error. -Otherwise, emit the output buffer and finish. - -2.4.3 Compression examples - -For the input string of , all characters are in -the same row, 0x01. Thus, the output is 0x012D114B. - -For the input string of , the characters are all -in row 0x01 or row 0x00. Thus, the output is 0x012DFFE04B. - -For the input string of , the characters are all -in row 0x12. Thus, the output is 0x1290FF990C. - -For the input string of , the characters are -from two rows other than 0x00. Thus, the output is 0xD8012D00E024D3. - -2.5 Base32 - -In order to encode non-ASCII characters in DNS-compatible host name parts, -they must be converted into legal characters. This is done with Base32 -encoding, described here. - -Table 1 shows the mapping between input bits and output characters in -Base32. Design note: the digits used in Base32 are "2" through "7" -instead of "0" through "6" in order to avoid digits "0" and "1". This -helps reduce errors for users who are entering a Base32 stream and may -misinterpret a "0" for an "O" or a "1" for an "l". - - Table 1: Base32 conversion - bits char hex bits char hex - 00000 a 0x61 10000 q 0x71 - 00001 b 0x62 10001 r 0x72 - 00010 c 0x63 10010 s 0x73 - 00011 d 0x64 10011 t 0x74 - 00100 e 0x65 10100 u 0x75 - 00101 f 0x66 10101 v 0x76 - 00110 g 0x67 10110 w 0x77 - 00111 h 0x68 10111 x 0x78 - 01000 i 0x69 11000 y 0x79 - 01001 j 0x6a 11001 z 0x7a - 01010 k 0x6b 11010 2 0x32 - 01011 l 0x6c 11011 3 0x33 - 01100 m 0x6d 11100 4 0x34 - 01101 n 0x6e 11101 5 0x35 - 01110 o 0x6f 11110 6 0x36 - 01111 p 0x70 11111 7 0x37 - -2.5.1 Encoding octets as Base32 - -The input is a stream of octets. However, the octets are then treated -as a stream of bits. - -Design note: The assumption that the input is a stream of octets -(instead of a stream of bits) was made so that no padding was needed. -If you are reusing this algorithm for a stream of bits, you must add a -padding mechanism in order to differentiate different lengths of input. - -1) If the input bit stream is not an even multiple of five bits, pad -the input stream with 0 bits until it is an even multiple of five bits. -Set the read pointer to the beginning of the input bit stream. - -2) Look at the five bits after the read pointer. - -3) Look up the value of the set of five bits in the bits column of -Table 1, and output the character from the char column (whose hex value -is in the hex column). - -4) Move the read pointer five bits forward. If the read pointer is at -the end of the input bit stream (that is, there are no more bits in the -input), stop. Otherwise, go to step 2. - -2.5.2 Decoding Base32 as octets - -The input is octets in network byte order. The input octets MUST be -values from the second column in Table 1. - -1) Count the number of octets in the input and divide it by 8; call the -remainder INPUTCHECK. If INPUTCHECK is 1 or 3 or 6, stop with an error. - -2) Set the read pointer to the beginning of the input octet stream. - -3) Look up the character value of the octet in the char column (or hex -value in hex column) of Table 1, and add the five bits from the bits -column to the output buffer. - -4) Move the read pointer one octet forward. If the read pointer is not -at the end of the input octet stream (that is, there are more octets in -the input), go to step 3. - -5) Count the number of bits that are in the output buffer and divide it -by 8; call the remainder PADDING. If the PADDING number of bits at the -end of the output buffer are not all zero, stop with an error. -Otherwise, emit the output buffer and stop. - -2.5.3 Base32 example - -Assume you want to encode the value 0x3a270f93. The bit string is: - -3 a 2 7 0 f 9 3 -00111010 00100111 00001111 10010011 - -Broken into chunks of five bits, this is: - -00111 01000 10011 10000 11111 00100 11 - -Padding is added to make the last chunk five bits: - -00111 01000 10011 10000 11111 00100 11000 - -The output of encoding is: - -00111 01000 10011 10000 11111 00100 11000 - h i t q 7 e y -or "hitq7ey". - - -3. Security Considerations - -Much of the security of the Internet relies on the DNS. Thus, any -change to the characteristics of the DNS can change the security of -much of the Internet. Thus, RACE makes no changes to the DNS -itself. - -Host names are used by users to connect to Internet servers. The -security of the Internet would be compromised if a user entering a -single internationalized name could be connected to different servers -based on different interpretations of the internationalized host -name. - -RACE is designed so that every internationalized host name part -can be represented as one and only one DNS-compatible string. If there -is any way to follow the steps in this document and get two or more -different results, it is a severe and fatal error in the protocol. - - -4. References - -[IDNComp] Paul Hoffman, "Comparison of Internationalized Domain Name Proposals", -draft-ietf-idn-compare. - -[IDNReq] James Seng, "Requirements of Internationalized Domain Names", -draft-ietf-idn-requirement. - -[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information -technology -- Universal Multiple-Octet Coded Character Set (UCS) -- -Part 1: Architecture and Basic Multilingual Plane. Five amendments and -a technical corrigendum have been published up to now. UTF-16 is -described in Annex Q, published as Amendment 1. 17 other amendments are -currently at various stages of standardization. [[[ THIS REFERENCE -NEEDS TO BE UPDATED AFTER DETERMINING ACCEPTABLE WORDING ]]] - -[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate -Requirement Levels", March 1997, RFC 2119. - -[STD13] Paul Mockapetris, "Domain names - implementation and -specification", November 1987, STD 13 (RFC 1035). - -[Unicode3] The Unicode Consortium, "The Unicode Standard -- Version -3.0", ISBN 0-201-61633-5. Described at -. - - -A. Acknowledgements - -Mark Davis contributed many ideas to the initial draft of this document, -as well as comments in later versions. Graham Klyne and Martin Duerst -offered technical comments on the algorithms used. GIM Gyeongseog and -Pongtorn Jentaweepornkul helped fix technical errors in early drafts. -Rick Wesson and Mark Davis contributed many suggestions on error -conditions in the processing. - -Base32 is quite obviously inspired by the tried-and-true Base64 -Content-Transfer-Encoding from MIME. - - - -B. Changes from Versions -02 to -03 of this Draft - -1: Wording corrections to third paragraph. - -2.2 and 2.3: Added need to check for all-STD13. - -2.4.1: Wording corrections in the first two paragraphs. Made step 1 and -2 clearer with resetting the input pointer. Also added sentence at the -end of step 1. Also added error conditions in steps 4 and 5. - -2.4.2: Added error condition in step 1. Added a new step 3 for an error -check. Expanded step 8 to check for malformed input error. Added error -check for odd-length output. - -2.4.3: Changed all the examples to use lowercase characters on input. - -2.5.1: Made the list of steps shorter by padding with 0 bits at the -beginning of the steps. - -2.5.2: Changed the sense of the test in step 3 and added step 4 to be -checkfor malformed input. Also made the output a buffer. Also added -new step 1. - - -C. IANA Considerations - -There are no IANA considerations in this document. - - -D. Author Contact Information - -Paul Hoffman -Internet Mail Consortium and VPN Consortium -127 Segre Place -Santa Cruz, CA 95060 USA -paul.hoffman@imc.org and paul.hoffman@vpnc.org diff --git a/doc/draft/draft-ietf-idn-race-04.txt b/doc/draft/draft-ietf-idn-race-04.txt new file mode 100644 index 0000000000..8025a396e3 --- /dev/null +++ b/doc/draft/draft-ietf-idn-race-04.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +P. Hoffman: paul.hoffman@vpnc.org + + diff --git a/doc/draft/draft-ietf-idn-udns-02.txt b/doc/draft/draft-ietf-idn-udns-03.txt similarity index 87% rename from doc/draft/draft-ietf-idn-udns-02.txt rename to doc/draft/draft-ietf-idn-udns-03.txt index 2867c0bd9e..a86887c1c9 100644 --- a/doc/draft/draft-ietf-idn-udns-02.txt +++ b/doc/draft/draft-ietf-idn-udns-03.txt @@ -1,7 +1,7 @@ -Internet Draft Dan Oscarsson -draft-ietf-idn-udns-02.txt Telia ProSoft -Updates: RFC 2181, 1035, 1034, 2535 24 February -2001 Expires: 24 August 2001 +Internet Draft Dan Oscarsson +draft-ietf-idn-udns-03.txt Telia ProSoft +Updates: RFC 2181, 1035, 1034, 2535 19 August 2001 +Expires: 19 February 2002 Using the Universal Character Set in the Domain Name System (UDNS) @@ -31,14 +31,11 @@ Abstract Since the Domain Name System (DNS) [RFC1035] was created there have been a desire to use other characters than ASCII in domain names. Lately this desire have grown very strong and several groups have - started to experiment with non-ASCII names. - - This document defines how the Universal Character Set (UCS) - [ISO10646] is to be used in DNS. - - It includes both a transition scheme for older software supporting - non-ASCII handling in applications only, as well as how to use UCS in - labels and having more than 63 octets in a label. + started to experiment with non-ASCII names. This document defines + how the Universal Character Set (UCS) [ISO10646] is to be used in + DNS. It includes both a transition scheme for older software + supporting non-ASCII handling in applications only, as well as how to + use UCS in labels and having more than 63 octets in a label. 1. Introduction @@ -46,17 +43,17 @@ Abstract While the need for non-ASCII domain names have existed since the creation of the DNS, the need have increased very much during the last few years. Currently there are at least two implementations - - - -Dan Oscarsson Expires: 24 August 2001 [Page 1] - -Internet Draft Universal DNS 24 February 2001 - - using UTF-8 in use, and others using other methods. To avoid several different implementations of non-ASCII names in DNS + + + +Dan Oscarsson Expires: 19 February 2002 [Page 1] + +Internet Draft Universal DNS 19 August 2001 + + that do not work together, and to avoid breaking the current ASCII only DNS, there is an immediate need to standardise how DNS shall handle non-ASCII names. @@ -83,6 +80,8 @@ Internet Draft Universal DNS 24 February 2001 1.2 Previous versions of this document + This version contains just minor corrections to the 4:th version. + The third version of this document included a way to return both ASCII and non-ASCII versions of a name. As this could not be guaranteed to work it has been removed. @@ -102,15 +101,15 @@ Internet Draft Universal DNS 24 February 2001 format of zone files or how to enter or display domain names are not part of the protocol. - - - -Dan Oscarsson Expires: 24 August 2001 [Page 2] - -Internet Draft Universal DNS 24 February 2001 - - The update of the protocol defined here can be used immediately as it + + + +Dan Oscarsson Expires: 19 February 2002 [Page 2] + +Internet Draft Universal DNS 19 August 2001 + + is fully compatible with the DNS of today. For a long time there will be software understanding UCS in DNS and @@ -122,7 +121,7 @@ Internet Draft Universal DNS 24 February 2001 - UDNS unaware client, UDNS aware DNS server - UDNS aware client, UDNS unaware DNS server - - UDNS aware client, UDNS unaware DNS server + - UDNS aware client, UDNS aware DNS server 2.1 Fundamentals @@ -161,9 +160,10 @@ Internet Draft Universal DNS 24 February 2001 -Dan Oscarsson Expires: 24 August 2001 [Page 3] + +Dan Oscarsson Expires: 19 February 2002 [Page 3] -Internet Draft Universal DNS 24 February 2001 +Internet Draft Universal DNS 19 August 2001 To handle form-insensitivity it is here defined the Binary Comparison @@ -202,10 +202,26 @@ Internet Draft Universal DNS 24 February 2001 document. Typical definitions that are suitable are [SACE] and [RACE]. + The reason that the BCF form of the label is used is to support + solutions where only applications know about non-ASCII labels. By + using BCF the server need not know about UCS and can just do binary + matching so it can be handled in old servers. Though due to the fact + that BCF destroys information contained in the original form of a + label it is impossible to return the original form to a client using + BCE. + 2.1.4 Long names The current DNS protocol limits a label to 63 octets. As UTF-8 take more than one octet for some characters, an UTF-8 name cannot have 63 + + + +Dan Oscarsson Expires: 19 February 2002 [Page 4] + +Internet Draft Universal DNS 19 August 2001 + + characters in a label like an ASCII name can. For example a name using Hangul would have a maximum of 21 characters. @@ -214,14 +230,6 @@ Internet Draft Universal DNS 24 February 2001 simplify implementations. To support longer names a long label type is defined using [RFC2671] - - - -Dan Oscarsson Expires: 24 August 2001 [Page 4] - -Internet Draft Universal DNS 24 February 2001 - - as extended label 0b000011 (the label type will be assigned by IANA and may not be the number used here). @@ -262,6 +270,14 @@ Internet Draft Universal DNS 24 February 2001 others. The effect of the above is: + + + +Dan Oscarsson Expires: 19 February 2002 [Page 5] + +Internet Draft Universal DNS 19 August 2001 + + - only servers handling authorative data must implement form- insensitive matching of names. And they need only implement the subset needed for the subset of characters of UCS they support in @@ -270,14 +286,6 @@ Internet Draft Universal DNS 24 February 2001 resolver <-> server <-> authorative server. While form-insensitive matching can be complex and CPU consuming, the server in the middle will do caching with only simple and fast - - - -Dan Oscarsson Expires: 24 August 2001 [Page 5] - -Internet Draft Universal DNS 24 February 2001 - - binary matching. So the impact of complex matching rules should not slow down DNS very much. @@ -319,6 +327,13 @@ Internet Draft Universal DNS 24 February 2001 2.3.3 non-UDNS aware client + + +Dan Oscarsson Expires: 19 February 2002 [Page 6] + +Internet Draft Universal DNS 19 August 2001 + + A non-UDNS aware client will send ASCII or whatever is sent from an application. It can be BCE which will for the client just be ASCII text. @@ -326,14 +341,6 @@ Internet Draft Universal DNS 24 February 2001 2.3.4 UDNS aware server An UDNS aware server MUST handle all in this document and follow: - - - -Dan Oscarsson Expires: 24 August 2001 [Page 6] - -Internet Draft Universal DNS 24 February 2001 - - - If an incoming query contains a long label the answer may contain a long label and the client is identified as being UDNS aware. - If the query comes from a non-UDNS aware client and the answer @@ -375,6 +382,14 @@ Internet Draft Universal DNS 24 February 2001 in ASCII or by tagged character sets should be avoided. DNS do not only have domain names in them, for example e-mail + + + +Dan Oscarsson Expires: 19 February 2002 [Page 7] + +Internet Draft Universal DNS 19 August 2001 + + addresses are also included. So an e-mail address would be expected to be changed to include non-ASCII both before and after the @-sign. @@ -382,14 +397,6 @@ Internet Draft Universal DNS 24 February 2001 recommendations given above, so that a human will see the characters in their local character set, if possible. - - - -Dan Oscarsson Expires: 24 August 2001 [Page 7] - -Internet Draft Universal DNS 24 February 2001 - - 4. Security Considerations As always with data, if software does not check for data that can be @@ -431,6 +438,14 @@ Internet Draft Universal DNS 24 February 2001 [UTR15] M. Davis and M. Duerst, "Unicode Normalization Forms", Unicode Technical Report #15, Nov 1999, + + + +Dan Oscarsson Expires: 19 February 2002 [Page 8] + +Internet Draft Universal DNS 19 August 2001 + + http://www.unicode.org/unicode/reports/tr15/. [UTR21] M. Davis, "Case Mappings", Unicode Technical Report #21, @@ -438,14 +453,6 @@ Internet Draft Universal DNS 24 February 2001 [UDATA] The Unicode Character Database, ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.txt. - - - -Dan Oscarsson Expires: 24 August 2001 [Page 8] - -Internet Draft Universal DNS 24 February 2001 - - The database is described in ftp://ftp.unicode.org/Public/UNIDATA/ UnicodeCharacterDatabase.html. @@ -488,20 +495,19 @@ Internet Draft Universal DNS 24 February 2001 + + +Dan Oscarsson Expires: 19 February 2002 [Page 9] + +Internet Draft Universal DNS 19 August 2001 + + Author's Address Dan Oscarsson Telia ProSoft AB Box 85 201 20 Malmo - - - -Dan Oscarsson Expires: 24 August 2001 [Page 9] - -Internet Draft Universal DNS 24 February 2001 - - Sweden E-mail: Dan.Oscarsson@trab.se @@ -547,11 +553,5 @@ Internet Draft Universal DNS 24 February 2001 - - - - - - -Dan Oscarsson Expires: 24 August 2001 [Page 10] +Dan Oscarsson Expires: 19 February 2002 [Page 10] diff --git a/doc/draft/draft-ietf-idn-uri-00.txt b/doc/draft/draft-ietf-idn-uri-00.txt deleted file mode 100644 index ab22a632c8..0000000000 --- a/doc/draft/draft-ietf-idn-uri-00.txt +++ /dev/null @@ -1,269 +0,0 @@ -INTERNET-DRAFT Martin Duerst -draft-ietf-idn-uri-00 W3C/Keio University -Expires July 2001 January 6, 2001 - - - Internationalized Domain Names in URIs and IRIs - -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 is a first draft for the provisions necessary to -upgrade the definitions of URIs [RFC 2396] and IRIs (Internationalized -Resource Identifiers, [IRI]) to work with internationalized domain -names. - - -1. Introduction - -Internet domain names serve to identify hosts and services on the -Internet in a convenient way. The IETF IDN working group is currently -working on extending the character repertoire usable in domain names -beyond a subset of US-ASCII. - -One of the most important places where domain names appear are -Uniform Resource Identifiers (URIs, [RFC 2396], as modified by -[RFC2732]). However, in the current definition of the generic URI -syntax, the restrictions on domain names are 'hard-coded'. This -document proposes to relax these restrictions by updating the syntax, -and defines how internationalized domain names are encoded in URIs. - -URIs themselves are restricted to a subset of US-ASCII. However, -there is a proposal for relieving these restrictions by creating -a new protocol element called an IRI (Internationalized Resource -Identifier [IRI]). While IRIs in general allow the use of non-ASCII -characters, the syntax of IRIs has the same restriction for domain -names as the syntaxt of URIs. This document proposes to relax these -restrictions, too, in a way that is compatible with the new syntax -for URIs. This means that encoding an internationalized domain name in -an URI and encoding the same name in an IRI will produce an URI and an -IRI that can be converted into each other using the procedures defined -in [IRI] for these conversions. - -2. URI syntax changes - -The syntax of URIs [RFC2326] currently contains the following rules -relevant to domain names: - - hostname = *( domainlabel "." ) toplabel [ "." ] - domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum - toplabel = alpha | alpha *( alphanum | "-" ) alphanum - -The later two rules are changed as follows: - - domainlabel = escalphanum | escalphanum *( escalphanum | "-" ) - escalphanum - toplabel = escalpha | escalpha *( escalphanum | "-" ) - escalphanum - -and the following rules are added: - - escalphanum = escaped8 | alphanum - escalpha = elcaped8 | alpha - escaped8 = "%" hexdig8 HEXDIG - hexdig8 = <> - -The %HH escaping is used to encode characters outside the repertoire -of US-ASCII. This is done by first encoding the characters in UTF-8 -[RFC 2279], resulting in a sequence of octets, and then escaping these -octets. - -Using UTF-8 assures that this encoding interoperates with IRIs (see -Section 3). It is also alligned with the recommendations in [RFC 2277] -and [RFC 2718], and is consistent with the URN syntax [RFC2141] as -well as recent URL scheme definitions that define encodings of -non-ASCII characters based on (e.g., IMAP URLs [RFC 2192] and POP URLs -[RFC 2384]). - -Please note that the use of UTF-8 for encoding internationalized -domain names in URIs is independent of the choice of encoding chosen -for these names in the DNS protocol. In case something else than UTF-8 -is chosen for the later, a future version of this document may give -instructions for the conversion if deemed necessary. - -The above syntax rules do not extend the possible domain names based -on US-ASCII characters. This may have to be changed in case the IDN -WG should decide to allow such extensions. - -The above rules also do not allow escaping of US-ASCII characters, -although this is allowed in the other parts of an URI (except for the -special provisions in case of reserved characters). Allowing such -escaping would make the syntax rules quite a bit more complicated, -would mean that the restrictions on US-ASCII characters can be -circumvented by using escaping, or would lead to much simpler syntax -rules that don't express these restrictions anymore. Even in case -escaping of US-ASCII characters is allowed in order to simplify -processing, it should be noted that it is always better not to escape -US-ASCII characters in domain names because of the possibility that -a resolver cannot unescape them. At least purely US-ASCII domain names -would then always be resolved by such a processor. - -While only the restrictions on US-ASCII characters are expressed in the -rules above, all the other restrictions on internationalized -domain names that will be defined by the IDN WG MUST be respected. - -The work of the IDN WG currently includes some procedures for name -preparation. Before encoding an internationalized domain name in an -URI, this preparation step SHOULD be applied. However, the resolver -MUST also apply name preparation. - - -2. IRI syntax changes - -The syntax of IRIs [IRI] currently contains the following rules -relevant to domain names: - - hostname = *( domainlabel "." ) toplabel [ "." ] - domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum - toplabel = alpha | alpha *( alphanum | "-" ) alphanum - -The later two rules are changed as follows: - - domainlabel = intalphanum | intalphanum *( intalphanum | "-" ) - intalphanum - toplabel = intalpha | intalpha *( intalphanum | "-" ) - intalphanum - -and the following rules are added: - - intalphanum = ichar | alphanum | escaped8 - intalpha = ichar | alpha | escaped8 - escaped8 = "%" hexdig8 HEXDIG - hexdig8 = <> - -where ichar, as in [IRI], is: - - ichar = << any character of UCS [ISO10646] beyond - U+0080, subject to limitations in Section - 3.1. of [IRI] >> - -With respect to the allowed domain names based on US-ASCII characters, -the same considerations as in Section 2 apply. - -As in Section 2, all the other restrictions on internationalized -domain names that will be defined by the IDN WG MUST be respected. -Also, before encoding an internationalized domain name in an IRI, -name preparation SHOULD be applied. However, the IRI resolver MUST -also apply name preparation. - -It is expected that the rules in Section 3.1 of [IRI] will be less -restrictive than the rules for internationalized domain names, so that -no escaping is necessary. Nevertheless, escaping is allowed for cases -where not all characters can be directly represented. - - -4. Security Considerations - -Besides the security considerations of [RFC 2396] and [IRI] and those -applying to the various aspects of internationalized domain names in -general, there are currently no known security problems. - - -Acknowledgements - -To be done. - - -Copyright - -Copyright (C) The Internet Society, 1997. 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." - - -Author's address - - Martin J. Duerst - W3C/Keio University - 5322 Endo, Fujisawa - 252-8520 Japan - duerst@w3.org - http://www.w3.org/People/D%C3%BCrst/ - Tel/Fax: +81 466 49 1170 - - Note: Please write "Duerst" with u-umlaut wherever - possible, e.g. as "Dürst" in XML and HTML. - - -References - -[IRI] L. Masinter, M. Duerst, "Internationalized Resource Identifiers - (IRI)", Internet Draft, January 2001, - , - work in progress. - -[ISO10646] ISO/IEC, Information Technology - Universal Multiple-Octet - Coded Character Set (UCS) - Part 1: Architecture and Basic - Multilingual Plane, Oct. 2000, with amendments. - -[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", March 1997. - -[RFC 2141] R. Moats, "URN Syntax", May 1997. - -[RFC 2192] C. Newman, "IMAP URL Scheme", September 1997. - -[RFC 2277] H. Alvestrad, "IETF Policy on Character Sets and - Languages". - -[RFC 2279] F. Yergeau. "UTF-8, a transformation format of ISO 10646.", - January 1998. - -[RFC 2384] R. Gellens, "POP URL Scheme", August 1998. - -[RFC 2396] T.Berners-Lee, R.Fielding, L.Masinter. "Uniform Resource - Identifiers (URI): Generic Syntax." August, 1998. - -[RFC 2640] B. Curtis, "Internationalization of the File Transfer - Protocol", July 1999. - -[RFC 2718] L. Masinter, H. Alvestrand, D. Zigmond, R. Petke, - "Guidelines for new URL Schemes", November 1999. - -[RFC 2732] R. Hinden, B. Carpenter, L. Masinter, "Format for Literal - IPv6 Addresses in URL's", December 1999. - - - diff --git a/doc/draft/draft-ietf-idn-uri-01.txt b/doc/draft/draft-ietf-idn-uri-01.txt new file mode 100644 index 0000000000..af19ecf9d3 --- /dev/null +++ b/doc/draft/draft-ietf-idn-uri-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +M. Duerst: mduerst@w3.org + + diff --git a/doc/draft/draft-ietf-idn-utf6-00.txt b/doc/draft/draft-ietf-idn-utf6-00.txt deleted file mode 100644 index e17a1007eb..0000000000 --- a/doc/draft/draft-ietf-idn-utf6-00.txt +++ /dev/null @@ -1,451 +0,0 @@ -Internet Engineering Task Force (IETF) Mark Welter -INTERNET-DRAFT Brian W. Spolarich -draft-ietf-idn-utf6-00 WALID, Inc. -November 16, 2000 Expires May 16, 2001 - - - UTF-6 - Yet Another ASCII-Compatible Encoding for IDN - -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. - -The distribution of this document is unlimited. - -Copyright (c) The Internet Society (2000). All Rights Reserved. - -Abstract - -This document describes a tranformation method for representing -Unicode character codepoints in host name parts in a fashion that is -completely compatible with the current Domain Name System. It is -proposed as a potential candidate for an ASCII-Compatible Encoding (ACE) -for supporting the deployment of an internationalized Domain Name System. -The tranformation method, an extension of the UTF-5 encoding proposed by -Duerst, provides both for more efficient representation of typical Unicode -sequences while preserving simplicity and readability. This transformation -method is deployed as part of the current WALID multilingual domain name -system implementation, although that status should not necessarily influence -the evaluation of its merits as a candidate encoding method. - - -Table of Contents - -1. Introduction -1.1 Terminology -2. Hostname Part Transformation -2.1 Post-Converted Name Prefix -2.2 Hostname Prepartion -2.3 Definitions -2.4 UTF-6 Encoding -2.4.1 Variable Length Hex Encoding -2.4.2 UTF-6 Compression Algorithm -2.4.3 Forward Transformation Algorithm -2.5 UTF-6 Decoding -2.5.1 Variable Length Hex Decoding -2.5.2 UTF-6 Decompression Algorithm -2.5.3 Reverse Transformation Algorithm -3. Examples -3.1 'www.walid.com' (in Arabic) -4. Security Considerations -5. References - - -1. Introduction - -UTF-6 describes an encoding scheme of the ISO/IEC 10646 [ISO10646] -character set (whose character code assignments are synchronized -with Unicode [UNICODE3]), and the procedures for using this scheme -to transform host name parts containing Unicode character sequences -into sequences that are compatible with the current DNS protocol -[STD13]. As such, it satisfies the definition of a 'charset' as -defined in [IDNREQ]. - -1.1 Terminology - -The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and -"MAY" in this document are to be interpreted as described in RFC 2119 -[RFC2119]. - -Hexadecimal values are shown preceded with an "0x". For example, -"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are -shown preceded with an "0b". For example, a nine-bit value might be -shown as "0b101101111". - -Examples in this document use the notation from the Unicode Standard -[UNICODE3] as well as the ISO 10646 names. For example, the letter "a" -may be represented as either "U+0061" or "LATIN SMALL LETTER A". - -UTF-6 converts strings with internationalized characters into -strings of US-ASCII that are acceptable as host name parts in current -DNS host naming usage. The former are called "pre-converted" and the -latter are called "post-converted". This specification defines both -a forward and reverse transformation algorithm. - - -2. Hostname Part Transformation - -According to [STD13], hostname parts must be case-insensitive, start and -end with a letter or digit, and contain only letters, digits, and the -hyphen character ("-"). This, of course, excludes most characters used -by non-English speakers, characters, as well as many other characters in -the ASCII character repertoire. Further, domain name parts must be -63 octets or shorter in length. - - -2.1 Post-Converted Name Prefix - -This document defines the string 'wq--' as a prefix to identify -UTF-6-encoded sequences. For the purposes of comparison in the IDN -Working Group activities, the 'wq--' prefix should be used solely to -identify UTF-6 sequences. However, should this document proceed beyond -draft status the prefix should be changed to whatever prefix, if any, -is the final consensus of the IDN working group. - -Note that the prepending of a fixed identifier sequence is only one -mechanism for differentiating ASCII character encoded international -domain names from 'ordinary' domain names. One method, as proposed in -[IDNRACE], is to include a character prefix or suffix that does not -appear in any name in any zone file. A second method is to insert a -domain component which pushes off any international names one or more -levels deeper into the DNS heirarchy. There are trade-offs between -these two methods which are independent of the Unicode to ASCII -transcoding method finally chosen. We do not address the international -vs. 'ordinary' name differention issue in this paper. - -2.2 Hostname Prepartion - -The hostname part is assumed to have at least one character disallowed -by [STD13], and that is has been processed for logically equivalent -character mapping, filtering of disallowed characters (if any), and -compatibility composition/decomposition before presentation to the UTF-6 -conversion algorithm. - -While it is possible to invent a transcoding mechanism that relies -on certain Unicode characters being deemed illegal within domain names -and hence available to the transcoding mechanism for improving encoding -efficiency, we feel that such a proposal would complicate matters -excessively. We also believe that Unicode name preprocessing for -both name resolution and name registration should be considered as s -separate, independent issues, which we will attempt to address in a -separate document. - -2.3 Definitions - -For clarity: - - 'integer' is an unsigned binary quantity; - 'byte' is an 8-bit integer quantity; - 'nibble' is a 4-bit integer quantity. - -2.4 UTF-6 Encoding - -The idea behind this scheme was to improve on the UTF-5 transformation -algorithm described in [IDNDUERST] by providing a straightforward -compression mechanism. UTF-6 defines a compression mechanism by -indentifying identical leading byte or nibble values in the pre-converted -string, and using the length of this leading value to select a mask which -can be applied to the pre-converted string. The resulting post-converted -string is preserves the simplicity and readability of UTF-5 while -enabling longer sequences to be encoded into a single host name part. - -2.4.1 Variable Length Hex Encoding - -The variable length hex encoding algorithm was introduced by Duerst in -[IDNDUERST]. It encodes an integer value in a slight modification of -traditional hexadecimal notation, the difference being that the most -significant digit is represented with an alternate set of "digits" -- -- 'g through 'v' are used to represent 0 through 15. The result is a -variable length encoding which can efficiently represent integers of -arbitrary length. - -The variable length nibble encoding of an integer, C, is defined -as follows: - - 1. Skip over leading non-significant zero nibbles to find I, - the first significant nibble of c; - - 2. Emit the Ith character of the set [ghijklmopqrstuv]; - - 3. Continue from most to least significant, encoding each remaining - nibble J by emitting the Jth character of the set [0123456789abcdef]. - -Examples: - - 0x1f4c is encoded as "hf4c" - 0x0624 is encoded as "m24" - 0x0000 is encoded as "g" - 'n' a single character in single quotes stands for the - Unicode code point for that character. - -2.4.2 UTF-6 Compression Algorithm - -UTF-6 improves on the UTF-5 encoding by providing compression, which -enables encoding of a larger number of characters in each hostname -part. The compression algorithm is defined as follows: - - 1. Set the mask to 0xFFFF; - - 2. If the number of non '-' characters is less than 2, proceed to - step 5; - - 3. If the most significant byte of every non '-' character is the - same value: - - 3a. Set HB to this value; - 3b. Emit 'Y'; - 3c. Emit the variable length hex encoding of HB; - 3d. Set the mask to 0x00FF; - 3e. Proceed to step 5. - - 4. If the most significant nibble of every non '-' character is the - same value: - - 4a. Set HN to this value; - 4b. Emit 'Z'; - 4c. Emit the variable length hex encoding of HN; - 4d. Set the mask to 0x0FFF. - - 5. Foreach input character: - - 5a. Set HN to the result of the bitwise AND of the input - character and the mask; - 5b. Emit the variable length nibble encoding of HN. - -2.4.3 Forward Transformation Algorithm - -The UTF-6 transformation algorithm accepts a string in UTF-16 -[ISO10646] format as input. The encoding algorithm is as follows: - - 1. Break the hostname string into dot-separated hostname parts. - For each hostname part, perform steps 2 and 3 below; - - 2. Compress the component using the method described in section - 2.4.2 above, and encode using the encoding described in section 2.4.1; - - 3. Prepend the post-converted name prefix 'wq--' (see section 2.1 - above) to the resulting string. - - -2.5 UTF-6 Decoding - -2.5.1 Variable Length Hex Decoding - - 1. Let N be the lower case of the first input character; - - If N is not in set [ghijklmnopqrstuv] return error, - else consume the input character; - - 2. Let R = N - 'g'; - - 3. If another input character exists, - then let N be the lower case of the next input character, - else goto Step 9; - - 4. If N is not in the set [0123456789abcdef], go to Step 9; - - 5. Let N = the lower case of the next input character and consume - the input character; - - 6. Let R = R * 16; - - 7. If N is in set [0123456789], - then let R = R + (N - '0'), - else let R = R + (N - 'a') + 10; - - 8. Go to step 3; - - 9. Return decoded result R. - -2.5.2 UTF-6 Decompression Algorithm - - 1. Let N be the lower case of the first input character; - - 2. If N != 'y' and N != 'z', - - 2a. Let CPART be 0; - 2b. Let VMAX be 0xFFFF; - - This is the no-compression case; - - 3. If N == 'y', - - 3a. Let M be the variable length hex decoding of the next - character; - 3b. Let CPART be the result of M * 0x0100; - 3c. Let VMAX be 0x00FF; - 3d. Continue to Step 5; - - 4. If N == 'z', - - 4a. Let M be the variable length hex decoding of the next - character; - 4b. Let CPART be the result of M * 0x1000; - 4c. Let VMAX be 0x0FFF; - 4d. Continue to Step 5; - - 5. While another input character exists, let N be the lower case of - the next input character, and do the following: - - 5a. If N == '-' consume the character and - then append '-' to the result string, - else let VPART be the next variable hex decoded value; - 5b. If VPART > VMAX, return error, - else append CPART + VPART to the result string; - - 6. Return the result string. - -2.5.3 Reverse Transformation Algorithm - - 1. Break the string into dot-separated components and apply Steps - 2 through 4 to each component: - - 2. Check for legality (in terms of RFC1035 permitted characters) and - return error status if illegal, - - 3. Remove the post converted name prefix 'wq--' (see Section 2.1), - - 4. Decompress the component using the decompression algorithm - described above. - - 5. Concatenate the decoded segments with dot separators and return. - - -3. Examples - -The examples below illustrate the encoding algorithm and provide -comparisons to alternate encoding schemes. UTF-5 sequences are -prefixed with '----', as no ACE prefix was defined for that encoding. - -3.1 'www.walid.com' (in Arabic): - - UTF-16: U+0645 U+0648 U+0642 U+0639 . U+0648 U+0644 U+064A U+062F . - U+0634 U+0631 U+0643 U+0629 - - UTF-6: wq--ymk5k8k2j9.wq--ymk8k4kaif.wq--ymj4j1k3i9 - - UTF-5: ----m45m48m42m39.----m48m44m4am2f.----m34m31m43m29 - - RACE: bq--azcuqqrz.bq--azeeisrp.bq--ay2dcqzj - - LACE: bq--aqdekscche.bq--aqdeqrckf5.bq--aqddimkdfe - - -3.2 Mixed Katakana and Hiragana (SOREZORENOBASHO) - - UTF-16: U+305D U+308C U+305E U+308C U+306E U+5834 U+6240 - - UTF-6: - - UTF-5: - - RACE: bq--4ayf3memgbpdbdbqnzmdiysa - - LACE: bq--auyf4dc7rrxacwbuafrea - - -3.3 Currently Disallowed ASCII Characters ($OneBillionDollars!): - - UTF-16: U+0024 U+004F U+006E U+0065 U+0042 U+0069 U+006C U+006C - U+0069 U+006F U+006E U+0044 U+006F U+006C U+006C U+0061 - U+0072 U+0073 U+0021 - - UTF-6: - - UTF-5: - - RACE: bq--aase74tfijuwy4djn6xei44mnrqxe5zb - - LACE: bq--cmacit4omvbgs4dmnfxw5rdpnrwgc5ttee - -4. Security Considerations - -Much of the security of the Internet relies on the DNS and any -change to the characteristics of the DNS may change the security of -much of the Internet. Therefore UTF-6 makes no changes to the DNS itself. - -UTF-6 is designed so that distinct Unicode sequences map to distinct -domain name sequences (modulo the Unicode and DNS equivalence rules). -Therefore use of UTF-6 with DNS will not negatively affect security. - -5. References - -[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name -Proposals", draft-ietf-idn-compare. - -[IDNREQ] James Seng, "Requirements of Internationalized Domain Names", -draft-ietf-idn-requirement. - -[IDNNAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of -Internationalized Host Names", draft-ietf-idn-nameprep - -[IDNDUERST] M. Duerst, "Internationalization of Domain Names", -draft-duerst-dns-i18n. - -[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information -technology -- Universal Multiple-Octet Coded Character Set (UCS) -- -Part 1: Architecture and Basic Multilingual Plane. Five amendments and -a technical corrigendum have been published up to now. UTF-16 is -described in Annex Q, published as Amendment 1. 17 other amendments are -currently at various stages of standardization. - -[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate -Requirement Levels", March 1997, RFC 2119. - -[STD13] Paul Mockapetris, "Domain names - implementation and -specification", November 1987, STD 13 (RFC 1035). - -[UNICODE3] The Unicode Consortium, "The Unicode Standard -- Version -3.0", ISBN 0-201-61633-5. Described at -. - -A. Acknowledgements - -The structure (and some of the structural text) of this document is -intentionally borrowed from the LACE IDN draft (draft-ietf-idn-lace) -by Mark Davis and Paul Hoffman. - -The 'SOREZORENOBASHO' example was taken from draft-ietf-idn-brace draft -by Adam Costello. - -B. IANA Considerations - -There are no IANA considerations in this document. - -C. Author Contact Information - -Mark Welter -Brian W. Spolarich -WALID, Inc. -State Technology Park -2245 S. State St. -Ann Arbor, MI 48104 -+1-734-822-2020 - -mwelter@walid.com -briansp@walid.com ------BEGIN PGP SIGNATURE----- -Version: GnuPG v1.0.1 (GNU/Linux) -Comment: For info see http://www.gnupg.org - -iD8DBQE6FaCt/DkPcNgtD/0RAtRmAJwISVeJGY6qmll71mL+Axc51o8iIwCgmNt/ -86RcQh1JQYWTux+8FS+XvMU= -=bxiv ------END PGP SIGNATURE----- - diff --git a/doc/draft/draft-ietf-idn-utf6-01.txt b/doc/draft/draft-ietf-idn-utf6-01.txt new file mode 100644 index 0000000000..0081775d08 --- /dev/null +++ b/doc/draft/draft-ietf-idn-utf6-01.txt @@ -0,0 +1,20 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +B. Spolarich: briansp@ans.net +M. Welter: mwelter@walid.com + + diff --git a/doc/draft/draft-ietf-idn-version-00.txt b/doc/draft/draft-ietf-idn-version-00.txt deleted file mode 100644 index 2e67d206bb..0000000000 --- a/doc/draft/draft-ietf-idn-version-00.txt +++ /dev/null @@ -1,254 +0,0 @@ -Internet Draft Marc Blanchet - -draft-ietf-idn-version-00.txt Viagenie -October 26, 2000 -Expires in six -months - - - - - Handling versions of internationalized domain names protocols - - -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 some issues related to handling changes in the -codepoints and other features in the chars space of an internationalized -domain name as well as changes in the protocol that supports it (whatever -that be). It also presents some solutions to these issues. - - -1. Rationale - -The nameprep draft [NAMEPREP] is defining prohibited chars, normalization -algorithms, etc.. The current concensus is to take the safer approach of -not accepting new chars if they are not listed, since the new characters -that can be included in the subsequent releases of the universal character -set can have an impact on the domain name (for example, a new variation of -the dot . will mostly be non-compatible and being excluded). - -The Unicode and ISO-10646 versioning is designed not for the same purpose -as the idn work: for example, some chars or properties can be changed or -added to those repertoires that cannot be taken as is by the idn -protocol. In essence, the idn nameprep versions cannot be in sync with -unicode/iso versions. idn need its own versioning of the accepted character -set, which can or cannot be synchronized with the two others. While saying -that, there is no intent at all to define new codepoints inside this work -and any attempt to do that must be rejected. - -Since internationalization and specifically internationalization of the -domain names is new, we don't really know if the chosen algorithm, protocol -and codepoitns will not have any problem in the future. We need to handle -versions of the protocol and to have a specific table for idn accepted chars. - -2. Versioning of the protocol - -Since the idn table of chars will be changed in the future, and possibly -the algorithms and the processing, then there is a need to handle these -situations in a controlled way. A version of the idn protocol should be -defined and included as part of the exchange between the parties so that -they can handle smoothly the new revisions. - -2.1 Implementing the version in the protocol -Depending on which way the idn protocol will be, a different versioning -will have to be defined. We will discuss the current proposals and identify -where a versioning system can be handled. - -2.1.1 Proposals based on extensions of the DNS protocol - Proposals based on extensions of the DNS protocol should include in the -bits the version number and a way to exchange version numbers between the -parties. [IDNE] already defined a version number as part of the use of -EDNS. Similar versioning should be defined in the other proposed protocols. - -2.1.2 Proposals based on ACE and application - Since ACEs (for example [RACE]) in applications [IDNA] do not change the -DNS protocol but only encode the idn in a ascii compatible way, it looks -more difficult to include a version number in the ACE encoding, since it -will change the domain name. The proposal is to use a different -prefix/suffix for each version, by using one of the chars used in the -prefix as a version number, beginning with the lowest possible ascii char -available and increase the ascii codepoint of the char by 1 for each -version. For example, if the prefix is "ra--", then the first version of -idn will be "ra--", the second version will be "rb--", the third "rc--". -While this would be more elegant, one can handle versioning by having -different prefixes for each version, while chosing prefixes randomly (i.e. -1st version: rq--, 2nd version: wz--, ...). IANA should block all possible -prefixes so that no pre-registration is permitted. - -2.2 Major and minor version numbers - - A . version number is proposed (i.e. 1.0, 1.1, 2.0). A -minor revision is defined to be as new chars or small changes in the table -to be handled without any modification of algorithm. The idea here is to -enable easy upgrading of idn processors when only new chars will be -handled. In this case, the binary software do not have to be changed and -only the table containing the chars has to be changed to enable a new -version. A major revision means that the software has to be upgraded since -it implies new ways of handling idn which are not identified in the table. - -2.3 Processing of the version numbers -Any idn processor MUST verify the version number before processing. When a -major version number is higher than what the processor currently handle is -detected, processing MUST be stopped and rejected. When a minor version -number is higher than what the processor currently handle, then any -intermediate processors MUST forward the idn but the end processor (i.e. -the dns server authoritative for that zone that is handling the request) -MUST stop and reject the request. Specific handling of rejecting the -request should be defined in the protocol document. - -2.4 Version numbers - Version numbers of the idn protocol will be handled by IANA. A -IESG-reviewed document should be used as the basis for IANA to define a new -protocol version number. - -3. Idn table - Since the unicode consortium and ISO will issue new versions not at the -same time as the idn protocol versioning, the IETF need to have its own -registered table of accepted idn chars. This will also enable specific data -only useful for idn. The intent is not to duplicate the unicode/iso effort, -it is to support the specific needs of the idn group. For example, it is -possible that specific chars will have a different behavior than the normal -Unicode way: the special casing for final or non-final letters in the -Unicode SpecialCasing.txt file can be merged (ie not totally identical to -the unicode processing) to only one casing since final and non-final -letters have less meaning in a domain name. Simpler processing for idn is -also useful: for example, the Lud property is probably not useful in the -idn context and can be considered equivalent to Lu. Combining those -properties together means much simple table and simpler processing and less -errors in implementations. Added chars, codepoint, properties MUST NOT be -done in this file, but must be done within the Unicode/ISO process. - -This document proposes a table contained in an ascii file handled by IANA -and available in the IANA public directory. The source of the table will be -the Unicode table, with a similar format, but a simpler, and perhaps -different, content based on the needs of the idn protocol. Proposed -filename is: idntab.txt. - -This file format will also help implementors to have the same input -description and exhaustive list of which chars and processing to handle -idn. This is easier for implementors to have a complete list of accepted -chars instead a list of non-accepted chars. The hope is also to help -decrease the different behaviors between the different implementations. -This table can be considered as an implementation of [NAMEPREP]. - -3.1 File format - -The file is divided in two parts. The first part contains variables. The -second part contains all the chars accepted for idn. The two parts are -separated by a empty line. - -The format of the first part is: -tag=value - -Currently, only the version tag is defined. The "version" tag defines the -highest idn version number that can be found in this table. The intent is -to have only one file that is kept current but where the beginning of the -file can be used by parsers to identify the latest version of the file. - -The first idntab.txt file will define version=1.0: -version=1.0 - -The format of the second part is: - one codepoint per line - lines separated by CR/LF - each field in the line separated by ";" - -The fields are (in order, from left to right): - 1. codepoint in hexadecimal (as in unicode table): HHHH - 2. first version of idn table that this char is supported - -It is possible that new fields will be added in the future. Parsers should -ignore the fields that they don't understand. - -Spaces (ascii 0x20) are ignored. Comments are identified by "#". All text -following the comment char up to the end of line is ignored. Any codepoint -not in the table is considered prohibited. Codepoints that are prohibited -may be included in the table inside commented lines in order to help a -reader to see explicitly which ones are prohibited. - -Example of the file idntab10.txt: -version=1.0 - -0041;1.0; - -4. Security Considerations - -Changing the way a software react about domain names is clearly something -that have security impacts. While the actual table doesn't present any -security threat by itself, if there is someways by a intruder to reload a -new table into a idn processor software without the knowledge of the user, -then it can completly disables name resolution or have other possible -threats. In conclusion, care must be taken by software developers on how -to manage the insertion of a new idn table in a idn processor software. - -5. IANA Considerations - This document describes versions of the idn file called idntab.txt. The -file should be kept in the IANA public directory for references purposes. -New versions of the file should be made available after IESG review of a -document. Old revisions of the file (idntab-xy.txt) should be kept for -documentation purposes. - -6. Acknowledgements - The author would like to acknowledge the comments and idea of the -following people: Fran‡ois Yergeau and Paul Hoffman. - -7. Author - -Marc Blanchet -Viagenie -2875 boul. Laurier, bur. 300 -Ste-Foy, Quebec, Canada -G1V 2M2 -Marc.Blanchet@viagenie.qc.ca -tel: 418-656-9254 - -8. References - -[NAMEPREP] Preparation of Internationalized Host Names, Paul Hoffman, Marc -Blanchet. Work in progress. - -[RACE] RACE: Row-based ASCII Compatible Encoding for IDN, Paul Hoffman. -Work in progress. - -[IDNA] Internationalizing Host Names In Applications (IDNA), Paul Hoffman, -Patrick Falstrom. Work in progress. - - -Marc Blanchet -Viag‰nie inc. -tel: 418-656-9254 -http://www.viagenie.qc.ca - ----------------------------------------------------------- -Normos (http://www.normos.org): Internet standards portal: -IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. - diff --git a/doc/draft/draft-ietf-idn-version-01.txt b/doc/draft/draft-ietf-idn-version-01.txt new file mode 100644 index 0000000000..8e37fc03c8 --- /dev/null +++ b/doc/draft/draft-ietf-idn-version-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +M. Blanchet: Marc.Blanchet@viagenie.qc.ca + + diff --git a/doc/draft/draft-ietf-ipngwg-default-addr-select-05.txt b/doc/draft/draft-ietf-ipngwg-default-addr-select-06.txt similarity index 88% rename from doc/draft/draft-ietf-ipngwg-default-addr-select-05.txt rename to doc/draft/draft-ietf-ipngwg-default-addr-select-06.txt index ecc0ad12ee..00021e6df7 100644 --- a/doc/draft/draft-ietf-ipngwg-default-addr-select-05.txt +++ b/doc/draft/draft-ietf-ipngwg-default-addr-select-06.txt @@ -2,26 +2,34 @@ IPng Working Group Richard Draves Internet Draft Microsoft Research -Document: draft-ietf-ipngwg-default-addr-select-05.txt June 4, 2001 +Document: draft-ietf-ipngwg-default-addr-select-06.txt September 28, 2001 Category: Standards Track Default Address Selection for IPv6 + Status of this Memo + This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. + 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 two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override @@ -34,17 +42,20 @@ Abstract selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. + All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. + 1. Introduction + The IPv6 addressing architecture [2] allows multiple unicast addresses to be assigned to interfaces. These addresses may have different reachability scopes (link-local, site-local, or global). These addresses may also be "preferred" or "deprecated" [3]. Privacy considerations have introduced the concepts of "public addresses" -Draves Standards Track - Expires January 2002 1 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 +Draves Standards Track - Expires April 2002 1 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 and "temporary addresses" [4]. The mobility architecture introduces @@ -53,12 +64,14 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 example, a node may have multiple interfaces, some of them tunnels or virtual interfaces, or a site may have multiple ISP attachments with a global prefix per ISP. + The end result is that IPv6 implementations will very often be faced with multiple possible source and destination addresses when initiating communication. It is desirable to have default algorithms, common across all implementations, for selecting source and destination addresses so that developers and administrators can reason about and predict the behavior of their systems. + Furthermore, dual or hybrid stack implementations, which support both IPv6 and IPv4, will very often need to choose between IPv6 and IPv4 when initiating communication. For example, when DNS name @@ -74,6 +87,7 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 communication. The destination address selection algorithm solves this with a unified procedure for choosing among both IPv6 and IPv4 addresses. + This document specifies source address selection and destination address selection separately, but using a common framework so that together the two algorithms yield useful results. The algorithms @@ -82,6 +96,7 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 Furthermore, this document suggests a preferred method, longest matching prefix, for choosing among otherwise equivalent addresses in the absence of better information. + The framework also has policy hooks to allow administrative override of the default behavior. For example, using these hooks an administrator can specify a preferred source prefix for use with a @@ -89,25 +104,33 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 over addresses with another prefix. These hooks give an administrator flexibility in dealing with some multi-homing and transition scenarios, but they are certainly not a panacea. + The selection rules specified in this document MUST NOT be construed to override an application or upper-layer's explicit choice of a legal destination or source address. + + + -Draves Standards Track - Expires January 2002 2 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 +Draves Standards Track - Expires April 2002 2 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 1.1. Conventions used in this document + 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 [7]. + 2. Framework + Our framework for address selection derives from the most common implementation architecture, which separates the choice of destination address from the choice of source address. Consequently, the framework specifies two separate algorithms for these tasks. The algorithms are designed to work well together and they share a mechanism for administrative policy override. + In this implementation architecture, applications use APIs [8] like getaddrinfo() that return a list of addresses to the application. This list might contain both IPv6 and IPv4 addresses (sometimes @@ -120,6 +143,7 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 application might also specify a source address with bind(), but often the source address is left unspecified. Therefore the network layer does often choose a source address from several alternatives. + As a consequence, we intend that implementations of getaddrinfo() will use the destination address selection algorithm specified here to sort the list of IPv6 and IPv4 addresses that they return. @@ -128,9 +152,11 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 specified a source address. Application of this framework to source address selection in an IPv4 network layer may be possible but this is not explored further here. + Well-behaved applications should iterate through the list of addresses returned from getaddrinfo() until they find a working addresses. + The algorithms use several criteria in making their decisions. The combined effect is to prefer destination/source address pairs for which the two addresses are of equal scope or type, prefer smaller @@ -144,12 +170,13 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 address and a care-of address (indicating the mobile node is "at home" for that address), then the home/care-of address is preferred -Draves Standards Track - Expires January 2002 3 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 +Draves Standards Track - Expires April 2002 3 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 over addresses that are solely a home address or solely a care-of address. + The framework optionally allows for the possibility of administrative configuration of policy that can override the default behavior of the algorithms. The policy override takes the form of a @@ -158,13 +185,16 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 not configurable, or if an implementation has not been configured, then the default policy table specified in this document SHOULD be used. + 2.1. Scope Comparisons + Multicast destination addresses have a 4-bit scope field that controls the propagation of the multicast packet. The IPv6 addressing architecture defines scope field values for interface- local (0x1), link-local (0x2), subnet-local (0x3), admin-local (0x4), site-local (0x5), organization-local (0x8), and global (0xE) scopes [9]. + Use of the source address selection algorithm in the presence of multicast destination addresses requires the comparison of a unicast address scope with a multicast address scope. We map unicast link- @@ -173,17 +203,22 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 example, unicast site-local is equal to multicast site-local, which is smaller than multicast organization-local, which is smaller than unicast global, which is equal to multicast global. + We write Scope(A) to mean the scope of address A. For example, if A is a link-local unicast address and B is a site-local multicast address, then Scope(A) < Scope(B). + This mapping implicitly conflates unicast site boundaries and multicast site boundaries [9]. + 2.2. IPv4 Addresses and IPv4-Mapped Addresses + The destination address selection algorithm operates on both IPv6 and IPv4 addresses. For this purpose, IPv4 addresses should be represented as IPv4-mapped addresses [2]. For example, to lookup the precedence or other attributes of an IPv4 address in the policy table, lookup the corresponding IPv4-mapped IPv6 address. + IPv4 addresses are assigned scopes as follows. IPv4 auto- configuration addresses [6], which have the prefix 169.254/16, are assigned link-local scope. IPv4 private addresses [10], which have @@ -193,53 +228,66 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 the treatment of the IPv6 loopback address [9, section 4]). Other IPv4 addresses are assigned global scope. -Draves Standards Track - Expires January 2002 4 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 +Draves Standards Track - Expires April 2002 4 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 IPv4 addresses should be treated as having "preferred" configuration status. + 2.3. IPv6 Addresses with Embedded IPv4 Addresses + IPv4-compatible addresses [2] and 6to4 addresses [12] contain an embedded IPv4 address. For the purposes of this document, these addresses should be treated as having global scope. + IPv4-compatible addresses should be treated as having "preferred" configuration status. + 2.4. Loopback Address and Other Format Prefixes + The loopback address should be treated as having link-local scope [9, section 4] and "preferred" configuration status. + NSAP addresses and other addresses with as-yet-undefined format prefixes should be treated as having global scope and "preferred" configuration status. Later standards may supersede this treatment. + 2.5. Policy Table + The policy table is a longest-matching-prefix lookup table, much like a routing table. Given an address A, a lookup in the policy table produces two values: a precedence value Precedence(A) and a classification or label Label(A). + The precedence value Precedence(A) is used for sorting destination addresses. If Precedence(A) > Precedence(B), we say that address A has higher precedence than address B, meaning that our algorithm will prefer to sort destination address A before destination address B. + The label value Label(A) allows for policies that prefer a particular source address prefix for use with a destination address prefix. The algorithms prefer to use a source address S with a destination address D if Label(S) = Label(D). + IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here. If an implementation is not configurable or has not been configured, then it SHOULD operate according to the algorithms specified here in conjunction with the following default policy table: + Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4 + -Draves Standards Track - Expires January 2002 5 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 +Draves Standards Track - Expires April 2002 5 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 @@ -250,26 +298,33 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 effect of the default policy table is to prefer communication using IPv6 addresses to communication using IPv4 addresses, if matching source addresses are available. + Policy table entries for scoped address prefixes MAY be qualified with an optional zone index. If so, a prefix table entry only matches against an address during a lookup if the zone index also matches the address's zone index. + 2.6. Common Prefix Length + We define the common prefix length CommonPrefixLen(A, B) of two addresses A and B as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common. It ranges from 0 to 128. + 3. Candidate Source Addresses + The source address selection algorithm uses the concept of a "candidate set" of potential source addresses for a given destination address. We write CandidateSource(A) to denote the candidate set for the address A. + It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination. (The "outgoing" interface.) On routers, the candidate set MAY include unicast addresses assigned to any interface that forwards packets, subject to the restrictions described below. + Discussion: The Neighbor Discovery Redirect mechanism [13] requires that routers verify that the source address of a packet identifies a neighbor before generating a Redirect, so it is @@ -278,24 +333,32 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 of global source addresses assigned to a loopback interface should behave as if the loopback interface originates and forwards the packet. + In some cases the destination address may be qualified with a zone index or other information that will constrain the candidate set. + For multicast and link-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same link as the outgoing interface. + + + -Draves Standards Track - Expires January 2002 6 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 +Draves Standards Track - Expires April 2002 6 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 Discussion: The restriction for multicast destination addresses is necessary because currently-deployed multicast forwarding algorithms use Reverse Path Forwarding (RPF) checks. + For site-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same site as the outgoing interface. + In any case, anycast addresses, multicast addresses, and the unspecified address MUST NOT be included in a candidate set. + If an application or upper-layer specifies a source address that is not in the candidate set for the destination, then the network layer MUST treat this is an error. The specified source address may @@ -306,36 +369,43 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 layer does not specify a source address, then the network layer uses the source address selection algorithm specified in the next section. - Discussion: + 4. Source Address Selection + The source address selection algorithm chooses a source address for use with a destination address D. It is specified here in terms of the pair-wise comparison of addresses SA and SB. The pair-wise comparison can be used to select an address from the set CandidateSource(D). + This source address selection algorithm only applies to IPv6 destination addresses, not IPv4 addresses. + The pair-wise comparison consists of eight rules, which should be applied in order. If a rule chooses an address, then the remaining rules are not relevant and should be ignored. Subsequent rules act as tie-breakers for earlier rules. If the eight rules fail to choose an address, some unspecified tie-breaker should be used. + Rule 1: Prefer same address. If SA = D, then choose SA. Similarly, if SB = D, then choose SB. + Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then choose SB and otherwise choose SA. Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then choose SA and otherwise choose SB. - -Draves Standards Track - Expires January 2002 7 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 - - + Rule 3: Avoid deprecated addresses. The addresses SA and SB have the same scope. If one of the source addresses is "preferred" and one of them is "deprecated", choose the one that is preferred. + + +Draves Standards Track - Expires April 2002 7 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + Rule 4: Prefer home addresses. If SA is simultaneously a home address and care-of address and SB is not, then prefer SA. Similarly, if SB is simultaneously a home @@ -346,16 +416,19 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 An implementation may support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer care-of addresses over home addresses. + Rule 5: Prefer outgoing interface. If SA is assigned to the interface that will be used to send to D and SB is assigned to a different interface, then prefer SA. Similarly, if SB is assigned to the interface that will be used to send to D and SA is assigned to a different interface, then prefer SB. + Rule 6: Prefer matching label. If Label(SA) = Label(D) and Label(SB) <> Label(D), then choose SA. Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then choose SB. + Rule 7: Prefer public addresses. If SA is a public address and SB is a temporary address, then prefer SA. Similarly, if SB is a public address and SA is a temporary @@ -364,6 +437,7 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 mechanism (for example, a socket option) to reverse the sense of this preference and prefer temporary addresses over public addresses. + This rule avoids applications potentially failing due to the relatively short lifetime of temporary addresses or due to the possibility of the reverse lookup of a temporary address either @@ -371,59 +445,81 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 privacy considerations outweigh these application compatibility concerns MAY reverse the sense of this rule and by default prefer temporary addresses over public addresses. + Rule 8: Use longest matching prefix. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then choose SB. + Rule 8 may be superseded if the implementation has other means of choosing among source addresses. For example, if the implementation - -Draves Standards Track - Expires January 2002 8 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 - - somehow knows which source address will result in the "best" communications performance. + Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability. + + +Draves Standards Track - Expires April 2002 8 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + 5. Destination Address Selection + The destination address selection algorithm takes a list of destination addresses and sorts the addresses to produce a new list. It is specified here in terms of the pair-wise comparison of addresses DA and DB, where DA appears before DB in the original list. + The algorithm sorts together both IPv6 and IPv4 addresses. To find the attributes of an IPv4 address in the policy table, the IPv4 address should be represented as an IPv4-mapped address. + We write Source(D) to indicate the selected source address for a destination D. For IPv6 addresses, the previous section specifies the source address selection algorithm. Source address selection for IPv4 addresses is not specified in this document. + We say that Source(D) is undefined if there is no source address available for destination D. For IPv6 addresses, this is only the case if CandidateSource(D) is the empty set. - The pair-wise comparison of destination addresses consists of nine + + The pair-wise comparison of destination addresses consists of ten rules, which should be applied in order. If a rule determines a result, then the remaining rules are not relevant and should be ignored. Subsequent rules act as tie-breakers for earlier rules. + Rule 1: Avoid unusable destinations. - If there is no route to DB or the current next-hop neighbor for DB - is known to be unreachable or if Source(DB) is undefined, then sort - DA before DB. Similarly, if there is no route to DA or the current - next-hop neighbor for DA is known to be unreachable or if Source(DA) - is undefined, then sort DB before DA. - For IPv6 destination addresses, the + If DB is known to be unreachable or if Source(DB) is undefined, then + sort DA before DB. Similarly, if DA is known to be unreachable or if + Source(DA) is undefined, then sort DB before DA. + + Discussion: An implementation may know that a particular + destination is unreachable in several ways. For example, the + destination may be reached through a network interface that is + currently unplugged. For example, the implementation may retain + for some period of time information from Neighbor Unreachability + Detection [13]. In any case, the determination of unreachability + for the purposes of this rule is implementation-dependent. + Rule 2: Prefer matching scope. If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), then sort DA before DB. Similarly, if Scope(DA) <> Scope(Source(DA)) and Scope(DB) = Scope(Source(DB)), then sort DB before DA. + Rule 3: Avoid deprecated addresses. If Source(DA) is deprecated and Source(DB) is not, then sort DB before DA. Similarly, if Source(DA) is not deprecated and Source(DB) is deprecated, then sort DA before DB. + + + + + -Draves Standards Track - Expires January 2002 9 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 +Draves Standards Track - Expires April 2002 9 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 Rule 4: Prefer home addresses. @@ -435,34 +531,63 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 of address, then sort DA before DB. Similarly, if Source(DA) is just a care-of address and Source(DB) is just a home address, then sort DB before DA. + Rule 5: Prefer matching label. If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), then sort DA before DB. Similarly, if Label(Source(DA)) <> Label(DA) and Label(Source(DB)) = Label(DB), then sort DB before DA. + Rule 6: Prefer higher precedence. If Precedence(DA) > Precedence(DB), then sort DA before DB. Similarly, if Precedence(DA) < Precedence(DB), then sort DB before DA. - Rule 7: Prefer smaller scope. + + Rule 7: Prefer native transport. + If DA is reached via an encapsulating transition mechanism (eg, IPv6 + in IPv4) and DB is not, then sort DB before DA. Similarly, if DB is + reached via encapsulation and DA is not, then sort DA before DB. + + Discussion: 6-over-4 [14], ISATAP [15], and configured + tunnels [16] are examples of encapsulating transition mechanisms + for which the destination address does not have a specific prefix + and hence can not be assigned a lower precedence in the policy + table. An implementation MAY generalize this rule by using a + concept of interface preference, and giving virtual interfaces + (like the IPv6-in-IPv4 encapsulating interfaces) a lower + preference than native interfaces (like ethernet interfaces). + + Rule 8: Prefer smaller scope. If Scope(DA) < Scope(DB), then sort DA before DB. Similarly, if Scope(DA) > Scope(DB), then sort DB before DA. - Rule 8: Use longest matching prefix. + + Rule 9: Use longest matching prefix. If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then sort DA before DB. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then sort DB before DA. - Rule 9: Otherwise, leave the order unchanged. + + Rule 10: Otherwise, leave the order unchanged. Sort DA before DB. - Rules 8 and 9 may be superseded if the implementation has other + + Rules 9 and 10 may be superseded if the implementation has other means of sorting destination addresses. For example, if the implementation somehow knows which destination addresses will result in the "best" communications performance. + + + +Draves Standards Track - Expires April 2002 10 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + 6. Interactions with Routing + This specification of source address selection assumes that routing (more precisely, selecting an outgoing interface on a node with multiple interfaces) is done before source address selection. However, implementations may use source address considerations as a tiebreaker when choosing among otherwise equivalent routes. + For example, suppose a node has interfaces on two different links, with both links having a working default router. Both of the interfaces have preferred global addresses. When sending to a global @@ -470,29 +595,28 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 interface over the other, then an implementation may preferentially choose the outgoing interface that will allow it to use the source address that shares a longer common prefix with the destination. - -Draves Standards Track - Expires January 2002 10 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 - - + Implementations may also use the choice of router to influence the choice of source address. For example, suppose a host is on a link with two routers. One router is advertising a global prefix A and - the other route is advertising global prefix B. Then when sending + the other router is advertising global prefix B. Then when sending via the first router, the host may prefer source addresses with prefix A and when sending via the second router, prefer source addresses with prefix B. + 7. Implementation Considerations + The destination address selection algorithm needs information about potential source addresses. One possible implementation strategy is - for getaddrinfo() to call down to the IPv6 network layer with a list - of destination addresses, sort the list in the network layer with - full current knowledge of available source addresses, and return the + for getaddrinfo() to call down to the network layer with a list of + destination addresses, sort the list in the network layer with full + current knowledge of available source addresses, and return the sorted list to getaddrinfo(). This is simple and gives the best results but it introduces the overhead of another system call. One way to reduce this overhead is to cache the sorted address list in the resolver, so that subsequent calls for the same name do not need to resort the list. + Another implementation strategy is to call down to the network layer to retrieve source address information and then sort the list of addresses directly in the context of getaddrinfo(). To reduce @@ -502,30 +626,34 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 have knowledge of the outgoing interface for each destination, so it MAY use a looser definition of the candidate set during destination address ordering. + In any case, if the implementation uses cached and possibly stale information in its implementation of destination address selection, or if the ordering of a cached list of destination addresses is possibly stale, then it should ensure that the destination address ordering returned to the application is no more than one second out of date. For example, an implementation might make a system call to + +Draves Standards Track - Expires April 2002 11 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + check if any routing table entries or source address assignments that might affect these algorithms have changed. Another strategy is to use an invalidation counter that is incremented whenever any underlying state is changed. By caching the current invalidation counter value with derived state and then later comparing against - the current value, the implementation can detect if the derived + the current value, the implementation could detect if the derived state is potentially stale. + 8. Security Considerations + This document has no direct impact on Internet infrastructure security. + Note that most source address selection algorithms, including the one specified in this document, expose a potential privacy concern. An unfriendly node can infer correlations among a target node's - -Draves Standards Track - Expires January 2002 11 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 - - addresses by probing the target node with request packets that force the target host to choose its source address for the reply packets. (Perhaps because the request packets are sent to an anycast or @@ -534,101 +662,129 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 reply packets.) By using different addresses for itself, the unfriendly node can cause the target node to expose the target's own addresses. + 9. Examples + This section contains a number of examples, first of default behavior and then demonstrating the utility of policy table configuration. These examples are provided for illustrative purposes; they should not be construed as normative. + 9.1. Default Source Address Selection + The source address selection rules, in conjunction with the default policy table, produce the following behavior: + Destination: 2001::1 Sources: 3ffe::1 vs fe80::1 Result: 3ffe::1 (prefer appropriate scope) + Destination: 2001::1 Sources: fe80::1 vs fec0::1 Result: fec0::1 (prefer appropriate scope) + Destination: fec0::1 Sources: fe80::1 vs 2001::1 Result: 2001::1 (prefer appropriate scope) + Destination: ff05::1 Sources: fe80::1 vs fec0::1 vs 2001::1 Result: fec0::1 (prefer appropriate scope) + + +Draves Standards Track - Expires April 2002 12 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + Destination: 2001::1 Sources: 2001::1 (deprecated) vs 2002::1 Result: 2001::1 (prefer same address) + Destination: fec0::1 Sources: fec0::2 (deprecated) vs 2001::1 Result: fec0::2 (prefer appropriate scope) + Destination: 2001::1 Sources: 2001::2 vs 3ffe::2 Result: 2001::2 (longest-matching-prefix) + Destination: 2001::1 Sources: 2001::2 (care-of address) vs 3ffe::2 (home address) Result: 3ffe::2 (prefer home address) - -Draves Standards Track - Expires January 2002 12 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 - - + Destination: 2002:836b:2179::1 Sources: 2002:836b:2179::d5e3:7953:13eb:22e8 (temporary) vs 2001::2 Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label) + Destination: 2001::d5e3:0:0:1 Sources: 2001::2 vs 2001::d5e3:7953:13eb:22e8 (temporary) Result: 2001::2 (prefer public address) + 9.2. Default Destination Address Selection + The destination address selection rules, in conjunction with the default policy table and the source address selection rules, produce the following behavior: + Sources: 2001::2 or fe80::1 or 169.254.13.78 Destinations: 2001::1 vs 131.107.65.121 Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 169.254.13.78) (prefer matching scope) + Sources: fe80::1 or 131.107.65.117 Destinations: 2001::1 vs 131.107.65.121 Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src fe80::1) (prefer matching scope) + Sources: 2001::2 or fe80::1 or 10.1.2.4 Destinations: 2001::1 vs 10.1.2.3 Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer higher precedence) + Sources: 2001::2 or fec0::2 or fe80::2 Destinations: 2001::1 vs fec0::1 vs fe80::1 Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then 2001::1 (src 2001::2) (prefer smaller scope) + Sources: 2001::2 (care-of address) or 3ffe::1 (home address) or fec0::2 (care-of address) or fe80::2 (care-of address) Destinations: 2001::1 vs fec0::1 + +Draves Standards Track - Expires April 2002 13 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home address) + Sources: 2001::2 or fec0::2 (deprecated) or fe80::2 Destinations: 2001::1 vs fec0::1 Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid deprecated addresses) + Sources: 2001::2 or 3f44::2 or fe80::2 Destinations: 2001::1 vs 3ffe::1 Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest matching prefix) + Sources: 2002:836b:4179::2 or fe80::2 Destinations: 2002:836b:4179::1 vs 2001::1 - -Draves Standards Track - Expires January 2002 13 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 - - Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src 2002:836b:4179::2) (prefer matching label) + Sources: 2002:836b:4179::2 or 2001::2 or fe80::2 Destinations: 2002:836b:4179::1 vs 2001::1 Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src 2002:836b:4179::2) (prefer higher precedence) + 9.3. Configuring Preference for IPv6 vs IPv4 + The default policy table gives IPv6 addresses higher precedence than IPv4 addresses. This means that applications will use IPv6 in preference to IPv4 when the two are equally suitable. An administrator can change the policy table to prefer IPv4 addresses by giving the ::ffff:0.0.0.0/96 prefix a higher precedence: + Prefix Precedence Label ::1/128 50 0 ::/0 40 1 @@ -638,19 +794,31 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 This change to the default policy table produces the following behavior: + Sources: 2001::2 or fe80::1 or 169.254.13.78 Destinations: 2001::1 vs 131.107.65.121 Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src 169.254.13.78) (prefer matching scope) + Sources: fe80::1 or 131.107.65.117 Destinations: 2001::1 vs 131.107.65.121 Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src fe80::1) (prefer matching scope) + + + + +Draves Standards Track - Expires April 2002 14 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + Sources: 2001::2 or fe80::1 or 10.1.2.4 Destinations: 2001::1 vs 10.1.2.3 New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2) (prefer higher precedence) + 9.4. Configuring Preference for Scoped Addresses + The destination address selection rules give preference to destinations of smaller scope. For example, a site-local destination will be sorted before a global scope destination when the two are @@ -658,11 +826,7 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 table to reverse this preference and sort global destinations before site-local destinations, and site-local destinations before link- local destinations: - -Draves Standards Track - Expires January 2002 14 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 - - + Prefix Precedence Label ::1/128 50 0 ::/0 40 1 @@ -674,15 +838,19 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 This change to the default policy table produces the following behavior: + Sources: 2001::2 or fec0::2 or fe80::2 Destinations: 2001::1 vs fec0::1 vs fe80::1 New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then fe80::1 (src fe80::2) (prefer higher precedence) + Sources: 2001::2 (deprecated) or fec0::2 or fe80::2 Destinations: 2001::1 vs fec0::1 Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2) (avoid deprecated addresses) + 9.5. Configuring a Multi-Homed Site + Consider a site A that has a business-critical relationship with another site B. To support their business needs, the two sites have contracted for service with a special high-performance ISP. This is @@ -690,45 +858,57 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 with different ISPs. The high-performance ISP is expensive and the two sites wish to use it only for their business-critical traffic with each other. + Each site has two global prefixes, one from the high-performance ISP and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48 from the high-performance ISP and prefix 2007:0:aaaa::/48 from its normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high- + + + +Draves Standards Track - Expires April 2002 15 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All hosts in both sites register two addresses in the DNS. + The routing within both sites directs most traffic to the egress to the normal ISP, but the routing directs traffic sent to the other site's 2001 prefix to the egress to the high-performance ISP. To prevent unintended use of their high-performance ISP connection, the two sites implement ingress filtering to discard traffic entering from the high-performance ISP that is not from the other site. + The default policy table and address selection rules produce the following behavior: + Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b - -Draves Standards Track - Expires January 2002 15 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 - - Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) (longest matching prefix) + In other words, when a host in site A initiates a connection to a host in site B, the traffic does not take advantage of their connections to the high-performance ISP. This is not their desired behavior. + Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then 2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) + In other words, when a host in site A initiates a connection to a host in some other site C, the reverse traffic may come back through the high-performance ISP. Again, this is not their desired behavior. + This situation demonstrates the limitations of the longest-matching- prefix heuristic in multi-homed situations. + However, the administrators of sites A and B can achieve their desired behavior via policy table configuration. For example, they can use the following policy table: + Prefix Precedence Label ::1 50 0 2001:aaaa:aaaa::/48 45 5 @@ -739,181 +919,309 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 ::ffff:0:0/96 10 4 This policy table produces the following behavior: + Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b + + +Draves Standards Track - Expires April 2002 16 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then 2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence) + In other words, when a host in site A initiates a connection to a host in site B, the traffic uses the high-performance ISP as desired. + Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then 2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix) + In other words, when a host in site A initiates a connection to a host in some other site C, the traffic uses the normal ISP as desired. - -Draves Standards Track - Expires January 2002 16 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 - - + References 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. + 2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. + 3 S. Thompson, T. Narten, "IPv6 Stateless Address Autoconfig- uration", RFC 2462 , December 1998. + 4 T. Narten, R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. + 5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf- - mobileip-ipv6-13.txt, November 2000. + mobileip-ipv6-14.txt, July 2001. + 6 S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local - Addresses", draft-ietf-zeroconf-ipv4-linklocal-02.txt, March - 2001. + Addresses", draft-ietf-zeroconf-ipv4-linklocal-04.txt, July 2001. + 7 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. + 8 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999. + 9 S. Deering et. al, "IP Version 6 Scoped Address Architecture", draft-ietf-ipngwg-scoping-arch-02.txt, March 2001. + 10 Y. Rekhter et. al, "Address Allocation for Private Internets", RFC 1918, February 1996. + 11 F. Baker, Editor, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. + + + + +Draves Standards Track - Expires April 2002 17 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + + 12 B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. + 13 T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6", RFC 2461, December 1998. + + 14 B. Carpenter and C. Jung, "Transmission of IPv6 over IPv4 Domains + without Explicit Tunnels", RFC 2529, March 1999. + + 15 F. Templin, "Intra-Site Automatic Tunnel Addressing Protocol + (ISATAP)", draft-ietf-ngtrans-isatap-01.txt, May 2001. + + 16 R. Gilligan and E. Nordmark, "Transition Mechanisms for IPv6 + Hosts and Routers", RFC 1933, April 1996. + Acknowledgments + The author would like to acknowledge the contributions of the IPng Working Group, particularly Marc Blanchet, Brian Carpenter, Matt - Crawford, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony - Hain, M.T. Hollinger, JINMEI Tatuya, Erik Nordmark, Ken Powell, - Markku Savela, Dave Thaler, Ole Troan, and Mauro Tortonesi. Please - let the author know if you contributed to the development of this - draft and are not mentioned here. - -Draves Standards Track - Expires January 2002 17 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 - - + Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun + Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Erik Nordmark, Ken + Powell, Markku Savela, Pekka Savola, Dave Thaler, Mauro Tortonesi, + Ole Troan, and Stig Venaas. + Author's Address + Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052 - Phone: 1-425-936-2268 + Phone: +1 425 706 2268 Email: richdr@microsoft.com + Revision History + +Changes from draft-ietf-ipngwg-default-addr-select-05 + + Clarified the first destination-address selection rule, avoiding + unusable destination addresses. + + Added a new destination-address selection rule, to prefer native + transport over transition mechanisms that use encapsulation. + Changes from draft-ietf-ipngwg-default-addr-select-04 + Clarified candidate set formation for routers. + Added some explanatory discussion to the candidate set section. + Replaced usages of scope id with zone index. + + + +Draves Standards Track - Expires April 2002 18 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + Augmented the first destination-address selection rule, to avoid destination addresses for which the current next-hop neighbor is known to be unreachable. + Changes from draft-ietf-ipngwg-default-addr-select-03 + Reversed the treatment of temporary addresses, so that unless an application specifies otherwise public addresses are preferred over temporary addresses. + Added text clarifying our expectation that applications should iterate through the list of possible destination addresses until finding a working address. + Removed references to getipnodebyname(). + Changes from draft-ietf-ipngwg-default-addr-select-02 + Changed scope treatment of IPv4-compatible and 6to4 addresses, so they are always considered to be global. Removed mention of IPX addresses. + Changed home address rules to favor addresses that are simultaneously home and care-of addresses, over addresses that are just home addresses or just care-of addresses. + Combined SrcLabel & DstLabel in the policy table into a single Label attribute. + Added mention of the invalidation counter technique in the implementation section. - -Draves Standards Track - Expires January 2002 18 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 - - + Changes from draft-ietf-ipngwg-default-addr-select-01 + Added Examples section, demonstrating default behavior and some policy table configuration scenarios. + Removed many uses of MUST. Remaining uses concern the candidate set of source addresses and the source address selection rule that prefers source addresses of appropriate scope. + Simplified the default policy table. Reordered the source address selection rules to reduce the influence of policy labels. Added more destination address selection rules. + Added scoping of v4-compatible and 6to4 addresses based on the embedded IPv4 address. + Changed references to anonymous addresses to use the new term, temporary addresses. + Clarified that a user-level implementation of destination address ordering, which does not have knowledge of the outgoing interface + +Draves Standards Track - Expires April 2002 19 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + for each destination, may use a looser definition of the candidate set. + Clarified that an implementation should prevent an application or upper-layer from choosing a source address that is not in the candidate set and not prevent an application or upper-layer from choosing a source address that is in the candidate set. + Miscellaneous editorial changes, including adding some missing references. + Changes from draft-ietf-ipngwg-default-addr-select-00 + Changed the candidate set definition so that the strong host model is recommended but not required. Added a rule to source address selection to prefer addresses assigned to the outgoing interface. + Simplified the destination address selection algorithm, by having it use source address selection as a subroutine. + Added a rule to source address selection to handle anonymous/public addresses. + Added a rule to source address selection to handle home/care-of addresses. + Changed to allow destination address selection to sort both IPv6 and IPv4 addresses. Added entries in the default policy table for IPv4- mapped addresses. + Changed default precedences, so v4-compatible addresses have lower precedence than 6to4 addresses. - -Draves Standards Track - Expires January 2002 19 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 - - + Changes from draft-draves-ipngwg-simple-srcaddr-01 + Added framework discussion. + Added algorithm for destination address ordering. + Added mechanism to allow the specification of administrative policy that can override the default behavior. + Added section on routing interactions and TBD section on mobility interactions. + Changed the candidate set definition for source address selection, so that only addresses assigned to the outgoing interface are allowed. + Changed the loopback address treatment to link-local scope. + + + + +Draves Standards Track - Expires April 2002 20 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 + + Changes from draft-draves-ipngwg-simple-srcaddr-00 + Minor wording changes because DHCPv6 also supports "preferred" and "deprecated" addresses. + Specified treatment of other format prefixes; now they are considered global scope, "preferred" addresses. + Reiterated that anycast and multicast addresses are not allowed as source addresses. + Recommended that source addresses be taken from the outgoing interface. Required this for multicast destinations. Added analogous requirements for link-local and site-local destinations. + Specified treatment of the loopback address. + Changed the second selection rule so that if both candidate source addresses have scope greater or equal than the destination address and only of them is preferred, the preferred address is chosen. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -Draves Standards Track - Expires January 2002 20 -draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 +Draves Standards Track - Expires April 2002 21 +draft-ietf-ipngwg-default-addr-select-06 September 28, 2001 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 @@ -927,13 +1235,41 @@ draft-ietf-ipngwg-default-addr-select-05 June 4, 2001 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. + + + + + + + + + + + + + + + + + + + + + + + + + + -Draves Standards Track - Expires January 2002 21 \ No newline at end of file +Draves Standards Track - Expires April 2002 22 \ No newline at end of file diff --git a/doc/draft/draft-ietf-ipngwg-prefix-rr-disc-00.txt b/doc/draft/draft-ietf-ipngwg-prefix-rr-disc-00.txt deleted file mode 100644 index f0cd106191..0000000000 --- a/doc/draft/draft-ietf-ipngwg-prefix-rr-disc-00.txt +++ /dev/null @@ -1,224 +0,0 @@ - -IPng Working Group Matt Crawford -Internet Draft Fermilab - November 17, 2000 - - Discovery of Resource Records Designating IPv6 Address prefixes - - - - -Status of this Memo - - 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 - 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 - - The A6 resource record type [A6] was introduced to store IPv6 - addresses in a manner which facilitates prefix changes and - assignment of addresses from multiple prefixes. In order to allow - use of dynamic DNS updates while still respecting whatever prefix - hierarchy may be in use in a site's "reverse" DNS zone, a method is - needed for discovering the name(s) of the A6 record(s) which specify - an address prefix. - - This memo specifies such a method of prefix name discovery. - - -1. Introduction - - The A6 resource record type [A6] was introduced to store IPv6 - addresses in a manner which facilitates prefix changes and - assignment of addresses from multiple prefixes. In order to allow - use of dynamic DNS updates while still respecting whatever prefix - hierarchy may be in use in a site's "reverse" DNS zone, a method is - needed for discovering the name(s) of the A6 record(s) which specify - an address prefix. - - - -Expires May 22, 2001 Crawford et al. [Page 1] - -Internet Draft IPv6 DNS November 17, 2000 - - - This memo specifies such a method. No new protocols or DNS record - types are involved -- only a convention for storing the required - information and a procedure for finding it. - - 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. Prefix Name Storage - - Recall from [A6] that address-to-name mapping information may be - stored in a subzone of IP6.ARPA, or in another zone reached by a - chain of one or more DNAME records. Nodenames are stored in PTR - records in such a zone. Extending that custom, we specify that - prefixes are to be named in PTR records in the same way. For a - prefix "P" of length "L" bits there should be a PTR whose RDATA - contains the owner name of an A6 record suitable for designating the - prefix P/L, and this PTR record is to be stored so that it will be - returned by a DNS query for the QNAME \[P/L].IP6.ARPA (possibly - after resolving intervening DNAMEs [DNAME]). - - Since the purpose of prefix name discovery is to facilitate dynamic - registration by hosts of their IPv6 addresses in DNS, only the names - of "longest" prefixes need to be discoverable. Accordingly, this - example will show just a prefix which is not subnetted further. - - Building on the example from [A6], section 5.2.3, the addition of - the required PTR record is shown below. - - $ORIGIN X.EXAMPLE. - N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6 - SUBNET-1.IP6 A6 48 0:0:0:1:: IP6 - PTR SUBNET-1.IP6 ; added record - IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET. - IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET. - $ORIGIN IP6 - \[x0001/16] DNAME SUBNET-1 - \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE. - - Notice that the owner and RDATA are the same. This is a consequence - of a somewhat arbitrary choice. The new record could equally well - have been - - \[x0001/16].IP6.X.EXAMPLE. PTR SUBNET-1.IP6.X.EXAMPLE. - - - It cannot be determined by inspecting an A6 DNS record whether that - - - -Expires May 22, 2001 Crawford et al. [Page 2] - -Internet Draft IPv6 DNS November 17, 2000 - - - record is meant to specify all the trailing bits of a 128-bit IPv6 - address or merely a prefix. Inclusion of the trailing bits does not - preclude its being pointed to as a prefix by some other A6 record. - Nevertheless, a human or automated zone maintainer will generally - know the intended purpose of each A6 record and which one should be - named in a PTR for prefix name discovery. - - -3. Prefix Name Discovery - - If a process wishing to do prefix name discovery has the prefix - itself available (as opposed to a full address of which an unknown - initial portion is the prefix), the prefix can be looked up - directly. Otherwise, two heuristics are available. - - First, it is possible that looking up a PTR record based on the full - IPv6 address, as would be done for ordinary address-to-name mapping, - will yield a PTR record containing a hostname. That hostname will - then be the owner of an A6 record. If its prefix length field is - non-zero, its prefix name field will contain the desired name. - - Otherwise, looking up a PTR record will fail, returning an - authoritative name error no no data of the requested type. There - will be a set of DNAME records in the answer section of the reply. - The last of these DNAMEs will indicate where to start looking for - the required PTR record. First its target should be tried, then its - owner. An especially persistent implementation can then prepend one - bit at a time from the portion of the IPv6 address not mapped by the - DNAME records to the target name, looking for a PTR record which was - not at a DNAME cut point of its own. An authoritative name error is - a stopping signal for this search. - - -4. Security Considerations - - No security concerns are raised by this specification beyond those - which apply to all uses of the DNS. - - -5. References - - - [A6] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 - Address Aggregation and Renumbering", RFC 2874, July 2000. - - [KWORD] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119. - - - - -Expires May 22, 2001 Crawford et al. [Page 3] - -Internet Draft IPv6 DNS November 17, 2000 - - - [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, - August 1999. - -6. Authors' Addresses - - Matt Crawford - Fermilab - MS 368 - PO Box 500 - Batavia, IL 60510 - USA - - +1 630 840-3461 - crawdad@fnal.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires May 22, 2001 Crawford et al. [Page 4] - diff --git a/doc/draft/draft-ietf-ipngwg-prefix-rr-disc-01.txt b/doc/draft/draft-ietf-ipngwg-prefix-rr-disc-01.txt new file mode 100644 index 0000000000..6f59071d82 --- /dev/null +++ b/doc/draft/draft-ietf-ipngwg-prefix-rr-disc-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +M. Crawford: crawdad+ietf@fnal.gov + + diff --git a/doc/draft/draft-ietf-ipngwg-rfc2292bis-02.txt b/doc/draft/draft-ietf-ipngwg-rfc2292bis-02.txt deleted file mode 100644 index b588cf15b0..0000000000 --- a/doc/draft/draft-ietf-ipngwg-rfc2292bis-02.txt +++ /dev/null @@ -1,4141 +0,0 @@ -INTERNET-DRAFT W. Richard Stevens (Consultant) -Expires: May 7, 2001 Matt Thomas (Consultant) -Obsoletes RFC 2292 Erik Nordmark (Sun) - November 7, 2000 - - - 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-02.txt [Page 1] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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 May 7, 2001. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 2] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - -Table of Contents - - 1. Introduction ..................................................... 6 - - 2. Common Structures and Definitions ................................ 7 - 2.1. The ip6_hdr Structure .......................................... 8 - 2.1.1. IPv6 Next Header Values ...................................... 8 - 2.1.2. IPv6 Extension Headers ....................................... 9 - 2.1.3. IPv6 Options ................................................. 10 - 2.2. The icmp6_hdr Structure ........................................ 13 - 2.2.1. ICMPv6 Type and Code Values .................................. 13 - 2.2.2. ICMPv6 Neighbor Discovery Definitions ........................ 14 - 2.2.3. Multicast Listener Discovery Definitions ..................... 17 - 2.2.4. ICMPv6 Router Renumbering Definitions ........................ 18 - 2.3. Address Testing Macros ......................................... 19 - 2.4. Protocols File ................................................. 20 - - 3. IPv6 Raw Sockets ................................................. 20 - 3.1. Checksums ...................................................... 22 - 3.2. ICMPv6 Type Filtering .......................................... 22 - 3.3. ICMPv6 Verification of Received Packets ........................ 25 - - 4. Access to IPv6 and Extension Headers ............................. 25 - 4.1. TCP Implications ............................................... 27 - 4.2. UDP and Raw Socket Implications ................................ 28 - - 5. Extensions to Socket Ancillary Data .............................. 28 - - 6. Packet Information ............................................... 29 - 6.1. Specifying/Receiving the Interface ............................. 30 - 6.2. Specifying/Receiving Source/Destination Address ................ 30 - 6.3. Specifying/Receiving the Hop Limit ............................. 31 - 6.4. Specifying the Next Hop Address ................................ 32 - 6.5. Additional Errors with sendmsg() and setsockopt() .............. 32 - - 7. Routing Header Option ............................................ 33 - 7.1. inet6_rth_space ................................................ 34 - 7.2. inet6_rth_init ................................................. 35 - 7.3. inet6_rth_add .................................................. 35 - 7.4. inet6_rth_reverse .............................................. 35 - 7.5. inet6_rth_segments ............................................. 36 - 7.6. inet6_rth_getaddr .............................................. 36 - - 8. Hop-By-Hop Options ............................................... 36 - 8.1. Receiving Hop-by-Hop Options ................................... 38 - 8.2. Sending Hop-by-Hop Options ..................................... 38 - - 9. Destination Options .............................................. 38 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 3] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 9.1. Receiving Destination Options .................................. 39 - 9.2. Sending Destination Options .................................... 39 - - 10. Hop-by-Hop and Destination Options Processing ................... 40 - 10.1. inet6_opt_init ................................................ 40 - 10.2. inet6_opt_append .............................................. 41 - 10.3. inet6_opt_finish .............................................. 41 - 10.4. inet6_opt_set_val ............................................. 42 - 10.5. inet6_opt_next ................................................ 42 - 10.6. inet6_opt_find ................................................ 42 - 10.7. inet6_opt_get_val ............................................. 43 - - 11. Additional Advanced API Functions ............................... 43 - 11.1. Sending with the Minimum MTU .................................. 43 - 11.2. Path MTU Discovery and UDP .................................... 44 - 11.3. Neighbor Reachability and UDP ................................. 44 - - 12. Ordering of Ancillary Data and IPv6 Extension Headers ........... 45 - - 13. IPv6-Specific Options with IPv4-Mapped IPv6 Addresses ........... 46 - - 14. Extended interfaces for rresvport, rcmd and rexec ............... 46 - 14.1. rresvport_af .................................................. 46 - 14.2. rcmd_af ....................................................... 47 - 14.3. rexec_af ...................................................... 47 - - 15. Summary of New Definitions ...................................... 47 - - 16. Security Considerations ......................................... 52 - - 17. Change History .................................................. 52 - - 18. TODO and Open Issues ............................................ 54 - - 19. References ...................................................... 56 - - 20. Acknowledgments ................................................. 56 - - 21. Authors' Addresses .............................................. 57 - - 22. Appendix A: Ancillary Data Overview ............................. 57 - 22.1. The msghdr Structure .......................................... 58 - 22.2. The cmsghdr Structure ......................................... 59 - 22.3. Ancillary Data Object Macros .................................. 60 - 22.3.1. CMSG_FIRSTHDR ............................................... 61 - 22.3.2. CMSG_NXTHDR ................................................. 62 - 22.3.3. CMSG_DATA ................................................... 63 - 22.3.4. CMSG_SPACE .................................................. 63 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 4] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 22.3.5. CMSG_LEN .................................................... 64 - - 23. Appendix B: Examples using the inet6_rth_XXX() functions ........ 64 - 23.1. Sending a Routing Header ...................................... 64 - 23.2. Receiving Routing Headers ..................................... 69 - - 24. Appendix C: Examples using the inet6_opt_XXX() functions ........ 71 - 24.1. Building options .............................................. 71 - 24.2. Parsing received options ...................................... 73 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 5] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - -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 header files. 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-02.txt [Page 6] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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 protocol headers are required, along with - common constant definitions for the structure members. - - 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(). - - Two new header files are defined: and - . - - When an include file is specified, that include file is allowed to - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 7] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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. - - struct ip6_hdr { - union { - struct ip6_hdrctl { - uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC, 20 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. - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 8] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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 - 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 - . - - /* - * Generic extension header structure used by many extension headers. - * Note that not all headers have this format. E.g. the fragmentation - * header is different. - */ - struct ip6_ext { - uint8_t ip6e_nxt; /* next header */ - uint8_t ip6e_len; /* length in units of 8 octets */ - }; - - /* 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 */ - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 9] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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 */ - /* followed by up to 127 struct in6_addr */ - }; - - /* 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 */ - #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 - - - -2.1.3. IPv6 Options - - Eleven options are defined for IPv6 at the time of writing this - document. We define structures for all except the unspecified EID - option. The following structures are defined as a result of - including . - - /* IPv6 options */ - struct ip6_opt { - uint8_t ip6o_type; - uint8_t ip6o_len; - }; - - /* - * The high-order 3 bits of the option type define the behavior - * when processing an unknown option and whether or not the option - * content changes in flight. - */ - #define IP6OPT_TYPE(o) ((o) & 0xc0) - #define IP6OPT_TYPE_SKIP 0x00 - #define IP6OPT_TYPE_DISCARD 0x40 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 10] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - #define IP6OPT_TYPE_FORCEICMP 0x80 - #define IP6OPT_TYPE_ICMP 0xc0 - #define IP6OPT_MUTABLE 0x20 - - #define IP6OPT_PAD1 0x00 /* 00 0 00000 */ - #define IP6OPT_PADN 0x01 /* 00 0 00001 */ - #define IP6OPT_JUMBO 0xc2 /* 11 0 00010 = 194 */ - #define IP6OPT_NSAP_ADDR 0xc3 /* 11 0 00011 */ - #define IP6OPT_TUNNEL_LIMIT 0x04 /* 00 0 00100 */ - #define IP6OPT_ROUTER_ALERT 0x05 /* 00 0 00101 */ - #define IP6OPT_BINDING_UPDATE 0xc6 /* 11 0 00110 */ - #define IP6OPT_BINDING_ACK 0x07 /* 00 0 00111 */ - #define IP6OPT_BINDING_REQ 0x08 /* 00 0 01000 */ - #define IP6OPT_HOME_ADDRESS 0xc9 /* 11 0 01001 */ - #define IP6OPT_EID 0x8a /* 10 0 01010 */ - - /* Jumbo Payload Option */ - struct ip6_opt_jumbo { - uint8_t ip6oj_type; - uint8_t ip6oj_len; - uint8_t ip6oj_jumbo_len[4]; - }; - #define IP6OPT_JUMBO_LEN 6 - - /* NSAP Address Option */ - struct ip6_opt_nsap { - uint8_t ip6on_type; - uint8_t ip6on_len; - uint8_t ip6on_src_nsap_len; - uint8_t ip6on_dst_nsap_len; - /* followed by source NSAP */ - /* followed by destination NSAP */ - }; - - /* Tunnel Limit Option */ - struct ip6_opt_tunnel { - uint8_t ip6ot_type; - uint8_t ip6ot_len; - uint8_t ip6ot_encap_limit; - }; - - /* Router Alert Option */ - struct ip6_opt_router { - uint8_t ip6or_type; - uint8_t ip6or_len; - uint8_t ip6or_value[2]; - }; - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 11] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - /* Router alert values (in network byte order) */ - #ifdef _BIG_ENDIAN - #define IP6_ALERT_MLD 0x0000 - #define IP6_ALERT_RSVP 0x0001 - #define IP6_ALERT_AN 0x0002 - #else - #define IP6_ALERT_MLD 0x0000 - #define IP6_ALERT_RSVP 0x0100 - #define IP6_ALERT_AN 0x0200 - #endif - - /* Binding Update Option */ - struct ip6_opt_binding_update { - uint8_t ip6ou_type; - uint8_t ip6ou_len; - uint8_t ip6ou_flags; - uint8_t ip6ou_prefixlen; - uint8_t ip6ou_seqno[2]; - uint8_t ip6ou_lifetime[4]; - uint8_t ip6ou_coa[16]; /* Optional based on flags */ - /* followed by sub-options */ - }; - - /* Binding Update Flags */ - #define IP6_BUF_ACK 0x80 /* Request a binding ack */ - #define IP6_BUF_HOME 0x40 /* Home Registration */ - #define IP6_BUF_COA 0x20 /* Care-of-address present in option */ - #define IP6_BUF_ROUTER 0x10 /* Sending mobile node is a router */ - - /* Binding Ack Option */ - struct ip6_opt_binding_ack { - uint8_t ip6oa_type; - uint8_t ip6oa_len; - uint8_t ip6oa_status; - uint8_t ip6oa_seqno[2]; - uint8_t ip6oa_lifetime[4]; - uint8_t ip6oa_refresh[4]; - /* followed by sub-options */ - }; - - /* Binding Request Option */ - struct ip6_opt_binding_request { - uint8_t ip6or_type; - uint8_t ip6or_len; - /* followed by sub-options */ - }; - - /* Home Address Option */ - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 12] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - struct ip6_opt_home_address { - uint8_t ip6oh_type; - uint8_t ip6oh_len; - uint8_t ip6oh_addr[16]; /* Home Address */ - /* followed by sub-options */ - }; - - - -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. - - 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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 13] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - #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_DST_UNREACH_NOROUTE 0 /* no route to destination */ - #define ICMP6_DST_UNREACH_ADMIN 1 /* communication with */ - /* destination */ - /* admin. prohibited */ - #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source address */ - #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 Definitions - - 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 */ - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 14] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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 - #define ND_RA_FLAG_OTHER 0x40 - #define ND_RA_FLAG_HOME_AGENT 0x20 - #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 */ - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 15] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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; - 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 - #define ND_OPT_ADVINTERVAL 7 - #define ND_OPT_HOMEAGENT_INFO 8 - - 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; - /* XXX uint8_t nd_opt_pi_reserved2[3]; */ - /* XXX uint8_t nd_opt_pi_sitelen; */ - struct in6_addr nd_opt_pi_prefix; - }; - - #define ND_OPT_PI_FLAG_ONLINK 0x80 - #define ND_OPT_PI_FLAG_AUTO 0x40 - #define ND_OPT_PI_FLAG_ROUTER 0x20 /* Added my Mobile IPv6 */ - #define ND_OPT_PI_FLAG_SITEPREF 0x10 /* XXX sitelen is valid */ - - 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; - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 16] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - /* 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; - }; - - struct nd_opt_advinterval { /* Advertisement Interval */ - uint8_t nd_opt_adv_type; - uint8_t nd_opt_adv_len; - uint16_t nd_opt_adv_reserved; - uint32_t nd_opt_adv_interval; /* In milliseconds */ - }; - - struct nd_opt_homeagent_info { /* Home Agent info */ - uint8_t nd_opt_hai_type; - uint8_t nd_opt_hai_len; - uint16_t nd_opt_hai_reserved; - int16_t nd_opt_hai_preference; - uint16_t nd_opt_hai_lifetime; - }; - - We note that the nd_na_flags_reserved flags have the same byte - ordering problems as we discussed with ip6f_offlg. - - -2.2.3. Multicast Listener Discovery Definitions - - The following structures and definitions are defined as a result of - including . - - #define MLD_LISTENER_QUERY 130 - #define MLD_LISTENER_REPORT 131 - #define MLD_LISTENER_REDUCTION 132 - - struct mld_hdr { - struct icmp6_hdr mld_hdr; - struct in6_addr mld_addr; /* multicast address */ - }; - #define mld_type mld_hdr.icmp6_type - #define mld_code mld_hdr.icmp6_code - #define mld_cksum mld_hdr.icmp6_cksum - #define mld_maxdelay mld_hdr.icmp6_data16[0] - #define mld_reserved mld_hdr.icmp6_data16[1] - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 17] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - -2.2.4. ICMPv6 Router Renumbering Definitions - - The following structures and definitions are defined as a result of - including . - - #define ICMP6_ROUTER_RENUMBERING 138 /* router renumbering */ - - struct icmp6_router_renum { /* router renumbering header */ - struct icmp6_hdr rr_hdr; - u_int8_t rr_segnum; - u_int8_t rr_flags; - u_int16_t rr_maxdelay; - u_int32_t rr_reserved; - }; - #define rr_type rr_hdr.icmp6_type - #define rr_code rr_hdr.icmp6_code - #define rr_cksum rr_hdr.icmp6_cksum - #define rr_seqnum rr_hdr.icmp6_data32[0] - - /* Router renumbering flags */ - #define ICMP6_RR_FLAGS_TEST 0x80 - #define ICMP6_RR_FLAGS_REQRESULT 0x40 - #define ICMP6_RR_FLAGS_FORCEAPPLY 0x20 - #define ICMP6_RR_FLAGS_SPECSITE 0x10 - #define ICMP6_RR_FLAGS_PREVDONE 0x08 - - - struct rr_pco_match { /* match prefix part */ - u_int8_t rpm_code; - u_int8_t rpm_len; - u_int8_t rpm_ordinal; - u_int8_t rpm_matchlen; - u_int8_t rpm_minlen; - u_int8_t rpm_maxlen; - u_int16_t rpm_reserved; - struct in6_addr rpm_prefix; - }; - - /* PCO code values */ - #define RPM_PCO_ADD 1 - #define RPM_PCO_CHANGE 2 - #define RPM_PCO_SETGLOBAL 3 - - struct rr_pco_use { /* use prefix part */ - u_int8_t rpu_uselen; - u_int8_t rpu_keeplen; - u_int8_t rpu_ramask; - u_int8_t rpu_raflags; - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 18] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - u_int32_t rpu_vltime; - u_int32_t rpu_pltime; - u_int32_t rpu_flags; - struct in6_addr rpu_prefix; - }; - #define ICMP6_RR_PCOUSE_RAFLAGS_ONLINK 0x20 - #define ICMP6_RR_PCOUSE_RAFLAGS_AUTO 0x10 - - #if BYTE_ORDER == BIG_ENDIAN - #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80000000 - #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40000000 - #elif BYTE_ORDER == LITTLE_ENDIAN - #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80 - #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40 - #endif - - struct rr_result { /* router renumbering result message */ - u_int16_t rrr_flags; - u_int8_t rrr_ordinal; - u_int8_t rrr_matchedlen; - u_int32_t rrr_ifid; - struct in6_addr rrr_prefix; - }; - - #if BYTE_ORDER == BIG_ENDIAN - #define ICMP6_RR_RESULT_FLAGS_OOB 0x0002 - #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0001 - #elif BYTE_ORDER == LITTLE_ENDIAN - #define ICMP6_RR_RESULT_FLAGS_OOB 0x0200 - #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0100 - #endif - - - -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 - including . - - int IN6_ARE_ADDR_EQUAL(const struct in6_addr *, - const struct in6_addr *); - - This macro returns non-zero if the addresses are equal; otherwise it - - - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 19] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - returns zero. - - -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 - 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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 20] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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 in Section 6. 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, to have it mean that the application will send down - complete packets including the IPv4 header. (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 - IP_HDRINCL socket option was added.) We note that IPPROTO_RAW has no - special meaning to an IPv6 raw socket (and the IANA currently - - - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 21] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - reserves the value of 255 when used as a next-header field). - - -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. - - An attempt to set IPV6_CHECKSUM for an ICMPv6 socket will fail. - - (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. - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 22] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - Most applications using an ICMPv6 raw socket care about only a small - subset of the ICMPv6 message types. To transfer extraneous ICMPv6 - 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 - . - - 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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 23] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - filter pointed to by the second argument. - - 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)) - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 24] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - (Note: These sample definitions have two limitations that an - 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.) - - -3.3. ICMPv6 Verification of Received Packets - - The protocol stack will verify the ICMPv6 checksum and discard any - packets with invalid checksums. - - An implementation might perform additional validity checks on the - ICMP message content and discard malformed packets. However, a - portable application must not assume that such validity checks have - been performed. - - The protocol stack should not automatically discard packets if the - ICMP type is unknown to the stack. For extensibility reasons received - ICMP packets with any type (informational or error) must be passed to - the applications (subject to ICMP6_FILTER filtering on the type value - and the checksum verification). - - -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: - - - - - - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 25] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - 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 affect 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 - 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 ip6_rthdr structure - IPPROTO_IPV6 IPV6_HOPOPTS ip6_hbh structure - IPPROTO_IPV6 IPV6_DSTOPTS ip6_dest structure - IPPROTO_IPV6 IPV6_RTHDRDSTOPTS ip6_dest structure - - - All these options are described in detail in Section 6, 7, 8 and 9. - All the constants beginning with IPV6_ are defined as a result of - including the . - - Issuing getsockopt() for the above options will return the sticky - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 26] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - option value i.e. the value set with setsockopt(). If no sticky - option value has been set getsockopt() will return the default value. - - 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"). - - The application does not explicitly need to access the data - structures 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 in - Section 8 and Section 10. Those functions simplify the interface to - these features instead of requiring the application to know the - intimate details of the extension header formats. - - -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 - 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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 27] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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. However, if the - information is not present in the packet the ancillary data item will - not be included. For example, if the application enables - IPV6_RECVRTHDR and a received datagram does not contain a Routing - header there will not be an IPV6_RTHDR ancillary data item. 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. Extensions to Socket Ancillary Data - - This specification uses ancillary data as defined in Posix.1g which - the following compatible extensions: - - - CMSG_NXTHDR has been extended to handle a NULL 2nd argument to - mean "get the first header". See Section 22.3.2. - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 28] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - A new CMSG_SPACE macro is defined. It is used to determine how - much space need to be allocated for an ancillary data item. See - Section 22.3.4. - - - A new CMSG_LEN macro is defined. It returns the value to store - in the cmsg_len member of the cmsghdr structure, taking into - account any padding needed to satisfy alignment requirements. - See Section 22.3.5. - - -6. 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 . - - struct in6_pktinfo { - struct in6_addr ipi6_addr; /* src/dst IPv6 address */ - unsigned int ipi6_ifindex; /* send/recv interface index */ - }; - - 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: - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 29] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - 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.) - - -6.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_RECVPKTINFO socket option is enabled, the received - interface index is always returned as the ipi6_ifindex member of the - in6_pktinfo structure. - - -6.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. - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 30] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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. - - -6.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)); - - 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 - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 31] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - x < -1: return an error of EINVAL - x == -1: use kernel default - 0 <= x <= 255: use x - x >= 256: return an error of EINVAL - - - In order to clear a sticky IPV6_HOPLIMIT option the application can - specify -1 as the value. Alternatively, the application can specify - an IPV6_HOPLIMIT socket option with a zero length. - - -6.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. - - In order to clear a sticky IPV6_NEXTHOP option the application must - issue a setsockopt for IPv6_NEXTHOP with a zero length. - - - -6.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-02.txt [Page 32] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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. - - -7. 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 six - 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 - using the IPV6_RTHDR option. - - 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 defined as a result - of including the . - - To receive a Routing header the application must enable the - IPV6_RECVRTHDR socket option: - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 33] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - 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 as a result of including the - : - - #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. - - -7.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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 34] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - required for the ancillary data. This allows an application to - 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.) - - -7.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 and sets ip6r_len based on the - segments parameter. bp_len is only used to verify that the buffer is - large enough. The ip6r_segleft field is set to zero; inet6_rth_add() - will increment it. - - 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 inet6_rth_add() - function. Upon an error the return value is NULL. - - -7.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. - - -7.4. inet6_rth_reverse - - - int inet6_rth_reverse(const void *in, void *out); - - This function takes a Routing header extension header (pointed to by - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 35] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - the first argument) and writes a new Routing header that sends - datagrams along the reverse of that route. The function reverses the - order of the addresses and sets the segleft member in the new Routing - header to the number of segments. 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 - error. - - -7.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. - - -7.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. - - -8. 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 four Hop-by-Hop options are defined for IPv6 [RFC-2460]: - Jumbo Payload, Pad1, PadN, and router-alert. The two pad options are - for alignment purposes and are automatically inserted by the - inet6_opt_XXX() routines and ignored by the inet6_opt_XXX() routines - on the receive side. - - This section of the API is therefore defined for future Hop-by-Hop - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 36] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - options (as well as destination options) that an application may need - to specify and receive. This IPv6 API defines seven functions that - the application calls to build and examine a Hop-by_Hop options - header, and the ability to use sticky options or ancillary data to - communicate this information between the application and the kernel. - This uses the IPV6_HOPOPTS for hob-by-hop options. - - Four functions build a options header: - - inet6_opt_init() - initialize buffer data for options header - inet6_opt_append() - add one TLV option to the options header - inet6_opt_finish() - finish adding TLV options to the options header - inet6_opt_set_val() - add one component of the option content to the option - - Three functions deal with a returned options header: - - inet6_opt_next() - extract the next option from the options header - inet6_opt_find() - extract an option of a specified type from the header - inet6_opt_get_val() - retrieve one component of the option content - - - Individual Hop-by-Hop options (and Destination options, which are - described in Section 9 and 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 - - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 37] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - certain options in received packets. - - -8.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 in - Section 10.6. - - -8.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 - 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 in - Section 10. - - Additional errors may be possible from sendmsg() and setsockopt() if - the specified option is in error. - - -9. 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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 38] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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. - - -9.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 - 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. - - -9.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 in Section 6 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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 39] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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 - ignored 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 in Section 10. - - Additional errors may be possible from sendmsg() and setsockopt() if - the specified option is in error. - - -10. Hop-by-Hop and Destination Options Processing - - 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. These functions assume the - formatting rules specified in Appendix B in [RFC-2460] i.e. that the - largest field is placed last in the option. - - The function prototypes for these functions are defined as a result - of including the . - - 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. - - -10.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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 40] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - also initializes the extension header to have the correct length - field. In that case if the extlen value is not a positive (i.e., - non-zero) multiple of 8 the function fails and returns -1. - - -10.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. - - 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 align - value can not exceed the value of len. - - -10.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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 41] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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. - - -10.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. - - -10.5. inet6_opt_next - - - int inet6_opt_next(void *extbuf, size_t extlen, int prevlen, - uint8_t *typep, size_t *lenp, - void **databufp); - - This function parses received option 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 by a previous call to 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 - computed by advancing past the option that was returned. This - returned "previous" length can then be passed to subsequent calls to - inet6_opt_next(). This function does not return any PAD1 or PADN - options. When there are no more options or if the option extension - header is malformed the return value is -1. - - -10.6. inet6_opt_find - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 42] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - 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 computed by advancing past the - option that was returned and past any options that didn't match the - type. This returned "previous" length can then be passed to - subsequent calls to inet6_opt_find() for finding the next occurrence - of the same option type. - - If an option of the specified type is not located, the return value - is -1. If the option extension header is malformed, the return value - is -1. - - -10.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. - - The function returns the offset for the next field (i.e., offset + - vallen) which can be used when extracting option content with - multiple fields. - - -11. Additional Advanced API Functions - - - -11.1. Sending with the Minimum MTU - - Some applications might not want to incur the overhead of path MTU - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 43] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - discovery, especially if the applications only send a single datagram - to a destination. A potential example is a DNS server. - - This specification defines a mechanism to avoid path MTU discovery by - sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger - than the minimum MTU and this feature has been enabled the IP layer - will fragment to the minimum MTU. This can be enabled using the - IPV6_USE_MIN_MTU socket option. - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on)); - - By default, this socket option is disabled. Setting the value to 0 - also disables the option. This option can also be sent as ancillary - data. - - - -11.2. Path MTU Discovery and UDP - - UDP and raw socket applications need to be able to determine the - "maximum send transport-message size" (Section 5.1 of [RFC-1981]) to - a given destination so that those applications can participate in - path MTU discovery. This lets those applications send smaller - datagrams to the destination, avoiding fragmentation. - - This is accomplished using a new ancillary data item (IPV6_PATHMTU) - which is delivered to recvmsg() without any actual data. The - application enable the receipt of IPV6_PATHMTU ancillary data items - by enabing IPV6_RECVPATHMTU. - - int on = 1; - setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPATHMTU, &on, sizeof(on)); - - By default, this socket option is disabled. Setting the value to 0 - also disables the option. - - When the application is sending packets too big for the path MTU - recvmsg will return zero (indicating no data) but there will be a - cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will - indicate that cmsg_data is 4 bytes long. CMSG_DATA will point to an - integer carrying the path MTU to use. - - -11.3. Neighbor Reachability and UDP - - UDP and raw socket application might know that communication is - making forward progress i.e. that the path from the node to the next - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 44] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - hop is working. In such a case the applications, similarly to TCP as - specified in [RFC-2461], has the option indicate to the internet - layer that the neighbor is reachable. See section 7.3.1 of [RFC- - 2461]. This could save unneeded neighbor solicitation and neighbor - advertisement messages. - - This is done by including an ancilary data item with cmsg_type being - IPV6_REACHCONF and with no attached CMSG_DATA. - - If implementations honor the IPV6_REACHCONF from any application - there is a possibility that, when there is an unreachability - situation, one application can cause a denial of service attack on - anogther application running on the same node by periodically issuing - sendmsg() with an IPV6_REACHCONF ancillary data item to prevent the - Neighbor Unreachability Detection algoritm to send probe messages and - declare the neighbor unreachable. It is unclear whether - implementations need to mitigate this very minor threat by e.g. - restricting IPV6_REACHCONF to priviledged applications. - - -12. 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 hop-by-hop ancillary data objects 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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 45] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - Routing header, the kernel will place those Destination options after - an authentication header and/or an encapsulating security payload - header, if present. - - -13. 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 - 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. - - -14. Extended interfaces for rresvport, rcmd and rexec - - TBD - - -14.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 AF_INET TCP socket, it can also create an - AF_INET6 TCP socket. The family argument is either AF_INET or - AF_INET6, and a new error return is EAFNOSUPPORT if the address - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 46] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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.) - - -14.2. rcmd_af - - The existing rcmd() function can not transparently use AF_INET6 - sockets since the an application would not be prepared to handle - AF_INET6 addresses returned by e.g. getpeername on the file - descriptor created by rcmd. Thus a new function is needed. - - int rcmd_af(char **ahost, unsigned short rport, const char *locuser, - const char *remuser, const char *cmd, int *fd2p, int af) - - This function behaves the same as the existing rcmd() function, but - instead of creating an AF_INET TCP socket, it can also create an - AF_INET6 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. - - -14.3. rexec_af - - The existing rexec() function can not transparently use AF_INET6 - sockets since the an application would not be prepared to handle - AF_INET6 addresses returned by e.g. getpeername on the file - descriptor created by rexec. Thus a new function is needed. - - int rexec_af(char **ahost, unsigned short rport, const char *name, - const char *pass, const char *cmd, int *fd2p, int af) - - This function behaves the same as the existing rexec() function, but - instead of creating an AF_INET TCP socket, it can also create an - AF_INET6 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. - - -15. Summary of New Definitions - - The following list summarizes the constants and structure, - definitions discussed in this memo, sorted by header. - - ICMP6_DST_UNREACH - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 47] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - ICMP6_DST_UNREACH_ADDR - ICMP6_DST_UNREACH_ADMIN - ICMP6_DST_UNREACH_BEYONDSCOPE - ICMP6_DST_UNREACH_NOPORT - ICMP6_DST_UNREACH_NOROUTE - ICMP6_ECHO_REPLY - ICMP6_ECHO_REQUEST - ICMP6_INFOMSG_MASK - ICMP6_PACKET_TOO_BIG - ICMP6_PARAMPROB_HEADER - ICMP6_PARAMPROB_NEXTHEADER - ICMP6_PARAMPROB_OPTION - ICMP6_PARAM_PROB - ICMP6_ROUTER_RENUMBERING - ICMP6_RR_FLAGS_FORCEAPPLY - ICMP6_RR_FLAGS_PREVDONE - ICMP6_RR_FLAGS_REQRESULT - ICMP6_RR_FLAGS_SPECSITE - ICMP6_RR_FLAGS_TEST - ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME - ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME - ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME - ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME - ICMP6_RR_PCOUSE_RAFLAGS_AUTO - ICMP6_RR_PCOUSE_RAFLAGS_ONLINK - ICMP6_RR_RESULT_FLAGS_FORBIDDEN - ICMP6_RR_RESULT_FLAGS_FORBIDDEN - ICMP6_RR_RESULT_FLAGS_OOB - ICMP6_RR_RESULT_FLAGS_OOB - ICMP6_TIME_EXCEEDED - ICMP6_TIME_EXCEED_REASSEMBLY - ICMP6_TIME_EXCEED_TRANSIT - MLD_LISTENER_QUERY - MLD_LISTENER_REDUCTION - MLD_LISTENER_REPORT - 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_PI_FLAG_ROUTER - ND_OPT_PI_FLAG_SITEPREF - ND_OPT_PREFIX_INFORMATION - ND_OPT_REDIRECTED_HEADER - ND_OPT_SOURCE_LINKADDR - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 48] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - ND_OPT_TARGET_LINKADDR - ND_RA_FLAG_HOME_AGENT - ND_RA_FLAG_MANAGED - ND_RA_FLAG_OTHER - ND_REDIRECT - ND_ROUTER_ADVERT - ND_ROUTER_SOLICIT - - struct icmp6_filter{}; - struct icmp6_hdr{}; - struct icmp6_router_renum{}; - struct mld_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{}; - struct rr_pco_match{}; - struct rr_pco_use{}; - struct rr_result{}; - - IPPROTO_AH - IPPROTO_DSTOPTS - IPPROTO_ESP - IPPROTO_FRAGMENT - IPPROTO_HOPOPTS - IPPROTO_ICMPV6 - IPPROTO_IPV6 - IPPROTO_NONE - IPPROTO_ROUTING - IPV6_CHECKSUM - IPV6_DSTOPTS - IPV6_HOPLIMIT - IPV6_HOPOPTS - IPV6_NEXTHOP - IPV6_PATHMTU - IPV6_PKTINFO - IPV6_RECVDSTOPTS - IPV6_RECVHOPLIMIT - IPV6_RECVHOPOPTS - IPV6_RECVPKTINFO - IPV6_RECVRTHDR - IPV6_RECVRTHDRDSTOPTS - IPV6_RTHDR - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 49] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - IPV6_RTHDRDSTOPTS - IPV6_RTHDR_TYPE_0 - IPV6_RECVPATHMTU - IPV6_REACHCONF - IPV6_USE_MIN_MTU - struct in6_pktinfo{}; - - IP6F_MORE_FRAG - IP6F_OFF_MASK - IP6F_RESERVED_MASK - IP6OPT_BINDING_ACK - IP6OPT_BINDING_REQ - IP6OPT_BINDING_UPDATE - IP6OPT_EID - IP6OPT_HOME_ADDRESS - IP6OPT_JUMBO - IP6OPT_JUMBO_LEN - IP6OPT_MUTABLE - IP6OPT_NSAP_ADDR - IP6OPT_PAD1 - IP6OPT_PADN - IP6OPT_ROUTER_ALERT - IP6OPT_TUNNEL_LIMIT - IP6OPT_TYPE_DISCARD - IP6OPT_TYPE_FORCEICMP - IP6OPT_TYPE_ICMP - IP6OPT_TYPE_SKIP - IP6_ALERT_AN - IP6_ALERT_AN - IP6_ALERT_MLD - IP6_ALERT_MLD - IP6_ALERT_RSVP - IP6_ALERT_RSVP - IP6_BUF_ACK - IP6_BUF_COA - IP6_BUF_HOME - IP6_BUF_ROUTER - struct ip6_dest{}; - struct ip6_ext{}; - struct ip6_frag{}; - struct ip6_hbh{}; - struct ip6_hdr{}; - struct ip6_opt{}; - struct ip6_opt_binding_ack{}; - struct ip6_opt_binding_request{}; - struct ip6_opt_binding_update{}; - struct ip6_opt_home_address{}; - struct ip6_opt_jumbo{}; - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 50] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - struct ip6_opt_nsap{}; - struct ip6_opt_router{}; - struct ip6_opt_tunnel{}; - struct ip6_rthdr{}; - struct ip6_rthdr0{}; - - - 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, - 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_t, 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); - - int IP6OPT_TYPE(uint8_t); - - unsigned int CMSG_LEN(unsigned int); - unsigned int CMSG_SPACE(unsigned int); - - int rresvport_af(int *, int); - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 51] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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); - - - -16. 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 - must be prevented; at least for non-privileged processes. - - -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-02.txt [Page 52] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - 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(). - - Changes since -00: - - - Changed ICMP unreachable code 2 name to be "beyond scope of - source address". - - - Added motivation for rcmd_af() and rexec_af(). - - - Added option definitions (IP6OPT_PAD1 etc) to ip6.h. - - - Added MLD and router renumbering definitions to icmp6.h - - - Removed ip6r0_addr field - replaced by a comment. - - - Made the content of IPV6_RTHDR, IPV6_HOPOPTS etc be specified as - the extension header format (struct ip6_rthdr etc) instead of the - previous "implementation dependent". - - - Removed attempt at RFC 2292 compatibility. - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 53] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - Excluded pad options from inet6_opt_next(). - - - Added IPV6_USE_MIN_MTU socket option for applications to avoid - fragmentation by sending at the minimum IPv6 MTU. - - - Added MTU notification so that UDP and raw socket applications - can participate in path MTU discovery. - - - Added Reachability confirmation for UDP and raw socket - applications. - - - Clarified that if the application asks for e.g., IPV6_RTHDR and a - received datagram does not contain a Routing header an - implementation will exclude the IPV6_RTHDR ancillary data item. - - - Removed the constraints for jumbo option. - - - Moved the new CMSG macros and changes from the appendix. - - - Add text about inet6_opt_ depending on 2260 appendix B formatting - rules i.e. largest field last in the option. - - - Specified that getsockopt() of a sticky option returns what was - set with setsockopt(). - - - Updated the summary of new definitions to make it current. - - Changes since -01: - - - Added a note about the minor threat for DoS attacks using - IPV6_REACHCONF - - - Clarified checksum and other receive side verification for RAW - ICMP sockets. - - - Editorial clarifications. - - - -18. TODO and Open Issues - - Items left to do: - - - Add macros for ip6_hdr to access the traffic class and flow label - fields. - - - Should we remove the 1, 2, 4, 8 byte restriction for - inet6_opt_set_val and inet6_opt_get_val? Option values can be - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 54] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - any size even though there alignment must be a power of two. - Issue of how natural alignment is defined for sizes that are not - a power of two. - - - Perhaps we should add a note to point out that robust receivers - should verify alignment before calling inet6_opt_get_val(). Or - require that inet6_opt_get_val() should check the alignment and - fail by returning -1? - - - Should we change IPV6_USE_MIN_MTU to IPV6_USEMTU taking a - uint32_t Should we add IPV6_DONTFRAG option for traceroute?? - - - Add credits for UDP MTU stuff - - - Move information about mapping from inet6_opt to setsockopt and - cmsg. - - - Clarify IPV6_RTHDRDSTOPTS's interaction with IPV6_RTHDR. - - - Make the new inet6_opt_set_val() and inet6_opt_get_val() check - the length of the data item. - - - Add sending and receiving sections for routing header text just - like destination options? - - - Include sample implementation of inet6_opt_XXX. - - - Fix Authors address wrt Rich. - - Open issues: - - - Add ICMP name lookups definitions? - - - Add site-prefixes definitions? - - - Add flow label allocation API as requested in draft-berson-rsvp- - ipv6-fl-00.txt? Draft has expired! - - - Anything special for mobility options? Restrict setting at API? - Filter out on receipt? If received what does the home address - option contain? - - - Specify "change" for TCP especially when there are multiple HBH - option headers etc. - - - Specify binding to scope-id => implies filtering of addresses - with that scope if the address you are bound to is link-local - etc. What about conflicts with bound scope-id and sendto/connect - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 55] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - scope-id? - - - Specify order for ifindex selection. Put in separate section. - Different cases for sending to link-local (scope_id including - nexthop scope_id) and global. Is multicast different? - - - bind() and sin6_scope_id. Should have been in Basic API. Error - checks when bind/sendto sin6_scope_id does not match? - - - Specify notion of default multicast interface? In Basic API? - - - What about site names and site ids? Need for interfaces to map? - Requires that site-prefixes pass name - does name need to use DNS - format to handle character sets? - - - If the home address option passed out in IPV6_RECVDSTOPTS? If so - what address value does it contain? - - -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 - 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, Jim Bound, - Don Coolidge, Matt Crawford, Sam T. Denton, Richard Draves, Francis - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 56] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - Dupont, Bob Gilligan, Jun-ichiro Hagino, Gerri Harter, Tim Hartrick, - Bob Halley, Masaki Hirabaru, Yoshinobu Inoue, Mukesh Kacker, A. N. - Kuznetsov, Sam Manthorpe, Pedro Marques, Jack McCann, der Mouse, John - Moy, Thomas Narten, Steve Parker, Charles Perkins, Ken Powell, Tom - Pusateri, Pedro Roque, Sameer Shah, Peter Sjodin, Stephen P. - Spackman, Jinmei Tatuya, Karen Tracey, Sowmini Varadhan, Quaizar - Vohra, Carl Williams, Steve Wise, Eric Wong, Farrell Woods, Kazu - Yamamoto, and Vlad Yasevich. - - -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 Overview - - 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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 57] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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 - 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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 58] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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 in Section 22.3. 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-02.txt [Page 59] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - |<--------------------------- 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-02.txt [Page 60] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - 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_len == 0) { - /* Error handling */ - break; - } - 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 by the 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 - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 61] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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 - 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_len == 0) { - /* Error handling */ - break; - } - if (cmsgptr->cmsg_level == ... && cmsgptr->cmsg_type == ... ) { - u_char *ptr; - - ptr = CMSG_DATA(cmsgptr); - /* process data pointed to by ptr */ - } - } - - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 62] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - One possible implementation could be: - - #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, when allocating 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. - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 63] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - One possible implementation could be: - - #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. - - - - - - - - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 64] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - 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 - - 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_SPACE(extlen); - cmsgptr = malloc(cmsglen); - cmsgptr->cmsg_len = CMSG_LEN(extlen); - cmsgptr->cmsg_level = IPPROTO_IPV6; - cmsgptr->cmsg_type = IPV6_RTHDR; - - extptr = CMSG_DATA(cmsgptr); - extptr = inet6_rth_init(extptr, extlen, IPV6_RTHDR_TYPE_0, 3); - - inet6_rth_add(extptr, &I1.sin6_addr); - inet6_rth_add(extptr, &I2.sin6_addr); - inet6_rth_add(extptr, &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). - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 65] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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 - 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 | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 66] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - The first call to inet6_rth_add() adds I1 to the list. - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 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-02.txt [Page 67] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 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-02.txt [Page 68] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | 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-02.txt [Page 69] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - struct msghdr msg; - struct iovec iov; - struct cmsghdr *cmsgptr; - size_t cmsgspace; - void *extptr; - int extlen; - - int segments; - int i; - char databuf[8192]; - - segments = 100; /* Enough */ - extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, segments); - cmsgspace = CMSG_SPACE(extlen); - cmsgptr = malloc(cmsgspace); - if (cmsgptr == NULL) { - perror("malloc"); - exit(1); - } - extptr = 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_rthdr *rthdr; - - rthdr = (struct ip6_rthdr *)extptr; - segments = inet6_rth_segments(extptr); - printf("route (%d segments, %d left): ", - segments, rthdr->ip6r_segleft); - for (i = 0; i < segments; i++) { - in6 = inet6_rth_getaddr(extptr, i); - if (in6 == NULL) - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 70] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - printf(" "); - else - printf("%s ", inet_ntop(AF_INET6, - (void *)in6->s6_addr, - asciiname, INET6_ADDRSTRLEN)); - } - if (inet6_rth_reverse(extptr, extptr) == -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-02.txt [Page 71] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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-02.txt [Page 72] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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) - { - struct ip6_dest *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 = (struct ip6_dest *)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 OPT_X: - offset = 0; - offset = inet6_opt_get_val(databuf, offset, - &value4, sizeof (value4)); - 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: - - - -draft-ietf-ipngwg-2292bis-02.txt [Page 73] - -INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000 - - - 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-02.txt [Page 74] - diff --git a/doc/draft/draft-ietf-ipngwg-rfc2292bis-03.txt b/doc/draft/draft-ietf-ipngwg-rfc2292bis-03.txt new file mode 100644 index 0000000000..7572973c26 --- /dev/null +++ b/doc/draft/draft-ietf-ipngwg-rfc2292bis-03.txt @@ -0,0 +1,21 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +E. Nordmark: nordmark@eng.sun.com +M. Thomas: thomas@vayu.net +R. Stevens: rstevens@noao.edu + + diff --git a/doc/draft/draft-ietf-ipngwg-rfc2553bis-03.txt b/doc/draft/draft-ietf-ipngwg-rfc2553bis-03.txt deleted file mode 100644 index aa99ffd6c8..0000000000 --- a/doc/draft/draft-ietf-ipngwg-rfc2553bis-03.txt +++ /dev/null @@ -1,2044 +0,0 @@ -IPNG Working Group R.E. Gilligan -INTERNET-DRAFT: draft-ietf-ipngwg-rfc2553bis-03.txt Cache Flow -Obsoletes RFC 2553 S. Thomson - Cisco - J. Bound - Nokia Networks - W. R. Stevens - February 2001 - - - - - - - Basic Socket Interface Extensions for IPv6 - - - - -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 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. - - 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 - -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. - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 1] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -Additional extensions for advanced IPv6 features (raw sockets and access -to the IPv6 extension headers) are defined in another document [4]. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 2] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -Table of Contents: - - -1. Introduction.................................................4 -2. Design Considerations........................................4 -2.1 What Needs to be Changed....................................4 -2.2 Data Types..................................................6 -2.3 Headers.....................................................6 -2.4 Structures..................................................6 -3. Socket Interface.............................................6 -3.1 IPv6 Address Family and Protocol Family.....................6 -3.2 IPv6 Address Structure......................................6 -3.3 Socket Address Structure for 4.3BSD-Based Systems...........7 -3.4 Socket Address Structure for 4.4BSD-Based Systems...........8 -3.5 The Socket Functions........................................9 -3.6 Compatibility with IPv4 Applications.......................10 -3.7 Compatibility with IPv4 Nodes..............................10 -3.8 IPv6 Wildcard Address......................................10 -3.9 IPv6 Loopback Address......................................11 -3.10 Portability Additions.....................................12 -4. Interface Identification....................................14 -4.1 Name-to-Index..............................................14 -4.2 Index-to-Name..............................................15 -4.3 Return All Interface Names and Indexes.....................15 -4.4 Free Memory................................................15 -5. Socket Options..............................................16 -5.1 Unicast Hop Limit..........................................16 -5.2 Sending and Receiving Multicast Packets....................17 -5.3 IPV6_V6ONLY option for AF_INET6 Sockets....................18 -6. Library Functions...........................................19 -6.1 Protocol-Independent Nodename and Service Name Translation.19 -6.2 Socket Address Structure to Nodename and Service Name......23 -6.3 Address Conversion Functions...............................25 -6.4 Address Testing Macros.....................................26 -7. Summary of New Definitions..................................27 -8. Security Considerations.....................................28 -9. Year 2000 Considerations....................................28 -Changes made to rfc2553bis-02 to rfc2553bis-03.................29 -Changes made to rfc2553bis-01 to rfc2553bis-02.................29 -Changes made to rfc2553bis-00 to rfc2553bis-01.................29 -Changes made rfc2553 to rfc2553bis-00:.........................29 -Acknowledgments................................................30 -References.....................................................30 -Authors' Addresses.............................................31 - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 3] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -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 additional - 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-200x. (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-ipngwg-2553bis-03.txt Expires July 2001 [Page 4] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - - - 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. The new API is based on -the IEEE Std 1003.1-200x draft [3] and 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-ipngwg-2553bis-03.txt Expires July 2001 [Page 5] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -2.2 Data Types - -The data types of the structure elements given in this memo are intended -to track the relevant standards. uintN_t means an unsigned integer of -exactly N bits (e.g., uint16_t). - - - -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-200x. (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. - - - -3.2 IPv6 Address Structure - -A new in6_addr structure holds a single IPv6 address and is defined as a -result of including : - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 6] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - - 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 -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 - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 7] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -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 [2,5,6,7]. 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 */ - }; - -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. - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 8] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -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 -IPv6, since all of the "address carrying" functions use an opaque -address pointer, and carry an address length as a function argument. - - - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 9] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -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 getaddrinfo() -function, when the specified host has only IPv4 addresses (as described -in Section 6.1 and 6.2). - -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. - - - -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" - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 10] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -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. - - - -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 - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 11] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -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 portable code across multiple address families and platforms. -This data structure is designed with the following goals. - - - Large enough to accommodate all supported protocol-specific address - structures. - - Aligned at an appropriate boundary so that pointers to it can be cast - as pointers to protocol specific address structures and used to - access the fields of those structures without alignment problems. - - -The sockaddr_storage structure contains field ss_family which is of type -sa_family_t. When a sockaddr_storage structure is cast to a sockaddr -structure, the ss_family field of the sockaddr_storage structure maps -onto the sa_family field of the sockaddr structure. When a -sockaddr_storage structure is cast as a protocol specific address -structure, the ss_family field maps onto a field of that structure that -is of type sa_family_t and that identifies the protocol's address -family. - -An example implementation design of such a data structure would be as -follows. - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 12] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -/* - * 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 */ -}; - -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. - -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]; - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 13] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - - /* 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_len, */ - /* __ss_family, __ss_pad1, __ss_align fields is 112 */ -}; - - - -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 -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). - - - - - - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 14] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -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). - - - -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 - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 15] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -it is recommended that these definitions be defined in net/if.h as well -as 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 . - - - -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; - socklen_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); - - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 16] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -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 - - 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 - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 17] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - - 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 use 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 */ - 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. - - - -5.3 IPV6_V6ONLY option for AF_INET6 Sockets - -This socket option restricts AF_INET6 sockets to IPv6 communications -only. As stated in section <3.7 Compatibility with IPv4 Nodes>, -AF_INET6 sockets may be used for both IPv4 and IPv6 communications. Some -applications may want to restrict their use of an AF_INET6 socket to -IPv6 communications only. For these applications the IPV6_V6ONLY socket -option is defined. When this option is turned on, the socket can be -used to send and receive IPv6 packets only. This is an IPPROTO_IPV6 -level option. This option takes an int value. This is a boolean -option. By default this option is turned off. - - Here is an example of setting this option: - - int on = 1; - - if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY, - (char *)&on, sizeof(on)) == -1) - perror("setsockopt IPV6_V6ONLY"); - else - printf("IPV6_V6ONLY set0); - -Note - This option has no effect on the use of IPv4 Mapped addresses -which enter a node as a valid IPv6 addresses for IPv6 communications as -defined by Stateless IP/ICMP Translation Algorithm (SIIT) [8]. - - - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 18] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -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. - -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. - - - -6.1 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 1003.1-200x -(POSIX) draft specification [3]. - -The official specification for this function will be the final IEEE -standard. In addition this specification is not specifying all -parameter possibilities for this function, but only the parameters that -can be provided to support IPv4 and IPv6 communications to support this -specification. This is beyond the scope of this document and additional -work on this function will be done by the Austin (IEEE/ISO/TOG) Group. - #include - #include - - - int getaddrinfo(const char *nodename, const char *servname, - const struct addrinfo *hints, struct addrinfo **res); - - void freeaddrinfo(struct addrinfo *ai); - - struct addrinfo { - 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 */ - socklen_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 */ - }; - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 19] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - - The getaddrinfo ( ) function translates the name of a service - location (for example, a host name) and/or a service name and returns - a set of socket addresses and associated information to be used in - creating a socket with which to address the specified service. - - The nodename and servname arguments are either null pointers or - pointers to null-terminated strings. One or both of these two - arguments must be a non-null pointer. - - The format of a valid name depends on the protocol family or - families. If a specific family is not given and the name could be - interpreted as valid within multiple supported families, the - implementation will attempt to resolve the name in all supported - families and, all successful results will be returned. - - If the nodename argument is not null, it can be a descriptive name or - can be an address string. If the specified address family is AF_INET, - or AF_UNSPEC, the permissable nodename argument is specified as - defined in inet_pton(). If the specified address family is AF_INET6 - or AF_UNSPEC, the permissable nodename argument is specified as - defined in [5]. - - If nodename is not null, the requested service location is named by - nodename; otherwise, the requested service location is local to the - caller. - - If servname is null, the call returns network-level addresses for the - specified nodename. If servname is not null, it is a null-terminated - character string identifying the requested service. This can be - either a descriptive name or a numeric representation suitable for - use with the address family or families. If the specified address - family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be - specified as a string specifying a decimal port number. - - If the argument hints is not null, it refers to a structure - containing input values that may direct the operation by providing - options and by limiting the returned information to a specific socket - type, address family and/or protocol. In this hints structure every - member other than ai_flags, ai_family, ai_socktype and ai_protocol - must be zero or a null pointer. A value of AF_UNSPEC for ai_family - means that the caller will accept any protocol family. A value of - zero for ai_socktype means that the caller will accept any socket - type. A value of zero for ai_protocol means that the caller will - accept any protocol. If hints is a null pointer, the behavior must be - as if it referred to a structure containing the value zero for the - ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC for the - ai_family field. - - Note: - - 1. If the caller handles only TCP and not UDP, for example, then the - ai_protocol member of the hints structure should be set to - IPPROTO_TCP when getaddrinfo ( ) is called. - - 2. 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. - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 20] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - - The ai_flags field to which hints parameter points must have the - value zero or be the bitwise OR of one or more of the values - AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV, - AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG. - - The AI_PASSIVE flag in the ai_flags member of the hints structure - specifies how to fill in the IP address portion of the socket address - structure. If the AI_PASSIVE flag is specified, then the returned - address information must be suitable for use in binding a socket for - accepting incoming connections for the specified service (i.e. a call - to bind()). In this case, if the nodename argument is null, 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, the returned address - information must be suitable for a call to connect( ) (for a - connection-mode protocol) or for a call to connect(), sendto() or - sendmsg( ) (for a connectionless protocol). In this case, if the - nodename argument is null, then the IP address portion of the socket - address structure will be set to the loopback address. This flag is - ignored if the nodename argument is not null. - - If the flag AI_CANONNAME is specified and the nodename argument is - not null, the function attempts to determine the canonical name - corresponding to nodename (for example, if nodename is an alias or - shorthand notation for a complete name). - - If the flag AI_NUMERICHOST is specified 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 (for example, the DNS) from being invoked. - - If the flag AI_NUMERICSERV is specified then a non-null servname - string must be a numeric port string. Otherwise an error [EAI_NONAME] - is returned. This flag prevents any type of name resolution service - (for example, NIS+) from being invoked. - - If the AI_V4MAPPED flag is specified along with an ai_family of - AF_INET6, then the caller will accept IPv4-mapped IPv6 addresses. - That is, if no AAAA or A6, records are found then a query is made for - A records and any found are returned as IPv4-mapped IPv6 addresses - (ai_addrlen will be 16). The AI_V4MAPPED flag is ignored unless - ai_family equals AF_INET6. - - The AI_ALL flag is used in conjunction with the AI_V4MAPPED flag, and - is only used with an ai_family of AF_INET6. When AI_ALL is logically - or'd with AI_V4MAPPED flag then the caller will accept all addresses: - IPv6 and IPv4-mapped IPv6. A query is first made for AAAA/A6 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 (ai_addrlen will be 16). This flag is ignored unless - ai_family equals AF_INET6. - - Note: - - When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and - AI_ALL flags will only be used if AF_INET6 is supported. - - If the AI_ADDRCONFIG flag is specified then a query for AAAA or A6 - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 21] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - - 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. The loopback - address is not considered for this case as valid as a configured - sources address. - - The ai_socktype field to which argument hints points specifies the - socket type for the service. If a specific socket type is not given - (for example, a value of zero) and the service name could be - interpreted as valid with multiple supported socket types, the - implementation will attempt to resolve the service name for all - supported socket types and, all successful results will be returned. - A non-zero socket type value will limit the returned information to - values with the specified socket type. - - The freeaddrinfo ( ) function frees one or more addrinfo structures - returned by getaddrinfo ( ), along with any additional storage - associated with those structures. If the ai_next field of the - structure is not null, the entire list of structures is freed. The - freeaddrinfo () function must support the freeing of arbitrary - sublists of an addrinfo list originally returned by getaddrinfo (). - - Functions getaddrinfo ( ) and freeaddrinfo ( ) must be thread-safe. - - A zero return value for getaddrinfo ( ) indicates successful - completion; a non-zero return value indicates failure. - - Upon successful return of getaddrinfo ( ), the location to which res - points refers to a linked list of addrinfo structures, each of which - specifies a socket address and information for use in creating a - socket with which to use that socket address. The list must include - at least one addrinfo structure. The ai_next field of each structure - contains a pointer to the next structure on the list, or a null - pointer if it is the last structure on the list. Each structure on - the list includes values for use with a call to the socket( ) - function, and a socket address for use with the connect() function - or, if the AI_PASSIVE flag was specified, for use with the bind( ) - function. The fields ai_family, ai_socktype, and ai_protocol are - usable as the arguments to the socket() function to create a socket - suitable for use with the returned address. The fields ai_addr and - ai_addrlen are usable as the arguments to the connect() or bind( ) - functions with such a socket, according to the AI_PASSIVE flag. - - If nodename is not null, and if requested by the AI_CANONNAME flag, - the ai_canonname field of the first returned addrinfo structure - points to a null-terminated string containing the canonical name - corresponding to the input nodename; if the canonical name is not - available, then ai_canonname refers to the argument nodename or a - string with the same contents. The contents of the ai_flags field of - the returned structures is undefined. - - All fields in socket address structures returned by getaddrinfo ( ) - that are not filled in through an explicit argument (for example, - sin6_flowinfo) must be set to zero. - - Note: This makes it easier to compare socket address structures. - - Error Return Values: - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 22] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - - [EAI_AGAIN] The name could not be resolved at this time. Future - attempts may succeed. - - [EAI_BADFLAGS] The flags parameter had an invalid value. - - [EAI_FAIL] A non-recoverable error occurred when attempting to - resolve the name. - - [EAI_FAMILY] The address family was not recognized. - - [EAI_MEMORY] There was a memory allocation failure when trying to - allocate storage for the return value. - - [EAI_NONAME] The name does not resolve for the supplied parameters. - Neither nodename nor servname were passed. At least one - of these must be passed. - - [EAI_SERVICE] The service passed was not recognized for the specified - socket type. - - [EAI_SOCKTYPE] The intended socket type was not recognized. - - [EAI_SYSTEM] A system error occurred; the error code can be found in - errno. - - #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. - - - -6.2 Socket Address Structure to Nodename and Service Name - -The official specification for this function will be the final Austin -Group standard update to getaddrinfo(), and will incorporate this -function. In addition this specification is not specifying all -parameter possibilities for this function, but only the parameters that -can be provided to support IPv4 and IPv6 communications to support this -specification. This is beyond the scope of this document and additional -work on this function will be done by the Austin group. - - #include - #include - - int getnameinfo(const struct sockaddr *sa, socklen_t salen, - char *host, socklen_t hostlen, - char *serv, socklen_t servlen, - int flags); - -The getnameinfo( ) translates a socket address to a node name and -service location, all of which are defined as with getaddrinfo (). - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 23] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -The argument sa points to a socket address structure to be translated. - -If the argument node is non-NULL and the argument nodelen is nonzero, -then the argument node points to a buffer able to contain up to nodelen -characters that will receive the node name as a null-terminated string. -If the argument node is NULL or the argument nodelen is zero, the node -name will not be returned. If the nodeÆs name cannot be located, the -numeric form of the nodes address is returned instead of its name. If -the sa argument is an IPv6 address the returned nodename may be in the -format as defined in [5]. - -If the argument service is non-NULL and the argument servicelen is -nonzero, then the argument service points to a buffer able to contain up -to servicelen characters that will receive the service name as a null- -terminated string. If the argument service is NULL or the argument -servicelen is zero, the service name will not be returned. If the -service name cannot be located, the numeric form of the service address -(for example, its port number) is returned instead of its name. - -The arguments node and service cannot both be NULL. - -The flags argument is a flag that changes the default actions of the -function. By default the fully-qualified domain name (FQDN) for the host -is returned, but - - - 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, the numeric form of the - host's address is returned instead of its name, under all - circumstances. - - - If the flag bit NI_NAMEREQD is set, an error is returned if the - hostÆs name cannot be located. - - - If the flag bit NI_NUMERICSERV is set, the numeric form of the - service address is returned (for example, its port number) instead of - its name, under all circumstances. - - - If the flag bit NI_NUMERICSCOPE is set, the numeric form of the - scope identifier is returned (for example, interface index) - instead of its name. This flag is ignored if the sa argument is - not an IPv6 address. - - - If the flag bit NI_DGRAM is set, this indicates that the service is - a datagram service (SOCK_DGRAM). The default behavior is to assume that - the service is a stream service (SOCK_STREAM). - -Note: - - 1. The three NI_NUMERICxxx flags are required to support the "-n" - flags that many commands support. - 2. The NI_DGRAM flag is required for the new AF_INET/AF_INET6 port - numbers (for example, 512-514) that represent different services - for UDP and TCP. - -Function getnameinfo() must be thread safe. - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 24] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -A zero return value for getnameinfo( ) indicates successful completion; -a non-zero return value indicates failure. - -On successful completion, function getnameinfo( ) returns the node and -service names, if requested, in the buffers provided. The returned names -are always null-terminated strings. - -Error Return Values: - - [EAI_AGAIN] The name could not be resolved at this time. - Future attempts may succeed. - - [EAI_BADFLAGS] The flags had an invalid value. - - [EAI_FAIL] A non-recoverable error occurred. - - [EAI_FAMILY] The address family was not recognized or the address - length was invalid for the specified family. - - [EAI_MEMORY] There was a memory allocation failure. - - [EAI_NONAME] The name does not resolve for the supplied parameters. - NI_NAMEREQD is set and the hostÆs name cannot be located, or - both nodename and servname were null. - - [EAI_SYSTEM] A system error occurred. The error code can be found in - errno. - - - - -6.3 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, socklen_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). - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 25] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -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]. - -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.4 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 *); - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 26] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -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. - - - -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_AGAIN - EAI_BADFLAGS - EAI_FAIL - EAI_FAMILY - EAI_MEMORY - 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; - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 27] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - - 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 -discussed in this memo, sorted by header. - - int inet_pton(int, const char *, void *); - const char *inet_ntop(int, const void *, - char *, socklen_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 *, socklen_t, char *, socklen_t, int); - void freeaddrinfo(struct addrinfo *); - char *gai_strerror(int); - - 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-ipngwg-2553bis-03.txt Expires July 2001 [Page 28] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -Changes made to rfc2553bis-02 to rfc2553bis-03 - - - 1. Edits only. - - - - -Changes made to rfc2553bis-01 to rfc2553bis-02 - - - 1. Updated all references to comply with latest IEEEE work on - socket APIs and changed all remaining size_t to socklen_t. - - 2. Edits caught. - - - - -Changes made to rfc2553bis-00 to rfc2553bis-01 - - - 1. Removed all references to getipnodebyname() and - getipnodebyaddr(). - - 2. Added IPV6_V6ONLY Socket IP level option to permit nodes - to not process IPv4 packets as IPv4 Mapped addresses - in implementations. - - 3. Added note to getaddrinfo() and getnameinfo() - that final specification of parameter associations for - these functions will be done by Austin. - - 4. Added SIIT to references and added new contributors. - - - - -Changes made rfc2553 to rfc2553bis-00: - - 1. Updated Portability Section 3.10 to conform to XNS 5.2. - - 2. Updated getaddrinfo(), getnameinfo(), to conform to XNS 5.2. - - 3. Added references to Scope Architecture, Scope Routing, and - Extension Format for Scoped Addresses work in progress. - - 4. Added NI_NUMERICSCOPE flag to getnameinfo(). - - 5. Added qualification to getipnodebyname/addr() functions that - they will not work as is with scope identifiers with IPv6, and - getaddrinfo/getnameinfo should be used. - - 6. Added DNS A6 record notation to AAAA and added ip6.arpa as new - PTR record domain. - - - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 29] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - -Acknowledgments - -This specification's evolution and completeness were significantly -influenced by the efforts of Richard Stevens, who has passed on. Rich's -wisdom and talent made the specification what it is today. The co- -authors will long think of Richard with great respect. - -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, Brian Haberman, Jun-ichiro -itojun Hagino, 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, Bill Sommerfield, Erik Scoredos, Keith -Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey Thompson, Dean -D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David Waitzman, Carl -Williams, Kazu Yamamoto, Vlad Yasevich, Stig Venaas, and Brian Zill - -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 -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 Std. 1003.1-200x (Portable Operating System Interface (POSIX)) - DRAFT 6, July 2000. - - [4] W. Stevens, M. Thomas, "Advanced Sockets API for IPv6", - RFC 2292, February 1998. - - [5] T. Jinmei, A. Onoe, "An Extension of Format for IPv6 Scoped - Addresses", Work-in-Progress. - - [6] S. Deering, B. Haberman, B. Zill "IP Version 6 Scoped Address - Architecture", Work-in-Progress. - - [7] B. Haberman " Routing of Scoped Addresses in the Internet Protocol - Version 6 (IPv6)", Work-in-Progress. - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 30] - - -INTERNET-DRAFT draft-ietf-ipngwg-rfc2553bis-03.txt February 2001 - - - [8] E. Nordmark "Stateless IP/ICMP Translation Algorithm (SIIT)" - RFC 2765, February 2000. - - - -Authors' Addresses - - -Bob Gilligan -Cacheflow, Inc. -650 Almanor Ave.. -Sunnyvale, CA 94086 -Telephone: 408-220-2084 (voice) - 408-220-2250 (fax) -Email: gilligan@cacheflow.com - -Susan Thomson -Cisco Systems -499 Thornall Street, 8th floor -Edison, NJ 08837 -Telephone: 732-635-3086 -Email: sethomso@cisco.com - -Jim Bound -Nokia Networks -5 Wayside Road -Burlington, MA 01803 -Phone: +1 781 492 6013 -Email: Jim.Bound@nokia.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -draft-ietf-ipngwg-2553bis-03.txt Expires July 2001 [Page 31] - diff --git a/doc/draft/draft-ietf-ipngwg-rfc2553bis-04.txt b/doc/draft/draft-ietf-ipngwg-rfc2553bis-04.txt new file mode 100644 index 0000000000..c75ea28294 --- /dev/null +++ b/doc/draft/draft-ietf-ipngwg-rfc2553bis-04.txt @@ -0,0 +1,22 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +R. Gilligan: gilligan@freegate.com +W. Stevens: rstevens@noao.edu +J. Bound: bound@zk3.dec.com +S. Thomson: set@bellcore.com + + diff --git a/doc/draft/draft-macgowan-dnsext-label-intel-manage-00.txt b/doc/draft/draft-macgowan-dnsext-label-intel-manage-00.txt deleted file mode 100644 index ed16cac511..0000000000 --- a/doc/draft/draft-macgowan-dnsext-label-intel-manage-00.txt +++ /dev/null @@ -1,802 +0,0 @@ -INTERNET-DRAFT DNS Label Intelligence and Management System -UPDATES RFC 1034 February 2001 - Expires August 2001 - - - - -Domain Name System (DNS) DNS Label Intelligence and Management System - draft-macgowan-dnsext-label-intel-manage-00.txt - - - -Michael L. Macgowan Jr. - - -Status of This Document - -This draft is intended to become a Proposed Standard RFC. Distribution -of this document is unlimited. Comments should be sent to the Domain -Name Server Extensions working group mailing -list or to the author. - -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 -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 multidimensional array of domain label analysis and extensions are -offered to overcome a number of issues with the DNS and its use to -locate resources on the Internet. These goals are accomplished by -proposing a naming convention to add labels to domain strings. The -result will be a rational relationship to the content that will provide -a method for meeting the ever-increasing need to expand the namespace, -while providing an efficient search system to access content in a user- -friendly manner. - -A fundamental problem exists in the design of DNS. A user must know the -domain name including the Top Level Domain, TLD, and type the Uniform -Resource Locator, URL, accurately to connect to resources on the -Internet. The current lookup organization of the DNS uses domain labels -separated by periods to provide hierarchical levels for a resolver to -seek in finding a path to an authority. A new masking technique within -labels is proposed to accommodate lookups based on the request. -Multiple processing trees are proposed to redistribute the requests -based on the known pieces of the domain name. Rather than knowing the -fully qualified domain name, FQDN, the user can search for content -based upon known pieces of the string like group (business), country, -area code, phone number, type of organization, street address, zip code -and/or GPS location, etc.. Intelligence is added for determining the -fastest route to resolution based on user weighting, number of -requests, and traffic within the system. - -A result of the masking technique is an opportunity to provide a -completely hidden label(s) for maintenance of the system. A TTL (Time -to Live), version, and type of request could be keyed into a label to -provide information, which remains with the client but is normally lost -after a request is processed. This system could be implemented to -create automatically updated records and content. Or hidden labels -could be used to distinguish between version 4 and version 6 requests -in the TCP/IP, Transmission Control Protocol/ Internet Protocol, -rollover. - -Implementation of the new name system is facilitated by the addition of -a client interface for building requests. Longer domain names are -enhanced by smart AutoCompletes and group edit boxes. - -Table of Contents - - Status of This Document 1 - Abstract 1 - - Table of Contents 3 - - 1. Introduction 4 - 2. Inputting Request for Resolution 4 - 3. Resolution Processing 7 - 4. Processing Forest 13 - 5. Extended Label Uses 14 - 6. IANA Considerations 16 - 6. Security Considerations 16 - - References 16 - - Authors Address 16 - Expiration and File Name 17 - - - - - - - - - - - - -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 phone numbers as described in [RFC 2535]. It is designed to -accommodate a user-friendly name as an abstraction level over an IP -address, which provides a path to the physical connection to resources -and/or content on the Internet. This abstraction allows for changing -the physical location of the content without an update by the client. -The design, however, lacks a user-friendly method for assigning TLDs -and determining which TLD a content provider will be registered under. - -According to COMPUTERGRAM INTERNATIONAL: January 08, 2001, over 100 -million hosts are connected to the Internet with over 350 million -users. ICANN has submitted plans to increase the number of TLDs to -accommodate the lack of namespace, but the problem of organization and -extensibility continues to exist. As the number of TLDs grows, it -becomes harder for a user to input a user friendly domain name. In -essence, the user must know what derivations and which TLDs were -available to a provider at the time the organization chose a domain -name. The method of one response, in an all or nothing request, forces -precision on the part of the user that is a distraction to the original -goal of a user-friendly name. Consider a user that wants to find a new -theoretical health related company called Healthy Foods. Will the -company be called Healthyfoods.com? Or will it have an extension like -healthfoods.net, healthfoods.org, or healthfoods.health? Maybe it will -be forced to be a derivation like healthf.com, healthf.net, etc. There -is no user-friendly method to determine what the associated domain name -might be. This is a central problem of focus and organization. The -number of iterations a user must try increases with each new TLD that -is added. If a user forms multiple guesses for the TLD, excess traffic -is generated and the search is slowed by the inefficient nature of -human typing. Further, if a system were proposed under the current root -structure to allow for a search of all possible TLDs, the number of -requests would grow exponentially with the addition of each new TLD. - -2. Inputting Request for Resolution - - - -The key to making a New Name System, NNS, is to provide a user -interface, which will accommodate a friendly method of building name -requests. AutoComplete and multiple-selection drop-down, group list -boxes (some editable, some not) will make more complicated names easier -to input. Consider the previous example of Healthy Foods. Additional -extensions could be added as labels to make the namespace exponentially -larger. The web content might be reached at -www.healthy.food.US2081234567.Fairview101. In this example, www is the -Device label or content desired by the user. Health is the domain or -Subgroup/Group name label. Food is the item under the Type label. -US2081234567 is the item country/area code/number for the Global label. -Sfairview101 is the street/address of the Local label. - -Derivations of this example provide a limitless expansion of the -namespace within the physical limits of the protocol. A competitor down -the block might have the same FQDN, except for the street number and -phone number e.g. www.healthy.food.US2088901234.SFairview990. A second -type of business could also be run from the same location by changing -the type e.g. www.healthy.entertainment.US2081234567.SFairview101. A -parody of the site might be offered at -www.healthy.parody.us2086669999.SState103. - -A method of using less descriptive labels could also be used to -generalize the content. For example, the site for the regional office -might use only the country and area code designation e.g. .US208. A -corporate address might be located at www.healthy.food.US.corporate. -This way the Global and Local labels are not tied to physical -locations. Or there may be an 800 or 888 number that could be used for -multiple sites that are tied to multiple registrations at different -street addresses in the Local label. - -The task of building these longer names with labels can be accomplished -by updating list items from the NNS and by designing a better -interface. Instead of waiting for ICANN to vote on the relative merits -of a proposal for a new TLD, items could be automatically updated and -added to the system by a list of requirements. This would force a -relationship between labels but provide a nonbiased method without -prejudice. For example, a .Bus(iness) item for the Type label would -require a copy of a business license to be granted by the governing -authorities for the area specified in the Global label or the address -specified in the Local label. A “TM” item could separate the -Intellectual Property of Trademarks and Copyrights from other -registered listings issued from the government specified by the country -code in the Global label. Additionally, the Academy of Motion Pictures -might request an Oscar item, which would restrict membership to -nominees or recipients of the coveted award. - -Just as the resolver gets an updated list of root servers upon first -connection, the resolver could also receive an updated list of items in -the Type label and return them to the client. The list could be updated -by a TTL trigger and should not be editable from the user’s standpoint. -The user interface should allow for multiple selections, which could be -used to form separate requests for resolution. Finally, the -implementation should begin with at least a list that is equal to a -subject list found in the yellow pages of the phone book. This will -provide a well-known classification that will greatly reduce -competition for names of organizations, which are similar but provide -for very different products/services. Delta.airline is readily -distinguished from Delta.homeimprovement. - -The device label would remain largely unaffected. A list of previously -connected items such as www, toasters, lock, refrigerator, etc. would -facilitate input. The list would be editable. As the number of devices -connected to the Internet grows, this method will be invaluable. -Consider mail and faxes being sent directly to -printer.mybusiness.computer.us2081234567.sfairview101. A user that -needs to send a fax to a satellite office might also be able to try -searching for mybusiness at its other street address or telephone -number eg., printer.mybusiness.computer.us714*.sPensylvaiaave2345. -Wildcards and searching are discussed in the next section. - -The items under the Groups/Subgroups labels would also be a list of -previously connected to domains (less the TLD) such as sales.business -or kitchen.home. The list would contain a history of previous -connections and be editable. - -The Global label would have two characters to represent the country -code followed optionally by all or part of a representative telephone -number or mask for identifying the voice number(s) associated as items -in the domain. An international code would require a rational -relationship with world organizations. The interface would contain the -country codes and/or area codes, but the numbers would have to be -added. - -The Local label would require a single character to represent the type -of information presented, followed by the information in a standardized -form. The following codes are proposed for the Local label, “P” for -Postal code, “G” for Global Satellite Positioning and “S” for street -address. For example, P83706 would represent the author’s postal code, -GP0445004N1162498 (since the “+” key is not valid, “p” and “n” -represent positive and negative) would represent the GPS position of -the author with padding to standardize degrees/min/sec or SOrchard15541 -would represent the Street address (house number at the end). Note each -of these would require a separate name registration. The editable list -box could be a fly out list box with one of the designators specified, -while the remainder would be user input. - -+------------------+ -|Street | -| Fairview101 | - State101 | -|Postal | -|GPS | -+------------------+ - -The added labels would exponentially expand the name space. This may -cause an undesired relation to a Global or Local designation. This -could hamper changes to an organization or business in the future. -Hence a business might want to use a CNAME entry to reference users to -a non-distinct item in a label. For instance, a corporation might want -to register mybusiness.bus.In(ternational).corporate so that the -corporate office could be used for email addresses and bookmarking. -Content might be located at each mybusiness.bus.country.location where -the company does business. This way a corporation does not have to be -penalized for moving to a new physical location. The goal of the DNS -was to remove a physical relationship to the network, but the need of -the users is for some content to have a physical relationship to the -content; which is why, in part, the NNS is proposed. The concept of an -update is also discussed in section 5. - -The system would need to distinguish between the need for a request for -a connection to single IP address versus multiple requests. In an -application like a browser, traditional requests for IP resolution are -all or none. Either an IP address is connected to or not. If wildcards -are added to the request, multiple entries could be returned as a “hit” -list. An option on the browser could determine the number of requests -specified by the user. The “hits” should also be weighted. For -instance, if a user wanted to find all the movie theatres in the local -area he/she might submit a request for www.*.movies.US8370*.*. She/he -would be more inclined to desire additional theatres at different -nearby area codes than derivations of different domain names or Local -label derivations for a single theatre. A simple listing of each label -with an associated numerical value in an advanced option field could -determine how the responses are weighted against one another. The NNS -could also take into account the number of requests on the system and -further limit the number of responses based upon traffic. - -For registration, the content provider might want to register a more -global entry to be displayed on a restrictive search e.g. loans.US*.*. -A business content provider might want to register mybusiness.com.US* -so that requests for www.mybusiness.com.US208.* and -www.mybusiness.com.us714.* both resolve to mybusiness. A process would -have to be in place to copy an entry with wildcards to each of the -associated branches of the processing trees as discussed in section 4. -Similarly wildcard registrations should meet the rational requirements -required for the known item with the generalized scope. In the previous -example the provider would have to be licensed as a financial -institution in each of the states of the United States. - -3. Resolution Processing - -The key to expanding the DNS is to provide for a name space, which can -be accessed quickly and efficiently. Organization is key to this -process. The current DNS has one root organized by TLDs of the Type -label combined with Country TLDs. If a user does not know the extension -for the name, requests must be created for each one until a match is -found. The NNS creates separate roots for each label that can be used -for a search (see graphic on next page, description of TLDs is in -section 5). Instead of one tree, a forest is created, connected by a -common list of authorities for devices in the zones requested. Requests -can be organized by the known piece(s) of information. For instance, if -a user is trying to find Hewlett Packard and does not know that content -is provided at HP, a search of www.H*.*.US*.* should be returned -alphabetically from the Group label, not the Type label. However, if -the type item is known to be “computer”, a search of the Type tree -would be fastest. If a user wants to find a local voice number for -Microsoft he/she could submit a request generalized request within the -local area code for www.Microsoft.software.US208*.*. The authority -would best be located by the Global processor, which might list -www.Microsoft.software.US5041234567.SState123 and -www.Microsoft.software.US5044567890.SredmondAve123. If the request for -www.Microsoft.software.US504*.* were sent to the Local processor, every -TLD would have to be queried. The result might be one phone number with -separate Local label listings for the street address, GPS, and postal -code. This would create unwanted traffic on the system. - - -Root “.” Group Root “.”Type - | | - | | - “H” TLD TLD “Computer” - | | - | | - --- Authority for..HP.computer.US2081234567.SChinden12---- - | | - | | - “US208” TLD TLD “SChi” - | | - | | -Root “.” Global Root “.”Local - - -In addition to determining which label(s) to process the request, the -system would also have to take into account the weighting by the user -and the traffic on the system as discussed in the previous section. -When the FQDN is specified, the resolver would query the processor with -the fastest expected response time. A FQDN can be resolved from any of -the search processor trees. In the example -oven.macgowan.private.US2081234567.SOrchard15541, it does not matter -whether the request is sent to the Group, Type, Global, or Local -processing tree. Each leads to the authority, -macgowan.private.us2081234567.SOrchard15541. - -If wildcards or null characters exist in the request, the system should -take into account the number of requests that might be generated. -Currently the DNS does not account for the “?” and reserves the “” for -the root. The “*” could replace the singe character wildcard “?” and -the word “null” could be used in lieu of “”. The following table could -be used to determine which processing tree should be the most desirable -under such conditions: - -any = any combination of characters displayed in request -reject= no preferred processor -*= match any combination of characters for response -?= match any single character for response -null= no character specified - - -Device Sub Group T G L Result -* * * * * * reject -* any any any any any reject -* * any any any any reject -* * * any any any submit to T, G, or L -* * * * any any submit to G, or L -* * * * * any submit to L -any * * * * * reject -any any * * * * reject -any any any * * * submit to group -any any any any * * submit to group, or T -any any any any any * submit to group, T, or G -any any any any any any submit to any -any * any any any any submit to any -any * * any any any submit to T, G, or L -any * * * any any submit to any G, or L -any * * * * any submit to any L -any any * any any any submit to any T, G, or L -any any * * any any submit to any G, or L -any any * * * any submit to any L -any any any * any any submit to any group, G, or L -any any any * * any submit to any group, or L -any any any any * any submit to any group, T, or L -any any any any * * submit to any group, or T - -* * * * * * reject -* any*any any*any any*any any*any any*any reject -* * any*any any*any any*any any*any reject -* * * any*any any*any any*any submit to T, G, or L -* * * * any*any any*any submit to G, or L -* * * * * any*any submit to L -any*any * * * * * reject -any*any any*any * * * * reject -any*any any*any any*any * * * submit to group -any*any any*any any*any any*any * * submit to group, or T -any*any any*any any*any any*any any*any * submit to group, T, or G -any*any any*any any*any any*any any*any any*any reject -any*any * any*any any*any any*any any*any reject -any*any * * any*any any*any any*any submit to T, G, or L -any*any * * * any*any any*any submit to any G, or L -any*any * * * * any*any submit to any L -any*any any*any * any*any any*any any*any reject -any*any any*any * * any*any any*any submit to any G, or L -any*any any*any * * * any*any submit to any L -any*any any*any any*any * any*any any*any reject -any*any any*any any*any * * any*any submit to any group, or L -any*any any*any any*any any*any * any*any submit to any group, T, or L -any*any any*any any*any any*any * * submit to any group, or T - -* * * * * * reject -* any* any* any* any* any* reject -* * any* any* any* any* reject -* * * any* any* any* reject -* * * * any* any* submit to G, or L -* * * * * any* submit to L -any* * * * * * reject -any* any* * * * * reject -any* any* any* * * * reject -any* any* any* any* * * reject -any* any* any* any* any* * reject -any* any* any* any* any* any* reject -any* * any* any* any* any* reject -any* * * any* any* any* submit to T, G, or L -any* * * * any* any* submit to any G, or L -any* * * * * any* submit to any L -any* any* * any* any* any* reject -any* any* * * any* any* submit to any G, or L -any* any* * * * any* submit to any L -any* any* any* * any* any* reject -any* any* any* * * any* submit to any group, or L -any* any* any* any* * any* reject -any* any* any* any* * * submit to any group, or T - -?any ?any ?any ?any ?any ?any reject -?any any any any any any reject -?any ?any any any any any reject -?any ?any ?any any any any submit to T, G, or L -?any ?any ?any ?any any any submit to G, or L -?any ?any ?any ?any ?any any submit to L -any ?any ?any ?any ?any ?any reject -any any ?any ?any ?any ?any reject -any any any ?any ?any ?any submit to group -any any any any ?any ?any submit to group, or T -any any any any any ?any submit to group, T, or G -any any any any any any submit to any -any ?any any any any any submit to any -any ?any ?any any any any submit to T, G, or L -any ?any ?any ?any any any submit to any G, or L -any ?any ?any ?any ?any any submit to any L -any any ?any any any any submit to any T, G, or L -any any ?any ?any any any submit to any G, or L -any any ?any ?any ?any any submit to any L -any any any ?any any any submit to any group, G, or L -any any any ?any ?any any submit to any group, or L -any any any any ?any any submit to any group, T, or L -any any any any ?any ?any submit to any group, or T - -any?any any?any any?any any?any any?any any?any reject -any?any any any any any any submit to any -any?any any?any any any any any submit to any -any?any any?any any?any any any any submit to any -any?any any?any any?any any?any any any submit to G, or L -any?any any?any any?any any?any any?any any submit to L -any any?any any?any any?any any?any any?any reject -any any any?any any?any any?any any?any reject -any any any any?any any?any any?any submit to group -any any any any any?any any?any submit to group, or T -any any any any any any?any submit to any -any any any any any any submit to any -any any?any any any any any submit to any -any any?any any?any any any any submit to any -any any?any any?any any?any any any submit to any G, or L -any any?any any?any any?any any?any any submit to any L -any any any?any any any any submit to any -any any any?any any?any any any submit to any G, or L -any any any?any any?any any?any any submit to any L -any any any any?any any any submit to any -any any any any?any any?any any submit to any group, or L -any any any any any?any any submit to any -any any any any any?any any?any submit to any group, or T - -any? any? any? any? any? any? reject -any? any any any any any submit to any -any? any? any any any any submit to any -any? any? any? any any any submit to any -any? any? any? any? any any submit to any -any? any? any? any? any? any submit to any -any any? any? any? any? any? submit to any -any any any? any? any? any? submit to any -any any any any? any? any? submit to any -any any any any any? any? submit to any -any any any any any any? submit to any -any any any any any any submit to any -any any? any any any any submit to any -any any? any? any any any submit to any -any any? any? any? any any submit to any -any any? any? any? any? any submit to any -any any any? any any any submit to any -any any any? any? any any submit to any -any any any? any? any? any submit to any -any any any any? any any submit to any -any any any any? any? any submit to any -any any any any any? any submit to any -any any any any any? any? submit to any - -Null any any any any any not valid -any Null any any any any submit to any -any any Null any any any reject -any any any Null any any submit to group, G, L -any any any any Null any submit to group, T, L -any any any any any Null submit to group, T, G -Null Null any any any any not valid -any Null Null any any any reject -any any Null Null any any submit to G, L -any any any Null Null any submit to group, L -any any any any Null Null submit to group, T -Null Null Null any any any not valid -any Null Null Null any any submit to G, L -any any Null Null Null any submit to L -any any any Null Null Null submit to group -Null Null Null Null any any not valid -any Null Null Null Null any submit to L -any any Null Null Null Null not valid -Null Null Null Null Null any not valid -any Null Null Null Null Null not valid -Null Null Null Null Null Null not valid - - - -4. Processing Forest - - - - |--Group Root---| - | | - |---Type Root---| - | | -client->------Resolver ->------| |----Authority->--- -return - | | - |--Global Root--| - | | - |--Local Root---| - -Once the resolver has determined which root to send the resolution -request to, each tree should be organized according to an exhaustive -replication of each name string on the route to an authority. For -instance, the Group tree would be organized alphabetically with TLDs -“A” through “Z” initially. Since there are a lot of organizations with -business name derivations using the word “micron”, there might be a -need to reorganize the “M” TLD to accommodate a “Mic” and a “Mid” TLD. -Although it would be more efficient to break down each letter according -to the demands of the system, it would be easier to specify one mask -for the entire tree. The number of TLDs becomes a function of the -permutations of the number of masked characters in the available set of -usable characters rather than a select few that are added over time. -The resolver can cache the TLDs and know when to use them based upon -the mask for the tree. If a larger mask is needed to further distribute -the load, the resolvers would have to be updated. - -To replicate the current DNS entries under the additional labels -specified in this proposal a number of applications and uses would have -to be accounted for. The ARPA listings would remain unchanged or they -could be replicated under each root by recombining telephone numbers in -a single label under the e164 or padding IP addresses under the inverse -lookup tables without the periods separating the octets. - -Since the NNS uses a forest of processing trees and the current system -uses only one tree, a conversion process would have to be developed to -distinguish between DNS requests and NNS requests. This could be -handled using a number of different methods. - -A version flag in the request could accomplish this. This way the -resolver would be able to determine which searchable labels were used -and the order of presentation by standardization. The resolver -intelligence would know which labels to use for lookup or in the -preferred embodiment. The resolver could also reorganize the labels to -be presented under the correct processor so that the Global label is -presented at the right of the name string for processing through the -Global tree. Legacy requests without a version would be sent to the -Type tree. - -Another method could accomplish the goal by combining the labels the -request for the processing tree. In the previous example, the request -oven.macgowan.private.US2081234567.SOrchard15541 could be recombined by -the submitting processor as -oven.macgowanUS2081234567SOrchard15541.private to be searched under the -Type tree. Similarly it could be recombined as -oven.macgowanprivateUS2081234567.SOrchard15541 to be searched under the -Local tree. If a legacy DNS based system submitted a request for -www.yahoo.com, it might be appended as www.yahoo.com..... The first “.” -after com is to end the Type label. The second “.” Represents the null -character at the end of the Global label. The third “.” is for the -Local label. The fourth “.” is for the root. The last “.” is for the -end of the sentence. If applications are affected by the reservation of -the “.” for the root, the request could be recreated as -www.yahoo.com.null.null.. - -A final method is to create a hidden label. Hidden labels are discussed -further in extended label uses. - -Once the authority for a label is found within the label, the system -must also determine if there are Subgroups. Subgroups can be used for a -number of internal functions and/or divisions within the authority for -an organization. At this point the system would continue to resolve -using subgroup labels as levels as it does under the current system -toward the device at the left of the name string. - -The remaining searchable labels would be serviced using a similar -method. The Type tree would be organized as it is in the DNS with TLDs -representing each item in the list. Since the items in the list are -limited by the system, the mask could be set to none. The Global label -should be organized by a mask, which would accommodate at least the -country and area codes. The Local label would mask the PGS items until -enough TLDs are derived to equal processing traffic under the other -trees. Provisions should be made for the non-distinct items like -“corporate” that may use characters not reserved for physical -locations. In addition, a null TLD could be used to organize the -remainder of name strings that have omitted labels. The null “” -character or the word “null” could be used to represent legacy DNS -strings under the new labels until the name strings are updated with -the longer requirements. - -The NNS allows a FQDN to be resolved from each searchable label. Please -refer to the previous example, -oven.macgowan.private.US2081234567.SOrchard15541. The authority, -“Macgowan.private.US2081234567.SOrchard15541” is found using the -traditional method of the DNS using a Type item of “private” (mask of -zero). The authority, “Macgowan.private.US2081234567.SOrchard15541” is -found through the Group processor under the “Mac” branch using a mask -of three characters. The “Macgowan.private.US2081234567.SOrchard15541” -authority is found under “US208” using a mask of four characters within -the Global processing tree. The -“Macgowan.private.US2081234567.SOrchard15541” authority is also found -under “SOr” of the branch masked under the Local tree. - -5. Extended Label Uses - -The NNS is a simple design which can accommodate the future of Internet -name strings by incorporating additional processing trees and a large -name space organized by labels with a user friendly interface. A search -engine is automatically derived from the organization within labels as -opposed to across labels. In other words, you send the known pieces of -the request to the processing tree that will yield the quickest results -with the least amount of traffic. Once names are bookmarked or selected -from a list of AutoCompletes, requests can be sent to any processing -tree to balance the load on the system. - -The present proposal also provides an extensible path for future labels -that may or may not have associated processors. A “Contact” label -might always be masked during the request for resolution, but provide -additional value to the user with a description about the connection or -a webmaster’s email address. This has extreme value in the event a name -can be resolved, but not reached by connection to the IP address. In -addition to adding new labels, a group or association might request a -new item under the Type label or a new area code might be added under -the Group label. Therefore, one result of this system is a combination -of devices and labels which expands exponentially to meet the demand -for namespace with an inherent capability to adjust to future needs. - -An additional hidden label (mask of all) adjacent to the root could be -hidden and give information for maintenance of the system and/or the -listing. The most important consideration is keying the order and -number of labels in the string. Or using this method, a hidden security -label could help create a firewall between valid requests from users in -the domain versus outsiders or tie to a public key for the destination. -The hidden label could also be used to pass a request for content -delivered in a specific language. With the addition of the Local and -Global labels it might also be necessary to add a TTL label which could -serve as a timer for the registration or the life of a bookmark or -connection. The client could use this value in a history of valid -connections to make a request for an updated TTL, a new IP address, -and/or a trigger for replacing the name with a new string. This would -allow for a change in address, phone number, new area code, etc. on the -part of the provider. Just as the domain name was an abstraction layer -over the IP address, the current domain string is an abstraction for a -future domain string. A routine could prompt a user to change an entry -in a contact/bookmark list. Services such as WWW could also -automatically update links in the content or reflect changes to related -destinations within the content. In use, the client could compare its -value to the value at the authority. If the authority has a value of -zero, the client would update its name and IP address to the new -pointer returned by the resolver. An electronically updating NNS with -updating links in content is a product of this system. - -An example of using this procedure could be applied to finding the best -cell phone plan. A user buys a cell plan. The user emails contact links -to friends and associates. The recipients use their link to dial the -user. The user determines a new provider would be more advantageous and -purchases a new plan with a new number. The user sets their old TTL to -zero in the NNS and creates a new FQDN with the new cell number. Now -when the recipients use the old string, they are pointed to the new -string. The string with the new number is updated in the recipient’s -contact list. The user is not tied to their telephone number and the -recipients do not need to manually adjust their entries. - -Hidden labels and masking would also have to be present at the client. -A business might have a lot of phone numbers or locations listed on the -name servers but use a shorter version of the string for making local -connections. This way all the devices under a group could be combined -as a single domain name. The future direction of label intelligence and -the ideas expressed here suggest that there may be numerous ways to -provide abstraction levels within the label string. Even the IP address -might be used as an identifier to search for the rest of the domain -string or an item like the telephone number. - -6. IANA Considerations - -The focus of the IANA will change considerably. The need to regulate -name hoarders, TM infringement considerations, and the decision to -implement new TLDs will be greatly reduced. The IANA might be used to -determine the relationships between labels as new items are added under -the requirements that provide for fair and equal addition to the Type -label. - -7. Security Consideration - -Name resolution is an inherent problem for spoofing content, but is -beyond the scope of this proposal. The suggested ability to update name -strings at the client also increases the need to provide secure -communications between the system and the client. - - -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 2535] – “E.164 number and DNS” , P. - - P. Faltstrom, 9/1/2000. - -Authors Address - - Michael L. Macgowan Jr. - 15541 Orchard Ave. - Caldwell, ID 83607 USA - - - Telephone: +1 208.454.1177 (h) - FAX: +1 208.455.0439 - EMail: mmacgowa@yahoo.com - - -Expiration and File Name - - This draft expires in August 2001 - - Its file name is labelmanage.txt - -Full Copyright Statement - -Copyright (C) The Internet Society (February 2001). 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." -Michael L. Macgowan Jr. February 2001 [Page 17] - -Internet Draft DNS Label Intelligence and Management System - - - diff --git a/doc/draft/draft-macgowan-dnsext-label-intel-manage-01.txt b/doc/draft/draft-macgowan-dnsext-label-intel-manage-01.txt new file mode 100644 index 0000000000..669f62d63e --- /dev/null +++ b/doc/draft/draft-macgowan-dnsext-label-intel-manage-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +M. Macgowan: mmacgowa@yahoo.com + + diff --git a/doc/draft/draft-msawyer-dnsext-edns-attributes-00.txt b/doc/draft/draft-msawyer-dnsext-edns-attributes-00.txt deleted file mode 100644 index 93cd28f2a3..0000000000 --- a/doc/draft/draft-msawyer-dnsext-edns-attributes-00.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -INTERNET-DRAFT M. Sawyer - A. Gustafsson - M. Graff - Nominum - 15 November 2000 - - Handling of unknown EDNS0 attributes - -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 - - This draft expires on May 15, 2001. - -Abstract - - This document provides a clarification of the EDNS0 protocol, - specifying the behavior of servers when they receive unknown EDNS - options. - -1.1 - Introduction - - Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms - [RFC2671] is helpful. - - EDNS0 [RFC2671] specifies a general framework for extending the - packet format used by the Domain Name System protocol. The framework - provides for a series of additional options, identified by a 16 bit - attribute ID and arbitrary sized payload. Any number of these - additional options can be specified in the DNS packet. As specified, - the current scheme has drawbacks: - - - -Expires May 2001 [Page 1] - -INTERNET-DRAFT Handling of unknown EDNS attributes October 2000 - - - - It provides no way for implementers to deploy test systems with - experimental features prior to approval of the feature and assignment - of an attribute ID. - - - It provides no specification on what an application should do when - receiving unrecognized options. - - This draft proposes to clarify the original EDNS0 draft [RFC2671], - addressing these drawbacks. - -1.2 - Requirements - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -2 - Protocol changes: - - This document updates [RFC2671]. Conformance to this specification - is claimed by specifying EDNS version 1. - -2.1 - Advisory and Required Options: - - - Some potential uses of EDNS options are advisory in nature, For - example, a hypothetical option indicating that "I understand frobozz - compression in responses" can be safely ignored by the recipient, - which will then simply not use frobozz compression. Others uses of - options, such as a hypothetical "send only cryptographically verified - data in responses" option, cannot be safely ignored, and should cause - the request to fail if not understood by the receiver. - - This suggests that we need two types of options, "advisory" options - (that can be ignored) and "required" options (that can not). Because - a server needs to classify options as advisory or required even if - they were not yet defined when the server was implemented, the type - of an option must be evident without knowing its internal structure. - This is achieved by splitting the option type codes into two ranges: - options with type code 0x0000-0x7FFF are considered "advisory", and - options with type code 0x8000-0xFFFF are considered "required". - -2.2 - Handling of Unknown and Unsupported EDNS Option Types - - When a server receives an unknown or unsupported advisory option in a - request or response message, it MUST ignore the unknown option and - process the message as if the option was not present. In the reply, - it SHOULD include an advisory UNSUPPORTED option (TBD). - - - - -Expires May 2001 [Page 2] - -INTERNET-DRAFT Handling of unknown EDNS attributes October 2000 - - - When a server receives an unknown or unsupported required option in a - request message, it MUST NOT act on the request, and it MUST return - an error response with the extended result code BADOPT (TBD). In the - reply, it SHOULD include an advisory UNSUPPORTED option. - - When a server receives an unknown or unsupported required option in a - response message, it MUST ignore the response. The server SHOULD - continue to parse options after the unknown option, including a list - of all unsupported options in the UNSUPPORTED option in the reply. - - Servers MAY include SUPPORTED options in replies to messages, listing - option codes which they understand. This message SHOULD contain all - option codes the server understands. This facility MAY NOT be used - in place of the UNSUPPORTED option to identify unsupported options in - replies. - - Clients MAY include SUPPORTED or UNSUPPORTED options in queries. - UNSUPPORTED options SHOULD only list those option codes which the - client has received in previous replies from the server, not an - inclusive list of all unsupported option codes. - -2.3 - Use of Reserved Options for Development - - Option codes in the range of 0x7FF0 to 0x7FFF and 0xFFF0 to 0xFFFF - are considered "reserved" and shall not be assigned to new protocols. - Software vendors SHOULD use these options for testing of protocols - under development, provided the following conditions are met: - - - Vendors MUST NOT ship any versions of the software which use option - codes in this range. They MUST delay shipping software with the new - options until IANA has assigned permanent option codes. - - - Vendors MUST NOT place development servers on the live internet - which send options in this range to remote servers or which - understand options in this range as having any meaning. - -3.1 - SUPPORTED and UNSUPPORTED options - - The SUPPORTED and UNSUPPORTED options contain a list of option codes - which the server or client does or doesn't support. The list - contains, in network byte order, the supported or unsupported 16 bit - option codes: - - 1 1 1 1 1 1 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - | SUPPORTED or UNSUPPORTED (TBD) | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - - -Expires May 2001 [Page 3] - -INTERNET-DRAFT Handling of unknown EDNS attributes October 2000 - - - | LENGTH (number of options * 2) | - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - / OPTION CODE(s) / - / / - +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ - - Sending a SUPPORTED option with a zero-length payload indicates that - the server or client supports no EDNS options, so none should be - used. UNSUPPORTED options with zero-length payloads SHOULD NOT be - sent, as such a message is meaningless. - -4 - IANA considerations - - When allocating EDNS Option Codes, the IANA shall henceforth require - the RFC defining the new option to specify whether the option is an - "advisory" or a "required" option. The option code for an advisory - option shall be allocated from the range 0x0000-0x7FEF, and the code - for a required option shall be allocated from the range - 0x8000-0xFFEF. - - Option codes in the ranges of 0x7FF0 to 0x7FFF and 0xFFF0 to 0xFFFF - are considered "reserved." - - The IANA is hereby requested to assign EDNS Version Number 1 to this - specification, to assign a new extended RCODE value for BADOPT, and - to assign advisory option codes for UNSUPPORTED and SUPPORTED. - - -5 - Security considerations - - This document provides a mechanism for users to override the default - behavior of the server when accessing data from its internal zone - databases. Software developers and administrators should use some - care when enabling these options, as they may provide outside users - the ability to retrieve information otherwise not available. - -6 - Acknowledgments - - The authors would like to thank Olafur Gudmundsson for his input on - this draft. - -7 - References - - [RFC2119] S. Brander, ``Key words for use in RFCs to Indicate - Requirement Levels,'' RFC 2119, ISI, November 1997. - - [RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC - 2671, ISI, August, 1999 - - - -Expires May 2001 [Page 4] - -INTERNET-DRAFT Handling of unknown EDNS attributes October 2000 - - -Author's Address - - Michael Sawyer - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - Phone: +1-650-779-6021 - michael.sawyer@nominum.com - - Andreas Gustafsson - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - Phone: +1-650-779-6004 - andreas.gustafsson@nominum.com - - Michael Graff - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - Phone: +1-650-779-6034 - michael.graff@nominum.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires May 2001 [Page 5] - diff --git a/doc/draft/draft-msawyer-dnsext-edns-attributes-01.txt b/doc/draft/draft-msawyer-dnsext-edns-attributes-01.txt new file mode 100644 index 0000000000..3cb583727e --- /dev/null +++ b/doc/draft/draft-msawyer-dnsext-edns-attributes-01.txt @@ -0,0 +1,21 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +A. Gustafsson: gson@namesurfer.com +M. Sawyer: michael.sawyer@nominum.com +M. Graff: michael.graff@nominum.com + + diff --git a/doc/draft/draft-sawyer-dnsext-edns0-zone-option-00.txt b/doc/draft/draft-sawyer-dnsext-edns0-zone-option-00.txt deleted file mode 100644 index 574b5f2940..0000000000 --- a/doc/draft/draft-sawyer-dnsext-edns0-zone-option-00.txt +++ /dev/null @@ -1,221 +0,0 @@ -INTERNET-DRAFT M. Sawyer - B. Wellington - M. Graff - Nominum - 9 October 2000 - - ZONE and VIEW option records in DNS messages - -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 - - This draft expires on April 9, 2001. - -Abstract - - This document defines two new EDNS option codes used to specify what - zone and view should be used in query messages to a remote DNS - server. - -1 - Introduction - - Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms - [RFC2671] is helpful. - - Domain Concepts and Facilities [RFC1034] Section 3.7 shows a typical - reply to a DNS query, containing the answer as well as additional - data related to the answer provided. The server's zone database may - contain out-of-zone data glue which is internally used but is never - returned in a reply to a query. If recursion is requested by the - client and available in the server, or if the data is available in - - - -Expires April 2001 [Page 1] - -INTERNET-DRAFT ZONE and VIEW option records October 2000 - - - the server's cache, the additional information will be taken from - these sources on most servers. - - There is no method currently available for an administrator to query - a server specifying that only data from a specific zone should be - used in formulating the reply and that all available data from that - zone's database should be used, including out-of-zone glue. As such, - there is no mechanism for an administrator to ensure that out-of-zone - data in the zone's database is correct except through direct - manipulation of the zone database files. In addition, zone transfers - via AXFR or IXFR do not include out-of-zone glue. The ZONE option - code is provided to specify directly which zone database should be - queried. - - In addition, DNS server software exists which may present different - "views" of the DNS space to different clients. In some cases, a - query may match the criteria of multiple views, and a user may wish - to specify which of the acceptable views match the query. The VIEW - option code is provided to specify which view should be searched for - the appropriate zone database. - -1.2 - Requirements - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - -2 - Protocol changes: - - This document updates [RFC2671]. The ZONE and VIEW option records - are intended as optional features. Servers MAY support either or - both of these options. Servers SHOULD provide configuration options - to enable or disable these optional records as needed. - - Servers and clients SHOULD NOT use the ZONE or VIEW option codes in - normal use. - - Servers SHOULD NOT use the VIEW option record in zone transfers - unless the administrator has specifically configured the server to - use these records. Servers MAY provide a mechanism for such - configuration. Servers SHOULD NOT use the ZONE option record in zone - transfers under any configuration. - -3 - ZONE option record - - The ZONE OPTION-DATA MUST contain a standard uncompressed wire-format - name in the format specified by [RFC1035] Section 3.3. Wildcards are - not permitted in ZONE option records. - - - -Expires April 2001 [Page 2] - -INTERNET-DRAFT ZONE and VIEW option records October 2000 - - - When a server receives a query with a ZONE option record, it MUST - reply with a REFUSED reply if it understands the ZONE record but is - not configured to allow ZONE specific requests, if the specified zone - does not exist on the server, or if the client is not authorized to - use the ZONE option. If the ZONE option is allowed, it MUST return a - normally formatted reply with a ZONE optional record, containing the - same zone as the one queried. When replying to AXFR or IXFR queries - with ZONE options, the entire zone, including out-of-zone glue, - should be returned to the client. - - Servers SHOULD treat ZONE options in zone transfer requests as an - unauthorized request and return REFUSED. - -3.2 - VIEW option record - - The VIEW OPTION-RECORD contains an arbitrary length text field, which - is used to match the name of the view in the server's configuration. - - When a server receives a query with a VIEW option record, it MUST - reply with a REFUSED reply if it understands the VIEW record but is - not configured to allow VIEW specific requests, the specified view - does not exist, or the client is not authorized to access the - specified view. If a VIEW option is allowed, it MUST return a - normally formatted reply with a VIEW optional record containing the - same view as the one queried. The information used in generating the - reply should contain only information from the specified view of the - DNS space. - -4 - IANA considerations - - We request IANA assign option codes for the ZONE and VIEW options. - -5 - Security considerations - - This document provides a mechanism for users to override the default - behavior of the server when accessing data from its internal zone - databases. Software developers and administrators should use some - care when enabling these options, as they may provide outside users - the ability to retrieve information otherwise not available. - -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. - - - - -Expires April 2001 [Page 3] - -INTERNET-DRAFT ZONE and VIEW option records October 2000 - - - [RFC2119] S. Brander, ``Key words for use in RFCs to Indicate - Requirement Levels,'' RFC 2119, ISI, November 1997. - - [RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC - 2671, ISI, August, 1999 - - -Author's Address - - Michael Sawyer - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - Phone: +1-650-779-6021 - michael.sawyer@nominum.com - - Brian Wellington - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - Phone: +1-650-779-6022 - brian.wellington@nominum.com - - Michael Graff - Nominum, Inc. - 950 Charter St. - Redwood City, CA 94063 - Phone: +1-650-779-6034 - michael.graff@nominum.com - - - - - - - - - - - - - - - - - - - - - - -Expires April 2001 [Page 4] - diff --git a/doc/draft/draft-sawyer-dnsext-edns0-zone-option-01.txt b/doc/draft/draft-sawyer-dnsext-edns0-zone-option-01.txt new file mode 100644 index 0000000000..f6b561c8eb --- /dev/null +++ b/doc/draft/draft-sawyer-dnsext-edns0-zone-option-01.txt @@ -0,0 +1,21 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +B. Wellington: brian.wellington@nominum.com +M. Sawyer: michael.sawyer@nominum.com +M. Graff: michael.graff@nominum.com + +