contrib/bind9/doc/rfc/rfc2825.txt

   1 \r
   2 \r
   3 \r
   4 \r
   5 \r
   6 \r
   7 Network Working Group                  Internet Architecture Board (IAB)\r
   8 Request for Comments: 2825                             L. Daigle, Editor\r
   9 Category: Informational                                         May 2000\r
  10 \r
  11 \r
  12          A Tangled Web: Issues of I18N, Domain Names, and the\r
  13                         Other Internet protocols\r
  14 \r
  15 Status of this Memo\r
  16 \r
  17    This memo provides information for the Internet community.  It does\r
  18    not specify an Internet standard of any kind.  Distribution of this\r
  19    memo is unlimited.\r
  20 \r
  21 Copyright Notice\r
  22 \r
  23    Copyright (C) The Internet Society (2000).  All Rights Reserved.\r
  24 \r
  25 Abstract\r
  26 \r
  27    The goals of the work to "internationalize" Internet protocols\r
  28    include providing all users of the Internet with the capability of\r
  29    using their own language and its standard character set to express\r
  30    themselves, write names, and to navigate the network. This impacts\r
  31    the domain names visible in e-mail addresses and so many of today's\r
  32    URLs used to locate information on the World Wide Web, etc.  However,\r
  33    domain names are used by Internet protocols that are used across\r
  34    national boundaries. These services must interoperate worldwide, or\r
  35    we risk isolating components of the network from each other along\r
  36    locale boundaries.  This type of isolation could impede not only\r
  37    communications among people, but opportunities of the areas involved\r
  38    to participate effectively in e-commerce, distance learning, and\r
  39    other activities at an international scale, thereby retarding\r
  40    economic development.\r
  41 \r
  42    There are several proposals for internationalizing domain names,\r
  43    however it it is still to be determined whether any of them will\r
  44    ensure this interoperability and global reach while addressing\r
  45    visible-name representation.  Some of them obviously do not. This\r
  46    document does not attempt to review any specific proposals, as that\r
  47    is the work of the Internationalized Domain Name (IDN) Working Group\r
  48    of the IETF, which is tasked with evaluating them in consideration of\r
  49    the continued global network interoperation that is the deserved\r
  50    expectation of all Internet users.\r
  51 \r
  52 \r
  53 \r
  54 \r
  55 \r
  56 \r
  57 \r
  58 IAB                          Informational                      [Page 1]\r
  59 \f\r
  60 RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000\r
  61 \r
  62 \r
  63    This document is a statement by the Internet Architecture Board. It\r
  64    is not a protocol specification, but an attempt to clarify the range\r
  65    of architectural issues that the internationalization of domain names\r
  66    faces.\r
  67 \r
  68 1. A Definition of Success\r
  69 \r
  70    The Internationalized Domain Names (IDN) Working Group is one\r
  71    component of the IETF's continuing comprehensive effort to\r
  72    internationalize language representation facilities in the protocols\r
  73    that support the global functioning of the Internet.\r
  74 \r
  75    In keeping with the principles of rough consensus, running code,\r
  76    architectural integrity, and in the interest of ensuring the global\r
  77    stability of the Internet, the IAB emphasizes that all solutions\r
  78    proposed to the (IDN) Working Group will have to be evaluated not\r
  79    only on their individual technical features, but also in terms of\r
  80    impact on existing standards and operations of the Internet and the\r
  81    total effect for end-users: solutions must not cause users to become\r
  82    more isolated from their global neighbors even if they appear to\r
  83    solve a local problem.  In some cases, existing protocols have\r
  84    limitations on allowable characters, and in other cases\r
  85    implementations of protocols used in the core of the Internet (beyond\r
  86    individual organizations) have in practice not implemented all the\r
  87    requisite options of the standards.\r
  88 \r
  89 2. Technical Challenges within the Domain Name System (DNS)\r
  90 \r
  91    In many technical respects, the IDN work is not different from any\r
  92    other effort to enable multiple character set representations in\r
  93    textual elements that were traditionally restricted to English\r
  94    language characters.\r
  95 \r
  96    One aspect of the challenge is to decide how to represent the names\r
  97    users want in the DNS in a way that is clear, technically feasible,\r
  98    and ensures that a name always means the same thing.  Several\r
  99    proposals have been suggested to address these issues.\r
 100 \r
 101    These issues are being outlined in more detail in the IDN WG's\r
 102    evolving draft requirements document; further discussion is deferred\r
 103    to the WG and its documents.\r
 104 \r
 105 3. Integrating with Current Realities\r
 106 \r
 107    Nevertheless, issues faced by the IDN working group are complex and\r
 108    intricately intertwined with other operational components of the\r
 109    Internet.  A key challenge in evaluating any proposed solution is the\r
 110    analysis of the impact on existing critical operational standards\r
 111 \r
 112 \r
 113 \r
 114 IAB                          Informational                      [Page 2]\r
 115 \f\r
 116 RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000\r
 117 \r
 118 \r
 119    which use fully-qualified domain names [RFC1034], or simply host\r
 120    names [RFC1123].  Standards-changes can be effected, but the best\r
 121    path forward is one that takes into account current realities and\r
 122    (re)deployment latencies. In the Internet's global context, it is not\r
 123    enough to update a few isolated systems, or even most of the systems\r
 124    in a country or region.  Deployment must be nearly universal in order\r
 125    to avoid the creation of "islands" of interoperation that provide\r
 126    users with less access to and connection from the rest of the world.\r
 127 \r
 128    These are not esoteric or ephemeral concerns.  Some specific issues\r
 129    have already been identified as part of the IDN WG's efforts.  These\r
 130    include (but are not limited to) the following examples.\r
 131 \r
 132 3.1 Domain Names and E-mail\r
 133 \r
 134    As indicated in the IDN WG's draft requirements document, the issue\r
 135    goes beyond standardization of DNS usage.  Electronic mail has long\r
 136    been one of the most-used and most important applications of the\r
 137    Internet.  Internet e-mail is also used as the bridge that permits\r
 138    the users of a variety of local and proprietary mail systems to\r
 139    communicate. The standard protocols that define its use (e.g., SMTP\r
 140    [RFC821, RFC822] and MIME [RFC2045]) do not permit the full range of\r
 141    characters allowed in the DNS specification. Certain characters are\r
 142    not allowed in e-mail address domain portions of these\r
 143    specifications.  Some mailers, built to adhere to these\r
 144    specifications, are known to fail when on mail having non-ASCII\r
 145    domain names in its address -- by discarding, misrouting or damaging\r
 146    the mail.  Thus, it's not possible to simply switch to\r
 147    internationalized domain names and expect global e-mail to continue\r
 148    to work until most of the servers in the world are upgraded.\r
 149 \r
 150 3.2 Domain Names and Routing\r
 151 \r
 152    At a lower level, the Routing Policy Specification Language (RPLS)\r
 153    [RFC2622] makes use of "named objects" -- and inherits object naming\r
 154    restrictions from older standards ([RFC822] for the same e-mail\r
 155    address restrictions, [RFC1034] for hostnames).  This means that\r
 156    until routing registries and their protocols are updated, it is not\r
 157    possible to enter or retrieve network descriptions utilizing\r
 158    internationalized domain names.\r
 159 \r
 160 3.3 Domain Names and Network Management\r
 161 \r
 162    Also, the Simple Network Management Protocol (SNMP) uses the textual\r
 163    representation defined in [RFC2579].  While that specification does\r
 164    allow for UTF-8-based domain names, an informal survey of deployed\r
 165    implementations of software libraries being used to build SNMP-\r
 166    compliant software uncovered the fact that few (if any) implement it.\r
 167 \r
 168 \r
 169 \r
 170 IAB                          Informational                      [Page 3]\r
 171 \f\r
 172 RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000\r
 173 \r
 174 \r
 175    This may cause inability to enter or display correct data in network\r
 176    management tools, if such names are internationalized domain names.\r
 177 \r
 178 3.4 Domain Names and Security\r
 179 \r
 180    Critical components of Internet public key technologies (PKIX,\r
 181    [RFC2459], IKE [RFC2409]) rely heavily on identification of servers\r
 182    (hostnames, or fully qualified domain names) and users (e-mail\r
 183    addresses).  Failure to respect the character restrictions in these\r
 184    protocols will impact security tools built to use them -- Transport\r
 185    Layer Security protocol (TLS, [RFC2246]), and IPsec [RFC2401] to name\r
 186    two.\r
 187 \r
 188    Failure may not be obvious.  For example, in TLS, it is common usage\r
 189    for a server to display a certificate containing a domain name\r
 190    purporting to be the domain name of the server, which the client can\r
 191    then match with the server name he thought he used to reach the\r
 192    service.\r
 193 \r
 194    Unless comparison of domain names is properly defined, the client may\r
 195    either fail to match the domain name of a legitimate server, or match\r
 196    incorrectly the domain name of a server performing a man-in-the-\r
 197    middle attack.  Either failure could enable attacks on systems that\r
 198    are now impossible or at least far more difficult.\r
 199 \r
 200 4. Conclusion\r
 201 \r
 202    It is therefore clear that, although there are many possible ways to\r
 203    assign internationalized names that are compatible with today's DNS\r
 204    (or a version that is easily-deployable in the near future), not all\r
 205    of them are compatible with the full range of necessary networking\r
 206    tools.  When designing a solution for internationalization of domain\r
 207    names, the effects on the current Internet must be carefully\r
 208    evaluated. Some types of solutions proposed would, if put into effect\r
 209    immediately, cause Internet communications to fail in ways that would\r
 210    be hard to detect by and pose problems for those who deploy the new\r
 211    services, but also for those who do not; this would have the effect\r
 212    of cutting those who deploy them off from effective use of the\r
 213    Internet.\r
 214 \r
 215    The IDN WG has been identified as the appropriate forum for\r
 216    identifying and discussing solutions for such potential\r
 217    interoperability issues.\r
 218 \r
 219    Experience with deployment of other protocols has indicated that it\r
 220    will take years before a new protocol or enhancement is used all over\r
 221    the Internet.  So far, the IDN WG has benefited from proposed\r
 222    solutions from all quarters, including organizations hoping to\r
 223 \r
 224 \r
 225 \r
 226 IAB                          Informational                      [Page 4]\r
 227 \f\r
 228 RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000\r
 229 \r
 230 \r
 231    provide services that address visible-name representation and\r
 232    registration -- continuing this process with the aim of getting a\r
 233    single, scalable and deployable solution to this problem is the only\r
 234    way to ensure the continued global interoperation that is the\r
 235    deserved expectation of all Internet users.\r
 236 \r
 237 5. Security Considerations\r
 238 \r
 239    In general, assignment and use of names does not raise any special\r
 240    security problems.  However, as noted above, some existing security\r
 241    mechanisms are reliant on the current specification of domain names\r
 242    and may not be expected to work, as is, with Internationalized domain\r
 243    names.  Additionally, deployment of non-standard systems (e.g., in\r
 244    response to current pressures to address national or regional\r
 245    characterset representation) might result in name strings that are\r
 246    not globally unique, thereby opening up the possibility of "spoofing"\r
 247    hosts from one domain in another, as described in [RFC2826].\r
 248 \r
 249 6. Acknowledgements\r
 250 \r
 251    This document is the outcome of the joint effort of the members of\r
 252    the IAB.  Additionally, valuable remarks were provided by Randy Bush,\r
 253    Patrik Faltstrom, Ted Hardie, Paul Hoffman, and Mark Kosters.\r
 254 \r
 255 7. References\r
 256 \r
 257    [RFC821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC\r
 258              821, August 1982.\r
 259 \r
 260    [RFC822]  Crocker, D., "Standard for the Format of ARPA Internet Text\r
 261              Messages", STD 11, RFC 822, August 1982.\r
 262 \r
 263    [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",\r
 264              STD 13, RFC 1034, November 1987.\r
 265 \r
 266    [RFC1123] Braden, R., "Requirements for Internet Hosts -- Application\r
 267              and Support", STD 3, RFC 1123, November 1989.\r
 268 \r
 269    [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the\r
 270              Internet Protocol", RFC 2401, November 1998.\r
 271 \r
 272    [RFC2409] Harkins, D and D. Carrel, "The Internet Key Exchange\r
 273              (IKE)", RFC 2409, November 1998.\r
 274 \r
 275    [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail\r
 276              Extensions (MIME) Part One:  Format of Internet Message\r
 277              Bodies", RFC 2045, November 1996.\r
 278 \r
 279 \r
 280 \r
 281 \r
 282 IAB                          Informational                      [Page 5]\r
 283 \f\r
 284 RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000\r
 285 \r
 286 \r
 287    [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",\r
 288              RFC 2246, January 1999.\r
 289 \r
 290    [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet\r
 291              X.509 Public Key Infrastructure Certificate and CRL\r
 292              Profile", RFC 2459, January 1999.\r
 293 \r
 294    [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.\r
 295              and M. Rose, "Textual Conventions for SMIv2", RFC 2579,\r
 296              April 1999.\r
 297 \r
 298    [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,\r
 299              Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra,\r
 300              "Routing Policy Specification Language (RPSL)", RFC 2622,\r
 301              June 1999.\r
 302 \r
 303    [RFC2826] IAB, "IAB Technical Comment on the Unique DNS Root", RFC\r
 304              2826, May 2000.\r
 305 \r
 306 8. Author's Address\r
 307 \r
 308    Internet Architecture Board\r
 309 \r
 310    EMail:  iab@iab.org\r
 311 \r
 312 \r
 313    Membership at time this document was completed:\r
 314 \r
 315       Harald Alvestrand\r
 316       Ran Atkinson\r
 317       Rob Austein\r
 318       Brian Carpenter\r
 319       Steve Bellovin\r
 320       Jon Crowcroft\r
 321       Leslie Daigle\r
 322       Steve Deering\r
 323       Tony Hain\r
 324       Geoff Huston\r
 325       John Klensin\r
 326       Henning Schulzrinne\r
 327 \r
 328 \r
 329 \r
 330 \r
 331 \r
 332 \r
 333 \r
 334 \r
 335 \r
 336 \r
 337 \r
 338 IAB                          Informational                      [Page 6]\r
 339 \f\r
 340 RFC 2825   Issues: I18N, Domain Names, and Internet Protocols   May 2000\r
 341 \r
 342 \r
 343 9. Full Copyright Statement\r
 344 \r
 345    Copyright (C) The Internet Society (2000).  All Rights Reserved.\r
 346 \r
 347    This document and translations of it may be copied and furnished to\r
 348    others, and derivative works that comment on or otherwise explain it\r
 349    or assist in its implementation may be prepared, copied, published\r
 350    and distributed, in whole or in part, without restriction of any\r
 351    kind, provided that the above copyright notice and this paragraph are\r
 352    included on all such copies and derivative works.  However, this\r
 353    document itself may not be modified in any way, such as by removing\r
 354    the copyright notice or references to the Internet Society or other\r
 355    Internet organizations, except as needed for the purpose of\r
 356    developing Internet standards in which case the procedures for\r
 357    copyrights defined in the Internet Standards process must be\r
 358    followed, or as required to translate it into languages other than\r
 359    English.\r
 360 \r
 361    The limited permissions granted above are perpetual and will not be\r
 362    revoked by the Internet Society or its successors or assigns.\r
 363 \r
 364    This document and the information contained herein is provided on an\r
 365    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
 366    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
 367    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
 368    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
 369    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
 370 \r
 371 Acknowledgement\r
 372 \r
 373    Funding for the RFC Editor function is currently provided by the\r
 374    Internet Society.\r
 375 \r
 376 \r
 377 \r
 378 \r
 379 \r
 380 \r
 381 \r
 382 \r
 383 \r
 384 \r
 385 \r
 386 \r
 387 \r
 388 \r
 389 \r
 390 \r
 391 \r
 392 \r
 393 \r
 394 IAB                          Informational                      [Page 7]\r
 395 \f\r