Sync usage with man page.

[netbsd-mini2440.git] / external / bsd / bind / dist / doc / rfc / rfc2825.txt

\r
\r
\r
\r
\r
\r
Network Working Group                  Internet Architecture Board (IAB)\r
Request for Comments: 2825                             L. Daigle, Editor\r
Category: Informational                                         May 2000\r
\r
\r
         A Tangled Web: Issues of I18N, Domain Names, and the\r
                        Other Internet protocols\r
\r
Status of this Memo\r
\r
   This memo provides information for the Internet community.  It does\r
   not specify an Internet standard of any kind.  Distribution of this\r
   memo is unlimited.\r
\r
Copyright Notice\r
\r
   Copyright (C) The Internet Society (2000).  All Rights Reserved.\r
\r
Abstract\r
\r
   The goals of the work to "internationalize" Internet protocols\r
   include providing all users of the Internet with the capability of\r
   using their own language and its standard character set to express\r
   themselves, write names, and to navigate the network. This impacts\r
   the domain names visible in e-mail addresses and so many of today's\r
   URLs used to locate information on the World Wide Web, etc.  However,\r
   domain names are used by Internet protocols that are used across\r
   national boundaries. These services must interoperate worldwide, or\r
   we risk isolating components of the network from each other along\r
   locale boundaries.  This type of isolation could impede not only\r
   communications among people, but opportunities of the areas involved\r
   to participate effectively in e-commerce, distance learning, and\r
   other activities at an international scale, thereby retarding\r
   economic development.\r
\r
   There are several proposals for internationalizing domain names,\r
   however it it is still to be determined whether any of them will\r
   ensure this interoperability and global reach while addressing\r
   visible-name representation.  Some of them obviously do not. This\r
   document does not attempt to review any specific proposals, as that\r
   is the work of the Internationalized Domain Name (IDN) Working Group\r
   of the IETF, which is tasked with evaluating them in consideration of\r
   the continued global network interoperation that is the deserved\r
   expectation of all Internet users.\r
\r
\r
\r
\r
\r
\r
\r
IAB                          Informational                      [Page 1]\r
\f\r
RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000\r
\r
\r
   This document is a statement by the Internet Architecture Board. It\r
   is not a protocol specification, but an attempt to clarify the range\r
   of architectural issues that the internationalization of domain names\r
   faces.\r
\r
1. A Definition of Success\r
\r
   The Internationalized Domain Names (IDN) Working Group is one\r
   component of the IETF's continuing comprehensive effort to\r
   internationalize language representation facilities in the protocols\r
   that support the global functioning of the Internet.\r
\r
   In keeping with the principles of rough consensus, running code,\r
   architectural integrity, and in the interest of ensuring the global\r
   stability of the Internet, the IAB emphasizes that all solutions\r
   proposed to the (IDN) Working Group will have to be evaluated not\r
   only on their individual technical features, but also in terms of\r
   impact on existing standards and operations of the Internet and the\r
   total effect for end-users: solutions must not cause users to become\r
   more isolated from their global neighbors even if they appear to\r
   solve a local problem.  In some cases, existing protocols have\r
   limitations on allowable characters, and in other cases\r
   implementations of protocols used in the core of the Internet (beyond\r
   individual organizations) have in practice not implemented all the\r
   requisite options of the standards.\r
\r
2. Technical Challenges within the Domain Name System (DNS)\r
\r
   In many technical respects, the IDN work is not different from any\r
   other effort to enable multiple character set representations in\r
   textual elements that were traditionally restricted to English\r
   language characters.\r
\r
   One aspect of the challenge is to decide how to represent the names\r
   users want in the DNS in a way that is clear, technically feasible,\r
   and ensures that a name always means the same thing.  Several\r
   proposals have been suggested to address these issues.\r
\r
   These issues are being outlined in more detail in the IDN WG's\r
   evolving draft requirements document; further discussion is deferred\r
   to the WG and its documents.\r
\r
3. Integrating with Current Realities\r
\r
   Nevertheless, issues faced by the IDN working group are complex and\r
   intricately intertwined with other operational components of the\r
   Internet.  A key challenge in evaluating any proposed solution is the\r
   analysis of the impact on existing critical operational standards\r
