396 lines
16 KiB
Plaintext
396 lines
16 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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]
|
||
|