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