\r
\r
\r
IAB                          Informational                      [Page 2]\r
\f\r
RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000\r
\r
\r
   which use fully-qualified domain names [RFC1034], or simply host\r
   names [RFC1123].  Standards-changes can be effected, but the best\r
   path forward is one that takes into account current realities and\r
   (re)deployment latencies. In the Internet's global context, it is not\r
   enough to update a few isolated systems, or even most of the systems\r
   in a country or region.  Deployment must be nearly universal in order\r
   to avoid the creation of "islands" of interoperation that provide\r
   users with less access to and connection from the rest of the world.\r
\r
   These are not esoteric or ephemeral concerns.  Some specific issues\r
   have already been identified as part of the IDN WG's efforts.  These\r
   include (but are not limited to) the following examples.\r
\r
3.1 Domain Names and E-mail\r
\r
   As indicated in the IDN WG's draft requirements document, the issue\r
   goes beyond standardization of DNS usage.  Electronic mail has long\r
   been one of the most-used and most important applications of the\r
   Internet.  Internet e-mail is also used as the bridge that permits\r
   the users of a variety of local and proprietary mail systems to\r
   communicate. The standard protocols that define its use (e.g., SMTP\r
   [RFC821, RFC822] and MIME [RFC2045]) do not permit the full range of\r
   characters allowed in the DNS specification. Certain characters are\r
   not allowed in e-mail address domain portions of these\r
   specifications.  Some mailers, built to adhere to these\r
   specifications, are known to fail when on mail having non-ASCII\r
   domain names in its address -- by discarding, misrouting or damaging\r
   the mail.  Thus, it's not possible to simply switch to\r
   internationalized domain names and expect global e-mail to continue\r
   to work until most of the servers in the world are upgraded.\r
\r
3.2 Domain Names and Routing\r
\r
   At a lower level, the Routing Policy Specification Language (RPLS)\r
   [RFC2622] makes use of "named objects" -- and inherits object naming\r
   restrictions from older standards ([RFC822] for the same e-mail\r
   address restrictions, [RFC1034] for hostnames).  This means that\r
   until routing registries and their protocols are updated, it is not\r
   possible to enter or retrieve network descriptions utilizing\r
   internationalized domain names.\r
\r
3.3 Domain Names and Network Management\r
\r
   Also, the Simple Network Management Protocol (SNMP) uses the textual\r
   representation defined in [RFC2579].  While that specification does\r
   allow for UTF-8-based domain names, an informal survey of deployed\r
   implementations of software libraries being used to build SNMP-\r
   compliant software uncovered the fact that few (if any) implement it.\r
\r
\r
\r
IAB                          Informational                      [Page 3]\r
\f\r
RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000\r
\r
\r
   This may cause inability to enter or display correct data in network\r
   management tools, if such names are internationalized domain names.\r
\r
3.4 Domain Names and Security\r
\r
   Critical components of Internet public key technologies (PKIX,\r
   [RFC2459], IKE [RFC2409]) rely heavily on identification of servers\r
   (hostnames, or fully qualified domain names) and users (e-mail\r
   addresses).  Failure to respect the character restrictions in these\r
   protocols will impact security tools built to use them -- Transport\r
   Layer Security protocol (TLS, [RFC2246]), and IPsec [RFC2401] to name\r
   two.\r
\r
   Failure may not be obvious.  For example, in TLS, it is common usage\r
   for a server to display a certificate containing a domain name\r
   purporting to be the domain name of the server, which the client can\r
   then match with the server name he thought he used to reach the\r
   service.\r
\r
   Unless comparison of domain names is properly defined, the client may\r
   either fail to match the domain name of a legitimate server, or match\r
   incorrectly the domain name of a server performing a man-in-the-\r
   middle attack.  Either failure could enable attacks on systems that\r
   are now impossible or at least far more difficult.\r
\r
4. Conclusion\r
\r
   It is therefore clear that, although there are many possible ways to\r
   assign internationalized names that are compatible with today's DNS\r
   (or a version that is easily-deployable in the near future), not all\r
   of them are compatible with the full range of necessary networking\r
   tools.  When designing a solution for internationalization of domain\r
   names, the effects on the current Internet must be carefully\r
   evaluated. Some types of solutions proposed would, if put into effect\r
   immediately, cause Internet communications to fail in ways that would\r
   be hard to detect by and pose problems for those who deploy the new\r
   services, but also for those who do not; this would have the effect\r
   of cutting those who deploy them off from effective use of the\r
   Internet.\r
\r
   The IDN WG has been identified as the appropriate forum for\r
   identifying and discussing solutions for such potential\r
   interoperability issues.\r
\r
   Experience with deployment of other protocols has indicated that it\r
   will take years before a new protocol or enhancement is used all over\r
   the Internet.  So far, the IDN WG has benefited from proposed\r
   solutions from all quarters, including organizations hoping to\r
