diff options
Diffstat (limited to 'doc/rfc/rfc2825.txt')
| -rw-r--r-- | doc/rfc/rfc2825.txt | 395 |
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc2825.txt b/doc/rfc/rfc2825.txt new file mode 100644 index 0000000..fd8ef7c --- /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]
+
|