\r
\r
\r
IAB                          Informational                      [Page 4]\r
\f\r
RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000\r
\r
\r
   provide services that address visible-name representation and\r
   registration -- continuing this process with the aim of getting a\r
   single, scalable and deployable solution to this problem is the only\r
   way to ensure the continued global interoperation that is the\r
   deserved expectation of all Internet users.\r
\r
5. Security Considerations\r
\r
   In general, assignment and use of names does not raise any special\r
   security problems.  However, as noted above, some existing security\r
   mechanisms are reliant on the current specification of domain names\r
   and may not be expected to work, as is, with Internationalized domain\r
   names.  Additionally, deployment of non-standard systems (e.g., in\r
   response to current pressures to address national or regional\r
   characterset representation) might result in name strings that are\r
   not globally unique, thereby opening up the possibility of "spoofing"\r
   hosts from one domain in another, as described in [RFC2826].\r
\r
6. Acknowledgements\r
\r
   This document is the outcome of the joint effort of the members of\r
   the IAB.  Additionally, valuable remarks were provided by Randy Bush,\r
   Patrik Faltstrom, Ted Hardie, Paul Hoffman, and Mark Kosters.\r
\r
7. References\r
\r
   [RFC821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC\r
             821, August 1982.\r
\r
   [RFC822]  Crocker, D., "Standard for the Format of ARPA Internet Text\r
             Messages", STD 11, RFC 822, August 1982.\r
\r
   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",\r
             STD 13, RFC 1034, November 1987.\r
\r
   [RFC1123] Braden, R., "Requirements for Internet Hosts -- Application\r
             and Support", STD 3, RFC 1123, November 1989.\r
\r
   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the\r
             Internet Protocol", RFC 2401, November 1998.\r
\r
   [RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange\r
             (IKE)", RFC 2409, November 1998.\r
\r
   [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail\r
             Extensions (MIME) Part One:  Format of Internet Message\r
             Bodies", RFC 2045, November 1996.\r
\r
\r
\r
\r
IAB                          Informational                      [Page 5]\r
\f\r
RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000\r
\r
\r
   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",\r
             RFC 2246, January 1999.\r
\r
   [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet\r
             X.509 Public Key Infrastructure Certificate and CRL\r
             Profile", RFC 2459, January 1999.\r
\r
   [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.\r
             and M. Rose, "Textual Conventions for SMIv2", RFC 2579,\r
             April 1999.\r
\r
   [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,\r
             Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra,\r
             "Routing Policy Specification Language (RPSL)", RFC 2622,\r
             June 1999.\r
\r
   [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC\r
             2826, May 2000.\r
\r
8. Author's Address\r
\r
   Internet Architecture Board\r
\r
   EMail:  iab@iab.org\r
\r
\r
   Membership at time this document was completed:\r
\r
      Harald Alvestrand\r
      Ran Atkinson\r
      Rob Austein\r
      Brian Carpenter\r
      Steve Bellovin\r
      Jon Crowcroft\r
      Leslie Daigle\r
      Steve Deering\r
      Tony Hain\r
      Geoff Huston\r
      John Klensin\r
      Henning Schulzrinne\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
IAB                          Informational                      [Page 6]\r
\f\r
RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000\r
\r
\r
9. Full Copyright Statement\r
\r
   Copyright (C) The Internet Society (2000).  All Rights Reserved.\r
\r
   This document and translations of it may be copied and furnished to\r
   others, and derivative works that comment on or otherwise explain it\r
   or assist in its implementation may be prepared, copied, published\r
   and distributed, in whole or in part, without restriction of any\r
   kind, provided that the above copyright notice and this paragraph are\r
   included on all such copies and derivative works.  However, this\r
   document itself may not be modified in any way, such as by removing\r
   the copyright notice or references to the Internet Society or other\r
   Internet organizations, except as needed for the purpose of\r
   developing Internet standards in which case the procedures for\r
   copyrights defined in the Internet Standards process must be\r
   followed, or as required to translate it into languages other than\r
   English.\r
\r
   The limited permissions granted above are perpetual and will not be\r
   revoked by the Internet Society or its successors or assigns.\r
\r
   This document and the information contained herein is provided on an\r
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
\r
Acknowledgement\r
\r
   Funding for the RFC Editor function is currently provided by the\r
   Internet Society.\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
\r
IAB                          Informational                      [Page 7]\r
\f\r