mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-30 05:57:52 +00:00
Code Issues Releases Wiki Activity

updated drafts

Browse Source
This commit is contained in:
Andreas Gustafsson 2001-04-27 17:54:21 +00:00
parent ecaedd50f4
commit 5bca09d7c1
27 changed files with 2007 additions and 7082 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

657
doc/draft/draft-costanzo-dns-gl-03.txt
View File

@ -1,657 +0,0 @@
INTERNET-DRAFT A. Costanzo
draft-costanzo-dns-gl-03.txt AKC Computer Services Corp.
Expires: December 2000 June 2000
Definition of the DNS GL Resource Record
used to encode Geographic Locations
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 except that the right to produce
derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast, or ftp.isi.edu
(US West Coast).
Distribution of this memo is unlimited.
2. Abstract
This document defines the format of a new Experimental Resource Record (RR)
namely GL for the Domain Naming System (DNS), and reserves a corresponding
DNS type mnemonic and numerical code XX (decimal). This definition deals
with associating geographical host location mappings to host names within
a domain.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Costanzo [Page 1]
EXPIRES IN SIX MONTHS June 2000
3. Introduction
The ideal way to manage and maintain a database of information, such as
geographical location of Internet hosts, is to delegate responsibility
to local domain administrators.
This document resolves the problem of relating host information within
the DNS to geographical locations. This definition has been designed to
be easy for the person who administrates DNS for a domain. The author
hopes that the lack of requiring longitude, latitude and elevation
information and merely being able to enter address information, as you
would address a postal letter, will mean broad acceptance and use of the
GL resource record.
The availability of geographical location information will immediately be
able to benefit applications in network management, which would enhance
and supplement various network tools which currently exist.
The Domain Name System is ideally suited to provide geographic location
information. The information we desire to make available globally needs
to be maintained and updated locally (perfect for DNS).
Although several other attempts by various authors have attempted to
created resource records that would allow location information on host to
be stored and distributed, none, to the authors knowledge, have either
gained acceptance on a wide scale or made allowance for location information
that is not within the confines of the planet Earth.
4. The GL format
GL has the following format:
<owner> <ttl> <class> GL <Rdata>
4.1 Rdata Format
Rdata has the following format:
<string> <string>
The format of the RDATA field is two varying length strings separated by
a space character. The first, the hierarchical locator, then an address
string. Each is quoted (like all strings) only when it has spaces in it,
which will never be true for the first string, and almost always for the
second.
Costanzo [Page 2]
EXPIRES IN SIX MONTHS June 2000
4.1.1 The Hierarchical Locator
The Hierarchical Locator contains the following components (each separated
by a period "."):
Astronomical Location - (Required)
A coded field defining the heavenly body within
the known Universe, where the machine resides. The most common
entry, "S3" is the planet Earth and is the only currently
defined location.
Man-made devices (Space Stations, Rockets, Probes, etc.) not residing
on planet Earth may have Astronimical Locations defined as well.
New locations MUST be registered with the Internet Assigned Numbers
Authority (IANA). Refer to section 6 for additional information.
Country Code - (Required)
The country code specifies the country the host computer resides
in. The code is a two character fixed length string and may only
be included within the Astronimical Location 'S3'. These codes
are defined in document ISO 3166-1 and are listed in Appendix A
for easy reference.
Postal Zone - (Optional)
This rdata component supplies the postal code (Zip Code) for the
location the host computer resides. For countries that have a
multi-segmented postal coding system, the segments should be
separated by period(s) ".".
This field may be omitted only if the country in which the host
machine resides does not use a postal coding system.
When all three Hierarchical Locator components exist for an DNS
entry, the position being defined is considered to be a "precise
position".
4.2 The Quoted String
This string should be entered as you would enter an address on
a postal letter within the country specified by the Hierarchical
Locator. The country code information should not be included within
the quoted string. This string is always required and must be
present in the RDATA field.
The quoted string may be used for both visual reference of the
physical address as well as by a software application to help
determine a more precise location of the host machine (if the
Hierarchical Locator lacks sufficient precision).
Costanzo [Page 3]
EXPIRES IN SIX MONTHS June 2000
The only instance in which any application should attempt to
interpret the quoted string is in a case where the country
code defines a country that does not use, or has not implemented
a postal code system.
No software or application should attempt to override a precise
position defined by the Hierarchical Locator with information
defined within the quoted string data.
5. Example(s)
Example 1 (with a postal zone defined):
donuts A 192.188.192.1
GL S3.US.45420.1910 "1425 Arbor Avenue, Dayton OH"
Example 2 (no postal zone):
lorinda A 129.122.1.1
GL S3.SR "Marthastrasse 64, Shawproject, Uitvlug, Parimaribo"
Example 3
; Authoritative data for akc.net.
;
; note in this example:
; uspring, diana and martha (even though the complete postal code was
; not entered) are precisely defined
;
; lorinda, resides in the country of SURINAME, which has not implemented
; a postal coding system.
;
; THIS IS ONLY AN EXAMPLE
;
@ IN SOA forme.akc.net. postmaster.akc.net.
(
99071100 ; Serial (yymmddnn)
10800 ; Refresh (3 hours)
3600 ; Retry (1 hour)
3600000 ; Expire (1000 hours)
86400 ; Minimum (24 hours)
)
IN NS ns.akc.net.
uspring IN A 192.188.192.2
IN MX 5 mail
IN HINFO Vax VMS
IN GL S3.US.45420.1910 "1425 Arbor Avenue, Dayton OH"
ftp IN CNAME uspring
Costanzo [Page 4]
EXPIRES IN SIX MONTHS June 2000
diana IN A 192.188.192.3
IN MX 5 mail
IN HINFO Vax VMS
IN GL S3.US.07204.1367 "808 Chestnut Street, Roselle
Park, NJ"
www IN CNAME diana
martha IN A 192.188.192.4
IN MX 5 mail
IN HINFO Vax VMS
IN GL S3.US.07204 "815 Chestnut Willis Place, Roselle
Park, NJ"
lorinda IN A 129.122.1.1
IN GL S3.SR "Marthastrasse 64, Shawproject, Uitvlug,
Parimaribo"
6. Registering New Astronomical Location(s)
New Astronomical Locations (ALs) MUST be registered with the Internet
Assigned Numbers Authority (IANA). IANA acts as a central registry for
these values. IANA may reject or modify the Astronomical Location
registration request if it does not meet the criteria as specified in
section 4.1.1.
Registration requests should be sent via electronic mail to IANA as
follows:
To: IANA@iana.org
Subject: Registration of a new Astronomical Location
The mail message must specify the proposed AL. Documentation defining
the AL and its proposed purpose must be included. The documentation must
either reference an external non-Internet standards document or an existing
or soon to be RFC. If applicable, the documentation should contain a
draft version of the future RFC. The draft must be submitted as a
RFC according to the normal procedure within a reasonable amount of
time after the AL registration has been approved.
IANA will not register a new Astronmical Location until an actual
computer requiring GL data in the DNS resides or will soon reside on a
heavenly body other than Earth.
Costanzo [Page 5]
EXPIRES IN SIX MONTHS May 2000
7. Notes To Implementors:
7.1 Defining New Astronimical Locations
The astronomical location 'S3' is intended to be Sol-Three (i.e. the Earth).
The Earth is the 3rd large planet in the solar system. The Sun would be S0
(not that we'd have a computer there), but a solar observatory in orbit might
be S0-001. Our moon would be S3-1. Other letters and such for catalogued
objects. Additionally, the ISS and Mir space stations could use S3-001 (Mir),
S3-002 (ISS) now, if they get connected on IP.
This document only defines 'S3' however the authors strongly suggest that the
above nomenclature be followed.
7.2 Other possible uses for GL
The use of postal codes also is exactly what is needed for credit card address
authentication. Sites could (quietly) compare GL info provided on entries from
ISPs to what someone enters for additional verification purposes.
Costanzo [Page 6]
EXPIRES IN SIX MONTHS June 2000
8. Appendix A: ISO 3166-1 Country Codes
The ISO country codes are merely listed here for easy reference and may
become out-of-date in this document. Any changes in the ISO specification
supercede this appendix and the ISO specification must be followed.
AFGHANISTAN AF
ALBANIA AL
ALGERIA DZ
AMERICAN SAMOA AS
ANDORRA AD
ANGOLA AO
ANGUILLA AI
ANTARCTICA AQ
ANTIGUA AND BARBUDA AG
ARGENTINA AR
ARMENIA AM
ARUBA AW
AUSTRALIA AU
AUSTRIA AT
AZERBAIJAN AZ
BAHAMAS BS
BAHRAIN BH
BANGLADESH BD
BARBADOS BB
BELARUS BY
BELGIUM BE
BELIZE BZ
BENIN BJ
BERMUDA BM
BHUTAN BT
BOLIVIA BO
BOSNIA AND HERZEGOWINA BA
BOTSWANA BW
BOUVET ISLAND BV
BRAZIL BR
BRITISH INDIAN OCEAN TERRITORY IO
BRUNEI DARUSSALAM BN
BULGARIA BG
BURKINA FASO BF
BURUNDI BI
CAMBODIA KH
CAMEROON CM
CANADA CA
CAPE VERDE CV
CAYMAN ISLANDS KY
CENTRAL AFRICAN REPUBLIC CF
CHAD TD
CHILE CL
CHINA CN
CHRISTMAS ISLAND CX
Costanzo [Page 7]
EXPIRES IN SIX MONTHS June 2000
COCOS (KEELING) ISLANDS CC
COLOMBIA CO
COMOROS KM
CONGO CG
COOK ISLANDS CK
COSTA RICA CR
COTE D'IVOIRE CI
CROATIA HR
CUBA CU
CYPRUS CY
CZECH REPUBLIC CZ
DENMARK DK
DJIBOUTI DJ
DOMINICA DM
DOMINICAN REPUBLIC DO
EAST TIMOR TP
ECUADOR EC
EGYPT EG
EL SALVADOR SV
EQUATORIAL GUINEA GQ
ERITREA ER
ESTONIA EE
ETHIOPIA ET
FALKLAND ISLANDS (MALVINAS) FK
FAROE ISLANDS FO
FIJI FJ
FINLAND FI
FRANCE FR
FRANCE, METROPOLITAN FX
FRENCH GUIANA GF
FRENCH POLYNESIA PF
FRENCH SOUTHERN TERRITORIES TF
GABON GA
GAMBIA GM
GEORGIA GE
GERMANY DE
GHANA GH
GIBRALTAR GI
GREECE GR
GREENLAND GL
GRENADA GD
GUADELOUPE GP
GUAM GU
GUATEMALA GT
GUINEA GN
GUINEA-BISSAU GW
GUYANA GY
HAITI HT
HEARD AND MC DONALD ISLANDS HM
HONDURAS HN
HONG KONG HK
HUNGARY HU
Costanzo [Page 8]
EXPIRES IN SIX MONTHS June 2000
ICELAND IS
INDIA IN
INDONESIA ID
IRAN (ISLAMIC REPUBLIC OF) IR
IRAQ IQ
IRELAND IE
ISRAEL IL
ITALY IT
JAMAICA JM
JAPAN JP
JORDAN JO
KAZAKHSTAN KZ
KENYA KE
KIRIBATI KI
KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF KP
KOREA, REPUBLIC OF KR
KUWAIT KW
KYRGYZSTAN KG
LAO PEOPLE'S DEMOCRATIC REPUBLIC LA
LATVIA LV
LEBANON LB
LESOTHO LS
LIBERIA LR
LIBYAN ARAB JAMAHIRIYA LY
LIECHTENSTEIN LI
LITHUANIA LT
LUXEMBOURG LU
MACAU MO
MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF MK
MADAGASCAR MG
MALAWI MW
MALAYSIA MY
MALDIVES MV
MALI ML
MALTA MT
MARSHALL ISLANDS MH
MARTINIQUE MQ
MAURITANIA MR
MAURITIUS MU
MAYOTTE YT
MEXICO MX
MICRONESIA (FEDERATED STATES OF) FM
MOLDOVA, REPUBLIC OF MD
MONACO MC
MONGOLIA MN
MONTSERRAT MS
MOROCCO MA
MOZAMBIQUE MZ
MYANMAR MM
NAMIBIA NA
NAURU NR
NEPAL NP
NETHERLANDS NL
NETHERLANDS ANTILLES AN
NEW CALEDONIA NC
Costanzo [Page 9]
EXPIRES IN SIX MONTHS June 2000
NEW ZEALAND NZ
NICARAGUA NI
NIGER NE
NIGERIA NG
NIUE NU
NORFOLK ISLAND NF
NORTHERN MARIANA ISLANDS MP
NORWAY NO
OMAN OM
PAKISTAN PK
PALAU PW
PANAMA PA
PAPUA NEW GUINEA PG
PARAGUAY PY
PERU PE
PHILIPPINES PH
PITCAIRN PN
POLAND PL
PORTUGAL PT
PUERTO RICO PR
QATAR QA
REUNION RE
ROMANIA RO
RUSSIAN FEDERATION RU
RWANDA RW
ST. HELENA SH
SAINT KITTS AND NEVIS KN
SAINT LUCIA LC
ST. PIERRE AND MIQUELON PM
SAINT VINCENT AND THE GRENADINES VC
SAMOA WS
SAN MARINO SM
SAO TOME AND PRINCIPE ST
SAUDI ARABIA SA
SENEGAL SN
SEYCHELLES SC
SIERRA LEONE SL
SINGAPORE SG
SLOVAKIA SK
SLOVENIA SI
SOLOMON ISLANDS SB
SOMALIA SO
SOUTH AFRICA ZA
SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS GS
SPAIN ES
SRI LANKA LK
SUDAN SD
SURINAME SR
SVALBARD AND JAN MAYEN ISLANDS SJ
SWAZILAND SZ
SWEDEN SE
SWITZERLAND CH
SYRIAN ARAB REPUBLIC SY
Costanzo [Page 10]
EXPIRES IN SIX MONTHS June 2000
TAIWAN, PROVINCE OF CHINA TW
TAJIKISTAN TJ
TANZANIA, UNITED REPUBLIC OF TZ
THAILAND TH
TOGO TG
TOKELAU TK
TONGA TO
TRINIDAD AND TOBAGO TT
TUNISIA TN
TURKEY TR
TURKMENISTAN TM
TURKS AND CAICOS ISLANDS TC
TUVALU TV
UGANDA UG
UKRAINE UA
UNITED ARAB EMIRATES AE
UNITED KINGDOM GB
UNITED STATES US
UNITED STATES MINOR OUTLYING ISLANDS UM
URUGUAY UY
UZBEKISTAN UZ
VANUATU VU
VATICAN CITY STATE (HOLY SEE) VA
VENEZUELA VE
VIET NAM VN
VIRGIN ISLANDS (BRITISH) VG
VIRGIN ISLANDS (U.S.) VI
WALLIS AND FUTUNA ISLANDS WF
WESTERN SAHARA EH
YEMEN YE
YUGOSLAVIA YU
ZAIRE ZR
ZAMBIA ZM
ZIMBABWE ZW
9. Acknowledgments
The author would like to thank
James Sears - for his continual editing effort
Robert Ullmann - for his input
and the members of the namedroppers mailing list for both their support and
criticism of this document.
10. Author's Address
Al Costanzo
AKC Computer Services Corp.
P.O. Box 4031, Roselle Park, NJ 07204-0531
www.AKC.com
Phone: +1 908 298 9000
Email: AL@AKC.COM
Costanzo [Page 11]

19
doc/draft/draft-costanzo-dns-gl-04.txt Normal file
View File

@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
A. Costanzo: al@akc.com

84
doc/draft/draft-ietf-dnsext-dnssec-okbit-01.txt → doc/draft/draft-ietf-dnsext-dnssec-okbit-02.txt
View File

@ -5,8 +5,8 @@
INTERNET-DRAFT David Conrad
draft-ietf-dnsext-dnssec-okbit-01.txt Nominum Inc.
November, 2000
draft-ietf-dnsext-dnssec-okbit-02.txt Nominum Inc.
May, 2001
Indicating Resolver Support of DNSSEC
@ -55,9 +55,9 @@ Abstract
Expires May, 2001 [Page 1]
Expires October, 2001 [Page 1]
draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000
draft-ietf-dnsext-dnssec-okbit-02.txt May, 2001
This document discusses a method to avoid these negative impacts,
@ -74,15 +74,15 @@ draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000
2. Rationale
As DNSSEC is deployed, the vast majority of queries will be from
resolvers that are not DNSSEC aware and thus do not understand or
support the DNSSEC security RRs. When a query from such a resolver
is received for a DNSSEC signed zone, the DNSSEC specification
indicates the nameserver must respond with the appropriate DNSSEC
security RRs. As DNS UDP datagrams are limited to 512 bytes
[RFC1035], responses including DNSSEC security RRs have a high
probability of resulting in a truncated response being returned and
the resolver retrying the query using TCP.
Initially, as DNSSEC is deployed, the vast majority of queries will
be from resolvers that are not DNSSEC aware and thus do not
understand or support the DNSSEC security RRs. When a query from
such a resolver is received for a DNSSEC signed zone, the DNSSEC
specification indicates the nameserver must respond with the
appropriate DNSSEC security RRs. As DNS UDP datagrams are limited to
512 bytes [RFC1035], responses including DNSSEC security RRs have a
high probability of resulting in a truncated response being returned
and the resolver retrying the query using TCP.
TCP DNS queries result in significant overhead due to connection
setup and teardown. Operationally, the impact of these TCP queries
@ -111,9 +111,9 @@ draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000
Expires May, 2001 [Page 2]
Expires October, 2001 [Page 2]
draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000
draft-ietf-dnsext-dnssec-okbit-02.txt May, 2001
non-compliant caching or forwarding servers inappropriately copy data
@ -167,9 +167,9 @@ draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000
Expires May, 2001 [Page 3]
Expires October, 2001 [Page 3]
draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000
draft-ietf-dnsext-dnssec-okbit-02.txt May, 2001
DNSSEC security RRs and SHOULD retry the query without the EDNS0 in
@ -182,16 +182,28 @@ Security Considerations
that zone as the response may be forged or a non-forged response of
an altered (DO bit cleared) query.
IANA Considerations
IANA considerations:
Allocation of the most significant bit of the Z field in the EDNS0
OPT meta-RR is required.
EDNS0[RFC2761] defines 16 bits as extened flags in the OPT record,
these bits are encoded into the TTL field of the OPT record (RFC2761
section 4.6).
This document reserves one of these bits as the OK bit. It is
requested that the left most bit be allocated. Thus the USE of the
OPT record TTL field would look like
+0 (MSB) +1 (LSB)
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0: | EXTENDED-RCODE | VERSION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2: |DO| Z |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Acknowledgements
This document is based on a rough draft by Bob Halley with input from
Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
Rob Austein, and Steve Bellovin.
Rob Austein, Steve Bellovin, and Erik Nordmark.
References
@ -208,6 +220,14 @@ References
2535, March 1999.
[RFC2671] Vixie, P., Extension Mechanisms for DNS (EDNS0)", RFC 2671,
Expires October, 2001 [Page 4]
draft-ietf-dnsext-dnssec-okbit-02.txt May, 2001
August 1999
Author's Address
@ -220,14 +240,6 @@ Author's Address
Phone: +1 650 779 6003
Expires May, 2001 [Page 4]
draft-ietf-dnsext-dnssec-okbit-01.txt November, 2000
Email: david.conrad@nominum.com
@ -267,17 +279,5 @@ Full Copyright Statement
Expires May, 2001 [Page 5]
Expires October, 2001 [Page 5]

172
doc/draft/draft-ietf-dnsext-dnssec-roadmap-02.txt → doc/draft/draft-ietf-dnsext-dnssec-roadmap-03.txt
View File

@ -6,7 +6,7 @@
DNEXT Working Group S. Rose
Internet Draft NIST
Expires: August 2001 February 2001
Expires: November 2001 April 2001
Category: Informational
@ -14,7 +14,7 @@ Category: Informational
DNS Security Document Roadmap
------------------------------
<draft-ietf-dnsext-dnssec-roadmap-02.txt>
<draft-ietf-dnsext-dnssec-roadmap-03.txt>
Status of this Document
@ -61,7 +61,7 @@ Rose [Page 1]
INTERNET-DRAFT DNS Security Document Roadmap February 2001
INTERNET-DRAFT DNS Security Document Roadmap April 2001
overview of what to find in which document and author
@ -120,7 +120,7 @@ Rose [Page 2]
INTERNET-DRAFT DNS Security Document Roadmap February 2001
INTERNET-DRAFT DNS Security Document Roadmap April 2001
1. Introduction
@ -180,7 +180,7 @@ Rose [Page 3]
INTERNET-DRAFT DNS Security Document Roadmap February 2001
INTERNET-DRAFT DNS Security Document Roadmap April 2001
possible that some documents fall into more than one of these
@ -207,11 +207,12 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001
| [RFC2538, | | [RFC2535, | | [SSH-DNS] |
| RFC2931, | | RFC3007, | +-------------+
| NO] | | RFC3008, |
+------------+ | CLARIFY, |
+------------+ | RFC3090, |
| SIZE ] |
| OKBIT, |
| ADBIT, |
| OPTIN ] |
| OPTIN, |
| PARSIG ] |
+-----------+
|
|
@ -233,14 +234,13 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001
Rose [Page 4]
INTERNET-DRAFT DNS Security Document Roadmap February 2001
INTERNET-DRAFT DNS Security Document Roadmap April 2001
The "DNSSEC protocol" document set refers to the document that makes
@ -258,8 +258,9 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001
lines of RFC/Internet Draft author guidelines). Also, the portions
of the specification to be modified SHOULD be synopsized in the new
document for the benefit of the reader. The "DNSSEC protocol" set
includes the documents [RFC2535], [RFC3007], [RFC3008], [CLARIFY],
[SIZE], [OKBIT], [ADBIT] and their derivative documents.
includes the documents [RFC2535], [RFC3007], [RFC3008], [RFC3090],
[SIZE], [OKBIT], [ADBIT], [OPTIN], [PARSIG] and their derivative
documents.
The "New Security RRs" set refers to the group of documents that seek
to add additional Resource Records to the set of base DNS Record
@ -289,8 +290,7 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001
vidual user public keys (PGP, e-mail, etc.) Some documents in this
group may fall beyond the DNSEXT WG scope, but they are included
because of their use of the security extensions. The documents in
this group should not propose any changes to the DNS protocol to sup-
port other protocols; only how existing DNS security records and
this group should not propose any changes to the DNS protocol to
@ -300,9 +300,10 @@ Rose [Page 5]
INTERNET-DRAFT DNS Security Document Roadmap February 2001
INTERNET-DRAFT DNS Security Document Roadmap April 2001
support other protocols; only how existing DNS security records and
transactions can be used to support other protocols. One such docu-
ment is [SSH-DNS] which deals with storing SSH keys in the DNS using
the security records.
@ -318,8 +319,8 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001
two Internet Drafts that fall under this category: the report on the
CAIRN DNSSEC testbed [CAIRN] and a draft on security key rollover
[ROLLOVER]. These documents were submitted through the DNSOP Working
Group, however the main concern of thesee documents is the implemen-
tation and limitations of the DNS security extensions, hence their
Group, however the main concern of these documents is the implementa-
tion and limitations of the DNS security extensions, hence their
interest to the DNS security community. The CAIRN draft deals with
the implementation of a secure DNS, and the draft on key rollover
deals with updating DNS keys in a secure fashion. Authors of docu-
@ -345,12 +346,11 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001
col to add security should follow common guidelines as to minimum
required content and structure. It is the purpose of this document
roadmap to establish criteria for content that any new DNS security
protocol specifications document SHOULD contain. This criteria
protocol specifications document SHOULD contain. These criteria
SHOULD be interpreted as a minimum set of information required/needed
in a document, any additional information regarding the specific
extension should also be included in the document. These criteria
are not officially part of the IETF guidelines regarding RFC/Internet
Drafts, but should be considered as guidance to promote uniformity to
@ -360,9 +360,10 @@ Rose [Page 6]
INTERNET-DRAFT DNS Security Document Roadmap February 2001
INTERNET-DRAFT DNS Security Document Roadmap April 2001
Drafts, but should be considered as guidance to promote uniformity to
Working Group documents.
Since the addition of security to the DNS protocol is now considered
@ -409,8 +410,7 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001
In addition, authors are encouraged to include any necessary descrip-
tion of the algorithm itself, as well as any know/suspected
weaknesses as an appendix to the document. This is for reference
only, as the goals of the DNSEXT working group is to propose exten-
sions to the DNS protocol, not cryptographic research.
only, as the goals of the DNSEXT working group is to propose
@ -420,7 +420,10 @@ Rose [Page 7]
INTERNET-DRAFT DNS Security Document Roadmap February 2001
INTERNET-DRAFT DNS Security Document Roadmap April 2001
extensions to the DNS protocol, not cryptographic research.
4.3 Refinement of Security Procedures
@ -468,9 +471,6 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001
6. Acknowledgements
In addition to the RFCs mentioned in this document, there are also
numerous Internet drafts that fall in one or more of the categories
of DNS Security documents mentioned above. Depending on where (and
if) these documents are on the IETF standards track, the reader may
@ -480,41 +480,44 @@ Rose [Page 8]
INTERNET-DRAFT DNS Security Document Roadmap February 2001
INTERNET-DRAFT DNS Security Document Roadmap April 2001
numerous Internet drafts that fall in one or more of the categories
of DNS Security documents mentioned above. Depending on where (and
if) these documents are on the IETF standards track, the reader may
not be able to access these documents through the RFC repositories.
For that reason, the version of the Internet drafts that were refer-
enced in this document are given below:
All of these documents are "Work in Progress" and are subject to
change, therefore a version number is not supplied for the current
revision.
* SIGALG: R. Austein, P. Vixie. "DNS SIGALGOPT". <draft-ietf-
dnsind-sigalgopt-00.txt>
* CLARIFY: E. Lewis. "DNS Security Extension Clarification on Zone
Status" <draft-ietf-dnsext-zone-status-05.txt>
* AUTH: B. Wellington. "Domain Name System Security (DNSSEC)
Signing Authority" <draft-ietf-dnsext-signing-auth-01.txt>
dnsind-sigalgopt-NN.txt>
* CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC Implementa-
tion in the CAIRN Testbed". <draft-ietf-dnsop-dnsseccairn-00.txt>
tion in the CAIRN Testbed". <draft-ietf-dnsop-dnsseccairn-NN.txt>
* UPDATE: B. Wellington. "Secure Domain Name System (DNS) Dynamic
Update". <draft-ietf-simple-secure-update-02.txt>
Update". <draft-ietf-simple-secure-update-NN.txt>
* SIZE: O. Gudmundsson. "DNSSEC and IPv6 A6 aware server/resolver
message size requirements". <draft-ietf-dnsext-message-size-03.txt>
message size requirements". <draft-ietf-dnsext-message-size-NN.txt>
* GSS-TSIG: S. Kwan, P. Garg, J. Gilroy, and L. Esibov. "GSS
Algorithm for TSIG (GSS-TSIG)". <draft-ietf-dnsext-gss-tsig-01.txt>
Algorithm for TSIG (GSS-TSIG)". <draft-ietf-dnsext-gss-tsig-NN.txt>
* NO: S. A. Josefsson. "Authenticating Denial of Existence in DNS
with Minimum Disclosure". <draft-ietf-dnsext-not-existing-rr-01.txt>
with Minimum Disclosure". <draft-ietf-dnsext-not-existing-rr-NN.txt>
* OKBIT: D. Conrad. "Indicting Resolver Support of DNSSEC".
<draft-ietf-dnsext-dnssec-okbit-01.txt>
<draft-ietf-dnsext-dnssec-okbit-NN.txt>
* RSA-SHA: D. Eastlake. "RSA/SHA-1 SIGs and RSA KEYs in the
Domain Name System (DNS)" <draft-ietf-dnsext-rsa-02.txt>
Domain Name System (DNS)" <draft-ietf-dnsext-rsa-NN.txt>
* ROLLOVER: M. Andrews, D. Eastlake. "Domain Name System (DNS)
Security Key Rollover" <draft-ietf-dnsopt-rollover-00.txt>.
Security Key Rollover" <draft-ietf-dnsopt-rollover-NN.txt>.
* ADBIT: B. Wellington. "Redefinition of DNS AD bit" <draft-
ietf-dnsext-ad-is-secure-01.txt>
ietf-dnsext-ad-is-secure-NN.txt>
* OPTIN: M. Kosters. "DNSSEC Opt-in for Large Zones" <draft-
kosters-dnsext-dnssec-opt-in-00.txt>
kosters-dnsext-dnssec-opt-in-NN.txt>
* SSH-DNS: W. Griffin. "Storing SSH Host Keys in DNS" <draft-
griffin-ssh-host-keys-in-dns-00.txt>
griffin-ssh-host-keys-in-dns-NN.txt>
* PARSIG: R. Geiben, T. Lindgreen. "Parent's SIG Over Child's
KEY" <draft-ietf-dnsext-parent-sig-NN.txt>
7. References
@ -528,9 +531,6 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001
(DNS)", RFC 2536, March 1999.
[RFC2137] D. Eastlake, "Secure Domain Name System Dynamic Update",
RFC 2137, April 1997.
[RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
@ -540,9 +540,12 @@ Rose [Page 9]
INTERNET-DRAFT DNS Security Document Roadmap February 2001
INTERNET-DRAFT DNS Security Document Roadmap April 2001
RFC 2137, April 1997.
[RFC2539] D. Eastlake, "Storage of Diffie-Hellman Keys in the Domain
Name System (DNS)", RFC 2539, March 1999.
[RFC2538] D. Eastlake, O. Gudmundsson, "Storing Certificates in the
@ -554,6 +557,9 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001
[RFC2931] D. Eastlake "DNS Request and Transaction Signatures
(SIG(0))" RFC 2931, September 2000.
[RFC3090] E. Lewis "DNS Security Extensions Clarification on Zone
Status" RFC 3090, March 2001.
[RFC1591] J. Postal, "Domain Name System Structure and Delegation",
RFC 1591, March 1994.
@ -588,19 +594,46 @@ INTERNET-DRAFT DNS Security Document Roadmap February 2001
Expiration and File Name:
This draft, titled <draft-ietf-dnsext-dnssec-roadmap-02.txt> expires June 2001
Rose [Page 10]
INTERNET-DRAFT DNS Security Document Roadmap February 2001
INTERNET-DRAFT DNS Security Document Roadmap April 2001
Expiration and File Name:
This draft, titled <draft-ietf-dnsext-dnssec-roadmap-03.txt> expires November
2001
Full Copyright Statement
@ -618,6 +651,18 @@ Full Copyright Statement
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
Rose [Page 11]
INTERNET-DRAFT DNS Security Document Roadmap April 2001
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
@ -654,6 +699,21 @@ Full Copyright Statement
Rose [Page 11]
Rose [Page 12]

558
doc/draft/draft-ietf-dnsext-ixfr-01.txt
View File

@ -1,558 +0,0 @@
INTERNET DRAFT M. Ohta
draft-ietf-dnsext-ixfr-01.txt Tokyo Institute of Technology
June 2000
Incremental Zone Transfer in DNS
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society (March/5/2000). All Rights
Reserved.
Abstract
This document proposes extensions to the DNS protocols to provide an
incremental zone transfer (IXFR) mechanism.
1. Introduction
For rapid propagation of changes to a DNS database [STD13], it is
necessary to reduce latency by actively notifying servers of the
change. This is accomplished by the NOTIFY extension of the DNS
[NOTIFY].
The current full zone transfer mechanism (AXFR) is not an efficient
means to propagate changes to a small part of a zone, as it transfers
the entire zone file.
Incremental transfer (IXFR) as proposed is a more efficient
mechanism, as it transfers only the changed portion(s) of a zone.
M. Ohta Expires on December 5, 2000 [Page 1]
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
In this document, a secondary name server which requests IXFR is
called an IXFR client and a primary or secondary name server which
responds to the request is called an IXFR server.
The current AXFR specification in [STD13] is very terse, and in
practice it does not contain sufficient information to construct
interoperable implementations. This memo assumes AXFR protocol used
in existing interoperable implementations.
2. Brief Description of the Protocol
If an IXFR client, which likely has an older version of a zone,
thinks it needs new information about the zone (typically through SOA
refresh timeout or the NOTIFY mechanism), it sends an IXFR message
containing the SOA serial number of its, presumably outdated, copy of
the zone.
An IXFR server should keep record of the newest version of the zone
and the differences between that copy and several older versions.
When an IXFR request with an older version number is received, the
IXFR server needs to send only the differences required to make that
version current. Alternatively, the server may choose to transfer
the entire zone just as in a normal full zone transfer.
When a zone has been updated, it should be saved in stable storage
before the new version is used to respond to IXFR (or AXFR) queries.
Otherwise, if the server crashes, data which is no longer available
may have been distributed to secondary servers, which can cause
persistent database inconsistencies.
If an IXFR query with the same or newer version number than that of
the server is received, it is replied to with a single SOA record of
the server's current version, just as a SOA query before TCP AXFR.
Transport of a query may be by either UDP or TCP. If an IXFR query
is via UDP, the IXFR server may attempt to reply using UDP if the
entire response can be contained in a single UDP packet. If the UDP
reply does not fit, the query is responded to with a single SOA
record of the server's current version to inform the client that a
TCP query should be initiated.
Thus, a client should first make an IXFR query using UDP. If the
query type or other part of the query is not recognized by the
server, an AXFR (preceded by a UDP SOA query) should be tried,
ensuring backward compatibility. If the query response is a single
packet with the entire new zone, or if the server does not have a
newer version than the client, everything is done. Otherwise, a TCP
IXFR query should be tried.
M. Ohta Expires on December 5, 2000 [Page 2]
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
To ensure integrity, servers should use UDP checksums for all UDP
responses. A cautious client which receives a UDP packet with a
checksum value of zero should ignore the result and try a TCP IXFR
instead.
The query type value of IXFR assigned by IANA is 251.
3. Query Format
The IXFR query packet format is the same as that of a normal DNS
query, but with the query type being IXFR and the authority section
containing the SOA record of client's version of the zone.
4. Response Format
If incremental zone transfer is not available, the entire zone is
returned. The first and the last RR of the response is the SOA
record of the zone. I.e. the behavior is the same as an AXFR
response except the query type is IXFR.
If incremental zone transfer is available, one or more difference
sequences is returned. The list of difference sequences is preceded
and followed by a copy of the server's current version of the SOA.
Each difference sequence represents one update to the zone (one SOA
serial change) consisting of deleted RRs and added RRs. The first RR
of the deleted RRs is the older SOA RR and the first RR of the added
RRs is the newer SOA RR.
Modification of an RR is performed first by removing the original RR
and then adding the modified one.
Each individual difference sequence must leave the zone in a
consistent state with contents identical to those visible in the
master at the time identified by the new SOA serial number. During a
transfer, the slave server may save the zone data to stable storage
and use it in responding to queries after applying one or more
complete difference sequences even if they do not yet form a complete
incremental transfer.
A difference sequence which indicates the removal of a non-existent
RR is an indication of an error that the IXFR client is out-of-sync
with the IXFR server. The IXFR SHOULD be aborted, and an AXFR
requested from the same server. A difference sequence which
indicates the addition of a seemingly duplicate (though a node may
have multiple TXT RR's with duplicate content) or conflicting RR may
just be a malformed zone. In any case the IXFR should be aborted and
AXFR performed.
M. Ohta Expires on December 5, 2000 [Page 3]
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
The sequences of differential information are ordered oldest first
newest last. Thus, the differential sequences are the history of
changes made since the version known by the IXFR client up to the
server's current version.
RR sets (RRs of the same RR types) in the incremental transfer
messages may be partial. For example, if a single RR of multiple RRs
of the same RR type changes, only the changed RR needs to be
transferred.
An IXFR client, should only replace an older version with a newer
version after all the differences have been successfully processed.
An incremental response is different from that of a non-incremental
response in that it begins with two SOA RRs, the server's current SOA
followed by the SOA of the client's version which is about to be
replaced.
A slave receiving an IXFR response needs to classify it as one of the
following four cases:
UDP-overflow An indication that the transfer will not fit in a
UDP packet and should be retried over TCP
up-to-date An indication that the serial number of the
request is current and no transfer is necessary
incremental An incremental transfer
nonincremental A full zone transfer
Performing this classification requires some care. For example,
UDP-overflow responses differ from UDP up-to-date responses only in
the value of the SOA serial number. Also, to distinguish between a
nonincremental and an incremental transfer, the slave needs to
receive the first two response RRs and check whether the second one
is a SOA. If the master chose to transmit each RR in a separate TCP
message, this involves waiting for a second TCP response message. On
the other hand, in the case of an up-to-date response, the slave must
not wait for a second TCP message as doing so would cause it to hang
waiting for a message the master will never send. Therefore, the
slave must examine the first message and eliminate the possibility
that it is a TCP up-to-date response before it attempts to receive a
second message.
Slaves must not attempt to classify a response based on incidental
information such as the presence or absence of a question section,
the QTYPE field of a possible question section, or the number of
M. Ohta Expires on December 5, 2000 [Page 4]
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
response RRs in a TCP response message.
An example algorithm for classifying IXFR responses appears in
Appendix A.
5. Purging Strategy
An IXFR server can not be required to hold all previous versions
forever and may delete them anytime. In general, there is a trade-
off between the size of storage space and the possibility of using
IXFR.
Information about older versions should be purged if the total length
of an IXFR response would be longer than that of an AXFR response.
Given that the purpose of IXFR is to reduce AXFR overhead, this
strategy is quite reasonable. The strategy assures that the amount
of storage required is at most twice that of the current zone
information.
Information older than the SOA expire period should also be purged.
6. Optional Condensation of Multiple Versions
An IXFR server may optionally condense multiple difference sequences
into a single difference sequence, thus, dropping information on
intermediate versions.
This may be beneficial if a lot of versions, not all of which are
useful, are generated. For example, if multiple ftp servers share a
single DNS name and the IP address associated with the name is
changed once a minute to balance load between the ftp servers, it is
not so important to keep track of all the history of changes.
But, this feature may not be so useful if an IXFR client has access
to two IXFR servers: A and B, with inconsistent condensation results.
The current version of the IXFR client, received from server A, may
be unknown to server B. In such a case, server B can not provide
incremental data from the unknown version and a full zone transfer is
necessary.
Condensation is completely optional. Clients can't detect from the
response whether the server has condensed the reply or not.
For interoperability, IXFR servers, including those without the
condensation feature, should not flag an error even if it receives a
client's IXFR request with a version number known not to exist (which
means that the server has versions with version numbers newer and
older than, but not equal to, the version number) and should,
M. Ohta Expires on December 5, 2000 [Page 5]
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
instead, attempt to perform a full zone transfer by replying with a
single SOA record of the server's current version (UDP case) or with
a full zone content (UDP or TCP case).
7. Example
Given the following three generations of data with the current serial
number of 3,
example.domain. IN SOA ns.example.domain. rt.example.domain. (
1 600 600 3600000 604800)
IN NS ns.example.domain.
ns.example.domain. IN A 10.0.0.1
ftp.example.domain. IN A 10.0.1.1
ftp.example.domain. is removed and www.example.domain. is added.
example.domain. IN SOA ns.example.domain. rt.example.domain. (
2 600 600 3600000 604800)
IN NS ns.example.domain.
ns.example.domain. IN A 10.0.0.1
www.example.domain. IN A 10.0.1.2
IN A 10.0.2.1
One of the IP addresses of www.example.domain. is changed.
example.domain. IN SOA ns.example.domain. rt.example.domain. (
3 600 600 3600000 604800)
IN NS ns.example.domain.
ns.example.domain. IN A 10.0.0.1
www.example.domain. IN A 10.0.3.1
IN A 10.0.2.1
The following IXFR query
+---------------------------------------------------+
Header | OPCODE=SQUERY |
+---------------------------------------------------+
Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | <empty> |
+---------------------------------------------------+
Authority | example.domain. IN SOA serial=1 |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
could be replied to with the following full zone transfer message:
M. Ohta Expires on December 5, 2000 [Page 6]
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | example.domain. IN SOA serial=3 |
| example.domain. IN NS NS.JAIN.AD.JP. |
| ns.example.domain. IN A 10.0.0.1 |
| www.example.domain. IN A 10.0.3.1 |
| www.example.domain. IN A 10.0.2.1 |
| example.domain. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
or with the following incremental message:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | example.domain. IN SOA serial=3 |
| example.domain. IN SOA serial=1 |
| ftp.example.domain. IN A 10.0.1.1 |
| example.domain. IN SOA serial=2 |
| www.example.domain. IN A 10.0.1.2 |
| www.example.domain. IN A 10.0.2.1 |
| example.domain. IN SOA serial=2 |
| www.example.domain. IN A 10.0.1.2 |
| example.domain. IN SOA serial=3 |
| www.example.domain. IN A 10.0.3.1 |
| example.domain. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
or with the following condensed incremental message:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
M. Ohta Expires on December 5, 2000 [Page 7]
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
Answer | example.domain. IN SOA serial=3 |
| example.domain. IN SOA serial=1 |
| ftp.example.domain. IN A 10.0.1.1 |
| example.domain. IN SOA serial=3 |
| www.example.domain. IN A 10.0.3.1 |
| www.example.domain. IN A 10.0.2.1 |
| example.domain. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
or, if UDP packet overflow occurs, with the following message:
+---------------------------------------------------+
Header | OPCODE=SQUERY, RESPONSE |
+---------------------------------------------------+
Question | QNAME=example.domain., QCLASS=IN, QTYPE=IXFR |
+---------------------------------------------------+
Answer | example.domain. IN SOA serial=3 |
+---------------------------------------------------+
Authority | <empty> |
+---------------------------------------------------+
Additional | <empty> |
+---------------------------------------------------+
8. Acknowledgements
The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
and Jon Postel.
For the refinement of the protocol and documentation, many people
have contributed including, but not limited to, Anant Kumar, Robert
Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz, Andreas
Gustafsson, Josh Littlefield, Olafur Gudmundsson, William King and
the members of the IETF DNSEXT working group.
9. References
[NOTIFY] Vixie, P., "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC1996, August 1996.
[STD13] Mockapetris, P., "Domain Name System" (RFC1034 and RFC1035),
November 1987.
10. Appendix A Appendix A. Pseudocode for response classification
M. Ohta Expires on December 5, 2000 [Page 8]
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
The following pseudocode outlines one possible algorithm for
classifying IXFR responses.
receive the first response message;
extract the first response RR, always an SOA;
if (the serial number of this SOA RR is less
than or equal to that of the request) {
the response is an up-to-date response;
} else {
if (the response message was received by UDP and
contains no more RRs after the initial SOA) {
the response is a UDP-overflow response;
} else {
extract the second response RR, waiting for a second TCP
response message if necessary;
if (this second RR is an SOA) {
the response is an incremental transfer;
} else {
the response is a nonincremental transfer;
}
}
}
11. Security Considerations
Though DNS is related to several security problems, no attempt is
made to fix them in this document.
This document is believed to introduce no additional security
problems to the current DNS protocol.
12. Author's Address
Masataka Ohta
Computer Center, Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku, Tokyo 152-8550, JAPAN
Phone: +81-3-5734-3299, Fax: +81-3-5734-3415
EMail: mohta@necom830.hpcl.titech.ac.jp
Comments should be directed to DNSEXT WG <namedroppers@ops.ietf.org>.
M. Ohta Expires on December 5, 2000 [Page 9]
INTERNET DRAFT Incremental Zone Transfer in DNS June 2000
13. Full Copyright Statement
"Copyright (C) The Internet Society (March/5/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.
M. Ohta Expires on December 5, 2000 [Page 10]

19
doc/draft/draft-ietf-dnsext-ixfr-02.txt Normal file
View File

@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
M. Ohta: mohta@necom830.hpcl.titech.ac.jp

1596
doc/draft/draft-ietf-enum-e164s2-np-00.txt
View File

File diff suppressed because it is too large Load Diff

19
doc/draft/draft-ietf-enum-e164s2-np-01.txt Normal file
View File

@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
A. Gallant: andrew.gallant@comsat.com

342
doc/draft/draft-ietf-enum-rqmts-01.txt
View File

@ -1,342 +0,0 @@
Telephone Number Mapping A. Brown
Internet Draft Nortel Networks
Document: <draft-ietf-enum-rqmts-01.txt> June 2000
Category: Informational
ENUM Requirements
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This paper defines the requirements for a DNS-based architecture and
protocols for mapping a telephone number to a set of attributes
(e.g., URLs) that can be used to contact a resource associated with
that number. There are many possible protocols that can be
considered for a telephone number mapping service. The purpose of
this document is to focus discussion on a DNS-based solution. The
intention is to enumerate the expectations of such a solution and to
clarify the scope.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
3. Requirements
3.1 Endpoint Address Lookup
The system SHALL provide a service for the retrieval of service
specific endpoint addresses (e.g., email address, IP address, SIP
address, URL, etc.) or the retrieval of the addresses of servers, if
available, which may contain this endpoint information.
ENUM Requirements June 2000
3.2 Capabilities Retrieval/Negotiation
The retrieval or negotiation of capabilities is beyond the scope of
the system.
3.3 Retrieval of Additional Information and Capabilities
The retrieval of additional, application-specific information (e.g.,
spoken name for verification purposes) is beyond the scope of the
system. The system MUST provide a service for the retrieval of
protocol and service information if available.
The system SHOULD provide access to capabilities relevant to the
telephone number in question. The retrieval or negotiation of
capabilities will depend on the outcome of the rescap work or work
done in other groups.
3.4 Qualification of the Request
The system is not required to enable the qualification of a request
by a user, for the purposes of filtering for reducing returned
information or for traffic reduction.
3.5 Provisioning
The architecture and protocol MAY support at least the existing
administrative model as the current E.164 telephone number
delegation system. The protocol SHOULD also provide the ability to
support corporate numbering plan or competitive directory service
providers under separate root domains. It SHOULD NOT require an
additional centralized administrator beyond that required for the
existing telephone number system.
The distribution of telephone numbers is a national affair by ITU
treaty and different telephone number distribution schemes may
require different delegation models. How nations choose to
administer the ENUM space within their borders is a national issue.
In any case, the subscriber or enterprise is the ultimate authority
for service provisioning.
Further, it must be possible for the authority to which a telephone
number has been delegated to redirect the query to a different
entity that provides service-specific information for that number.
3.6 Propagation of Changes
Propagation of Changes If multiple copies of the data are
distributed in different areas, their update should be incorporated
almost simultaneously depending on the application of DNS to
services.
ENUM Requirements June 2000
When a numbering plan change is made in a country or network, the
update of relevant E.164 number data in DNS needs to be coordinated
with the change.
3.7 Response Timeout
The system SHALL have a defined timeout mechanism.
3.8 Global Number Portability
The system MUST support existing local number portability
mechanisms, where applicable. It is RECOMMENDED that the system not
be designed in such as way as to impede future global number
portability.
3.9 Scalability
The system MUST scale to handle quantities of telephone numbers and
queries comparable to current and expected future PSTN usage.
It must be possible to operate the system based on telephone number
blocks defined at the digit boundaries as well as explicit per-
number configuration.
3.10 Query Performance
It SHOULD be possible to administer the ENUM service using the
selected protocols and structures such that the current user
expectations for latency in telecommunications services can be met.
In particular, it SHOULD be possible to operate the system in such a
manner that an ENUM query for a service-specific record can be
satisfied within one second 95% of the time and that within two
seconds, the query can be satisfied 99% of the time.
3.11 Other PSTN Numbering Services
E.164 numbers, short codes, service codes and prefixes are
categorized in dialing plans. A prefix is an indicator consisting
of one or more digits that allows the selection of different types
of number formats, networks and/or services. Prefixes are not part
of the number and are part of a dialing plan. The uses and the
formats of prefixes are a national matter. Short codes, e.g.
emergency, or service codes may be used based on the national
numbering plan. Those codes are not universal and typically valid
only within a numbering domain identified with the same country code
or country code + network identification code.
PSTN type numbering services such as Emergency 911, directory
assistance 411, and other carrier codes for services accessible via
non-E164 (or subset) telephone number service access codes are
outside the scope of ENUM.
3.12 Privacy
ENUM Requirements June 2000
The system MUST allow the owner of the telephone number to control
the information which prospective callers may receive.
3.13 Competition
The solution MUST permit competing service providers to offer
telecommunications service for a given number. Competing
telecommunications services MUST be enabled where the ENUM entry is
administered by the single entity to which the number is delegated.
Who that single entity is, is beyond the scope of ENUM.
3.14 Authorization of Requests and Responses
The system SHALL enable the authorization of requests and responses.
3.15 Privacy and Integrity of Requests and Responses
The system SHALL enable the privacy and integrity of requests and
responses.
3.16 Call Routing
The system is not required to provide a service for routing calls or
locating gateways to a specific service.
3.17 Service Logic
The system is not responsible for employing service logic for the
intelligent retrieval of information.
3.18 E.164 Numbers
The system is not responsible for returning information on private
numbering plans and non-E.164 numbers. The system is responsible
for returning information on 1-800 and other legitimate E.164
numbers.
3.19 Application Specific Use of ENUM
The ENUM service MUST be application agnostic. It is expected that
various other IETF work groups will develop ENUM specific usage
profiles for their specific application. ENUM will not mandate the
use of any specific DNS Resource Record for any particular
application.
4. Security Considerations
This document specifies several security requirements including
privacy of information, and authorization, privacy and integrity or
requests and responses.
ENUM Requirements June 2000
The system will be designed to retrieve information required to
initiate an Internet telephony session. Each of these session types
will have their own security threats, which should be addressed in
the groups responsible for those services.
5. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
6. Acknowledgements
This document is based on discussions from the ENUM working group.
7. Author's Addresses
Anne Brown
Nortel Networks
P.O. Box 3511, Station C
K1Y 4H7
Phone: +1 613 765 5274
Email: arbrown@nortelnetworks.com
8. Changes From draft-enum-rqmts-00.txt
Based on WG discussions and input documents from the SG2 workshop,
the following changes have been made since the previous version of
this draft:
3.1 Endpoint Address Lookup
Major - URLs are not the only response
3.3 Retrieval of Additional Information and Capabilities
Renamed from "Retrieval of Additional Information"
Minor - Added paragraph on capabilities
3.5 Provisioning
Major - New text involving change of ENUM scope
3.6 Propagation of Changes
New section
Major - New section based on nnar-e164-dns-iw-info.txt
3.9 Scalability
Renumbered from 3.8
Major - New paragraph on handling of both blocks and
individual telephone numbers.
3.10 Query Performance
Renumbered from 3.9
Major - Upgraded to support PSTN performance
expectations
3.11 Other PSTN Numbering Services
Renumbered from 3.10
ENUM Requirements June 2000
Renamed from "Other PSTN Services"
Minor - Changes for clarification based on WG
discussions and nnar-e164-dns-iw-info.txt
3.13 Competition
Renumbered from 3.12
Major - Telephone number MUST be able to be
administered by a single entity
3.19 Application Specific Use of ENUM
New Section
Major - For clarification
Full Copyright Statement
"Copyright (C) The Internet Society (date). 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 implmentation 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

19
doc/draft/draft-ietf-enum-rqmts-02.txt Normal file
View File

@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
A. Brown: arbrown@nortel.ca

90
doc/draft/draft-ietf-idn-cjk-00.txt → doc/draft/draft-ietf-idn-cjk-01.txt
View File

@ -1,7 +1,7 @@
Internet Draft James SENG
<draft-ietf-idn-cjk-00.txt> Yoshiro YONEYA
12th Sep 2000 Kenny HUANG
Expires 12 Mar 2001 KIM Kyongsok
<EFBFBD>©ÀInternet Draft James SENG
<draft-ietf-idn-cjk-01.txt> Yoshiro YONEYA
11th Apr 2001 Kenny HUANG
Expires 11 Oct 2001 KIM Kyongsok
Han Ideograph (CJK) for Internationalized Domain Names
@ -54,11 +54,6 @@ for reference for the ideograph described.
Han ideographs are defined as the Chinese ideographs starting from
U+3400 to U+9FFF or commonly known as CJK Unification Ideographs. This
Expires 12th March 2001 [Page 1]
Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001
covers Chinese 'hanzi' {U+6F22 U+5B57/U+6C49 U+5B57}, Japanese 'kanji'
(U+6F22 U+5B57) and Korean 'hanja' {U+6F22 U+5B57/U+D55C U+C790}.
Additional Han ideographs will appear in other location (not necessary
@ -113,11 +108,6 @@ points in Unicode.
Chinese ideographs or hanzi {U+6F22 U+5B57/U+6C49 U+5B57} originated
from pictograph. They are 'pictures' which evolved into ideographs
during several thousand years. For instance, the ideograph for "hill"
Expires 12th March 2001 [Page 2]
Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001
{U+5C71} still bears some resembles to 3 peaks of a hill.
Not all ideographs are pictograph. There are other classifications such
@ -172,11 +162,6 @@ match with TC {U+81FA U+5F4E} or TC {U+53F0 U+5F4E}.
The side effect of this method is that comparing SC {U+53D1} to TC
{U+667C} or TC {U+9AEE} will both be positive. This implies that SC
'hair' SC …ñ³…Åæ {U+5934 U+53D1} will match TC
Expires 12th March 2001 [Page 3]
Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001
(U+982D U+9AEE). It will also match TC {U+982D U+9AEE} that does not
have any meaning in Chinese.
@ -231,11 +216,6 @@ the 5th century. Chinese ideographs in Japanese are known as 'kanji'
{U+6F22 U+5B57}. They also developed their own syllabary hiragana
{U+5E73 U+4EEE U+540D} (U+3040-U+309F) and katakana {U+7247 U+4EEE
U+540D} (U+30A0-U+30FF), both are derivative of kanji that has same
Expires 12th March 2001 [Page 4]
Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001
pronunciation. Hiragana is a simplified cursive form, for example, 'a'
{U+3042} was derived from 'an' {U+5B89}. Katakana is a simplified part
form, for example, 'a' {U+30A2} was derived from 'a' {U+963F}. However,
@ -290,11 +270,6 @@ Hence, Han folding here is not recommended.
4. Vietnamese
While Vietnamese also adopted Chinese ideographs ('chu han') and created
Expires 12th March 2001 [Page 5]
Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001
their own ideographs ('chu nom'), they were now replaced by romanized
'quoc ngu' today. Hence, this document does not attempt to address any
issues with 'chu han' or 'chu nom'.
@ -349,11 +324,6 @@ or removing radical from standard ideographs.
7. Mechanism
Expires 12th March 2001 [Page 6]
Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001
The implicit proposal in this document is that CJKV ideographs may or
may not be "folded" for the purposes of comparison of domain names.
@ -405,14 +375,6 @@ If conservative safety is really required, then
are made on x-axis characters, but the license of that domain name
can pick which y or z variants they wish to use..
Expires 12th March 2001 [Page 7]
Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001
Acknowledgement
The editor gratefully acknowledge the contributions of:
@ -424,7 +386,7 @@ Karlsson Kent <keka@im.se>
Author(s)
James SENG
James SENG ˆÄè†î¯…«Å
i-DNS.net International Pte Ltd.
8 Temasek Boulevard
Suntec Tower 3 #24-02
@ -439,7 +401,7 @@ Shinagawa IntercityBldg., B-13F
Email: yone@po.ntts.co.jp
Tel: +81-3-5782-7291
Kenny HUANG
Kenny HUANG ‰©â…雷¢ä
Geotempo International Ltd; TWNIC
3F, No 16 Kang Hwa Street, Nei Hu
Taipei 114, Taiwan
@ -468,11 +430,6 @@ References
[KANJIDIC] Sanseido‚ÇÖs Unicode Kanji Information Dictionary
ISBN 4-385-13690-4
Expires 12th March 2001 [Page 8]
Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001
[UNICHART] Unicode chart http://charts.unicode.org/
[ZONGBIAO] Simplified Characters Standard Chart 2nd Edition, 1986
@ -494,37 +451,4 @@ Internet Draft Han Ideograph (CJK) for IDN 12th Mar 2001
Vol. 14, No. 4, pp. 297-325, Aug. 1992.
[KimK 1999] A Hangeul story inside computers. KIM, Kyongsok. Busan
National University Press. 1999. [in Hangeul]
Expires 12th March 2001 [Page 9]
National University Press. 1999. [in Hangeul]

687
doc/draft/draft-ietf-idn-compare-01.txt
View File

@ -1,687 +0,0 @@
Internet Draft Paul Hoffman
draft-ietf-idn-compare-01.txt IMC & VPNC
July 11, 2000
Expires in six months
Comparison of Internationalized Domain Name Proposals
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The IDN Working Group is working on proposals for internationalized
domain names that might become a standard in the IETF. Before a single
full proposal can be made, competing proposals must be compared on a
wide range of requirements and desired features. This document compares
the many parts of a comprehensive protocol that have been proposed. It
is the companion document to "Requirements of Internationalized Domain
Names" [IDN-REQ], which lays out the requirements for the
internationalized domain name protocol.
1. Introduction
As the IDN Working Group has discussed the requirements for IDN,
suggestions have been made for various candidate protocols that might
meet the requirements. These proposals have been somewhat helpful in
bringing up real-world needs for the requirements.
It became clear no single proposal had wide agreement from the working
group. In fact, the authors of various proposals found themselves taking
some features from other proposals as they revised their drafts. At the
same time, working group participants were making suggestions for
incremental changes that might affect more than one proposal.
Because of this mixing and matching, it was decided that this IDN
comparisons document should compare features that might end up in the
final protocol, not full protocol suggestions themselves. The features
that had been discussed in the working group were divided by function,
and appear in this document in separate sections. For each function,
there are multiple suggestions for protocol elements that might meet the
requirements that are described in [IDN-REQ].
This document is being discussed on the "idn" mailing list. To join the
list, send a message to <majordomo@ops.ietf.org> with the words
"subscribe idn" in the body of the message. Archives of the mailing list
can also be found at ftp://ops.ietf.org/pub/lists/idn*.
1.1 Format of this document
Each section covers one feature that has been discussed as being part of
the final IDN solution. Within each section, alternate proposals are
listed with the major perceived pros and cons of the proposal. Also,
each proposal is given a label to make discussion of this document (and
of the proposals themselves) easier.
References to the numbered requirements in [IDN-REQ] are from version
-02 of that document. These numbers are expected to change and the
requirements document evolves. In this draft, the requirements are show
as "[#n-02]", where "n" is the requirement number from draft -02 of
[IDN-REQ]. This document only lists where particular proposals don't
meet particular requirmenents from [IDN-REQ], not the ones that they
fulfill.
Note that this document is supposed to reflect the discussion of all
proposed alternatives, not just the ones that fully match the
requirements in [IDN-REQ]. It will serve as a summary of the discussion
in the IDN WG for readers in the future who may want to know why certain
alternatives were not chosen for the eventual protocol.
The proposal drafts covered in this document are:
[DUERST] Character Normalization in IETF Protocols,
draft-duerst-i18n-norm-03
[IDNE] Internationalized domain names using EDNS (IDNE),
draft-ietf-idn-idne-01
[KWAN] Using the UTF-8 Character Set in the Domain Name System,
draft-skwan-utf8-dns-03
[RACE] RACE: Row-based ASCII Compatible Encoding for IDN,
draft-ietf-idn-race-00
[SENG] UTF-5, a transformation format of Unicode and ISO 10646,
draft-jseng-utf5-01
[UDNS] Using the Universal Character Set in the Domain Name System
(UDNS), draft-ietf-idn-udns-00
2. Architecture
One of the biggest questions raised early in the IDN discussion was what
the format of internationalized name parts would be on the wire, that
is, between the user's computer and the DNS resolvers. It was agreed
that the DNS protocols certainly allow non-ASCII octets in domain name
parts and resource records, but there was also acknowledgement that many
protocols that rely on the DNS could not handle non-ASCII names due to
the design of the protocol. Section 3.1 of this document describes the
proposed encodings for the non-ASCII name parts.
Because of requirement [#2-02], there were proposals for
ASCII-compatible encodings (ACEs) of non-ASCII characters. Different
ACEs were proposed (and are discussed in Section 4 of this document),
but they all have the same goal: to allow non-ASCII characters to be
represented in host names that conform to RFC 1034 [RFC1034].
2.1 arch-1: Just send binary
[KWAN] proposes beginning to send characters outside the range allowed
in RFC 1034.
Pro: Easiest to describe. Only changes host name syntax, not any of the
related DNS protocols.
Con: Doesn't work with many exiting protocols that relies on DNS.
Violates requirement [#9-02].
2.2 arch-2: Send binary or ACE
[UDNS] (and, later, [IDNE]) proposes using both binary and ACE formats
on the wire.
Pro: Allows protocols that can handle binary name parts to use them
directly, while allowing protocols that cannot use binary name parts to
also handle names without conversion. Allows domain names in free text
to be displayed in binary even in systems that require ACE-formatted
names on the wire.
Con: Requires all software that uses domain names to handle both
formats. Requires processing time for conversion of ACE formats into the
format must likely used internally to the software.
2.3 arch-3: Just send ACE
[RACE] and [SENG] propose that host naming rules remain the same and
that all internationalize domain names be sent in ACE format.
Pro: No changes at all to current DNS protocols.
Con: Requires all software to recognize ACE domain names and convert
them to human-readable for display. This is true not only in domain
names used on the wire but also domain names used in free text.
3. Names in binary
Both arch-1 and arch-2 include domain name parts that are represented on
the wire in a binary format. This section describes some of the features
of such names.
3.1 bin-1: Format
There are many different charsets and encodings for the scripts of the
world. The WG has discussed which binary encoding should be used on the
wire.
3.1.1 bin-1.1: UTF-8
The IETF policy on character sets [RFC2277] states that UTF-8 [RFC2279]
is the preferred charset for IETF protocols. UTF-8 encodes all
characters in the ISO 10646 repertoire.
Pro: Well-supported in other IETF protocols. Compact for most scripts.
Wide implementation in programming languages. US-ASCII characters have
the same encoding in UTF-8 as they do in US-ASCII. Because it is based
on ISO 10646, expansion of the repertoire comes from respected
international standards bodies.
Con: Asian scripts require three octets per character.
3.1.2 bin-1.2: Labelled charsets
Mailing list discussion mentioned using multiple charsets for the binary
representation. Each name part would be labelled with the charset used.
Pro: Allows users to specify names in the charsets they are most
familiar with.
Con: All resolvers would have to know all charsets. Thus, the number of
charsets would probably have to be limited and never expand. Mapping of
characters between charsets would have to be exact and not change over
time.
3.2 bin-2: Distinguishing binary from current format
Software built for current domain names might give unexpected results
when dealing with non-ASCII characters in domain names. For example, it
was reported on the mailing list that some software crashes when a
non-ASCII domain name is returned for in-addr.arpa requests. Thus, there
may be a need for IDN to prevent software that is not binary-aware from
receiving domain names with binary parts. This would only apply to an
IDN that used arch-2, not arch-1.
3.2.1 bin-2.1: Don't mark binary
[KWAN] does not specify any way of changing requests to prevent binary
name parts from being transmitted.
Pro: No changes to current DNS requests and responses.
Con: Likely to cause disruption in software that is not binary-aware.
Likely to cause systems to misread names and possibly (and incorrectly)
convert them to ASCII names by stripping off the high bit in octets;
this in turn would lead to security problems due to mistaken identities.
Returning binary host names to DNS queries is known to break some
current software.
3.2.2 bin-2.2: Mark binary with IN bit
[UDNS] describes using a bit from the header of DNS queries to mark the
query as possibly containing a binary name part and indicating that the
response to the query can contain binary name parts.
Pro: This bit is currently unused and must be set to zero, so current
software won't use it accidentally. No changes to any other part of the
query or RRs.
Con: It's the last unused bit in the header and DNS folks have indicated
that they are very hesitant to give it up.
3.2.3 bin-2.3: Mark binary with new QTYPEs
[UDNS] using new QTYPEs to mark the query as possibly containing a
binary name part and indicating that the response to the query can
contain binary name parts. QTYPEs are two octets long, and no QTYPEs to
date use more than the lower eight bits, so one of the bits from the
upper octet could be used to indicate binary names.
Pro: These bits are currently unused and must be set to zero, so current
software won't use them accidentally. No changes to any other part of
the query or RRs. Uses a bit that isn't as prized as the IN bit.
Con: Software must pay more attention to the QTYPEs than it might have
previously.
3.2.4 bin-2.4: Mark binary with EDNS
[IDNE] uses EDNS [RFC2671] to mark the query and response as containing
a binary name part.
Pro: There is little use of EDNS at this point, so it is very unlikely
to have bad interactions with old software. EDNS allows longer name
parts, and allows additional information (such as IDN version number)
in each name part.
Con: There is little use of EDNS and this might make implementation
harder.
4. Names in ASCII-compatible encoding (ACE)
Both arch-2 and arch-3 include domain name parts that are represented on
the wire in an ASCII-compatible encoding (ACE). This section describes
some of the features of such names.
4.1 ace-1: Format
A variety of proposals for the format of ACE have been proposed. Each
proposal has different features, such as how many characters can be
encoded within the 63 octet limit for each name part. The length
descriptions in this section assume that there is no distinguishing of
ACE from current names; this is not a likely outcome of the WG work.
The descriptions of lengths is based on script block names from
[BLOCK-NAMES].
4.1.1 ace-1.1: UTF-5
[SENG] Describes UTF-5, which is a fairly direct encoding of ISO 10646
characters using a system similar to UTF-8. Characters from Basic Latin
and Latin-1 Supplement take 2 octets; Latin Extended-A through Tibetan
take 3 octets; Myanmar through the end of BMP take 4 octets; non-BMP
characters take 5 octets. This means that names using all characters
in the Myanmar through the end of BMP are limited to 15 characters.
Pro: Extremely simple.
Con: Poor compression, particularly for Asian scripts.
4.1.2 ace-1.2: RACE
[RACE] describes RACE, which is a two-step algorithm that first
compresses the name part, then converts the compressed string into and
ACE. Name parts in all scripts other than Han, Yi, Hangul syllables,
Ethiopic, and non-BMP take up ceil(1.6*(n+1)) octets; name parts in
those scripts and any name that mixes characters from different rows in
ISO 10646 take up ceil(3.2*(n+1)) octets. This means that names using
Han, Yi, Hangul syllables, or Ethiopic, are limited to 18 characters.
(Note: this document used to be called CIDNUC.)
Pro: Best compression for most scripts, and similar compression for the
scripts where it is not the best.
Con: More complicated than UTF-5. Not well optimized for names that have
mixed scripts, such as non-Latin names that use hyphen or ASCII digits.
4.1.3 ace-1.3: Hex of UTF-8
An early draft described "hex of UTF-8", which is a straight-forward
hexadecimal encoding of UTF-8. Characters in Basic Latin (other than
non-US-ASCII and hyphen) take 3 octets; Latin Extended-A through Tibetan
take 5 octets; Myanmar through end of BMP take 7 octets; non-BMP
characters take 9 octets. This means that names using all characters
in the Myanmar through the end of BMP are limited to 9 characters.
Pros: Very simple to describe.
Cons: Very poor compression for all scripts.
4.1.4 ace-1.5: SACE
A message on the mailing list pointed to code for SACE, an ASCII
encoding that purports to compact to about the same size as UTF-8.
Pros: Similar compression to UTF-8.
Cons: No description of how the algorithm works.
4.2 ace-2: Distinguishing ACE from current names
Software that finds ACE name parts in free text probably should
display the name part using the actual characters, not the ACE
equivalent. Thus, software must be able to identify which ASCII name
parts are ACE and which are non-ACE ASCII parts (such as current names).
This would only apply to an IDN proposal that used arch-2, not arch-3.
4.2.1 ace-2.1: Currently legal names
Name parts that are currently legal in RFC 1034 can be tagged to
indicate the part is encoded with ACE.
4.2.1.1 ace-2.1.1: Add hopefully-unique legal tag
[RACE] proposes adding a hopefully-unique legal tag to the beginning
of the name. The proposal would also work with such a tag at the end of
the name part, but it is easier for most people to recognize at the
beginning of name parts.
Pros: Easy for software (and humans) to recognize.
Cons: There is no way to prevent people from beginning non-ACE names
with the tag. Unless the tag is very unlikely to appear in any name in
any human language, non-ACE names that begin with the tag will display
oddly or be rejected by some systems.
4.2.1.2 ace-2.1.2: Add a checksum
Off-list discussion has mentioned the possibility of creating a checksum
mechanism where the checksum would be added to the beginning (or end) of
ACE name parts.
4.2.2 ace-2.2: Currently illegal names
Instead of creating names that are currently legal, another proposal is
to create names that use the current ASCII characters but are illegal.
4.2.2.1 ace-2.2.1: Add trailing hyphen
An earlier draft described using a trailing hyphen as a signifier of an
ACE name.
Pros: It is surmised that most current software does not reject names
that are illegal in this fashion. Thus, there would be little disruption
to current systems. This mechanism takes up fewer characters than any
proposed in ace-2.1.
Cons: Some current software is will probably break with this mechanism.
It goes against some current protocols that match the rules in RFC 1034.
5. Prohibited characters
There was a short but active discussion on the mailing list about which
characters from the ISO 10646 character set should never appear in host
names. To date, there are no Internet Drafts on the subject. This
section summarizes some of the suggestions.
5.1 prohib-1: Identical and near-identical characters
Some characters are visually identical or incredibly similar to other
characters, thus making it impossible to accurately enter host names
that are seen in print.
5.2 prohib-2: Separators
Horizontal and vertical spacing characters would make it unclear where a
host name begins and ends. Also, allowing periods and period-like
characters as characters within a name part would also cause similar
confusion.
5.3 prohib-3: Non-displaying and non-spacing characters
There are many characters that cannot be seen in the ISO 10646 character
set. These include control characters, non-breaking spaces, formatting
characters, and tagging characters. These characters would certainly
cause confusion if allowed in host names.
5.4 prohib-4: Private use characters
Private use characters from ISO 10646 inherently have no specified
visual form (and in fact can be used for non-displaying characters).
Thus, there could be no visual interoperability for characters in the
private use areas.
5.5 prohib-5: Punctuation
Some punctuation characters are disallowed in URLs because they are used
in URL syntax.
5.6 prohib-6: Symbols
Some mailing list discussion stated that characters that do not normally
appear in human or company names should not be allowed in host names.
This includes symbols and non-name punctuation.
6. Canonicalization
The working group has a spirited discussion on the need for
canonicalization. [IDN-REQ] describes many requirements for when and what
type of canonicalization might be performed.
6.1 canon-1: Type of canonicalization
The Unicode Consortium's recommendations and definitions of
canonicalization [UTR-15] describes many forms of canonicalization that
can be performed on character strings. [DUERST] covers much of the same
ground but makes more focused requirements for canonicalization on the
Internet.
6.1.1 canon-1.1: Normalization Form C
[DUERST] recommends Normalization Form C, as described in [UTR-15], for
use on the Internet. This form is a canonical decomposition, followed by
canonical composition.
6.1.2 canon-1.2: Normalization Form KC
Discussion on the mailing list recommended Normalization Form KC. This
form is a compatibility decomposition, followed by canonical
composition. Compatibility decomposition makes characters that have
compatibility equivalence the same after decomposing.
6.2 canon-2: Other canonicalization
Host names may have special canonicalization needs that can be added to
those given in canon-1.
6.2.1 canon-2.1: Case folding in ASCII
RFC 1034 specifies that there is no difference between host names that
have the same letters but the letters have different case. Thus, the
name part "example" is considered the same as "Example" and "EXamPLe".
Neither uppercase nor lowercase is specified as being canonical.
6.2.2 canon-2.2: Case folding in non-ASCII
Discussion on the mailing list has raised the issue of whether or not
non-ASCII Latin characters should have the same case-folding rules as
ASCII. Such rules would match the expectations of native speakers of
some languages, but would go counter to the expectations of native
speakers of other languages.
6.2.3 canon-2.3: Han folding
Discussion on the mailing list has raised the issue of equivalences in
some languages use of Han characters. For example, in Chinese, there are
many traditional characters that have equivalent simplified characters.
Similarly, there are some Han ideographs for which there are multiple
representations in ISO 10646. There are no well-established rules for
such folding, and some of the proposed folding would be locale-specific.
6.3 canon-3: Location of canonicalization
Canonicalization can be performed in any system in the DNS. Because it
is not a trivial operation and can require large tables, the location of
where canonicalization is performed is important.
6.3.1 canon-3.1: Canonicalize only in the application
Early canonicalization is a cleaner architecture design. Spending the
cycles on the end systems puts less burden on resolvers or servers in
the DNS service. When IDN is first adopted, the applications need to be
updated anyway to handle the new format for the names. It is easier for
people to upgrade their applications than their resolvers if they need a
new IDN feature.
6.3.2 canon-3.2: Canonicalize only in the resolver
Updating a single resolver provides new service to large number of
applications and (possibly) users. It is easier to find canonicalization
bugs in resolvers than in applications because the resolver has
predictable programmatic interfaces. IDN will probably be revised often
as new characters are added to ISO 10646, so updating smaller number of
resolvers is better than revising more applications. When an end user
has a problem with resolving an IDN name, it is much easier to test if
the problem is in the resolver than in the user's application.
6.3.3 canon-3.3: Canonicalize in the DNS service
Canonicalization should happen as late as possible so that changes in
the canonicalization algorithm don't orphan all applications and
resolvers. Some canonicalization discards information and so should be
delayed as long as possible. Canonicalization is practically free,
computationally (although it involves some large tables). Because adding
IDN to the DNS will happen over time, canonicalizing at the server will
minimize the number of things that need to be changed, and simplify and
centralize the process of change.
7. Transitions
Early in the working group discussion, there was active debate about how
the transition from the current host name rules to IDN would be handled.
Given requirement [#1-02], this transition is quite important to
deciding which proposals might be feasible.
7.1 trans-1: Always do current plus new architecture
In this proposal, IDN will be used at the same time as the current DNS
forever. That is, IDN will be in addition to the current DNS.
7.2 trans-2: Transition period
In this proposal, IDN will be used at the same time as the current DNS
for a specified period of time, after which only IDN will exist. That
is, IDN will replace the current DNS.
8. Root server considerations
DNS root servers receive all requests for top-level domains that are not
in the local DNS cache. They are critical to the Internet. Care must be
taken to ensure that root servers will not be affected by new mechanisms
introduced.
Any IDN proposal that includes a binary encoding will have an impact on
the root servers. The binary requests will affect the root servers
because the current root server software is designed to handle current
host names. Further, the root zone files which contain ccTLDs and gTLDs
would have to support binary domain names and possibly binary host names
for NS records. Because all the root servers are equivalent, they would
have to be synchronized to support the binary domain names at the same
time.
Proposals that only use ACE and use tagging with currently-legal names
would, by definition, not affect the root servers.
9. Security considerations
All security considerations listed in [IDN-REQ] apply to this document.
Further, all security considerations listed in each of the IDN proposals
must be considered when comparing the proposals.
Some proposals described in this document may create new security
considerations. However, these considerations will have to be addressed
in the eventual protocol document. All the proposals described here are
still incomplete and security considerations may be added to them as
they are revised. All the proposals listed in this document use the ISO
10646 character set, so the proposals inherit any security
characteristics of that character set.
Many protocols and applications rely on domain names to identify the
parties involved in a network transaction. For example, a user who
connects to a web site by entering or selecting a URL expects that their
software will select the web site named in the URL. The uniqueness of
domain names are crucial to ensure identification of Internet entities.
To make round-trip translation between local charsets and ISO 10646, the
ISO 10646 specification has assigned multiple code points to individual
glyphs. Moreover, some glyphs might look similar to some users, but look
clearly different by other users. This means that it would be simple for
an attacker to mimic a domain name by using similar-looking but
different glyphs and guessing that some users will not see the
difference in their user interface.
Some IDN protocols may have denial of service attacks, such as by using
non-identified chars, exception characters, or under-specified behavior
in using some special characters.
10. IANA considerations
This document does not create any new IANA registries. However, it is
possible that a character property registry may need to be set up when
the IDN protocol is created in order to list prohibited characters
(section 5) and canonicalization mappings (section 6).
11. Acknowledgements
James Seng and Marc Blanchet gave many helpful suggestions on the
pre-release versions of this document.
12. References
[BLOCK-NAMES] Unicode Consortium,
<ftp://ftp.unicode.org/Public/UNIDATA/Blocks.txt>.
[DUERST] Character Normalization in IETF Protocols,
draft-duerst-i18n-norm-03
[IDN-REQ] Requirements of Internationalized Domain Names,
draft-ietf-idn-requirements-02
[IDNE] Internationalized domain names using EDNS (IDNE),
draft-ietf-idn-idne-01
[KWAN] Using the UTF-8 Character Set in the Domain Name System,
draft-skwan-utf8-dns-03
[RACE] RACE: Row-based ASCII Compatible Encoding for IDN,
draft-ietf-idn-race-00
[RFC2277] IETF Policy on Character Sets and Languages, RFC 2277
[RFC2279] UTF-8, a transformation format of ISO 10646, RFC 2279
[RFC2671] Extension Mechanisms for DNS (EDNS0), RFC 2671
[SENG] UTF-5, a transformation format of Unicode and ISO 10646,
draft-jseng-utf5-01
[UDNS] Using the Universal Character Set in the Domain Name System
(UDNS), draft-ietf-idn-udns-00
[UTR15] Unicode Normalization Forms, Unicode Technical Report #15
A. Differences Between -00 and -01 Drafts
Throughout: Changed references from [HOFFMAN] to [RACE].
Throughout: Changed references from [OSCARSSON] to [UDNS].
Throughout: Added [IDNE].
Removed section 1.2.
3.2.3: Updated to mention [UDNS].
3.2.4: Updated with [IDNE], changed "EDNS0" to "EDNS", and reworded.
4.1.2: Added Ethiopic to the list of scripts that require two octets per
character.
4.1.3: Removed reference to [OSCARSSON] because that is no longer in the
[UDNS] draft.
4.2.2.1: Removed reference to [OSCARSSON] because that is no longer in
the [UDNS] draft.
6.1.1: Reworded first sentence.
6.3: Added entire section and subsections.
8: Fixed typo in first sentence.
B. Author Contact
Paul Hoffman
IMC & VPNC
127 Segre Place
Santa Cruz, CA 95060
phoffman@imc.org or paul.hoffman@vpnc.org

19
doc/draft/draft-ietf-idn-compare-02.txt Normal file
View File

@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
P. Hoffman: phoffman@imc.org

596
doc/draft/draft-ietf-idn-dude-00.txt
View File

@ -1,596 +0,0 @@
Internet Engineering Task Force (IETF) Mark Welter
INTERNET-DRAFT Brian W. Spolarich
draft-ietf-idn-dude-00.txt WALID, Inc.
November 16, 2000 Expires May 16, 2001
DUDE: Differential Unicode Domain Encoding
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The distribution of this document is unlimited.
Copyright (c) The Internet Society (2000). All Rights Reserved.
Abstract
This document describes a tranformation method for representing
Unicode character codepoints in host name parts in a fashion that is
completely compatible with the current Domain Name System. It provides
for very efficient representation of typical Unicode sequences as
host name parts, while preserving simplicity. It is proposed as a
potential candidate for an ASCII-Compatible Encoding (ACE) for supporting
the deployment of an internationalized Domain Name System.
Table of Contents
1. Introduction
1.1 Terminology
2. Hostname Part Transformation
2.1 Post-Converted Name Prefix
2.2 Radix Selection
2.3 Hostname Prepartion
2.4 Definitions
2.5 DUDE Encoding
2.5.1 Extended Variable Length Hex Encoding
2.5.2 DUDE Compression Algorithm
2.5.3 Forward Transformation Algorithm
2.6 DUDE Decoding
2.6.1 Extended Variable Length Hex Decoding
2.6.2 DUDE Decompression Algorithm
2.6.3 Reverse Transformation Algorithm
3. Examples
3.1 'www.walid.com' (in Arabic)
4. DUDE Extensions
4.1 Extended DUDE Encoding
4.1.1 Modified Extended Variable Length Hex Encoding
4.1.2 Extended Compression Algorithm
4.1.3 Extended Forward Transformation Algorithm
4.2 Extended DUDE Decoding
4.2.1 Modified Extended Variable Length Hex Decoding
4.2.2 Extended Decompression Algorithm
4.2.3 Extended Reverse Transformation Algorithm
5. Security Considerations
6. References
1. Introduction
DUDE describes an encoding scheme of the ISO/IEC 10646 [ISO10646]
character set (whose character code assignments are synchronized
with Unicode [UNICODE3]), and the procedures for using this scheme
to transform host name parts containing Unicode character sequences
into sequences that are compatible with the current DNS protocol
[STD13]. As such, it satisfies the definition of a 'charset' as
defined in [IDNREQ].
1.1 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119].
Hexadecimal values are shown preceded with an "0x". For example,
"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are
shown preceded with an "0b". For example, a nine-bit value might be
shown as "0b101101111".
Examples in this document use the notation from the Unicode Standard
[UNICODE3] as well as the ISO 10646 names. For example, the letter "a"
may be represented as either "U+0061" or "LATIN SMALL LETTER A".
DUDE converts strings with internationalized characters into
strings of US-ASCII that are acceptable as host name parts in current
DNS host naming usage. The former are called "pre-converted" and the
latter are called "post-converted". This specification defines both
a forward and reverse transformation algorithm.
2. Hostname Part Transformation
According to [STD13], hostname parts must start and end with a letter
or digit, and contain only letters, digits, and the hyphen character
("-"). This, of course, excludes most characters used by non-English
speakers, characters, as well as many other characters in the ASCII
character repertoire. Further, domain name parts must be 63 octets or
shorter in length.
2.1 Post-Converted Name Prefix
This document defines the string 'dq--' as a prefix to identify
DUDE-encoded sequences. For the purposes of comparison in the IDN
Working Group activities, the 'dq--' prefix should be used solely to
identify DUDE sequences. However, should this document proceed beyond
draft status the prefix should be changed to whatever prefix, if any,
is the final consensus of the IDN working group.
Note that the prepending of a fixed identifier sequence is only one
mechanism for differentiating ASCII character encoded international
domain names from 'ordinary' domain names. One method, as proposed in
[IDNRACE], is to include a character prefix or suffix that does not
appear in any name in any zone file. A second method is to insert a
domain component which pushes off any international names one or more
levels deeper into the DNS hierarchy. There are trade-offs between
these two methods which are independent of the Unicode to ASCII
transcoding method finally chosen. We do not address the international
vs. 'ordinary' name differention issue in this paper.
2.2 Radix Selection
There are many proposed methods for representing Unicode characters
within the allowed target character set, which can be split into groups
on the basis of the underlying radix. We have chosen a method with
radix 16 because both UTF-16 and ASCII are represented by even multiples
of four bits. This allows a Unicode character to be encoded as a
whole number of ASCII characters, and permits easier manipulation of
the resulting encoded data by humans.
2.3 Hostname Prepartion
The hostname part is assumed to have at least one character disallowed
by [STD13], and that is has been processed for logically equivalent
character mapping, filtering of disallowed characters (if any), and
compatibility composition/decomposition before presentation to the DUDE
conversion algorithm.
While it is possible to invent a transcoding mechanism that relies
on certain Unicode characters being deemed illegal within domain names
and hence available to the transcoding mechanism for improving encoding
efficiency, we feel that such a proposal would complicate matters
excessively. We also believe that Unicode name preprocessing for
both name resolution and name registration should be considered as
separate, independent issues, which we will address in a separate
document.
2.4 Definitions
For clarity:
'integer' is an unsigned binary quantity;
'byte' is an 8-bit integer quantity;
'nibble' is a 4-bit integer quantity.
2.5 DUDE Encoding
The idea behind this scheme is to provide compression by encoding the
contiguous least significant nibbles of a character that differ from the
preceding character. Using a variant of the variable length hex encoding
desribed in [IDNDUERST] and elsewhere, by encoding leading zero nibbles
this technique allows recovery of the differential length. The encoding
is, with some practice, easy to perform manually.
There are two extensions to this basic idea: one enables encoding the
preferred case for each charcter (for reverse DNS resolution) and
another improves the worse case behaviour related to surrogates. The
basic algorithms will be formally described first and then the extended
algorithms will be described.
2.5.1 Extended Variable Length Hex Encoding
The variable length hex encoding algorithm was introduced by Duerst in
[IDNDUERST]. It encodes an integer value in a slight modification of
traditional hexadecimal notation, the difference being that the most
significant digit is represented with an alternate set of "digits"
- -- 'g through 'v' are used to represent 0 through 15. The result is a
variable length encoding which can efficiently represent integers of
arbitrary length.
This specification extends the variable length hex encoding algorithm
to support the compression scheme defined below by potentially not
supressing leading zero nibbles.
The extended variable length nibble encoding of an integer, C,
to length N, is defined as follows:
1. Start with I, the Nth least significant nibble from the least
significant nibble of C;
2. Emit the Ith character of the sequence [ghijklmnopqrstuv];
3. Continue from the most to least significant, encoding each
remaining nibble J by emitting the Jth character of the
sequence [0123456789abcdef].
2.5.2 DUDE Compression Algorithm
1. Let PREV = 0;
2. If there are no more characters in the input, terminate successfully;
4. Let C be the next character in the input;
5. If C != '-' , then go to step 5;
6. Consume the input character, emit '-', and go to step 2;
7. Let D be the result of PREV exclusive ORed with C;
8. Find the least positive value N such that
D bitwise ANDed with M is zero
where M = the bitwise complement of (16**N) - 1;
9. Let V be C ANDed with the bitwise complement of M;
10. Variable length hex encode V to length N and emit the result;
11. Let PREV = C and go to step 2.
2.5.3 Forward Transformation Algorithm
The DUDE transformation algorithm accepts a string in UTF-16
[ISO10646] format as input. The encoding algorithm is as follows:
1. Break the hostname string into dot-separated hostname parts.
For each hostname part which contains one or more characters
disallowed by [STD13], perform steps 2 and 3 below;
2. Compress the hostname part using the method described in section
2.5.2 above, and encode using the encoding described in section
2.5.1;
3. Prepend the post-converted name prefix 'dq--' (see section 2.1
above) to the resulting string.
2.6 DUDE Decoding
2.6.1 Extended Variable Length Hex Decoding
Decoding extended variable length hex encoded strings is identical
to the standard variable length hex encoding, and is defined as
follows:
1. Let CL be the lower case of the first input character,
If CL is not in set [ghijklmnopqrstuv],
return error,
else
consume the input character;
2. Let R = CL - 'g',
Let N = 1;
3. If no more input characters exist, go to step 9.
4. Let CL be the lower case of the next input character;
5. If CL is not in the set [0123456789abcdef], go to Step 9;
6. Consume the next input character,
Let N = N + 1;
Let R = R * 16;
7. If N is in set [0123456789],
then let R = R + (N - '0')
else let R = R + (N - 'a') + 10;
8. Go to step 3;
9. Let MASK be the bitwise complement of (16**N) - 1;
10. Return decoded result R as well as MASK.
2.6.2 DUDE Decompression Algorithm
1. Let PREV = 0;
2. If there are no more input characters then terminate successfully;
3. Let C be the next input character;
4. If C == '-', append '-' to the result string, consume the character,
and go to step 2,
5. Let VPART, MASK be the next variable length hex decoded
value and mask;
6. If VPART > 0xFFFF then return error status,
7. Let CU = ( PREV bitwise-AND MASK) + VPART,
Let PREV = CU;
8. Append the UTF-16 character CU to the result string;
9. Go to step 2.
2.6.3 Reverse Transformation Algorithm
1. Break the string into dot-separated components and apply Steps
2 through 4 to each component;
2. Remove the post converted name prefix 'dq--' (see Section 2.1);
3. Decompress the component using the decompression algorithm
described above;
4. Concatenate the decoded segments with dot separators and return.
3. Examples
The examples below illustrate the encoding algorithm and provide
comparisons to alternate encoding schemes. UTF-5 sequences are
prefixed with '----', as no ACE prefix was defined for that encoding.
3.1 'www.walid.com' (in Arabic):
UTF-16: U+0645 U+0648 U+0642 U+0639 . U+0648 U+0644 U+064A U+062F .
U+0634 U+0631 U+0643 U+0629
DUDE: dq--m45oij9.dq--m48kqif.dq--m34hk3i9
UTF-6: wq--ymk5k8k2j9.wq--ymk8k4kaif.wq--ymj4j1k3i9
UTF-5: ----m45m48m42m39.----m48m44m4am2f.----m34m31m43m29
RACE: bq--azcuqqrz.bq--azeeisrp.bq--ay2dcqzj
LACE: bq--aqdekscche.bq--aqdeqrckf5.bq--aqddimkdfe
(more examples to come)
4. DUDE Extensions
The first extension to the DUDE concept recognizes that the first
character emitted by the variable length hex encoding algorithm is
always alphabetic. We encode the case (if any) of the original Unicode
character in the case of the initial "hex" character. Because the DNS
performs case-insensitive comparisons, mixed case international domain
names behave in exactly the same way as traditional domain names.
In particular, this enables reverse lookups to return names in the
preferred case.
The second extension regards the treatment of Unicode surrogate
characters. If surrogates are not expanded, two 16-bit surrogates are
needed to represent a single codepoint in the range of 0x10000
through 0x10FFFF. This cuts the worse case limits in half for most
proposals. We will assume that our input and output Unicode are in
UTF-32 format -- that is, any surrogates are expanded to their UCS-4
equivalents. If the input codes all fall under 0x10000, then the
extended method will emit the same length string as the basic method.
One final modification takes note of the fact that the only only
codepoints forcing the use of six hex digits is for those with a "10"
as the fifth and sixth digits. We will encode the fifth digit using
a seventeenth digit as a special case to avoid this extra expansion.
4.1 Extended DUDE Encoding
4.1.1 Modified Extended Variable Length Hex Encoding
The modified extended variable length hex encoding of an integer C to
length N with case U is performed as follows:
1. If C > 0x10FFFF return error status;
2. If N < 6 go to step 5; (this is true for characters from
the first 16 Planes)
3. If U is 'Uppercase' then emit 'W'
else emit 'w'; (special case for the 17th Plane)
4. go to step 7;
5. Let I be the Nth nibble from the right of C;
6. If U is 'Uppercase'
then emit the Ith character of sequence [GHIJKLMNOPQRSTUV],
else emit the Ith character of sequence [ghijklmnopqrstuv];
7. Let N = N - 1;
8. Continue from N to 1, encoding each remaining nibble, J, by
emitting the Jth character of sequence [0123456789abcdef].
4.1.2 Extended Compression Algorithm
1. Let PREV = 0;
2. If there are no more characters in the input, terminate successfully;
4. Let U be the case of the next character in the input;
Let C be the lowercase value of the next input character;
5. If C != '-' , then go to step 7;
6. Consume the input character, emit '-', and go to step 2;
7. Let D be the result of PREV exclusive ORed with C;
8. Find the least positive value N such that
D bitwise ANDed with M is zero
where M = the bitwise complement of (16**N) - 1;
9. Let V = C ANDed with the bitwise complement of M;
10. Emit the modified variable length hex encoding of V to length
N with case U;
11. Let PREV = C and go to step 2.
4.1.3 Extended Forward Transformation Algorithm
The overall extended encoding algorithm is as follows:
1. Break the hostname string into dot-separated hostname parts.
For each hostname part, perform steps 2 and 3 below;
2. Compress the component using the method described in section
4.1.2 above, and encode using the encoding described in section
4.1.1;
3. Prepend the post-converted name prefix 'dq--' (see section 2.1
above) to the resulting string.
4.2 Extended DUDE Decoding
4.2.1 Modified Extended Variable Length Hex Decoding
1. Let U be the case of the next input character,
Let C0 be the lower case of the next input character;
2. If C0 is not in set [ghijklmnopqrstuw] then return error status,
else, consume the input character;
3. Let R = C0 - 'g'
Let N = 1;
4. If no more input characters exist then go to step 8;
5. Let CL be the lower case of the next input character,
If CL is not in set [0123456789abcdef] then go to step 8;
6. Consume the next input character,
Let N = N + 1,
Let R = R * 16,
If CL is in set [0-9]
then let R = R + (CL - '0')
else let R = R + (CL - 'a') + 10;
7. Go to step 4;
8. If R < 0x100000 then go to step 10;
9. Let N = N + 1,
If (N > 6) or (C0 != 'w')
then return error status;
10. Let MASK be the bitwise complement of (16**N) - 1. Return
result R, MASK, and U.
4.2.2 Extended Decompression Algorithm
1. Let PREV = 0;
2. If there are no more input characters then terminate successfully;
3. Let C be the next input character;
4. If C == '-', append '-' to the result
string, consume the character, and go to step 2;
5. Let VPART, MASK, and U be the result of the modified extended
variable length decoded value;
6. Let CU = (PREV 'bitwise AND' MASK) + VPART,
Let PREV = CU;
7. If U == 'Uppercase' then let CU = the corresponding upper case value
of CU;
8. Append CU to the result string and go to step 2.
4.2.3 Extended Reverse Transformation Algorithm
1. Break the string into dot-separated components and apply Steps
2 through 4 to each component;
2. Remove the post converted name prefix 'dq--' (see Section 2.1);
3. Decompress the component using the extended decompression
algorithm described in section 4.2.2 above;
4. Concatenate the decoded segments with dot separators and return.
Note that DUDE decoding will return error for input strings which do
not comply with RFC1035.
5. Security Considerations
Much of the security of the Internet relies on the DNS and any
change to the characteristics of the DNS may change the security of
much of the Internet. Therefore DUDE makes no changes to the DNS itself.
DUDE is designed so that distinct Unicode sequences map to distinct
domain name sequences (modulo the Unicode and DNS equivalence rules).
Therefore use of DUDE with DNS will not negatively affect security.
6. References
[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
Proposals", draft-ietf-idn-compare;
[IDNRACE] Paul Hoffman, "RACE: Row-Based ASCII Compatible Encoding for
IDN", draft-ietf-idn-race;
[IDNREQ] James Seng, "Requirements of Internationalized Domain Names",
draft-ietf-idn-requirement;
[IDNNAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep;
[IDNDUERST] M. Duerst, "Internationalization of Domain Names",
draft-duerst-dns-i18n;
[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information
technology -- Universal Multiple-Octet Coded Character Set (UCS) --
Part 1: Architecture and Basic Multilingual Plane. Five amendments and
a technical corrigendum have been published up to now. UTF-16 is
described in Annex Q, published as Amendment 1. 17 other amendments are
currently at various stages of standardization;
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119;
[STD13] Paul Mockapetris, "Domain names - implementation and
specification", November 1987, STD 13 (RFC 1035);
[UNICODE3] The Unicode Consortium, "The Unicode Standard -- Version
3.0", ISBN 0-201-61633-5. Described at
<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.
A. Acknowledgements
The structure (and some of the structural text) of this document is
intentionally borrowed from the LACE IDN draft (draft-ietf-idn-lace-00)
by Mark Davis and Paul Hoffman.
B. IANA Considerations
There are no IANA considerations in this document.
C. Author Contact Information
Mark Welter
Brian W. Spolarich
WALID, Inc.
State Technology Park
2245 S. State St.
Ann Arbor, MI 48104
+1-734-822-2020
mwelter@walid.com
briansp@walid.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE6FZ/D/DkPcNgtD/0RAoswAKCUGBTSFJv96+Z+YnA8m47qrnheAgCeLQ6C
1+knyHluauC+66esCtPVoKU=
=hbT+
-----END PGP SIGNATURE-----

898
doc/draft/draft-ietf-idn-dude-01.txt Normal file
View File

@ -0,0 +1,898 @@
Internet Engineering Task Force (IETF) Mark Welter
INTERNET-DRAFT Brian W. Spolarich
draft-ietf-idn-dude-01.txt WALID, Inc.
March 02, 2001 Expires September 02, 2001
DUDE: Differential Unicode Domain Encoding
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The distribution of this document is unlimited.
Copyright (c) The Internet Society (2000). All Rights Reserved.
Abstract
This document describes a tranformation method for representing
Unicode character codepoints in host name parts in a fashion that is
completely compatible with the current Domain Name System. It provides
for very efficient representation of typical Unicode sequences as
host name parts, while preserving simplicity. It is proposed as a
potential candidate for an ASCII-Compatible Encoding (ACE) for supporting
the deployment of an internationalized Domain Name System.
Table of Contents
1. Introduction
1.1 Terminology
2. Hostname Part Transformation
2.1 Post-Converted Name Prefix
2.2 Radix Selection
2.3 Hostname Prepartion
2.4 Definitions
2.5 DUDE Encoding
2.5.1 Extended Variable Length Hex Encoding
2.5.2 DUDE Compression Algorithm
2.5.3 Forward Transformation Algorithm
2.6 DUDE Decoding
2.6.1 Extended Variable Length Hex Decoding
2.6.2 DUDE Decompression Algorithm
2.6.3 Reverse Transformation Algorithm
3. Examples
4. Optional Case Preservation
5. Security Considerations
6. References
1. Introduction
DUDE describes an encoding scheme of the ISO/IEC 10646 [ISO10646]
character set (whose character code assignments are synchronized
with Unicode [UNICODE3]), and the procedures for using this scheme
to transform host name parts containing Unicode character sequences
into sequences that are compatible with the current DNS protocol
[STD13]. As such, it satisfies the definition of a 'charset' as
defined in [IDNREQ].
1.1 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119].
Hexadecimal values are shown preceded with an "0x". For example,
"0xa1b5" indicates two octets, 0xa1 followed by 0xb5. Binary values are
shown preceded with an "0b". For example, a nine-bit value might be
shown as "0b101101111".
Examples in this document use the notation from the Unicode Standard
[UNICODE3] as well as the ISO 10646 names. For example, the letter "a"
may be represented as either "U+0061" or "LATIN SMALL LETTER A".
DUDE converts strings with internationalized characters into
strings of US-ASCII that are acceptable as host name parts in current
DNS host naming usage. The former are called "pre-converted" and the
latter are called "post-converted". This specification defines both
a forward and reverse transformation algorithm.
2. Hostname Part Transformation
According to [STD13], hostname parts must start and end with a letter
or digit, and contain only letters, digits, and the hyphen character
("-"). This, of course, excludes most characters used by non-English
speakers, characters, as well as many other characters in the ASCII
character repertoire. Further, domain name parts must be 63 octets or
shorter in length.
2.1 Post-Converted Name Prefix
This document defines the string 'dq--' as a prefix to identify
DUDE-encoded sequences. For the purposes of comparison in the IDN
Working Group activities, the 'dq--' prefix should be used solely to
identify DUDE sequences. However, should this document proceed beyond
draft status the prefix should be changed to whatever prefix, if any,
is the final consensus of the IDN working group.
Note that the prepending of a fixed identifier sequence is only one
mechanism for differentiating ASCII character encoded international
domain names from 'ordinary' domain names. One method, as proposed in
[IDNRACE], is to include a character prefix or suffix that does not
appear in any name in any zone file. A second method is to insert a
domain component which pushes off any international names one or more
levels deeper into the DNS hierarchy. There are trade-offs between
these two methods which are independent of the Unicode to ASCII
transcoding method finally chosen. We do not address the international
vs. 'ordinary' name differention issue in this paper.
2.2 Radix Selection
There are many proposed methods for representing Unicode characters
within the allowed target character set, which can be split into groups
on the basis of the underlying radix. We have chosen a method with
radix 16 because both UTF-32 and ASCII are represented by even multiples
of four bits. This allows a Unicode character to be encoded as a
whole number of ASCII characters, and permits easier manipulation of
the resulting encoded data by humans.
2.3 Hostname Preparation
The hostname part is assumed to have at least one character disallowed
by [STD13], and that is has been processed for logically equivalent
character mapping, filtering of disallowed characters (if any), and
compatibility composition/decomposition before presentation to the DUDE
conversion algorithm.
While it is possible to invent a transcoding mechanism that relies
on certain Unicode characters being deemed illegal within domain names
and hence available to the transcoding mechanism for improving encoding
efficiency, we feel that such a proposal would complicate matters
excessively.
2.4 Definitions
For clarity:
'integer' is an unsigned binary quantity;
'byte' is an 8-bit integer quantity;
'nibble' is a 4-bit integer quantity.
2.5 DUDE Encoding
The idea behind this scheme is to provide compression by encoding the
contiguous least significant nibbles of a character that differ from the
preceding character. Using a variant of the variable length hex encoding
desribed in [IDNDUERST] and elsewhere, by encoding leading zero nibbles
this technique allows recovery of the differential length. The encoding
is, with some practice, easy to perform manually.
2.5.1 Extended Variable Length Hex Encoding
The variable length hex encoding algorithm was introduced by Duerst in
[IDNDUERST]. It encodes an integer value in a slight modification of
traditional hexadecimal notation, the difference being that the most
significant digit is represented with an alternate set of "digits"
- -- 'g through 'v' are used to represent 0 through 15. The result is a
variable length encoding which can efficiently represent integers of
arbitrary length.
This specification extends the variable length hex encoding algorithm
to support the compression scheme defined below by potentially not
supressing leading zero nibbles.
The extended variable length nibble encoding of an integer, C,
to length N, is defined as follows:
1. Start with I, the Nth least significant nibble from the least
significant nibble of C;
2. Emit the Ith character of the sequence [ghijklmnopqrstuv];
3. Continue from the most to least significant, encoding each
remaining nibble J by emitting the Jth character of the
sequence [0123456789abcdef].
2.5.2 DUDE Compression Algorithm
1. Let PREV = 0;
2. If there are no more characters in the input, terminate successfully;
4. Let C be the next character in the input;
5. If C != '-' , then go to step 7;
6. Consume the input character, emit '-', and go to step 2;
7. Let D be the result of PREV exclusive ORed with C;
8. Find the least positive value N such that
D bitwise ANDed with M is zero
where M = the bitwise complement of (16**N) - 1;
9. Let V be C ANDed with the bitwise complement of M;
10. Variable length hex encode V to length N and emit the result;
11. Let PREV = C and go to step 2.
2.5.3 Forward Transformation Algorithm
The DUDE transformation algorithm accepts a string in UTF-32
[UNICODE3] format as input. It is assumed that prior nameprep
processing has disallowed the private use code points in
0X100000 throuh 0X10FFFF, so that we are left with the task of
encoding 20 bit integers. The encoding algorithm is as follows:
1. Break the hostname string into dot-separated hostname parts.
For each hostname part which contains one or more characters
disallowed by [STD13], perform steps 2 and 3 below;
2. Compress the hostname part using the method described in section
2.5.2 above, and encode using the encoding described in section
2.5.1;
3. Prepend the post-converted name prefix 'dq--' (see section 2.1
above) to the resulting string.
2.6 DUDE Decoding
2.6.1 Extended Variable Length Hex Decoding
Decoding extended variable length hex encoded strings is identical
to the standard variable length hex encoding, and is defined as
follows:
1. Let CL be the lower case of the first input character,
If CL is not in set [ghijklmnopqrstuv],
return error,
else
consume the input character;
2. Let R = CL - 'g',
Let N = 1;
3. If no more input characters exist, go to step 9.
4. Let CL be the lower case of the next input character;
5. If CL is not in the set [0123456789abcdef], go to Step 9;
6. Consume the next input character,
Let N = N + 1;
Let R = R * 16;
7. If N is in set [0123456789],
then let R = R + (N - '0')
else let R = R + (N - 'a') + 10;
8. Go to step 3;
9. Let MASK be the bitwise complement of (16**N) - 1;
10. Return decoded result R as well as MASK.
2.6.2 DUDE Decompression Algorithm
1. Let PREV = 0;
2. If there are no more input characters then terminate successfully;
3. Let C be the next input character;
4. If C == '-', append '-' to the result string, consume the character,
and go to step 2,
5. Let VPART, MASK be the next extended variable length hex decoded
value and mask;
6. If VPART > 0xFFFFF then return error status,
7. Let CU = ( PREV bitwise-AND MASK) + VPART,
Let PREV = CU;
8. Append the UTF-32 character CU to the result string;
9. Go to step 2.
2.6.3 Reverse Transformation Algorithm
1. Break the string into dot-separated components and apply Steps
2 through 4 to each component;
2. Remove the post converted name prefix 'dq--' (see Section 2.1);
3. Decompress the component using the decompression algorithm
described above (which in turn invokes the decoding algorithm
also described above);
4. Concatenate the decoded segments with dot separators and return.
3. Examples
The examples below illustrate the encoding algorithm. Allowed RFC1035
characters, including period [U+002E] and dash [U+002D] are shown as
literals in the UTF-16 version of the example. DUDE is compared to
LACE as proposed in [IDNLACE]. A comprehensive comparison of ACE
proposals is outside of the scope of this document. However we believe
that DUDE shows a good balance between efficiency (resulting in shorter
ACE sequences for typical names) and complexity.
3.1 'www.walid.com' [Arabic]:
UTF-16: U+0645 U+0648 U+0642 U+0639 . U+0648 U+0644 U+064A U+062F .
U+0634 U+0631 U+0643 U+0629
DUDE: dq--m45oij9.dq--m48kqif.dq--m34hk3i9
LACE: bq--aqdekscche.bq--aqdeqrckf5.bq--aqddimkdfe
3.2 'Abugazalah-Intellectual-Property.com' [Arabic]:
UTF-16: U+0623 U+0628 U+0648 U+063A U+0632 U+0627 U+0644 U+0629 -
U+0644 U+0644 U+0645 U+0644 U+0643 U+064A U+0629 - U+0627
U+0644 U+0641 U+0643 U+0631 U+064A U+0629 . U+0634 U+0631
U+0643 U+0629
DUDE: dq--m23ok8jaii7k4i9-m44klkjqi9-m27k4hjj1kai9.dq--m34hk3i9
LACE: bq--badcgkcihizcorbjaeac2bygircekrcdjiuqcabna4dcorcbimyuuki.
bq--aqddimkdfe
3.3 'King-Hussain.person.jr' [Arabic]
UTF-16: U+0627 U+0644 U+0645 U+0644 U+0643 - U+062D U+0633 U+064A
U+0646 . U+0634 U+062E U+0635 . U+0627 U+0644 U+0623 U+0631
U+062F U+0646
DUDE: dq--m27k4lkj-m2dj3kam.dq--m34iej5.dq--m27k4i3j1ifk6
LACE: bq--audcorcfirbqcabnaudegljtjjda.bq--amddilrv.
bq--aydcorbdgexum
3.4 'Jordanian-Dental-Center.com.jr' [Arabic]
UTF-16: U+0645 U+0631 U+0643 U+0632 - U+0627 U+0644 U+0623 U+0631 U+062F
U+0646 - U+0644 U+0644 U+0623 U+0633 U+0646 U+0627 U+0646 .
U+0634 U+0631 U+0643 U+0629 . U+0627 U+0644 U+0623 U+0631 U+062F
U+0646
DUDE: dq--m45j1k3j2-m27k4i3j1ifk6-m44ki3j3k6i7k6.dq--m34hk3i9.
dq--m27k4i3j1ifk6
LACE: bq--aqdekmkdgiaqaligaytuiizrf5dacabna4deirbdgndcorq.
bq--aqddimkdfe.bq--aydcorbdgexum
3.5 'Mahindra.com' [Hindi]:
UTF-16: U+092E U+0939 U+093F U+0928 U+094D U+0926 U+094D U+0930
U+093E . U+0935 U+094D U+092F U+093E U+092A U+093E U+0930
DUDE: dq--p2ej9vi8kdi6kdj0u.dq--p35kdifjeiajeg
LACE: bq--bees4oj7fbgsmtjqhy.bq--a4etktjphyvd4ma
3.6 'Webdunia.com' [Hindi]:
UTF-16: U+0935 U+0947 U+092C U+0926 U+0941 U+0928 U+093F U+092F
U+093E . U+0935 U+094D U+092F U+093E U+092A U+093E U+0930
DUDE: dq--p35k7icmk1i8jfifje.dq--p35kdifjeiajeg
LACE: bq--beetkrzmezasqpzphy.bq--a4etktjphyvd4ma
3.7 'Chinese Finance.com' [Traditional Chinese]
UTF-16: U+4E2D U+83EF U+8CA1 U+7D93 . c o m
DUDE: dq--ke2do3efsa1nd93.com
LACE: bq--75hc3a7prsqx3ey.com
3.8 'Chinese Readers.net' [Chinese]
UTF-16: U+842C U+7DAD U+8B80 U+8005 . U+7DB2 U+7D61
DUDE: dq--o42cndadob80g05.dq--ndb2m1
LACE: bq--76ccy7nnroaiabi.bq--aj63eyi
3.9 'Russian-Standard.com.ru' [Russian]
UTF-16: U+0440 U+0443 U+0441 U+0441 U+043A U+0438 U+0439 -
U+0441 U+0442 U+0430 U+043D U+0434 U+0430 U+0440 U+0442 .
U+043A U+043E U+043C . U+0440 U+0444
DUDE: dq--k40jhhjaop-k3ausk1ij0tkgk0i.dq--k3aus.dq--k40k
LACE: bq--a4ceaq2bie5dqoibaawqqbcbiiyd2nbqibba.bq--amcdupr4.
bq--aiceara
3.10 'Vladimir-Putin.person.ru' [Russian]
UTF-16: U+0432 U+043B U+0430 U+0434 U+0438 U+043C U+0438 U+0440 -
U+043F U+0443 U+0442 U+0438 U+043D . U+043B U+0438 U+0447
U+043D U+043E U+0441 U+0442 U+044C . U+0440 U+0444 U+0020
DUDE: dq--k32rgkosok0-k3fk3ij8t.dq--k3bok7jduk1is.dq--k40k
LACE: bq--bacdeozqgq4dyocaaeac2bieh5bueob5.
bq--bacdwochhu7ecqsm.bq--aiceara
4. Optional Case Preservation
An extension to the DUDE concept recognizes that the first
character emitted by the variable length hex encoding algorithm is
always alphabetic. We encode the case (if any) of the original Unicode
character in the case of the initial "hex" character. Because the DNS
performs case-insensitive comparisons, mixed case international domain
names behave in exactly the same way as traditional domain names.
In particular, this enables reverse lookups to return names in the
preferred case.
In contrast to other proposals as of this writing, such a case preserving
version of DUDE will interoperate with the non case preserving version.
Despite the foregoing, we feel that the additional complexity of tracking
character case through the nameprep processing is not warranted by the
marginal utility of the result.
5. Security Considerations
Much of the security of the Internet relies on the DNS and any
change to the characteristics of the DNS may change the security of
much of the Internet. Therefore DUDE makes no changes to the DNS itself.
DUDE is designed so that distinct Unicode sequences map to distinct
domain name sequences (modulo the Unicode and DNS equivalence rules).
Therefore use of DUDE with DNS will not negatively affect security below
the application level.
If an application has security reliance on the Unicode string S, produced
by an inverse ACE transformation of a name T, the application must verify
that the nameprepped and ACE encoded result of S is DNS-equivalent to T.
6. Change History
The statement that we intended to submit a Nameprep draft was removed in
light of the changes made between the frist and second nameprep drafts.
The details of DUDE extensions for case preservation etc. have been
removed. Basic DUDE was changed to operate over the relevant 20 bit
UTF32 code points.
Examples have been extended.
ACE security issues were clarified.
7. References
[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
Proposals", draft-ietf-idn-compare;
[IDNrACE] Paul Hoffman, "RACE: Row-Based ASCII Compatible Encoding for
IDN", draft-ietf-idn-race;
[IDNLACE] Mark Davis, "LACE: Length-Based ASCII Compatible Encoding for
IDN", draft-ietf-idn-lace;
[IDNREQ] James Seng, "Requirements of Internationalized Domain Names",
draft-ietf-idn-requirement;
[IDNNAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep;
[IDNDUERST] M. Duerst, "Internationalization of Domain Names",
draft-duerst-dns-i18n;
[ISO10646] ISO/IEC 10646-1:1993. International Standard -- Information
technology -- Universal Multiple-Octet Coded Character Set (UCS) --
Part 1: Architecture and Basic Multilingual Plane. Five amendments and
a technical corrigendum have been published up to now. UTF-16 is
described in Annex Q, published as Amendment 1. 17 other amendments are
currently at various stages of standardization;
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119;
[STD13] Paul Mockapetris, "Domain names - implementation and
specification", November 1987, STD 13 (RFC 1035);
[UNICODE3] The Unicode Consortium, "The Unicode Standard -- Version
3.0", ISBN 0-201-61633-5. Described at
<http://www.unicode.org/unicode/standard/versions/Unicode3.0.html>.
A. Acknowledgements
The structure (and some of the structural text) of this document is
intentionally borrowed from the LACE IDN draft (draft-ietf-idn-lace-00)
by Mark Davis and Paul Hoffman.
B. IANA Considerations
There are no IANA considerations in this document.
C. Author Contact Information
Mark Welter
Brian W. Spolarich
WALID, Inc.
State Technology Park
2245 S. State St.
Ann Arbor, MI 48104
+1-734-822-2020
mwelter@walid.com
briansp@walid.com
D. DUDE C++ Implementation
#include <stdio.h>
#include <string.h>
#include <ctype.h>
#include <limits.h>
#define IDN_ERROR INT_MIN
#define DUDETAG "dq--"
typedef unsigned int uchar_t;
bool idn_isRFC1035(const uchar_t * in, int len)
{
const uchar_t * end = in + len;
while (in < end)
{
if ((*in > 127) ||
!strchr("abcdefghijklmnopqrstuvwxyz0123456789-.", tolower(*in)))
return false;
in++;
}
return true;
}
static const char *hexchar = "0123456789abcdef";
static const char *leadchar = "ghijklmnopqrstuv";
/*
dudehex -- convert an integer, v, into n DUDE hex characters.
The result is placed in ostr. The buffer ends at the byte before
eop, and false is returned to indicate insufficient buffer space.
*/
static bool dudehex(char * & ostr, const char * eop,
unsigned int v, int n)
{
if ((ostr + n) >= eop)
return false;
n--; // convert to zero origin
*ostr++ = leadchar[(v >> (n << 2)) & 0x0F];
while (n > 0)
{
n--;
*ostr++ = hexchar[(v >> (n << 2)) & 0x0F];
}
return true;
}
/*
idn_dudeseg converts istr, a utf-32 domain name segment into DUDE.
eip points at the character after the input segment.
ostr points at an output buffer which ends just before eop.
If there is insufficient buffer space, the function return is false.
Invalid surrogate sequences will also cause a return of false.
*/
static bool idn_dudeseg(const uchar_t * istr, const uchar_t * eip,
char * & ostr, char * eop)
{
const uchar_t * ip = istr;
unsigned p = 0;
while (ip < eip)
{
if (*ip == '-')
*ostr++ = *ip;
else // if (validnc(*ip))
{
unsigned int c = *ip;
unsigned d = p ^ c; // d now has the difference (xor)
// between the current and previous char
int n = 1; // Count the number of significant nibbles
while (d >>= 4)
n++;
dudehex(ostr, eop, c, n);
p = c;
}
ip++;
}
*ostr = 0;
return true;
}
/*
idn_UTF32toDUDE converts a UTF-32 domain name into DUDE.
in, a UTF-32 vector of length inlen is the input domain name.
outstr is a char output buffer of length outmax.
On success, the number of output characters is returned.
On failure, a negative number is returned.
It is assumed that the input has been nameprepped.
If this routine is used in a registration context, segment and
overall length restrictions must be checked by the user.
*/
int idn_UTF32toDUDE(const uchar_t * in, int inlen, char *outstr, int outmax)
{
const uchar_t *ip = in;
const uchar_t *eip = in + inlen;
const uchar_t *ep = ip;
char *op = outstr;
char *eop = outstr + outmax - 1;
while (ip < eip)
{
ep = ip;
while ((ep < eip) && (*ep != '.'))
ep++;
const char * tagp = DUDETAG; // prefix the segment
while (*tagp) // with the tag (dq--)
{
if (op >= eop)
{
*outstr = '\0';
return IDN_ERROR;
}
*op++ = *tagp++;
}
if (idn_isRFC1035(ip, ep - ip))
{
if ((ep - ip) >= (eop - op))
{
*outstr = '\0';
return IDN_ERROR;
}
while (ip < ep)
*op++ = *ip++;
}
else
{
if (!idn_dudeseg(ip, ep, op, eop))
{
*outstr = '\0';
return IDN_ERROR;
}
}
if (op >= eop) // check for output buffer overflow
{
*outstr = '\0';
return IDN_ERROR;
}
if (ep < eip)
*op++ = *ep; // copy '.'
ip = ep + 1;
}
*op = '\0';
return (op - outstr) - 1;
}
/*
idn_DUDEsegtoUTF32 converts instr, DUDE encoded domain name segment
into UTF32.
eip points at the character after the input segment.
ostr points at an output buffer which ends just before eop.
If there is insufficient buffer space, the function return is false.
*/
static int idn_DUDEsegtoUTF32(const char * instr, int inlen,
uchar_t * outstr, int maxlen)
{
const char * ip = instr;
const char * eip = instr + inlen;
uchar_t * op = outstr;
uchar_t * eop = op + maxlen - 1;
unsigned prev = 0;
while (ip < eip)
{
if (*ip == '-')
*op++ = '-';
else
{
char c0 = tolower(*ip);
if ((c0 < 'g') || (c0 > 'v'))
return false;
ip++;
unsigned r = c0 - 'g';
int n = 1;
while (ip < eip)
{
char cl = tolower(*ip);
if ((cl >= '0') && (cl <= '9'))
{
r <<= 4;
r += cl - '0';
}
else if ((cl >= 'a') && (cl <= 'f'))
{
r <<= 4;
r += (cl - 'a') + 10;
}
else
break;
ip++;
n++;
}
if (r >= 0x0fffff)
{
return false;
}
unsigned mask = -1 << (n << 2);
unsigned cu = (prev & mask) + r;
prev = cu;
if (op >= eop)
return IDN_ERROR;
*op++ = cu;
}
}
*op = '\0';
return (op - outstr);
}
int idn_DUDEtoUTF32(const char * in, int inlen, uchar_t * outstr, int outmax)
{
const char *ip = in;
const char *eip = in + inlen;
const char *ep = ip;
uchar_t *op = outstr;
uchar_t *eop = outstr + outmax - 1;
while (ip < eip)
{
ep = ip;
while ((ep < eip) && (*ep != L'.'))
ep++;
const char * tip = ip;
const char * tagp = DUDETAG;
while (*tagp && (tip < ep) && (tolower(*tagp) == tolower(*tip)))
{
tip++;
tagp++;
}
if (*tagp)
{ // tag doesn't match, copy segment verbatim
while (ip < ep)
{
if (op >= eop)
return IDN_ERROR;
*op++ = *ip++;
}
}
else
{
ip = tip;
int rv = idn_DUDEsegtoUTF32(ip, ep - ip, op, eop - op);
if (rv < 0)
return IDN_ERROR;
op += rv;
}
*op++ = *ep;
if (!*ep)
break;
ip = ep + 1;
}
if (op >= eop)
return IDN_ERROR;
*op = '\0';
return (op - outstr) - 1;
}
/*
DUDE test driver
*/
void printres(char *title, int rv, char *buff);
void printres(char *title, int rv, uchar_t *buff);
int main(int argc, char *argv[])
{
char inbuff[512];
while (fgets(inbuff, sizeof(inbuff), stdin))
{
char cbuff[128];
uchar_t wbuff[128];
uchar_t iwbuff[128];
uchar_t *wsp = wbuff;
uchar_t wc;
int in;
int nr;
char * inp = inbuff;
wsp = wbuff;
while (sscanf(inp, "%x%n", &in, &nr) > 0)
{
inp += nr;
*wsp++ = in;
}
fprintf(stdout, "\n");
int rv;
rv = idn_UTF32toDUDE(wbuff, wsp - wbuff, cbuff, sizeof(cbuff));
printres("toDUDE", rv, cbuff);
if (rv >= 0)
{
rv = idn_DUDEtoUTF32(cbuff, rv, iwbuff, sizeof(iwbuff));
printres("toUTF32", rv, iwbuff);
}
}
return 0;
}
void printres(char *title, int rv, char *buff)
{
fprintf(stdout, "%s (%d) : ", title, rv);
if (rv >= 0)
{
unsigned char *dp = (unsigned char *) buff;
while (*dp)
{
fprintf(stdout, "%c", *dp++);
}
}
fprintf(stdout, "\n");
}
void printres(char *title, int rv, uchar_t *buff)
{
fprintf(stdout, "%s (%d) : ", title, rv);
if (rv >= 0)
{
uchar_t *dp = buff;
while (*dp)
{
fprintf(stdout, " %05x", *dp++);
}
}
fprintf(stdout, "\n");
}

514
doc/draft/draft-ietf-idn-icu-00.txt
View File

@ -1,514 +0,0 @@
IETF IDN Working Group Seungik Lee, Hyewon Shin, Dongman Lee
Internet Draft ICU
draft-ietf-idn-icu-00.txt Eunyong Park, Sungil Kim
Expires: 14 January 2001 KKU, Netpia.com
14 July 2000
Architecture of Internationalized Domain Name System
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
For restrict use of Domain Name System (DNS) for domain names with
alphanumeric characters only, there needs a way to find an Internet
host using multi-lingual domain names: Internationalized Domain Name
System (IDNS).
This document describes how multi-lingual domain names are handled in
a new protocol scheme for IDNS servers and resolvers in architectural
view and it updates the [RFC1035] but still preserves the backward
compatibility with the current DNS protocol.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
"IDNS" (Internationalized Domain Name System) is used here to
indicate a new system designed for a domain name service, which
supports multi-lingual domain names.
"The current/conventional DNS" or "DNS" (Domain Name System) is used
here to indicate the domain name systems currently in use. It
fulfills the [RFC1034, RFC1035], but implementations and functional
operations may be different from each other.
The "alphanumeric" character data used here is the character set that
is allowed for a domain name in DNS query format, [a-zA-Z0-9-].
3. Introduction
Domain Name System (DNS) has eliminated the difficulty of remembering
the IP addresses. As the Internet becomes spread over all the people,
the likelihood that the people who are not familiar with alphanumeric
characters use the Internet increases. The domain names in
alphanumeric characters are difficult to remember or use for the
people who is not educated English. Therefore, it needs a way to find
an Internet host using multi-lingual domain name: Internationalized
Domain Name System.
3.1 The current issues of IDNS
IDNS maps a name to an IP address as the typical DNS does, but it
allows domain names to contain multi-lingual characters. The multi-
lingual characters need to be encoded/decoded into one standardized
format, and it needs changes in the conventional DNS protocol
described in [RFC1034] and [RFC1035]. But it is required to minimize
the changes in the present DNS protocol so that it guarantees the
backward compatibility.
The IDNS issues have been discussed in IETF IDN Working Group. These
issues are well described in [IDN-REQ]. The main issues are:
- Compatibility and interoperability. The DNS protocol is in use
widely in the Internet. Although a new protocol is introduced for DNS,
the current protocol may be used with no changes. Therefore, a new
design for DNS protocol, IDNS must provide backward compatibility and
interoperability with the current DNS.
- Internationalization. IDNS is on the purpose of using multi-lingual
domain names. The international character data must be represented by
one standardized format in domain names.
- Canonicalization. DNS indexes and matches domain names to look up a
domain name from zone data. In the conventional DNS, canonicalization
is subjected to US-ASCII only. However, every multi-lingual character
data must be canonicalized in its own rules for a DNS standardized
matching policy, e.g. case-insensitive matching rule.
- Operational issues. IDNS uses international character data for
domain names. Normalization and canonicalization of domain names are
needed in addition to the current DNS operations. IDNS also needs an
operation for interoperability with the current DNS. Therefore, it is
needed to specify the operational guidelines for IDNS.
3.2 Overview of the proposed scheme
Our proposed scheme for IDNS is also subjected on the issues
described earlier to fulfill the requirements of IDN [IDN-REQ].
The proposed scheme can be summarized as following:
- The IN bit, which is reserved and currently unused in the DNS
query/response format header, is used to distinguish between the
queries generated by IDNS servers or resolvers and those of non-IDNS
ones [Oscarsson]. This mechanism is also needed to indicate whether
the query is generated by the appropriate IDNS operations for
canonicalization and normalization or not.
- The multi-lingual domain names are encoded into UTF-8 as a wire
format. UTF-8 is recommended as a default character encoding scheme
(CES) in the creation of new protocols which transmit text in
[RFC2130]. This scheme allows the IDNS server to handle the DNS query
from non-IDNS servers or resolvers because the ASCII code has no
changes in UTF-8.
- The UTF-8 domain names must be case-folded before transmission. It
minimizes the overhead on server's operations of matching names in
case-insensitive. It also guarantees that the result of caching
queries can be used without any further normalization and
canonicalization. If IDNS server gets non-IDNS query that is not
case-folded, it case-folds the query before transmitting to another
servers.
4. Design considerations
Our proposed scheme is designed to fulfill the requirements of IETF
IDN WG [IDN-REQ]. All the methods for IDNS schemes must be approved
by the requirements documents. The design described in this document
is based on these requirements.
4.1 Protocol Extensions
To indicate an IDNS query format, we use an unallocated bit in the
current DNS query format header, named 'IN' bit [Oscarsson]. All IDNS
queries are set IN bit to 1. Without this bit set to 1, we cannot
guarantee that the query is in the appropriate format for IDNS.
'IN' bit is to indicate whether the query is from IDNS
resolvers/servers or not. It also reduces overhead on canonicalizing
operation at IDNS server. It will be described further in <4.4.
Canonicalization>.
We devise new operations and new structures of resolvers and name
servers to add the multi-lingual domain name handling features into
the DNS. This causes changes of all DNS servers and resolvers to use
multi-lingual domain names. The new architectures for resolvers and
servers will be described in <5. Architectures>
4.2 Compatibility and interoperability
The 'IN' bit is valid bit location of query for the conventional DNS
protocol to be set to zero [RFC1035]. And operations and structures
of IDNS preserve the conventional rules of DNS to guarantee the
interoperability with the conventional DNS servers or resolvers so
that the changes are optional. These make this scheme for IDNS
compatible with the current protocol.
Although the current DNS protocol uses 7-bit ASCII characters only,
the query format of the current DNS protocol set is 8 bit-clean.
Therefore, we can guarantee the backward compatibility and
interoperability with the current DNS using UTF-8 code because the
ASCII code is preserved with no changes in UTF-8.
Note: There are also in use implementations that are compatible with
the current DNS but extend their operations to use UTF-8 domain names.
The IDNS described here interoperates well with these implementations.
The interoperability with these implementations will be described in
<5.4 Interoperability with the current DNS>.
4.3 Internationalization
All international character data must be represented in one
standardized format and the standardized format must be compatible
with the current ASCII-based protocols. Therefore, the coded
character set (CCS) for IDNS protocol must be Unicode [Unicode], and
be encoded using the UTF-8 [RFC2279] character encoding scheme (CES).
The client-side interface may allow the domain names encoded in any
local character sets, Unicode, ASCII and so on. But they must be
encoded into Unicode before being used in IDNS resolver. The IDNS
resolver accepts Unicode character data only, and converts it to UTF-
8 finally for transmission.
4.4 Canonicalization
In the current DNS protocol, the domain names are matched in case-
insensitive. Therefore, the domain names in a query and zone file
must be case-folded before equivalence test.
The case-folding issue has been discussed for a long time in IETF IDN
WG. The main problem is for case folding in locale-dependent. Some
different local characters are overlapped within case-folded format.
For example, Latin capital letter I (U+0049) case-folded to lower
case in the Turkish context will become Latin small letter dotless i
(U+0131). But in the English context, it will become Latin small
letter i (U+0069)
Therefore, we case-fold the domain names in locale-independent in our
new IDNS design with a method defined in [UTR21].
Multi-lingual domain names should be case-folded in IDNS resolvers or
IDNS servers before transmitting to other IDNS/DNS servers. That is,
IDNS resolver should case-fold the domain name and converts it to
UTF-8 before transmission. In case of IDNS server, if it gets a query
with IN bit set to 1, then it needs not to make the multi-lingual
domain name canonicalized anymore. If the IDNS server gets a query
with IN bit set to 0, then it cannot determine the query is
appropriate canonicalized format for IDNS server, so that it case-
folds that multi-lingual domain name in the query, and set 'IN' bit
to 1.
The current DNS queries contain the original case of domain names to
preserve the original cases. To be consistent with this rule, all
case-folded multi-lingual domain names should be stored by IDNS
resolvers or servers before case-folding, and should be restored
before sending response.
In the case of case-folding UTF-8 code, using the case-folding method
in [UTR21], the UTF-8 should be converted to Unicode and it must be
mapped to the mapping table finally. Of course that if we could make
a case-folding mapping table of UTF-8 character data, this overhead
could be reduced.
However it cannot avoid an overhead in IDNS servers for
canonicalization, because the canonicalization of international
character data is complicated.
To minimize this overhead, we use 'IN' bit to indicate that the
canonicalization for the query has been already handled. That means
it needs not canonicalization operation anymore. The detailed
operations according to the 'IN' bit are described later in <5.
Architectures>.
With international character data, the canonicalization (e.g. case-
folding) is much more complicated than the one with US-ASCII, and is
different from each other's by their locale contexts.
But this document doesn't specify any method or recommendation more
than case-folding. For canonicalization of international character
data, [UTR15] is a good start. It must be discussed further and
specified in the IDNS protocol specification.
4.5 Operational issues
In the current DNS scheme, it uses only ASCII code for a wire format.
But our new IDNS scheme uses UTF-8 code for a wire format. All the
IDNS resolvers must transmit queries encoded in UTF-8 and case-folded.
This format can be guaranteed by checking the IN bit: if IN bit is
set to 1, the query is encoded in UTF-8 and case-folded. Otherwise
the IDNS server cannot assure that the query is encoded in UTF-8 and
case-folded. Therefore it needs additional operations for encoding to
UTF-8 and case-folding, etc in this case.
The current DNS resolvers transmit the queries in ASCII code. But
it's not considerable in IDNS servers because the ASCII code is
preserved with no changes in UTF-8.
Some applications and resolvers transmit the queries in UTF-8
although they don't fit on the new IDNS resolvers' structures, e.g.
Microsoft's DNS servers. We cannot guarantee that those queries are
case-folded correctly. Therefore, the IDNS servers should convert
them to appropriate IDNS queries instead of the IDNS resolver in that
case.
All detailed operations of IDNS servers and resolvers are described
in <5. Architectures>.
5. Architectures
5.1 New header format
A new IDNS servers and resolvers must interoperate with the ones of
current DNS. Therefore, we need a way to determine whether the query
is for IDN or not. For this reason, we use a new header format as
proposed in [Oscarsson].
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|QR| Opcode |AA|TC|RD|RA|IN|AD|CD| RCODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| QDCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ANCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| NSCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ARCOUNT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The IDNS resolvers and servers identify themselves in a query or a
response by setting the 'IN' bit to 1 in the DNS query/response
format header. This bit is defined to be zero by default in the
current DNS servers and resolvers.
5.2 Structures of IDNS resolvers
To use multi-lingual domain names with IDNS servers, all the IDNS/DNS
resolvers must generate the query in a format of UTF-8 or ASCII. The
design of a resolver could be different with each other according to
the local operating systems or applications. We propose new design
guidelines of a resolver for a new standardization.
The IDNS resolver accepts Unicode from user interface for domain
names. The other character sets should be rejected. It encodes all
such character data into UTF-8 for transmission to name servers.
The procedures of the operation of an IDNS resolver are below:
<1>. If the resolver gets a domain name in Unicode or ASCII then it
stores the original domain name query. Otherwise the request for
lookup is rejected. In the current DNS protocol, the original case of
the domain name should be preserved. Therefore, the resolver must
store the original cases of the domain names before canonicalization
(e.g. case-folding).
<2>. Make the domain name case-folded with locale-independent case-
mapping table defined in [UTR21].
<3>. Convert it to UTF-8.
<4>. Set IN bit to 1. It indicates the query is from IDNS resolver
and the format is UTF-8, case-folded.
<5>. Send request query to name servers.
<6>. Restore the original domain name query into the response query
format.
<7>. Send response to the application.
5.3 Structures of IDNS servers
The operation of IDNS server is similar to the current one of DNS
server, but the IDNS server accepts UTF-8 queries and converts them
to the appropriate formats additionally.
The IDNS server distinguishes between the IDNS queries and DNS
queries by checking IN bit in the query/response format header.
According to the 'IN' bit, it operates differently.
The procedures of the operation of an IDNS server are below:
<1>. If the IN bit in the query/response format header is set to 1
then it matches the domain name within zone file data or forwards
request query to resolve. It operates as same as the operations of
the current DNS servers but retrieves UTF-8 code. In this case, it
needs not to make domain name canonicalized because the domain name
is already canonicalized in the previous procedures of IDNS resolvers
or IDNS servers. Go to step <7>.
<2>. Set IN bit to 1.
<3>. Store the original domain name query.
<4>. Make the domain name case-folded with locale-independent case-
mapping table defined in [UTR21].
<5>. Match the domain name within zone file data or send request
query to lookup.
<6>. Restore the original domain name query into the response query
format.
<7>. Send response for the query to the resolver or the other server
requested.
5.4 Interoperability with the current DNS
The DNS servers and resolvers accept domain names in ASCII only. But
IDNS servers and resolvers accept domain names in UTF-8. Therefore,
the queries from DNS ones to IDNS ones can be well handled because
the UTF-8 is a superset of ASCII code. But the queries from IDNS ones
to DNS ones will be rejected because the UTF-8 code is beyond the
range of ASCII code.
Note: There are some implementations which can handle UTF-8 domain
names although they don't fit on this specification of IDNS and fully
implemented with DNS protocol specification, e.g. Microsoft's DNS
server and resolvers. In this case, we cannot guarantee that the
queries from these 3rd-party implementations are encoded into UTF-8
and well canonicalized. But this queries are set 'IN' bit to 0, so
that the IDNS evaluates whether the domain name is the range of UTF-8
or not, and converts it into UTF-8 and makes it canonicalized finally.
6. Security Considerations
This architecture of IDNS uses 8bit-clean queries for transmission
and the UTF-8 code is handled instead of ASCII. The DNS protocol has
already allocated 8bit query format for domain names Therefore, the
IDNS protocol inherits the security issues for the current DNS.
Canonicalization of IDNS is defined in [UTR15] and case folding in
[UTR21]. All security issues related with canonicalization or
normalization inherits ones described in [UTR15, UTR21].
As always with data, if software does not check for data that can be
a problem, security may be affected. As more characters than ASCII is
allowed, software only expecting ASCII and with no checks may now get
security problems.
7. References
[IDN-REQ] James Seng, "Requirements of Internationalized Domain
Names," Internet Draft, June 2000
[KWAN] Stuart Kwan, "Using the UTF-8 Character Set in the
Domain Name System," Internet Draft, February 2000
[Oscarsson] Dan Oscarsson, "Internationalisation of the Domain Name
Service," Internet Draft, February 2000
[RFC1034] Mockapetris, P., "Domain Names - Concepts and
Facilities," STD 13, RFC 1034, USC/ISI, November 1987
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification," STD 13, RFC 1035, USC/ISI, November
1987
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119, March 1997
[RFC2130] C. Weider et. Al., "The Report of the IAB Character Set
Workshop held 29 February - 1 March 1996," RFC 2130,
Apr 1997.
[RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO
10646," RFC 2279, January 1998
[RFC2535] D. Eastlake, "Domain Name System Security Extensions,"
RFC 2535, March 1999
[UNICODE] The Unicode Consortium, "The Unicode Standard - Version
3.0," http://www.unicode.org/unicode/
[UTR15] M. Davis and M. Duerst, "Unicode Normalization Forms",
Unicode Technical Report #15, Nov 1999,
http://www.unicode.org/unicode/reports/tr15/
[UTR21] Mark Davis, "Case Mappings," Unicode Technical Report
#21, May 2000,
http://www.unicode.org/unicode/reports/tr21
8. Acknowledgments
Kyoungseok Kim <gimgs@asadal.cs.pusan.ac.kr>
Chinhyun Bae <piano@netpia.com>
9. Author's Addresses
Seungik Lee
Email: silee@icu.ac.kr
Hyewon Shin
Email: hwshin@icu.ac.kr
Dongman Lee
Email: dlee@icu.ac.kr
Information & Communications University
58-4 Whaam-dong Yuseong-gu Taejon, 305-348 Korea
Eunyong Park
Email: eunyong@eunyong.pe.kr
Konkuk University
93-1 Mojindong, Kwangjin-ku Seoul, 143-701 Korea
Sungil Kim
Email: clicky@netpia.com
Netpia.com
35-1 8-ga Youngdeungpo-dong Youngdeungpo-gu Seoul, 150-038 Korea

19
doc/draft/draft-ietf-idn-icu-01.txt Normal file
View File

@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
E. Park: eunyong@eunyong.pe.kr

103
doc/draft/draft-ietf-idn-idne-01.txt → doc/draft/draft-ietf-idn-idne-02.txt
View File

@ -1,9 +1,9 @@
Internet Draft Marc Blanchet
draft-ietf-idn-idne-01.txt Viagenie
July 8, 2000 Paul Hoffman
draft-ietf-idn-idne-02.txt Viagenie
March 19, 2001 Paul Hoffman
Expires in six months IMC & VPNC
Internationalized domain names using EDNS (IDNE)
Internationalized domain names using EDNS (IDNE)
Status of this Memo
@ -19,11 +19,11 @@ and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
@ -98,11 +98,11 @@ new extended label type for IDNE is used to identify an IDNE label. This
document uses 0b000010 as the extended label type; however, the label
type will be assigned by IANA and it may not be 0b000010.
0 1 2
0 1 2
bits 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
|0 1| ELT | Size | IDN label ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
|0 1| ELT | Size | IDN label ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
ELT: The six-bit extended label type to be assigned by the IANA for an
@ -134,20 +134,20 @@ then transformed using UTF-8 [RFC2279] to 0x6DC3A9.
Ignoring the other fields of the message, the domain name portion of the
datagram could look like:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | 0 1 0 0 0 0 1 0| 0 0 0 0 0 0 1 1|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | 0x6D (m) | 0xC3 (e'(1)) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | 0xA9 (e'(2)) | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | 0x63 (c) | 0x6F (o) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 | 0x6D (m) | 0x00 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | 0 1 0 0 0 0 1 0| 0 0 0 0 0 0 1 1|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | 0x6D (m) | 0xC3 (e'(1)) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | 0xA9 (e'(2)) | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | 0x63 (c) | 0x6F (o) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 | 0x6D (m) | 0x00 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Octet 20 means EDNS extended label type (0b01) using the IDN label
type (0b000010)
type (0b000010)
Octet 21 means size of label is 3 octets following
Octet 22-24 are the "m*" label encoded in UTF-8
Octet 25-28 are "com" encoded as a STD13 label
@ -161,25 +161,25 @@ Using the previous labels, one datagram might contain "www.m*.com" and
Ignoring the other fields of the message, the domain name portions of
the datagram could look like:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | 0 1 0 0 0 0 1 0| 0 0 0 0 0 0 1 1|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | 0x6D (m) | 0xC3 (e'(1)) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | 0xA9 (e'(2)) | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | 0x63 (c) | 0x6F (o) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 | 0x6D (m) | 0x00 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. . .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 | 3 | 0x77 (w) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 | 0x77 (w) | 0x77 (w) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1| 20 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
20 | 0 1 0 0 0 0 1 0| 0 0 0 0 0 0 1 1|
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
22 | 0x6D (m) | 0xC3 (e'(1)) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
24 | 0xA9 (e'(2)) | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
26 | 0x63 (c) | 0x6F (o) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
28 | 0x6D (m) | 0x00 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. . .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
40 | 3 | 0x77 (w) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
42 | 0x77 (w) | 0x77 (w) |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
44 | 1 1| 20 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The domain name "m*.com" is shown at offset 20. The domain name
"www.m*.com" is shown at offset 40; this definition uses a pointer to
@ -405,23 +405,9 @@ Bill Sommerfeld
Francois Yergeau
B. Changes from -00 to -01
B. Changes from -01 to -02
1.1: Added reference to Unicode names.
3: Clarified that a size of zero is not allowed.
3.1.1 and 3.1.2: Fixed two very serious errors in the examples.
6: Removed second paragraph, which was redundant with 7.3.
12: Beefed up the security considerations.
13: Added [ISO10646] and [UNICODE3].
Added Appendix A.
Added Appendex B.
None.
C. Authors' Addresses
@ -438,4 +424,3 @@ Internet Mail Consortium and VPN Consortium
Santa Cruz, CA 95060 USA
phoffman@imc.org

334
doc/draft/draft-ietf-idn-idnra-00.txt
View File

@ -1,334 +0,0 @@
Internet Draft Paul Hoffman
draft-ietf-idn-idnra-00.txt IMC & VPNC
August 17, 2000 Patrik Faltstrom
Expires in six months Cisco
Internationalized Host Names
Using Resolvers and Applications (IDNRA)
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The current DNS infrastructure does not provide a way to use
internationalized host names (IDN). This document describes a mechanism
that requires no changes to any DNS server that will allow
internationalized host names to be used by end users with changes only
to resolvers and applications. It allows flexibility for user input and
display, and assures that host names that have non-ASCII characters are
not sent to servers.
1. Introduction
In the discussion of IDN solutions, a great deal of discussion has
focused on transition issues and how IDN will work in a world where not
all of the components have been updated. Earlier proposed solutions
require that user applications, resolvers, and DNS servers to be updated
in order for a user to use an internationalized host name. Instead of
this requirement for widespread updating of all components, the current
proposal is that only user applications and the resolvers on user's
systems be updated; no changes are needed to the DNS protocol or any DNS
servers. We also show that it is enough to update only the application,
and at the same time an encoded version of the host name can be used
even in current existing applications.
The proposal is called IDNRA because it only requires changes to
resolvers and applications (the "R" and "A" in the name).
1.1 Design philosophy
To date, the proposals for IDN protocols have required that DNS servers
be updated to handle internationalized host names. Because of this, the
person who wanted to use an internationalized host name had to be sure
that their request went to a DNS server that was updated for IDN.
Further, that server could only send queries to other servers that had
been updated for IDN because the queries contain new protocol elements
to differentiate IDN name parts from current host parts. In addition,
these proposals require that resolvers must be updated to use the new
protocols, and in most cases the applications would need to be updated
as well.
Updating all (or even a significant percentage) of the DNS servers in
the world will be difficult, to say the least. Because of this, we have
designed a protocol that requires no updating of any name servers. IDNRA
still requires the updating of applications and resolvers, but once a
user has updated these, she or he could immediately start using
internationalized host names. The cost of implementing IDN would thus be
much lower, and the speed of implementation will be much higher.
IDNRA also specifies how to use old applications and/or old resolvers in
parallel with updated ones.
1.2 Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and
"MAY" in this document are to be interpreted as described in RFC 2119
[RFC2119].
1.3 IDN summary
Using the terminology in [IDNCOMP], this protocol specifies an IDN
architecture of arch-3 (just send ACE). The format is ace-1.2 (RACE),
and the method for distinguishing ACE name parts from current name parts
is ace-2.1.1 (add hopefully-unique legal tag). Because there is no
changes needed to the DNS, the transition strategy is trans-1 (always do
current plus new architecture).
2. Structural Overview
In IDNRA, users' applications and resolvers are updated to perform the
processing needed to input internationalized host names from users,
display internationalized host names that are returned from the DNS to
users, and process the inputs and outputs from the DNS.
2.1 Interfaces between DNS components in IDNRA
The interfaces in IDNRA can be represented pictorially as:
+------+
| User |
+------+
^
| Input and display: any charset
v
+-------------+
| Application |
+-------------+
^
| API call and return: UTF-8
v
+----------+
| Resolver |
+----------+
^
| DNS query and response: RACE
v
+-------------+
| DNS servers |
+-------------+
2.1.1 Users and applications
Applications can accept host names using any character set or sets
desired by the application developer, and can display host names in any
charset. That is, this protocol does not affect the interface between
users and applications.
An IDNRA-aware application can accept and display internationalized host
names in two formats: the internationalized character set(s) supported
by the application, and in RACE [RACE] ASCII-compatible encoding.
Applications MAY allow RACE input and output, but are not encouraged to
do so except as an interface for advanced users, possibly for debugging.
RACE encoding is opaque and ugly, and should thus only be exposed to
users who absolutely need it. The optional use, especially during a
transition period, of RACE encodings in the user interface is described
in section 3.
2.1.2 Applications and resolvers
Applications communicate with resolver libraries through a programming
interface (API). Typically, the IETF does not standardize APIs, although
it has for IPv6. This protocol does not specify a specific API, but
instead specifies only the input and output formats of the host names to
the resolver library.
This protocol specifies that host names SHOULD be passed to resolvers
using UTF-8 [RFC2279] because there are many libraries for converting
between arbitrary charsets and UTF-8. However, because the API is not
specified in this document, some resolvers may use different charsets
for input and output, and applications must, of course, use the same
charset as the resolver library they call.
IDNRA-aware applications MUST be able to work with both IDNRA-aware and
non-aware resolvers. An IDNRA-aware application that is resolving a
non-internationalized host name (one that conforms to RFC 1035[STD13])
MUST use non-aware APIs such as "gethostbyname" and "gethostbyaddr". An
IDNRA-aware application that is resolving a internationalized host name
(one that does not conform to RFC 1035) MUST use an API that is specific
to IDNRA.
2.1.3 Resolvers and DNS servers
Before converting the name parts into RACE, the resolver MUST prepare
each name part as specified in [NAMEPREP]. The resolver MUST use RACE
ASCII-compatible encoding for the name parts that are sent in the DNS
query, and will always get name parts encoded in RACE from the DNS
service. DNS servers MUST use the RACE format for internationalized host
name parts.
If a signalling system which makes negotiation possible between old and
new DNS clients and servers is standardized in the future, the encoding
of the query in the DNS protocol itself can be changed from RACE to
something else, such as UTF-8. The question whether or not this should
be used is, however, a separate problem and is not discussed in this
memo.
3. Combinations of Resolvers and Applications
IDNRA allows non-IDNRA applications to coexist with IDNRA-aware
resolvers, and non-IDNRA resolvers to coexist with IDNRA-aware
applications. This section describes the interactions between
applications and resolvers as users update each separately.
In this section, "old" means an application or resolver that has not bee
upgraded to be IDNRA-aware, and "new" means an IDNRA-aware application
or resolver. The two APIs are also called "old" and "new". "Binary"
means any host name that is not compatible with current DNS character
restrictions.
3.1 Old application, old resolver
Because it is an old resolver (and an old application), all host names
MUST (and will) be resolved using the old API. A user cannot enter
binary names in the application. A user MAY enter a name that uses RACE
encoding. Each RACE-encoded name part in such a name MUST already have
had all name preparation done on it and be correctly converted to RACE
encoding; otherwise, it will not be matched in the DNS.
When the resolver receives a RACE name in a response to a old API
gethostbyaddr-type query, the resolver will not convert the host name to
a binary form, and the application will thus display the name in RACE
format. Showing the results of a gethostbyaddr-type queries is rare in
typical Internet applications, so the display of RACE names is not
likely in typical environments.
3.2 Old application, new resolver
Because it is an old application, all host names MUST (and will) be
resolved using the old API. A user cannot enter binary names in the
application. A user MAY enter a name that uses RACE encoding. Each
RACE-encoded name part in such a name MUST already have had all name
preparation done on it and be correctly converted to RACE encoding;
otherwise, it will not be matched in the DNS. Note that, even though the
resolver is new, the resolver MUST NOT do further name preparation on
RACE-encoded name parts because the call was using the old API, which
tells the resolver that the resolver is dealing with an old application.
If the resolver receives a RACE name in a response to a old API
gethostbyaddr-type query, the resolver MUST NOT convert the host name to
a binary form, and the application will thus display the name in RACE
format. Showing the results of a gethostbyaddr-type queries is rare in
typical Internet applications, so the display of RACE names is not
likely in typical environments.
3.3 New application, old resolver
Because it is an old resolver, all host names MUST (and will) be
resolved using the old API. If the user enters a binary host name, the
application SHOULD reject the name as illegal. This is due to the fact
that, if the application did not reject the name as illegal, the
application would have to contain all of the name preparation logic and
RACE-encoding logic, but that logic would only be used in the rare case
where a user had updated applications but not the resolver. It is likely
that applications would not fully implement and rigorously test the name
preparation logic, and it is therefore likely that some applications in
this scenario would give incorrect information to the user, and would
possibly be susceptible to spoofing attacks. If an application is going
allow the input of binary names and convert them to their RACE-encoded
form for use on the old API, the application MUST do full name
preparation exactly as it would have been done in a new resolver.
If the application receives a RACE-encoded name part in a response to a
old API gethostbyaddr-type query, the application SHOULD convert the
host name to a binary form for display. However, the application MAY
have an interface that allows the display of RACE names that are
returned by gethostbyaddr-type queries, but the default setting of such
an interface SHOULD be to show the binary form, not the RACE form.
3.4 New application, new resolver
All host names MUST be resolved using the new API. A user MAY enter a
name that uses RACE encoding. Each RACE-encoded name part in such a name
MUST already have had all name preparation done on it and be correctly
converted to RACE encoding; otherwise, it will not be matched in the
DNS.
When the resolver receives a RACE name in a response to a
gethostbyaddr-type query, if the query was to the old API, the resolver
MUST NOT convert the host name and MUST pass the RACE-formatted name to
the application. If the query was to the new API, the resolver MUST
convert the host name part to the binary form. The application MAY have
an interface that allows the user to decide whether to use the old or
new API, and therefore to show the results in RACE or binary format, but
the default setting of such an interface SHOULD be to use the new API.
4. Root Server Considerations
Because there are no changes to the DNS protocols, adopting this
protocol has no effect on the root servers.
5. Security Considerations
Much of the security of the Internet relies on the DNS. Thus, any change
to the characteristics of the DNS can change the security of much of the
Internet.
Host names are used by users to connect to Internet servers. The
security of the Internet would be compromised if a user entering a
single internationalized name could be connected to different servers
based on different interpretations of the internationalized host name.
Because this document normatively refers to [NAMEPREP], it includes the
security considerations from that document as well.
6. References
[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
Proposals", draft-ietf-idn-compare.
[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
Internationalized Host Names", draft-ietf-idn-nameprep.
[RACE] RACE: Row-based ASCII Compatible Encoding for IDN,
draft-ietf-idn-race.
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119.
[RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
10646", January 1998, RFC 2279.
[STD13] Paul Mockapetris, "Domain names - implementation and
specification", November 1987, STD 13 (RFC 1035).
A. Authors' Addresses
Paul Hoffman
Internet Mail Consortium and VPN Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
phoffman@imc.org
Patrik Faltstrom
Cisco Systems
170 W Tasman Drive SJ-13/2
San Jose, CA 9 5134 USA
paf@cisco.com

20
doc/draft/draft-ietf-idn-idnra-01.txt Normal file
View File

@ -0,0 +1,20 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
P. Hoffman: phoffman@imc.org
P. Faltstrom: paf@cisco.com

276
doc/draft/draft-ietf-idn-sace-00.txt
View File

@ -1,276 +0,0 @@
Internet Draft Dan Oscarsson
draft-ietf-idn-sace-00.txt Telia ProSoft
Expires: 27 February 2001 27 August 2000
Simple ASCII Compatible Encoding (SACE)
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a way to encode non-ASCII characters in host
names in a way that is completely compatible with the current ASCII
only host names that are used in DNS. It can be used both with DNS to
support software only handling ASCII host names and as a way to
downgrade from 8-bit text to ASCII in protocols.
1. Introduction
This document defines an ASCII Compatible Encoding (ACE) of names
that can be used when communicating with DNS. It is needed during a
transition period when non-ASCII names are introduced in DNS to avoid
breaking programs expecting ASCII only.
The Simple ASCII Compatible Encoding (SACE) defined here can be
compared to [RACE]. The main differences are:
- RACE encodes by first compressing and the encoding the resulting
bit stream into ASCII. SACE encodes each character directly in one
Dan Oscarsson Expires: 27 Februray 2001 [Page 1]
Internet Draft SACE 27 August 2000
pass.
- SACE recognises that at lot of latin based names are mostly
composed of ASCII characters and gives a higher compression for
those. In the 63 byte limit of DNS RACE will allow 36 characters
for ISO 8859-1 and less if characters from the additional Latin
characters are needed. SACE will allow around 40 characters if
about 10 % of a Latin name is non-ASCII (in the UCS [ISO10646]
range 0-0x217). SACE is closer to the compression that UTF-8 have
than RACE.
- Most ASCII characters will not be encoded so Latin based names
composed of mostly ASCII characters will be somewhat readable.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Simple ASCII Compatible Encoding
The encoding encodes values using the available characters allowed in
a ASCII host name (a-z0-9 and hyphen).
Values are encoded as follows:
Character - value mapping
value character value character
0 a 18 s
1 b 19 t
2 c 20 u
3 d 21 v
4 e 22 w
5 f 23 x
6 g 24 y
7 h 25 z
8 i 26 1
9 j 27 2
10 k 28 3
11 l 29 4
12 m 30 7
13 n 31 9
14 o 32 0
15 p 33 8
16 q 34 5
17 r 35 6
Dan Oscarsson Expires: 27 Februray 2001 [Page 2]
Internet Draft SACE 27 August 2000
In the following description the following syntax will be used:
B => one value in the range 0-35 mapped to a character as above
X => one value in the range 0-31 mapped to a character as above
Each UCS character is identified as follows:
latin => a character in the range 0-0x217
10bit => a character in the range 0x218-0x2FFF
base36 => all other characters
During encoding/decoding a string a current mode is used. In each
mode characters are encoded like this:
latin => as themselves, 00 for 0, 88 for 8 or as 10 bit value
encoded as 0XX (two 5 bit values)
10bit => as 15 bits represented by its current prefix of 5 bits
followed by 10 bits encoded as XX
(the value is the 15 bits of prefix and
10 bits concatenated)
base36 => as a base 36 value represented by its current base 36
prefix followed by three base 36 digits encoded as BBB
(the value is prefix*36*36*36*36+B*36*36+B*36+B)
Before encoding the character value must first be
reduced:
if >= 0xd800 reduce by 8192 (private/surrogate start)
then reduce by 0x2FFF.
After decoding the character value need to be restored
as
add 0x2FFF
followed by adding 8192 if >= 0xd800
2.1 Decoding a string
During decode you start with:
Mode: latin
10bit prefix: 0
base36 prefix: 0
Then the characters in an encoded string are interpreted as follows
depending on current mode:
When in latin mode:
00 => the character 0
0XX => XX represents 10 bits which decodes to one character
88 => the character 8
85 => switch to 10bit mode with same prefix as last time
8X5 => switch 10 10bit mode setting X as current 10bit prefix
87 => switch to base36 mode with same prefix as last time
8X7 => switch to base36 mode setting X as current base36 prefix
Dan Oscarsson Expires: 27 Februray 2001 [Page 3]
Internet Draft SACE 27 August 2000
other => the characters represent itself
When in 10bit mode
- => the character -
0 => switch to latin mode
X5 => switch 10 10bit mode using X as current prefix
7 => switch to base36 mode with same prefix as last time
X7 => switch to base36 mode using X as current prefix
XX => current 10bit prefix plus XX gives the character
When in base36 mode
-- => the character -
-0 => switch to latin mode
-5 => switch to 10bit mode with same prefix as last time
-X5 => switch 10 10bit mode setting X as current prefix
-X7 => switch to base36 mode setting X as current prefix
XXX => current base36 prefix plus XXX as base 36 values gives
character
2.2 Encoding a string
To encode a string you start with the data as UCS characters and:
Mode: latin
10bit prefix: 0
base36 prefix: 0
Then for each UCS character, the mode and/or prefix is switched if
needed and then the character is encoded as defined above.
3. References
[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997, RFC 2119.
[RFC2279] F. Yergeau, "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[ISO10646] ISO/IEC 10646-1:2000. International Standard --
Information technology -- Universal Multiple-Octet Coded
Character Set (UCS)
[Unicode] The Unicode Consortium, "The Unicode Standard -- Version
3.0", ISBN 0-201-61633-5. Described at
http://www.unicode.org/unicode/standard/versions/
Unicode3.0.html
Dan Oscarsson Expires: 27 Februray 2001 [Page 4]
Internet Draft SACE 27 August 2000
[IDNREQ] James Seng, "Requirements of Internationalized Domain
Names", draft-ietf-idn-requirement.
[RACE] Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding
for IDN", draft-ietf-idn-race.
4. Acknowledgements
Paul Hoffman for many good ideas.
Author's Address
Dan Oscarsson
Telia ProSoft AB
Box 85
201 20 Malmo
Sweden
E-mail: Dan.Oscarsson@trab.se
Dan Oscarsson Expires: 27 Februray 2001 [Page 5]

19
doc/draft/draft-ietf-idn-sace-01.txt Normal file
View File

@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
D. Oscarsson: dan.oscarsson@trab.se

537
doc/draft/draft-ietf-idn-vidn-00.txt
View File

@ -1,537 +0,0 @@
IETF IDN Working Group Sung Jae Shim
Internet Draft DualName, Inc.
Document: draft-ietf-idn-vidn-00.txt 14 November 2000
Expires: 14 May 2001
Virtually Internationalized Domain Names (VIDN)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document describes a method that internationalizes existing as
well as future domain names in English, not making any change to the
current DNS, not requiring separate name server or resolver, and not
creating domain names in non-English languages. Based upon the
knowledge of transliteration between a local language and English,
the method allows a user to use virtual domain names in the user's
preferred local language by converting them into the corresponding
actual domain names in English that comply with the current DNS. The
conversion takes place automatically and transparently in the user's
applications before DNS queries are sent. The method uses the current
DNS as it is and meets all the requirements of internationalized
domain names as described in Wenzel and Seng [2].
2. Conventions and definitions used in this document
The key words "REQUIRED" and "MAY" in this document are to be
interpreted as described in RFC-2119 [1].
A "host" is a computer or device attached to the Internet. A "user
host" is a computer or device with which a user is connected to the
Virtually Internationalized Domain Names November 2000
Internet, and a "user" is a person who uses a user host. A "server
host" is a computer or device that provides services to user hosts.
An "entity" is an organization or individual that has a domain name
registered with the DNS.
A "local language" is a language other than English that a user
prefers to use in a local context.
A "virtual domain name" is a domain name in a local language, and it
is not registered with the DNS but used for the convenience of a
user. An "actual domain name" is a domain name in English, and it is
actually used in the DNS. A "domain name" refers to an actual domain
name in English that complies with the DNS, unless specified
otherwise.
A "coded portion" is a pre-coded portion of a domain name (e.g.,
generic organization codes including `com', `edu', `gov', `int',
`mil', `net', `org', and country codes such as `kr', `jp', and so
on). An "entity-defined portion" is a portion of a domain name, which
is defined by the entity that holds the domain name (e.g.,
organization name, server name, and so on).
The method proposed in this document is called "virtually
internationalized domain names (VIDN)" because it uses virtual domain
names in local languages to internationalize actual domain names in
English that comply with the DNS.
A number of Korean-language characters are used in the original of
this document for examples, which is available from the author upon
request. The software used for Internet-Drafts does not allow using
multilingual characters other than ASCII characters. Thus, this
document may not display Korean-language characters properly,
although it may be comprehensible without the examples using Korean-
language characters. Also, when you open the original of this
document, please select your view encoding type to Korean for Korean-
language characters to be displayed properly.
3. Introduction
Domain names are valuable to Internet users as a main identifier of
hosts on the Internet. The current DNS allows using only English
characters in naming hosts or clusters of hosts on the Internet. More
specifically, the DNS uses only the basic Latin alphabets (case-
insensitive), the decimal digits (0-9) and the hyphen (-) in domain
names. But there is a growing need for internationalized or non-
English domain names. Recognizing this need, various methods have
been proposed to use non-English characters in domain names. But to
date, it seems that no method has met all the requirements of
internationalized domain names as described in Wenzel and Seng [2].
A group of earlier methods has tried to put internationalized domain
names inside some parts of the overall DNS system, using UCS encoding
Virtually Internationalized Domain Names November 2000
schemes. But these methods put too much of a burden on the DNS,
requiring a great deal of work for transition and update of the DNS
components. Another group of earlier methods has tried to build
separate directory services for internationalized domain names or
internationalized keywords. But these methods also require complex
implementation efforts, duplicating much of the work already done for
the DNS. Both the groups of earlier methods have tried to build some
mechanisms inside or outside the DNS and put internationalized domain
names or internationalized keywords there in addition to existing
domain names in English.
Unlike earlier methods that involve a lengthy and costly process of
implementation, VIDN provides a more immediate and less costly
solution to internationalized domain names by focusing on
internationalizing existing as well as future domain names in English
that comply with the current DNS, without actually creating domain
names in local languages. VIDN takes notice of the fact that most
domain names used in regions where English is not widely spoken, have
their entity-defined portions consisting of characters or words in
English as transliterated from characters and words in the respective
local languages. Based upon the knowledge of transliteration between
a local language and English, VIDN allows using virtual domain names
in a local language by converting them into the corresponding actual
domain names in English that comply with the current DNS. VIDN allows
the same domain names to be used not only in English as usual but
also in local languages, without creating additional domain names in
local languages.
4. VIDN method
4.1. Objectives
To date, the methods for internationalized domain names have tried to
create domain names or keywords in local languages one way or another
in addition to existing domain names in English, and put them inside
or outside the DNS, using special encoding schemes or lookup
services. These methods require a lengthy and costly process of
implementation. Even when they are successfully implemented, these
methods may localize the Internet by separating it into groups of
local languages that are less universal than English. Further, these
methods may cause disputes on copyrights, trademarks, and so on in
local contexts, in addition to all those disputes we observe with
current domain names in English. VIDN intends to provide a solution
to the problems of earlier methods, by (1) allowing the same domain
names to be used both in English and local languages, without
creating domain names in local languages, (2) working in applications
at user hosts automatically and transparently before DNS requests are
sent, (3) using the current DNS as it is, without requiring any
additional name server or resolver, and (4) being implemented
immediately with little cost.
4.2. Description
Virtually Internationalized Domain Names November 2000
It is important to note that most domain names used in regions where
English is not widely spoken have their entity-defined portions
consisting of characters or words in English as transliterated from
characters or words in local languages. These transliterated
characters or words in English do not have any meanings in English,
but their originals in local languages before the transliteration
into English have some meanings in local contexts, usually indicating
organization names, brand names, trademarks, and so on. VIDN allows
using these original characters or words in local languages as the
entity-defined portions of virtual domain names in local languages,
by transliterating them into the corresponding entity-defined
portions of actual domain names in English. In this way, VIDN allows
the same domain names in English to be also used virtually in local
languages without actually creating domain names in local languages.
As domain names overlay IP addresses, so virtual domain names in
local languages do actual domain names in English. The relationship
between virtual domain names in a local language and actual domain
names in English can be depicted as:
+---------------------------------+
| User |
+---------------------------------+
| |
+----------------|-----------------------|------------------+
| v (Transliteration) v |
| +---------------------+ | +-----------------------+ |
| | Virtual domain name | | | Actual domain name | |
| | in a local language |--+->| in English | |
| +---------------------+ +-----------------------+ |
| User application | |
+----------------------------------------|------------------+
v
DNS request
VIDN uses the phonemes of a local language and English as a medium in
transliterating the entity-defined portions of virtual domain names
in the local language into those of actual domain names in English.
This process of transliteration can be depicted as:
Local language English
+----------------------------+ +-----------------------------+
| Characters ----> Phonemes -----------> Phonemes ----> Characters |
| | | | | | |
| | | | | | |
| (Inverse of transcription) | Match | (Transcription) |
+----------------------------+ +-----------------------------+
| ^
| (Transliteration) |
+------------------------------------+
First, each entity-defined portion of a virtual domain name in the
local language is decomposed into individual characters or sets of
Virtually Internationalized Domain Names November 2000
characters so that each individual character or set of characters can
represent an individual phoneme of the local language, which is the
inverse of transcription of phonemes into characters. Second, each
individual phoneme of the local language is matched with an
equivalent phoneme of English that has the same or most proximate
sound. Third, each phoneme of English is transcribed into the
corresponding character or set of characters in English. Finally, all
the characters or sets of characters converted into English are
united to compose the corresponding entity-defined portion of an
actual domain name in English.
For example, a word in Korean, `??' that means `century' in English,
is transliterated into `segi' in English, and so, the entity whose
name contains `??' in Korean may have an entity-defined portion of
its domain name as `segi' in English. VIDN allows using `??' in
Korean as an entity-defined portion of a virtual domain name in
Korean, which is converted into `segi' in English, the corresponding
entity-defined portion of an actual domain name in English. More
specifically, the phonemes represented by the characters consisting
of `??' in Korean have the same sounds as the phonemes represented
by the characters consisting of `segi' in English. In the local
context, `??' in Korean is clearly easier to remember and type and
more intuitive and meaningful than `segi' in English.
An entity-defined portion of a virtual domain name in Korean, `??',
is transliterated into `yahoo' in English, since the phonemes
represented by the characters consisting of `??' in Korean have the
same sounds as the phonemes represented by the characters consisting
of `yahoo' in English. That is, `??' in Korean is pronounced as the
same as `yahoo' in English, and so, it is easy for Korean-speaking
people to deduce `??' in Korean as the virtual equivalent of
`yahoo' in English. VIDN allows using virtual domain names in a local
language for domain names whose originals are in the local language,
e.g., `??' in Korean, as well as domain names whose originals are
in English, e.g., `??' in Korean. In this way, VIDN can make domain
names truly international, allowing the same domain names to be used
both in English and local languages.
The coded portions of domain names such as organization codes,
geographic codes and country codes, can also be transliterated from a
local language into English, using the phonemes of the two languages
as a medium. For example, seven generic organization codes in English,
`com', `edu', `gov', `int', `mil', `net', and `org', can be
transliterated from `?', `??', `??', `??', `?', `??', `??' in
Korean, respectively, which can be used as the corresponding
organization codes of virtual domain names in Korean. Based upon its
meaning in English, each coded portion of actual domain names also
can be pre-assigned a virtual equivalent word or code in a local
language. For example, seven generic organization codes in English,
`com', `edu', `gov', `int', `mil', `net', and `org', can be pre-
assigned `??' (meaning `commercial' in Korean), `??' (meaning
`education' in Korean), `??' (meaning `government' in Korean),
`??' (meaning `international' in Korean), `??' (meaning `military'
in Korean), `??' (meaning `network' in Korean), and `??' (meaning
Virtually Internationalized Domain Names November 2000
`organization' in Korean), respectively, which can be used as the
corresponding organization codes of virtual domain names in Korean.
Since VIDN uses the phonemes of a local language and English as a
medium of the transliteration, it does not create such complexities
as other conversion methods based upon semantics do. Further, most
languages have a small number of phonemes. For example, Korean
language has nineteen consonant phonemes and twenty-one vowel
phonemes, and English language has twenty-four consonant phonemes and
twenty vowel phonemes. Each phoneme of Korean language can be matched
with a phoneme of English language that has the same or proximate
sound, and vice versa.
Some characters or sets of characters of a language may represent
more than one phoneme. Also, some phonemes of a language may be
represented by more than one character or set of characters. But
these variations usually occur in particular situations, and so, VIDN
incorporates the special provisions to deal with such variations. In
addition, not every character or set of characters in a local
language may be neatly transliterated into only one character or set
of characters in English. In practice, people often transliterate the
same word in a local language differently into English or vice versa.
VIDN also incorporates the provisions to deal with such variations
caused by common usages or idiomatic expressions. Because of these
variations, however, it is probable for one virtual domain name
entered in a local language to result in more than one actual domain
name in English.
VIDN includes a coding scheme in order to make each virtual domain
name entered in a local language correspond to exactly one actual
domain name in English. In this coding scheme, a unique code is pre-
assigned to one of the corresponding actual domain names in English
for each virtual domain name to be entered in a local language. The
code is kept somewhere at the server host that has the actual domain
name in English, for example, in the main HTML document at the server
host, so that VIDN can check the code. VIDN also generates the same
unique code whenever the corresponding virtual domain name is entered
in user applications. Then, VIDN checks whether the code at each
server host matches with the code generated in user applications. If
one of the server hosts has the code that matches with the code
generated in user applications, VIDN recognizes that the virtual
domain name entered by the user corresponds only to the actual domain
name of that server host, and connects the user host to the server
host. The domain names of the remaining server hosts that do not have
the matching code may be listed to the user as alternative sites. For
security purpose, this coding scheme may use an encryption technique.
For example, `??.?', a virtual domain name entered in Korean, may
result in four corresponding domain names in English including
`jungang.com', `joongang.com,' `chungang.com', and `choongang.com',
since the phonemes represented by characters consisting of `??.?'
in Korean can have the same or almost the same sounds as the phonemes
represented by characters consisting of `jungang.com',
`joongang.com,' `chungang.com', or `choongang.com' in English. In
Virtually Internationalized Domain Names November 2000
this case, we assume that the server host with its domain name
`jungang.com' has the pre-assigned code that matches with the code
generated when `??.?' in Korean is entered in user applications.
Then, the user host is connected to this server host, and the other
server hosts may be listed to the user as alternative sites so that
the user can try them.
The process of this coding scheme that makes each virtual domain name
in a local language correspond to only one actual domain name in
English, can be depicted as:
+---------------------------------+
| User |
+---------------------------------+
| |
+----------------|-----------------------|------------------+
| v v |
| +---------------------+ +-----------------------+ |
| | Virtual domain name | | Potential domain names| |
| | in a local language |---->| in English | |
| | e.g., `??.?' | | e.g., `jungang.com' | |
| | (code: 297437)| | `joongang.com' | |
| | | | `chungang.com' | |
| | | | `choongang.com' | |
| +---------------------+ +-----------------------+ |
| User application | |
+----------------------------------------|------------------+
^ |
| | Code check by VIDN
Connection to | | +-- `jungang.com'
the server host | | | (code: 297437)
`jungang.com' | | |-- `joongang.com'
| |----+ (not active)
| | |-- `chungang.com'
| | | (code: 381274)
| DNS request and | +-- `choongang.com'
| response | (not active)
+-----------------------+
Since VIDN converts separately the entity-defined portions and the
coded portions of a virtual domain name, it preserves the current
syntax of domain names, that is, the hierarchical dotted notation,
which Internet users are familiar with. Also, VIDN allows using a
virtual domain name mixed with characters in a local language and
English as the user wishes to, since the conversion takes place on
each individual portion of the domain name and each individual
character or set of characters of the portion.
While VIDN preserves the hierarchical dotted notation of current
domain names, the principles of VIDN are also applicable to domain
names in other possible notations such as those in a natural language
(e.g., `microsoft windows' rather than `windows.microsoft.com'). Also,
the principles of VIDN can be applied into other identifiers used on
the Internet, such as user IDs of e-mail addresses, names of
Virtually Internationalized Domain Names November 2000
directories and folders, names of web pages and files, keywords used
in search engines and directory services, and so on, allowing them to
be used interchangeably in a local language and English, without
creating additional identifiers in the local language. The conversion
of VIDN can be done between any two languages interchangeably. Thus,
even when the DNS accepts and registers domain names in other
languages in addition to English, VIDN can allow using the same
domain names in any two languages by converting virtual domain names
in one language into actual domain names in another language.
4.3. Implementation
In a preferred arrangement, VIDN is implemented in applications at
the user host. That is, the conversion of virtual domain names in a
local language into the corresponding actual domain names in English
takes place at the user host before DNS requests are sent. Thus,
neither a special encoding nor a separate lookup service is needed to
implement VIDN. VIDN is also modularized with each module being used
for conversion of virtual domain names in one local language into the
corresponding actual domain names in English. A user needs only the
module for conversion of his or her preferred local language into
English. Also, VIDN can be implemented at a central server host or a
cluster of local server hosts. A central server with all the language
modules of VIDN can provide the conversion service for all local
languages, or a cluster of local server hosts can share the
conversion service. In the latter case, each local server host with a
language module or a set of language modules can provide the
conversion service for the respective local language or set of local
languages used in a certain region.
Because of its small size, VIDN can be easily embedded into
applications software such as web browser, e-mail software, ftp
system, and so on at the user host, or it can work as an add-on
program to such software. In either case, the only requirement on the
part of the user is to install VIDN or software embedding VIDN at the
user host. Using virtual domain names in a local language in
accordance with the principles of VIDN is very intuitive to those who
speak the local language. The only requirement on the part of the
entity whose server host provides Internet services to user hosts is
to have an actual domain name in English into which a virtual domain
name in a local language is neatly transliterated in accordance with
the principles of VIDN, and to have a pre-assigned code kept at its
server host for one-to-one matching of its actual domain name and a
virtual domain name to be used by users. Most entities in regions
where English is not widely spoken already have such domain names in
English. Finally, there is nothing to change on the part of the DNS,
since VIDN uses the current DNS as it is.
Taken together, the features of VIDN can meet all the requirement of
internationalized domain names as described in Wenzel and Seng [2],
with respect to compatibility and interoperability,
internationalization, canonicalization, and operating issues. Given
the fact that different methods toward internationalized domain names
Virtually Internationalized Domain Names November 2000
confuse users, as already observed in some regions where some of
these methods have already been commercialized, e.g., Korea, it is
important to find and implement the most effective solution to
internationalized domain names as soon as possible.
4.4. Testing results
A testing version of VIDN has been developed for Korean-English
conversion as a web browser add-on program. The program contains all
the features described in this document except the coding scheme.
While the final version of the program is planned to include the
coding scheme, the testing version lists all the domain names in
English that correspond to a virtual domain name entered in Korean so
that a user can choose one. The testing results of a sample of
randomly selected domain names used in Korea show that the program
can cover more than ninety percent of the sample. The results
indicate that more than ninety percent of web sites in Korea can be
accessed using virtual domain names in Korean without creating
additional domain names in Korean. The remaining ten percent of
domain names are mostly those that contain acronyms, abbreviations or
initials. With improvement of its knowledge of transliteration, the
final version of the program is expected to cover most domain names
used in Korea.
5. Security considerations
Because VIDN uses the DNS as it is, it inherits the same security
considerations as the DNS.
6. Intellectual property considerations
It is the intention of DualName, Inc. to submit the VIDN method and
other elements of VIDN software to IETF for review, comment or
standardization.
DualName has applied for one or more patents on the technology
related to virtual domain name software and virtual email software.
If a standard is adopted by IETF and any patents are issued to
DualName with claims that are necessary for practicing the standard,
DualName is prepared to make available, upon written request, a non-
exclusive license under fair, reasonable and non-discriminatory terms
and condition, based on the principle of reciprocity, consistent with
established practice.
7. References
1 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
Virtually Internationalized Domain Names November 2000
2 Wenzel, Z. and Seng, J. (Editors), "Requirements of
Internationalized Domain Names," draft-ietf-idn-requirements-
03.txt, August 2000
8. Author's address
Sung Jae Shim
DualName, Inc.
3600 Wilshire Boulevard, Suite 1814
Los Angeles, California 90010
USA
Email: shimsungjae@dualname.com

505
doc/draft/draft-ietf-idn-vidn-01.txt Normal file
View File

@ -0,0 +1,505 @@
IETF IDN Working Group Sung Jae Shim
Internet Draft DualName, Inc.
Document: draft-ietf-idn-vidn-01.txt 2 March 2001
Expires: 2 September 2001
Virtually Internationalized Domain Names (VIDN)
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document proposes a method that enables domain names to be used in both
local and English scripts, as a directory-search solution at an upper layer
above the DNS. The method first converts virtual domain names typed in local
scripts into the corresponding domain names in English scripts that comply with
the DNS, using the knowledge of transliteration between local and English
scripts. Then, the method searches for and displays domain names in English
scripts that are active on the Internet so that the user can choose any of them.
The conversion takes place automatically and transparently in the user's
applications before DNS queries are sent, and so, the method does not make any
change to the DNS nor require separate name servers.
2. Conventions and definitions used in this document
The key words "REQUIRED" and "MAY" in this document are to be interpreted as
described in RFC-2119 [1].
A "host" is a computer or device attached to the Internet. A "user host" is a
computer or device with which a user is connected to the Internet, and a "user"
is a person who uses a user host. A "server host" is a computer or device that
provides services to user hosts.
An "entity" is an organization or individual that has a domain name registered
with the DNS.
A "local language" is a language other than English language that a user prefers
to use in a local context. "Local scripts" are scripts of a local language and
"English scripts" are scripts of English language.
A "virtual domain name" is a domain name in local scripts, and it is not
registered with the DNS but used for the convenience of users. An "English
domain name" is a domain name in English scripts. A "domain name" refers to an
English domain name that complies with the DNS, unless specified otherwise.
A "coded portion" is a pre-coded portion of a domain name (e.g., generic codes
including 'com', 'edu', 'gov', 'int', 'mil', 'net', 'org', and country codes
such as 'kr', 'jp', 'cn', and so on). An "entity-defined portion" is a portion
of a domain name, which is defined by the entity that holds the domain name
(e.g., host name, organization name, server name, and so on).
The method proposed in this document is called "virtually internationalized
domain names (VIDN)," as it enables domain names in English scripts to be used
virtually in local scripts.
A number of Korean-language characters are used in the original of this document
for examples, which is available from the author upon request. The software used
for Internet-Drafts does not allow using multilingual characters other than
ASCII characters. Thus, this document may not display Korean-language characters
properly, although it may be comprehensible without the examples using Korean-
language characters. Also, when you open the original of this document, please
select your view encoding type to Korean for Korean-language characters to be
displayed properly.
3. Introduction
Domain names are valuable to Internet users as a main identifier of entities and
resources on the Internet. The DNS allows using only English scripts in naming
hosts or clusters of hosts on the Internet. More specifically, the DNS uses only
the basic Latin alphabets (case-insensitive), the decimal digits (0-9) and the
hyphen (-) in domain names. But there is a growing need for internationalized
domain names in local scripts. Recognizing this need, various methods have been
proposed to use local scripts in domain names. But to date, no method appears to
meet all the requirements of internationalized domain names as described in
Wenzel and Seng [2].
A group of earlier methods tries to put internationalized domain names in local
scripts inside some parts of the overall DNS, using special encoding schemes of
Universal Character Set (UCS). But these methods put too much of a burden on the
DNS, requiring a great deal of work for transition and update of the DNS
components and the applications working with the DNS. Another group of earlier
methods tries to build separate directory services for internationalized domain
names or keywords in local scripts. But these methods also require complex
implementation efforts, duplicating much of the work already done for the DNS.
Both the groups of earlier methods require creating internationalized domain
names or keywords in local scripts from scratch, which is a costly and lengthy
process on the parts of the DNS and Internet users. Further, domain names or
keywords created in local scripts are usable only by those who know the local
scripts, and so, they may segregate the Internet into many groups of different
sets of local scripts that are less universal than English scripts.
VIDN intends to provide a more immediate and less costly solution to
internationalized domain names than earlier methods. VIDN does not make any
change to the DNS nor require creating additional domain names in local scripts.
VIDN takes notice of the fact that many domain names currently used in regions
where English scripts are not widely used have their entity-defined portions
consisting of English scripts as transliterated from the respective local
scripts. Using this knowledge of transliteration between local and English
scripts, VIDN converts virtual domain names typed in local scripts into the
corresponding domain names in English scripts that comply with the DNS. In this
way, VIDN enables the same domain names to be used not only in English scripts
as usual but also in local scripts, without creating additional domain names in
local scripts.
4. VIDN method
4.1. Objectives
Earlier methods of internationalized domain names try to create domain names or
keywords in local scripts one way or another in addition to existing domain
names in English scripts, and put them inside or outside the DNS, using special
encoding schemes or lookup services. These methods require a lengthy and costly
process of creating domain names in local scripts and updating the DNS
components and applications. Even when they are successfully implemented, these
methods have a risk of localizing the Internet by segregating it into groups of
different sets of local scripts that are less universal than English scripts and
so diminishing the international scope of the Internet. Further, these methods
may cause more problems and disputes on copyrights, trademarks, and so on, in
local contexts than those that we experience with current domain names in
English scripts.
VIDN intends to provide a solution to the problems of earlier methods of
internationalized domain names. VIDN enables the same domain names to be used in
both English scripts as usual and local scripts, and so, there is no need to
create domain names in local scripts in addition to domain names in English
scripts. VIDN works automatically and transparently in applications at user
hosts before DNS requests are sent, and so, there is no need to make any change
to the DNS or to have additional name servers. For these reasons as well as
others, VIDN can be implemented more immediately with less cost than other
methods of internationalized domain names.
4.2. Description
It is important to note that most domain names used in regions where English
scripts are not widely used have their entity-defined portions consisting of
English scripts as transliterated from local scripts. Of course, there are many
domain names in those regions that do not follow this kind of transliteration
between local and English scripts. In such case, new domain names in English
scripts need to be created following this transliteration, but the number would
be minimal, compared to the number of internationalized domain names in local
scripts to be created and registered under other methods.
The English scripts transliterated from local scripts do not have any meanings
in English language, but their originals in local scripts before the
transliteration have some meanings in the respective local language, usually
indicating organization names, brand names, trademarks, and so on. VIDN enables
to use these original local scripts as the entity-defined portions of virtual
domain names in local scripts, by transliterating them into the corresponding
entity-defined portions of actual domain names in English scripts. In this way,
VIDN enables the same domain names in English scripts to be used virtually in
local scripts without actually creating domain names in local scripts.
As domain names in English scripts overlay IP addresses, so virtual domain names
in local scripts do actual domain names in English scripts. The relationship
between virtual domain names in local scripts and actual domain names in English
scripts can be depicted as:
+---------------------------------+
| User |
+---------------------------------+
| |
+----------------|-----------------------|------------------+
| v (Transliteration) v |
| +---------------------+ | +-----------------------+ |
| | Virtual domain name | | | Actual domain name | |
| | in local scripts |--+->| in English scripts | |
| +---------------------+ +-----------------------+ |
| User application | |
+----------------------------------------|------------------+
v
DNS requests
VIDN uses the phonemes of local and English scripts as a medium in
transliterating the entity-defined portions of virtual domain names in local
scripts into those of actual domain names in English scripts. This process of
transliteration can be depicted as:
Local scripts English scripts
+----------------------------+ +-----------------------------+
| Characters ----> Phonemes -----------> Phonemes ----> Characters |
| | | | | | |
| | | | | | |
| (Inverse of transcription) | Match | (Transcription) |
+----------------------------+ +-----------------------------+
| ^
| (Transliteration) |
+------------------------------------+
First, each entity-defined portion of a virtual domain name typed in local
scripts is decomposed into individual characters or sets of characters so that
each individual character or set of characters can represent an individual
phoneme of the local language. This is the inverse of transcription of phonemes
into characters. Second, each individual phoneme of the local language is
matched with an equivalent phoneme of English language that has the same or most
proximate sound. Third, each phoneme of English language is transcribed into the
corresponding character or set of characters in English language. Finally, all
the characters or sets of characters converted into English scripts are united
to compose the corresponding entity-defined portion of an actual domain name in
English scripts.
For example, a word in Korean language, '­­˜‚' that means 'century' in English
language, is transliterated into 'segi' in English scripts, and so, the entity
whose name contains '­­˜‚' in Korean language may have an entity-defined portion
of its domain name as 'segi' in English scripts. VIDN enables to use '­­˜‚' as
an entity-defined portion of a virtual domain name in Korean scripts, which is
converted into 'segi,' the corresponding entity-defined portion of an actual
domain name in English scripts. In other words, the phonemes represented by the
characters consisting of '­­˜‚' in Korean scripts have the same sounds as the
phonemes represented by the characters consisting of 'segi' in English scripts.
In the local context, '­­˜‚' in Korean scripts is clearly easier to remember and
type and more intuitive and meaningful than 'segi' in English scripts.
An entity-defined portion of a virtual domain name in Korean scripts, '¾ž®ý', is
transliterated into 'yahoo' in English scripts, since the phonemes represented
by the characters consisting of '¾ž®ý' in Korean scripts have the same sounds as
the phonemes represented by the characters consisting of 'yahoo' in English
scripts. That is, '¾ž®ý' in Korean scripts is pronounced as the same as 'yahoo'
in English scripts, and so, it is easy for Korean-speaking people to deduce '¾ž
®ý' in Korean scripts as the virtual equivalent of 'yahoo' in English scripts.
VIDN enables to use virtual domain names in local scripts for domain names whose
originals are in local scripts, e.g., '­­˜‚' in Korean scripts, as well as
domain names whose originals are in English scripts, e.g., '¾ž®ý' in Korean
scripts. In this way, VIDN is able to make domain names truly international,
allowing the same domain names to be used both in English and local scripts.
The coded portions of domain names such as generic codes and country codes can
also be transliterated from local scripts into English scripts, using their
phonemes as a medium. For example, seven generic codes in English scripts, 'com',
'edu', 'gov', 'int', 'mil', 'net', and 'org', can be transliterated from 'ýý', '
Àí´€', '—<>¦Š', 'ÁðË«', ' Ï', 'þÚË«', 'ÀÁ˜Ú' in Korean scripts, respectively,
which can be used as the corresponding generic codes of virtual domain names in
Korean scripts. Based upon its meaning in English language, each coded portion
of actual domain names also can be pre-assigned a virtual equivalent word or
code in local scripts. For example, seven generic codes in English scripts,
'com', 'edu', 'gov', 'int', 'mil', 'net', and 'org', can be pre-assigned '˜‚¾•'
(meaning 'commercial' in Korean language), 'ÌϘþ' (meaning 'education' in Korean
language), 'Âñ¦ð' (meaning 'government' in Korean language), '˜ Âª' (meaning
'international' in Korean language), '˜¦À‹' (meaning 'military' in Korean
language), 'þÚË«' (meaning 'network' in Korean language), and '³›È­' (meaning
'organization' in Korean language), respectively, which can be used as the
corresponding generic codes of virtual domain names in Korean scripts.
VIDN does not create such complexities as other conversion methods based upon
semantics do, since it uses phonemes as a medium of transliteration between
local and English scripts. Further, most languages have a small number of
phonemes. For example, Korean language has nineteen consonant phonemes and
twenty-one vowel phonemes, and English language has twenty-four consonant
phonemes and twenty vowel phonemes. Each phoneme of Korean language can be
matched with a phoneme of English language that has the same or proximate sound,
and vice versa.
Some characters or sets of characters may represent more than one phoneme. Some
phonemes may be represented by more than one character or set of characters.
Also, not every character or set of characters in local scripts may be neatly
transliterated into only one character or set of characters in English scripts.
In practice, people often transliterate the same local scripts differently into
English scripts or vice versa. VIDN incorporates the provisions to deal with
those variations that usually occur in particular situations as well as those
variations that are caused by common usage or idiomatic expressions. More
fundamentally, VIDN uses phonemes, which are very universal across different
languages, as a medium of transliteration rather than following a certain set of
transliteration rules that does not exist in many non-English-speaking countries
nor is followed by many non-English-speaking people.
One virtual domain name typed in local scripts may be converted into more than
one possible domain name in English scripts. In such case, VIDN can search for
and displays only those domain names in English scripts that are active on the
Internet, so that the user can choose any of them. Further, VIDN can be used as
a directory-search solution at an upper layer above the DNS. That is, the user
can use VIDN to query a phoneme-based domain name request in local scripts,
receive one or more corresponding domain names in English or ASCII-compatible
scripts preferably, choose one based upon the results of that search, and make
the final DNS request using any protocol or method to be chosen for
internationalized domain names. In this regard of directory search, VIDN uses
one-to-many map between virtual domain names in local scripts and actual domain
names in English scripts.
VIDN needs the one-to-many mapping and subsequent multiple DNS lookups only at
the first query of each virtual domain name typed in local scripts at the user
host. After the first query, the virtual domain name is set to the domain name
in English scripts that has been chosen at the first query. Any subsequent
queries with the same virtual domain name generate only one query with the
selected domain name in English scripts. Once the use selects one possible
domain name in English scripts from the list, VIDN remembers the user's
selection and directs the user to the same domain name at his or her subsequent
queries with that virtual domain name. In this way, VIDN can generate less
traffic on the DNS, while providing faster, easier, and simpler navigation on
the Internet to the user, using local scripts.
Utilizing a coding scheme, VIDN is also capable of making each virtual domain
name typed in local scripts correspond to exactly one actual domain name in
English scripts. In this coding scheme, a unique code such as the Unicode or
hexadecimal code represented by the virtual domain name, is pre-assigned to one
of the corresponding domain names in English scripts and stored in the
respective server host, so that both the user host and the server host can
support and understand the code. Then, VIDN checks whether the code at each
server host matches with the code generated at the user host. If one of the
servers stores the code that matches with the code generated at the user host,
the virtual domain name typed at the user host is recognized as corresponding
only to the domain name of that server host, and the user host is connected to
the server host. The domain names of the remaining server hosts that do not have
the matching code are also displayed at the user host as alternative sites.
Because a unique code is assigned to only one of the domain names in English
scripts, it does not cause any domain name squatting problem beyond what we
experience with current domain names in English scripts. Unique codes do not
need to be stored in any specific format, that is, they can be embedded in HTML,
XML, WML, and so on, so that the user host can interpret the retrieved code
correctly. Likewise, unique codes do not require any specific intermediate
transport protocol such as TCP/IP. The only requirement is that the protocol
must be understood among all participating user hosts and server hosts. For
security purpose, this coding scheme may use an encryption technique.
For example, 'ž¾Ô.ýý', a virtual domain name typed in Korean scripts, may
result in four corresponding domain names in English scripts, including
'jungang.com', 'joongang.com,' 'chungang.com', and 'choongang.com', since the
phonemes represented by characters consisting of 'ž¾Ô.ýý' in Korean scripts can
have the same or almost the same sounds as the phonemes represented by
characters consisting of 'jungang.com', 'joongang.com,' 'chungang.com', or
'choongang.com' in English scripts. In this case, we assume that the server host
with its domain name 'jungang.com' has the pre-assigned code that matches with
the code generated when 'ž¾Ô.ýý' in Korean scripts is entered in user
applications. Then, the user host is connected to this server host, and the
other server hosts may be listed to the user as alternative sites so that the
user can try them.
The process of this coding scheme that makes each virtual domain name in local
scripts correspond to only one actual domain name in English scripts, can be
depicted as:
+---------------------------------+
| User |
+---------------------------------+
| |
+----------------|-----------------------|------------------+
| v v |
| +---------------------+ +-----------------------+ |
| | Virtual domain name | | Potential domain names| |
| | in a local language |---->| in English | |
| | e.g., 'ž¾Ô.ýý' | | e.g., 'jungang.com' | |
| | (code: 297437)| | 'joongang.com' | |
| | | | 'chungang.com' | |
| | | | 'choongang.com' | |
| +---------------------+ +-----------------------+ |
| User application | |
+----------------------------------------|------------------+
^ |
| | Code check by VIDN
Connection to | | +-- 'jungang.com'
the server host | | | (code: 297437)
'jungang.com' | | |-- 'joongang.com'
| |----+ (not active)
| | |-- 'chungang.com'
| | | (code: 381274)
| DNS request and | +-- 'choongang.com'
| response | (not active)
+-----------------------+
Since VIDN converts separately the entity-defined portions and the coded
portions of a virtual domain name, it preserves the current syntax of domain
names, that is, the hierarchical dotted notation, which Internet users are
familiar with. Also, VIDN allows using a virtual domain name mixed with local
and English scripts as the user wishes to, since the conversion takes place on
each individual portion of the domain name and each individual character or set
of characters of the portion.
While VIDN preserves the hierarchical dotted notation of current domain names,
the principles of VIDN are applicable to domain names in other possible
notations such as those in a natural language (e.g., 'microsoft windows' rather
than 'windows.microsoft.com'). Also, the principles of VIDN can be applied into
other identifiers used on the Internet, such as user IDs of e-mail addresses,
names of directories and folders, names of web pages and files, keywords used in
search engines and directory services, and so on, allowing them to be used
interchangeably in local and English scripts, without creating additional
identifiers in local scripts. The conversion of VIDN can be done between any two
sets of scripts interchangeably. Thus, even when the DNS accepts and registers
domain names in other local scripts in addition to English, VIDN can allow using
the same domain names in any two sets of scripts by converting virtual domain
names in one set of scripts into actual domain names in another set of scripts.
4.3. Development and implementation
In a preferred arrangement, the development of VIDN for each set of local
scripts may be administered by one or more local standard bodies in regions
where the local scripts are widely used, for example, Korean Network Information
Center for Korean scripts, Japan Network Information Center for Japanese scripts,
and China, Hong Kong and Taiwan Network Information Centers for Chinese scripts,
with consultation with experts on phonemics and linguistics of the respective
local language and English language. Also, the unique codes for one-to-one
mapping between virtual domain names in local scripts and actual domain names in
English scripts can be administered by a central standard body like IANA.
Alternatively, the unique codes for each set of local scripts may be
administered by one or more local standard bodies in regions where the local
scripts are widely used, as with the development of VIDN.
VIDN is implemented in applications at the user host. That is, the conversion of
virtual domain names in local scripts into the corresponding actual domain names
in English scripts takes place at the user host before DNS requests are sent.
Thus, neither a special encoding nor a separate lookup service is needed to
implement VIDN. VIDN is also modularized with each module being used for
conversion of virtual domain names in one set of local scripts into the
corresponding actual domain names in English scripts. A user needs only the
module for conversion of his or her preferred set of local scripts into English
scripts. Alternatively, VIDN can be implemented at a central server host or a
cluster of local server hosts. A central server can provide the conversion
service for all sets of local scripts, or a cluster of local server hosts can
share the conversion service. In the latter case, each local server host can
provide the conversion service for one or more sets of local scripts used in a
certain region.
Because of its small size, VIDN can be easily embedded into applications
software such as web browser, e-mail software, ftp system, and so on at the user
host, or it can work as an add-on program to such software. In either case, the
only requirement on the part of the user is to install VIDN or software
embedding VIDN at the user host. Using virtual domain names in local scripts in
accordance with the principles of VIDN is very intuitive to those who use the
local scripts. The only requirement on the part of the entity whose server host
provides Internet services to user hosts is to have an actual domain name in
English scripts into which virtual domain names in local scripts are neatly
transliterated in accordance with the principles of VIDN. Most entities in
regions where English scripts are not widely used already have such domain names
in English scripts. Finally, there is nothing to change on the part of the DNS,
since VIDN uses the current DNS as it is.
Taken together, the features of VIDN can meet all the requirement of
internationalized domain names as described in Wenzel and Seng [2], with respect
to compatibility and interoperability, internationalization, canonicalization,
and operating issues. Given the fact that different methods toward
internationalized domain names confuse users, as already observed in some
regions where some of these methods have already been commercialized, e.g.,
Korea, Japan and China, it is important to find and implement the most effective
solution to internationalized domain names as soon as possible.
4.4. Current status
VIDN has been developed for Korean-English conversion as a web browser add-on
program. The program contains all the features described in this document and is
capable of listing all the domain names in English scripts that correspond to a
virtual domain name typed in Korean scripts so that a user can choose any of
them. The program can cover more than ninety percent of the sample. That is, the
results of testing indicate that more than ninety percent of web sites in Korea
can be accessed using virtual domain names in Korean scripts without creating
additional domain names in Korean scripts. The remaining ten percent of domain
names are mostly those that contain acronyms, abbreviations or initials. With
improvement of its knowledge of transliteration, the program is expected to
cover more domain names used in Korea.
5. Security considerations
Because VIDN uses the DNS as it is, it inherits the same security considerations
as the DNS.
6. Intellectual property considerations
It is the intention of DualName, Inc. to submit the VIDN method and other
elements of VIDN software to IETF for review, comment or standardization.
DualName has applied for one or more patents on the technology related to
virtual domain name software and virtual email software. If a standard is
adopted by IETF and any patents are issued to DualName with claims that are
necessary for practicing the standard, DualName is prepared to make available,
upon written request, a non-exclusive license under fair, reasonable and non-
discriminatory terms and condition, based on the principle of reciprocity,
consistent with established practice.
7. References
1 Wenzel, Z. and Seng, J. (Editors), "Requirements of Internationalized Domain
Names," draft-ietf-idn-requirements-03.txt, August 2000
8. Author's address
Sung Jae Shim
DualName, Inc.
3600 Wilshire Boulevard, Suite 1814
Los Angeles, California 90010
USA
Email: shimsungjae@dualname.com

388
doc/draft/draft-ietf-ipngwg-default-addr-select-02.txt → doc/draft/draft-ietf-ipngwg-default-addr-select-03.txt
View File

@ -2,7 +2,7 @@
IPng Working Group Richard Draves
Internet Draft Microsoft Research
Document: draft-ietf-ipngwg-default-addr-select-02.txt November 24, 2000
Document: draft-ietf-ipngwg-default-addr-select-03.txt March 3, 2001
Category: Standards Track
Default Address Selection for IPv6
@ -54,8 +54,8 @@ Abstract
These addresses may also be "preferred" or "deprecated" [3]. Privacy
considerations have introduced the concepts of "public addresses"
Draves Standards Track - Expires June 2001 1
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Draves Standards Track - Expires September 2001 1
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
and "temporary addresses" [4]. The mobility architecture introduces
@ -112,8 +112,8 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Draves Standards Track - Expires June 2001 2
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Draves Standards Track - Expires September 2001 2
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
1.1. Conventions used in this document
@ -163,17 +163,21 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
address pairs having the longest possible common prefix. For source
address selection, temporary addresses [4] are preferred over public
addresses. In mobile situations [5], home addresses are preferred
over care-of addresses.
over care-of addresses. If an address is simultaneously a home
address and a care-of address (indicating the mobile node is "at
home" for that address), then the home/care-of address is preferred
over addresses that are solely a home address or solely a care-of
address.
Draves Standards Track - Expires September 2001 3
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
The framework optionally allows for the possibility of
administrative configuration of policy that can override the default
behavior of the algorithms. The policy override takes the form of a
configurable table that specifies precedence values and preferred
Draves Standards Track - Expires June 2001 3
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
source prefixes for destination prefixes. If an implementation is
not configurable, or if an implementation has not been configured,
then the default policy table specified in this document SHOULD be
@ -222,38 +226,36 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
IPv4 addresses should be treated as having "preferred" configuration
status.
Draves Standards Track - Expires September 2001 4
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
2.3. IPv6 Addresses with Embedded IPv4 Addresses
IPv4-compatible addresses [2] and 6to4 addresses [12] contain an
embedded IPv4 address. For the purposes of this document, these
addresses should be treated as having the scope of the embedded IPv4
Draves Standards Track - Expires June 2001 4
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
address. For example, the IPv6 address ::169.254.3.18 has link-local
scope and the address 2002:0a01:0203::1 has site-local scope.
addresses should be treated as having global scope.
IPv4-compatible addresses should be treated as having "preferred"
configuration status.
2.4. Loopback Address and Other Format Prefixes
The loopback address should be treated as having link-local scope
and "preferred" configuration status.
The loopback address should be treated as having link-local
scope [9] and "preferred" configuration status.
NSAP addresses, IPX addresses, and other addresses with as-yet-
undefined format prefixes should be treated as having global scope
and "preferred" configuration status. Later standards may supercede
this treatment.
NSAP addresses and other addresses with as-yet-undefined format
prefixes should be treated as having global scope and "preferred"
configuration status. Later standards may supercede this treatment.
2.5. Policy Table
The policy table is a longest-matching-prefix lookup table, much
like a routing table. Given an address A, a lookup in the policy
table produces three values: a precedence value Precedence(A), a
classification or label SrcLabel(A), and a second label DstLabel(A).
table produces two values: a precedence value Precedence(A) and a
classification or label Label(A).
The precedence value Precedence(A) is used for sorting destination
addresses. If Precedence(A) > Precedence(B), we say that address A
@ -261,10 +263,10 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
will prefer to sort destination address A before destination address
B.
The labels SrcLabel(A) and DstLabel(A) allow for policies that
prefer a particular source address prefix for use with a destination
address prefix. The algorithms prefer to use a source address S with
a destination address D if SrcLabel(S) = DstLabel(D).
The label value Label(A) allows for policies that prefer a
particular source address prefix for use with a destination address
prefix. The algorithms prefer to use a source address S with a
destination address D if Label(S) = Label(D).
IPv6 implementations SHOULD support configurable address selection
via a mechanism at least as powerful as the policy tables defined
@ -273,23 +275,23 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
specified here in conjunction with the following default policy
table:
Prefix Precedence SrcLabel DstLabel
::1/128 50 0 0
::/0 40 1 1
2002::/16 30 2 2
::/96 20 3 3
::ffff:0:0/96 10 4 4
Prefix Precedence Label
::1/128 50 0
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
One effect of the default policy table is to prefer using native
source addresses with native destination addresses, 6to4 [12] source
addresses with 6to4 destination addresses, and v4-compatible [2]
source addresses with v4-compatible destination addresses. Another
Draves Standards Track - Expires June 2001 5
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Draves Standards Track - Expires September 2001 5
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
addresses with 6to4 destination addresses, and v4-compatible [2]
source addresses with v4-compatible destination addresses. Another
effect of the default policy table is to prefer communication using
IPv6 addresses to communication using IPv4 addresses, if matching
source addresses are available.
@ -340,14 +342,15 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
specifies a source address that is in the candidate set for the
destination, then the network layer MUST respect that choice. If the
application or upper-layer does not specify a source address, then
Draves Standards Track - Expires September 2001 6
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
the network layer uses the source address selection algorithm
specified in the next section.
Draves Standards Track - Expires June 2001 6
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
4. Source Address Selection
The source address selection algorithm chooses a source address for
@ -369,9 +372,9 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
If SA = D, then choose SA. Similarly, if SB = D, then choose SB.
Rule 2: Prefer appropriate scope.
If Scope(SA) < Scope(SB). If Scope(SA) < Scope(D), then choose SB
If Scope(SA) < Scope(SB): If Scope(SA) < Scope(D), then choose SB
and otherwise choose SA.
Similarly, if Scope(SB) < Scope(SA). If Scope(SB) < Scope(D), then
Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then
choose SA and otherwise choose SB.
Rule 3: Avoid deprecated addresses.
@ -380,9 +383,12 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
one that is preferred.
Rule 4: Prefer home addresses.
If SA is a home address and SB is a care-of address, then prefer SA.
Similarly, if SB is a home address and SA is a care-of address, then
prefer SB.
If SA is simultaneously a home address and care-of address and SB is
not, then prefer SA. Similarly, if SB is simultaneously a home
address and care-of address and SA is not, then prefer SB.
If SA is just a home address and SB is just a care-of address, then
prefer SA. Similarly, if SB is just a home address and SA is just a
care-of address, then prefer SB.
An implementation may support a per-connection configuration
mechanism (for example, a socket option) to reverse the sense of
this preference and prefer care-of addresses over home addresses.
@ -394,18 +400,17 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
send to D and SA is assigned to a different interface, then prefer
SB.
Rule 6: Prefer matching label.
If Label(SA) = MatchSrcLabel(D) and Label(SB) <> MatchSrcLabel(D),
then choose SA. Similarly, if Label(SB) = MatchSrcLabel(D) and
Label(SA) <> MatchSrcLabel(D), then choose SB.
Draves Standards Track - Expires June 2001 7
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Draves Standards Track - Expires September 2001 7
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
Rule 6: Prefer matching label.
If Label(SA) = Label(D) and Label(SB) <> Label(D), then choose SA.
Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then
choose SB.
Rule 7: Prefer temporary addresses.
If SA is a temporary address and SB is a public address, then prefer
SA. Similarly, if SB is a temporary address and SA is a public
@ -454,16 +459,16 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
result, then the remaining rules are not relevant and should be
ignored. Subsequent rules act as tie-breakers for earlier rules.
Draves Standards Track - Expires September 2001 8
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
Rule 1: Avoid unusable destinations.
If there is no route to DB or if Source(DB) is undefined, then sort
DA before DB. Similarly, if there is no route to DA or if Source(DA)
is undefined, then sort DB before DA.
Draves Standards Track - Expires June 2001 8
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Rule 2: Prefer matching scope.
If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)),
then sort DA before DB. Similarly, if Scope(DA) <> Scope(Source(DA))
@ -475,15 +480,19 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
is deprecated, then sort DA before DB.
Rule 4: Prefer home addresses.
If Source(DA) is a home address and Source(DB) is a care-of address,
then sort DA before DB. Similarly, if Source(DA) is a care-of
address and Source(DB) is a home address, then sort DB before DA.
If Source(DA) is simultaneously a home address and care-of address
and Source(DB) is not, then sort DA before DB. Similarly, if
Source(DB) is simultaneously a home address and care-of address and
Source(DA) is not, then sort DB before DA.
If Source(DA) is just a home address and Source(DB) is just a care-
of address, then sort DA before DB. Similarly, if Source(DA) is just
a care-of address and Source(DB) is just a home address, then sort
DB before DA.
Rule 5: Prefer matching label.
If SrcLabel(Source(DA)) = DstLabel(DA) and SrcLabel(Source(DB)) <>
DstLabel(DB), then sort DA before DB. Similarly, if
SrcLabel(Source(DA)) <> DstLabel(DA) and SrcLabel(Source(DB)) =
DstLabel(DB), then sort DB before DA.
If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB),
then sort DA before DB. Similarly, if Label(Source(DA)) <> Label(DA)
and Label(Source(DB)) = Label(DB), then sort DB before DA.
Rule 6: Prefer higher precedence.
If Precedence(DA) > Precedence(DB), then sort DA before DB.
@ -508,6 +517,11 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
implementation somehow knows which destination addresses will result
in the "best" communications performance.
Draves Standards Track - Expires September 2001 9
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
6. Interactions with Routing
This specification of source address selection assumes that routing
@ -516,12 +530,6 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
However, implementations may use source address considerations as a
tiebreaker when choosing among otherwise equivalent routes.
Draves Standards Track - Expires June 2001 9
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
For example, suppose a node has interfaces on two different links,
with both links having a working default router. Both of the
interfaces have preferred global addresses. When sending to a global
@ -567,24 +575,41 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
information in its implementation of destination address selection,
or if the ordering of a cached list of destination addresses is
possibly stale, then it should ensure that the destination address
Draves Standards Track - Expires September 2001 10
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
ordering returned to the application is no more than one second out
of date. For example, an implementation might make a system call to
check if any routing table entries or source address assignments
that might affect these algorithms have changed.
that might affect these algorithms have changed. Another strategy is
to use an invalidation counter that is incremented whenever any
underlying state is changed. By caching the current invalidation
counter value with derived state and then later comparing against
the current value, the implementation can detect if the derived
state is stale.
Draves Standards Track - Expires June 2001 10
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
8. Security Considerations
This document has no direct impact on Internet infrastructure
security.
Note that most source address selection algorithms, including the
one specified in this document, expose a potential privacy concern.
An unfriendly node can infer correlations among a target node's
addresses by probing the target node with request packets that force
the target host to choose its source address for the reply packets.
(Perhaps because the request packets are sent to an anycast or
multicast address, or perhaps the upper-layer protocol chosen for
the attack does not specify a particular source address for its
reply packets.) By using different addresses for itself, the
unfriendly node can cause the target node to expose the target's own
addresses. For example, the unfriendly node might correlate the
target's current IPv6 temporary address with its IPv4 address by
sending requests with a global source address and an IPv4-compatible
source address.
9. Examples
This section contains a number of examples, first of default
@ -608,6 +633,11 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Sources: fe80::1 vs 2001::1
Result: 2001::1 (prefer appropriate scope)
Draves Standards Track - Expires September 2001 11
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
Destination: ff05::1
Sources: fe80::1 vs fec0::1 vs 2001::1
Result: fec0::1 (prefer appropriate scope)
@ -632,12 +662,6 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Sources: 2002:836b:2179::2 vs 2001::d5e3:7953:13eb:22e8 (temporary)
Result: 2002:836b:2179::2 (prefer matching label)
Draves Standards Track - Expires June 2001 11
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Destination: 2001::1
Sources: 2001::2 vs 2001::d5e3:7953:13eb:22e8 (temporary)
Result: 2001::d5e3:7953:13eb:22e8 (prefer temporary address)
@ -667,7 +691,11 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Destinations: 2001::1 vs fec0::1 vs fe80::1
Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then
2001::1 (src 2001::2) (prefer smaller scope)
Draves Standards Track - Expires September 2001 12
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
Sources: 2001::2 (care-of address) or 3ffe::1 (home address) or
fec0::2 (care-of address) or fe80::2 (care-of address)
Destinations: 2001::1 vs fec0::1
@ -691,11 +719,6 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Sources: 2002:836b:4179::2 or 2001::2 or fe80::2
Destinations: 2002:836b:4179::1 vs 2001::1
Draves Standards Track - Expires June 2001 12
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src
2002:836b:4179::2) (prefer higher precedence)
@ -707,12 +730,12 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
administrator can change the policy table to prefer IPv4 addresses
by giving the ::ffff:0.0.0.0/96 prefix a higher precedence:
Prefix Precedence SrcLabel DstLabel
::1/128 50 0 0
::/0 40 1 1
2002::/16 30 2 2
::/96 20 3 3
::ffff:0:0/96 100 4 4
Prefix Precedence Label
::1/128 50 0
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 100 4
This change to the default policy table produces the following
behavior:
@ -724,6 +747,13 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Sources: fe80::1 or 131.107.65.117
Destinations: 2001::1 vs 131.107.65.121
Draves Standards Track - Expires September 2001 13
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1
(src fe80::1) (prefer matching scope)
@ -742,26 +772,14 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
site-local destinations, and site-local destinations before link-
local destinations:
Draves Standards Track - Expires June 2001 13
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Prefix Precedence SrcLabel DstLabel
::1/128 50 0 0
::/0 40 1 1
fec0::/10 37 1 1
fe80::/10 33 1 1
2002::/16 30 2 2
::/96 20 3 3
::ffff:0:0/96 10 4 4
Prefix Precedence Label
::1/128 50 0
::/0 40 1
fec0::/10 37 1
fe80::/10 33 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
This change to the default policy table produces the following
behavior:
@ -788,6 +806,12 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Each site has two global prefixes, one from the high-performance ISP
and one from their normal ISP. Site A has prefix 2001:aaaa:aaaa::/48
Draves Standards Track - Expires September 2001 14
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
from the high-performance ISP and prefix 2007:0:aaaa::/48 from its
normal ISP. Site B has prefix 2001:bbbb:bbbb::/48 from the high-
performance ISP and prefix 2007:0:bbbb::/48 from its normal ISP. All
@ -805,13 +829,6 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a
Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b
Draves Standards Track - Expires June 2001 14
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b
(src 2001:aaaa:aaaa::a) (longest matching prefix)
@ -836,17 +853,23 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
desired behavior via policy table configuration. For example, they
can use the following policy table:
Prefix Precedence SrcLabel DstLabel
::1 50 0 0
2001:aaaa:aaaa::/48 45 5 5
2001:bbbb:bbbb::/48 45 5 5
::/0 40 1 1
2002::/16 30 2 2
::/96 20 3 3
::ffff:0:0/96 10 4 4
Prefix Precedence Label
::1 50 0
2001:aaaa:aaaa::/48 45 5
2001:bbbb:bbbb::/48 45 5
::/0 40 1
2002::/16 30 2
::/96 20 3
::ffff:0:0/96 10 4
This policy table produces the following behavior:
Draves Standards Track - Expires September 2001 15
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a
Destinations: 2001:bbbb:bbbb::b vs 2007:0:bbbb::b
New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then
@ -865,11 +888,6 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
host in some other site C, the traffic uses the normal ISP as
desired.
Draves Standards Track - Expires June 2001 15
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
References
1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP
@ -888,8 +906,9 @@ References
5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-
mobileip-ipv6-12.txt, April 2000.
6 R. Troll. "Automatically Choosing an IP Address in an Ad-Hoc IPv4
Network", draft-ietf-dhc-ipv4-autoconfig-05.txt, March 2000.
6 S. Cheshire. "Dynamic Configuration of IPv4 Link-local
Addresses", draft-ietf-zeroconf-ipv4-linklocal-01.txt, November
2000.
7 S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
@ -903,6 +922,13 @@ References
10 Y. Rekhter et. al, "Address Allocation for Private Internets",
RFC 1918, February 1996.
Draves Standards Track - Expires September 2001 16
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
11 F. Baker, Editor. "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
@ -912,9 +938,10 @@ References
Acknowledgments
The author would like to acknowledge the contributions of the IPng
Working Group, particularly Steve Deering and Ken Powell. Please let
the author know if you contributed to the development of this draft
and are not mentioned here.
Working Group, particularly Steve Deering, Jun-ichiro itojun Hagino,
M.T. Hollinger, Ken Powell, Markku Savela, Dave Thaler, and Mauro
Tortonesi. Please let the author know if you contributed to the
development of this draft and are not mentioned here.
Author's Address
@ -922,17 +949,27 @@ Author's Address
Microsoft Research
One Microsoft Way
Redmond, WA 98052
Draves Standards Track - Expires June 2001 16
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Phone: 1-425-936-2268
Email: richdr@microsoft.com
Revision History
Changes from draft-ietf-ipngwg-default-addr-select-02
Changed scope treatment of IPv4-compatible and 6to4 addresses, so
they are always considered to be global. Removed mention of IPX
addresses.
Changed home address rules to favor addresses that are
simultaneously home and care-of addresses, over addresses that are
just home addresses or just care-of addresses.
Combined SrcLabel & DstLabel in the policy table into a single Label
attribute.
Added mention of the invalidation counter technique in the
implementation section.
Changes from draft-ietf-ipngwg-default-addr-select-01
Added Examples section, demonstrating default behavior and some
@ -942,6 +979,13 @@ Changes from draft-ietf-ipngwg-default-addr-select-01
of source addresses and the source address selection rule that
prefers source addresses of appropriate scope.
Draves Standards Track - Expires September 2001 17
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
Simplified the default policy table. Reordered the source address
selection rules to reduce the influence of policy labels. Added more
destination address selection rules.
@ -980,12 +1024,6 @@ Changes from draft-ietf-ipngwg-default-addr-select-00
Added a rule to source address selection to handle home/care-of
addresses.
Draves Standards Track - Expires June 2001 17
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Changed to allow destination address selection to sort both IPv6 and
IPv4 addresses. Added entries in the default policy table for IPv4-
mapped addresses.
@ -1001,7 +1039,11 @@ Changes from draft-draves-ipngwg-simple-srcaddr-01
Added mechanism to allow the specification of administrative policy
that can override the default behavior.
Draves Standards Track - Expires September 2001 18
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
Added section on routing interactions and TBD section on mobility
interactions.
@ -1035,13 +1077,29 @@ Changes from draft-draves-ipngwg-simple-srcaddr-00
Draves Standards Track - Expires June 2001 18
draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Draves Standards Track - Expires September 2001 19
draft-ietf-ipngwg-default-addr-select-03 March 3, 2001
Full Copyright Statement
@ -1098,4 +1156,4 @@ draft-ietf-ipngwg-default-addr-select-02 November 24, 2000
Draves Standards Track - Expires June 2001 19
Draves Standards Track - Expires September 2001 20

580
doc/draft/draft-whr-dnsext-secure-online-update-00.txt
View File

@ -1,580 +0,0 @@
INTERNET-DRAFT X. Wang, Y. Huang, D Rine (GMU)
<draft-whr-dnsext-secure-online-update-00.txt> June 2000
Updates: RFC 2136
Replaces: RFC 2137
Secure Online Domain Name System (DNS) Dynamic Update
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as ``work in
progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Comments should be sent to the authors or the DNSIND WG mailing
list namedroppers@internic.net.
This draft expires on December 9, 2000.
Copyright Notice
Copyright (C) The Internet Society (2000). All rights reserved.
Abstract
This document proposes an alternate architecture to enable secure
online Domain Name System (DNS) dynamic updates. It is intended
Expires December 2000 [Page 1]
INTERNET-DRAFT Secure Online DNS Dynamic Update June 2000
to enable a DNS zone to provide online dynamic update and at the
same time, maintain the zone's security including role separation
and intrusion tolerance against insider and outsider attacks.
Threshold digital signature is used to implement the proposed
architecture.
1 - Introduction
This document proposes an alternate architecture to allow a
DNS zone to provide secure online dynamic update. In contrast
to existing dynamic update scheme, the proposed architecture
distinguishes itself in that it provides high security
for a zone when allowing it support online dynamic update.
Familiarity with the DNS system [RFC1034, RFC1035], DNS
Security Extension [RFC2535], dynamic update [RFC2136] and
secure dynamic update [RFC2137] is helpful and is assumed by
this document.
This document obsoletes RFC 2137, an alternate proposal
for secure dynamic update, due to implementation experience.
1.1 - Overview of DNS Security Extension
DNS Security Extension (DNSSEC) is proposed in [RFC2535].
The DNSSEC provides RR authentication by the use of digital
signatures. In DNSSEC, each zone is equipped with a
public/private key pair. The private key is used to digitally
sign all the RRs in that zone. The response to a DNS query
will also include the requested RRs and a SIG RR
(signature RR), which contains the digital signature of the
requested RRs. The zone public key, used to verify signatures,
is disseminated by means of KEY RRs.
A major security principle of the DNSSEC is the role separation:
it differentiates the roles of the DNS server administrator from
the DNS zone manager. One advantage of the role separation
is that it helps to prevent power abuses [SBM99]. In DNSSEC,
it is the DNS zone manager, not the DNS server administrator,
who is responsible for the security of a zone. A DNS server is
just a place to publish the digitally signed DNS data of the zone.
Thus, compromise of a secondary server or, if the zone private
key is kept off line, even the primary server for a zone, will
not necessarily affect the degree of assurance that a DNS
client receives [RFC2535]. When zone data is updated, the zone
manager will sign the new zone data off-line.
1.2 - Overview of DNS Dynamic Update and DNS Secure Dynamic Update
The idea of keeping zone private key off-line and computing
the signatures of RRs off-line is based on the assumption
that RRs in a DNS zone are relatively static. Indeed, in
normal situations we can expect that bindings between domain
names and IP addresses do not change frequently. However, it
has been pointed out that DNS dynamic updates, which enable
real-time changes (that is, add, delete, or update) in
name/address bindings, are useful under many circumstances
[Liu99,RFC2136]. (For example, such an update allows a
Wang, Huang & Rine [Page 2]
INTERNET-DRAFT June 2000
corporation to switch to a new domain name without waiting for
the slow, manual processing of the name change request by a
domain name registrar.) For a dynamic RR update to take effect
immediately and securely, the signature of the updated RR must
be computed online. It is worthwhile to note that although
a DNS dynamic update requestor is communicating with a name
server, the name server itself has no rights to update the
zone data. Instead, it is the zone private key, instead of
the name server's private key, that is needed in the dynamic
update.
In [RFC2137], two modes are defined to achieve the above goal.
In mode A, the zone private key is kept off-line and any
dynamic requests will be authorized by a dynamic update key
that is kept online. However, in this mode, since the zone
private key is not kept online, zone transfer security is
not automatically provided for dynamically added RRs, where
they could be omitted, and authorization is not provided for
the server denial of the existence of a dynamically added
type [RFC2137]. In this sense, this mode is not a genuine
DNS dynamic update. In mode B, on the other hand, the zone
private key is kept online at the zone primary name server;
thus, any legitimate DNS dynamic updates can be in effect
immediately.
1.3 - The existing drawbacks
Both of the above modes above require that a zone security
related private key be kept on line at the primary name server.
This practice raises security concerns [RFC2137]. First, it makes
the primary name server a single point of attack to an outside
attacker. Should the primary server be compromised, the on¡line
private key will be exposed, rendering dynamic RRs insecure
in mode A or, even worse, all RRs in the entire zone insecure
in mode B. Second, as an insider, the name server administrator
has access of this private key, compromising the role separation
principle and making it possible for the name server
administrator to abuse his/her power. (The importance of fending
off insider attacks has been emphasized by the security
community [RFC2196].)
2 - The Secure On-line DNS Dynamic Update Architecture
2.1 - Background: Threshold Cryptography
Threshold cryptography is a branch of cryptography that
enables a group of n members, 1,2, ..., n, to act as a single
communication party, using one pair of public and private keys
[Des87,Des94,Des97]. Similar to the traditional public key
cryptography, the public key is known to the public. Unlike
the traditional public key cryptography, the private key of
the group, K_private, does not exist as a whole. Rather, each
member i, 1 <= i <= n, will be assigned a number of key shares
of the private key. (For each public key cryptography algorithm,
Wang, Huang & Rine [Page 3]
INTERNET-DRAFT June 2000
a corresponding key sharing mechanism must be devised.) To
perform a cryptographic computation (such as decryption, signing,
identification, etc.) on message m with key K_private, b,
b <= n , group members will be required. Each member will compute
a partial result. Subsequently, the partial results are combined
to produce the final result. The combiner is not necessarily to
be trusted. Note that during this whole process the shared
private key, K_private, is never reconstructed. Further,
threshold cryptography requires that the shared private key
cannot be reconstructed from any t < b group members.
Practical threshold cryptography for RSA and DSS have been
designed. A practical threshold RSA is given by [DDB94] where
b = t+1 and a practical threshold DSS is given by [GJKR96b] where
t < n/2 and b = 2t+1.
2.2 - Introduction
+------------------------+
+---------+ #####| zone-security server 1 |
+---------+ | DNS | # +------------------------+
|DNS | DNS query | | #
| Inquirer|---------> | | #
+---------+ | Primary | # +------------------------+
| |#########| zone-security server 2 |
| Name | # +------------------------+
| | #
| | # . . .
+------+ | Server | # . . .
|DNS | DNS Dynamic | | # . . .
| User |=============> | | # +--------------------------+
+------+ Update request| | #####| zone-security server n-1 |
| | +--------------------------+
+---------+
|
| zone transfer
\|/
+-----------------+
| DNS Secondary |
| Name Server |
+-----------------+
In the above proposed architecture, we assume that there exist
(n-1), n >= 2, machines in a given DNS zone that are under the
control of the zone manager, but not under the control of the
name server administrators. These machines are called the
zone-security servers.
Using a threshold cryptography scheme with n > t >= 1, the
zone private key is shared among the (n-1) zone-security servers
and the primary name server. To update zone's data dynamically,
some of the servers will be needed. Let b > t be the number of
zone private key shares needed in the computation of the
signature of an RR. Since b >= 2, any change to the zone data
will need the cooperation of at least one zone-security server;
Wang, Huang & Rine [Page 4]
INTERNET-DRAFT June 2000
the name server administrator will have no way to modify the
digitally signed zone data. Thus, the role separation principle
holds. Moreover, the above architecture enhances intrusion
tolerance of DNS.
A DNS system is said to be k-intrusion-tolerant against an
entity, E, if breaking into k servers (including the
zone-security servers and the DNS name servers, if applicable)
that are outside E's control will not help E gain any knowledge
of the zone private key. A DNS system is said to be intrusion
tolerant against an outsider (insider) if it is at least
1-intrusion-tolerant against the outsider (insider). The
architecture proposed in this document can be configured to be
intrusion tolerant against outside and inside attackers.
Intrusion tolerance against outsider attacks. In the
architecture, the zone private key cannot be recovered from
any single location, thus, making the system intrusion
tolerant against an outside attacker. That is, even when an
outside attacker manages to corrupt l, l <= t, of relevant
servers (including the name servers and the zone-security
servers), secrecy of the zone private key is still
maintained.
Intrusion tolerance against insider attacks. The presence of
zone security servers and the necessity of their involvement
in signature computations constitute a defense line
against insider attacks, in particular, attacks from name
server administrators. Clearly, a hostile name server
administrator must break into at least t zone security
servers (to get access to the respective key shares) in
order to perform unauthorized RR signature computations.
3 - Implementation Details
[RFC2535] defines two types of SIG records, the DSA SIG and
the RSA/MD5 SIG. The important configuration and implementation
aspects of our proposed architecture with respect to these two types
of SIGs are given next. In the following statement,
the primary name server will be referred to as server 0 and the
(n-1) zone-security servers will be referred to as servers
1, 2, ... , (n-1).
3.1 - Example Configurations
The following table gives some representative configurations, in
terms of t and n, to achieve the above security levels in
different application cases.
Wang, Huang & Rine [Page 5]
INTERNET-DRAFT June 2000
+----------------------------+----------------------------+
| | RSA/MD5 SIG | DSA SIG |
| SECURITY LEVEL +-------------+--------------+
| | 1-2 | 2-4 | 1-3 | 2-5 |
+----------------------------+-----+-------+-------+------+
|Intrusion tolerant against | | | | |
| outsider attackers (Y/N) | Y | Y | Y | Y |
+----------------------------+-----+-------+-------+------+
|Intrusion tolerant against | | | | |
| insider attackers (Y/N) | N | Y | N | Y |
+----------------------------+-----+-------+-------+------+
3.2 - The RSA/MD5 SIG
Assume that, in RSA, the zone's private key is d and its
public key is (e, N). Phi(N) is the Euler function of N, i.e.,
phi(N) = (p-1)(q-1) where N = p * q. We use the threshold
digital signature scheme given in [DDB94] and now give
how the zone private key is shared and how to generate a
RSA/MD5 SIG RR online.
The 1-2 case. In this case, the zone manager generates a random,
d1, 1 < d1 < phi(N), and compute d2, d2 = d - d1 mod phi(N).
Values d1 and d2 are sent securely to the primary name server
and the zone-security server respectively.
To generate a RSA/MD5 SIG of m, where m is the MD5 digest of
an RR, the two servers will compute m^d1 mod N and m^d2 mod N
respectively. Then any one of them can combine the partial
results as m^d1 * m^d2 mod N = m^d mod N, the digital signature
of m by the zone private key.
The 2-4 case. To generate key shares, the zone manager generates
4 random numbers, d1, d2, d3, d4, where 1 < di < phi(N)
for 1 <= i <= 4. He/she will also compute two numbers,
d5 = d - d1 - d2 mod phi(N) and d6 = d - d3 - d4 mod phi(N).
Subsequently, d1 and d6 are sent to the primary name server,
d2 and d6 are sent to server 1, d3 and d5 are sent to server 2,
d4 and d5 are sent to server 3, as shown in the following table.
+---------------------+----------+----------+----------+---------+
| | SERVER 0 | SERVER 1 | SERVER 2 | SERVER 3|
+---------------------+----------+----------+----------+---------+
| KEYS ASSIGNED | d1, d6 | d2, d6 | d3, d5 | d4, d5 |
+-------------+-------+----------+----------+----------+---------+
|PARTICIPATING|(0,1,2)| d1 | d2 | d5 | |
| +-------+----------+----------+----------+---------+
| |(0,1,3)| d1 | d2 | | d5 |
| +-------+----------+----------+----------+---------+
| |(0,2,3)| d6 | | d3 | d4 |
| SERVERS +-------+----------+----------+----------+---------+
| |(1,2,3)| | d6 | d3 | d4 |
+-------------+-------+----------+----------+----------+---------+
Wang, Huang & Rine [Page 6]
INTERNET-DRAFT June 2000
To generate a RSA/MD5 SIG, any 3 of the 4 servers will be
needed. For example, if the primary name server and the
zone-security servers 1 and 2 are present (the (0,1,2) case in
the above table), the three servers will compute m^d1 mod N,
m^d2 mod N, and m^d3 mod N respectively. After that any one of
them can combine the partial results to produce
m^d1 * m^d2 * m^d3 mod N = m^d mod N, the digital signature of
m by the zone private key. Other possibilities of computing
the signature of m are summarized in the above table.
3.3 - The DSA SIG
In this case, for a t-n configuration (such as the 1-3 and 2-5
configurations), the zone manager will generate n shares of the
zone private key and distribute them to the n servers
using a (t,n) Shamir secret sharing scheme [Sha79]. When the
zone data needs updating, (2t+1) servers are required to jointly
compute the DSA SIG RR [GJKR96b].
5 - Security considerations
This document proposes an architecture to allow a DNS zone to
provide secure online DNS dynamic update. It uses threshold
digital signature to maintain the role separation principle and can
also provide intrusion tolerance against both outside attackers
and inside attackers.
It should be noted that the authentication a DNS dynamic update
requestor and authorization of a update request, which is handled
elsewhere such as [RFC2535], is not dealt in this document,
6 - Acknowledgements
The authors wish to thank for many helpful discussions on the
DNSSEC mailing list and would like to give special thanks to
Yvo Desmedt.
7 - References
[DDB94] Y. Desmedt, G. Di Crescenzo, and M. Burmester.
``Multiplicative nonabelian sharing schemes and their
application to threshold cryptography''. In J. Pieprzyk
and R. SafaviNaini, editors, Advances in Cryptology -
Asiacrypt '94, volume 917 of Lecture Notes in Computer
Science, pages 21--32, Wollongong, Australia,
November/December 1994. Springer-Verlag.
[Des87] Y. Desmedt. ``Society and group oriented cryptography:
a new concept''. In C. Pomerance, editor, Advances in
Cryptology, Proc. of Crypto '87, volume 293 of Lecture
Notes in Computer Science, pages 120--127, Santa Barbara,
California, U.S.A., August 16--20, 1988. Springer-Verlag.
Wang, Huang & Rine [Page 7]
INTERNET-DRAFT June 2000
[Des94] Y. Desmedt. ``Threshold cryptography''. European Trans.
on Telecommunications, 5(4):449--457, July-August 1994.
[Des97] Y. Desmedt. ``Some recent research aspects of threshold
cryptography''. In E. Okamoto, G. Davida, and M. Mambo,
editors, Information Security, volume 1396 of Lecture
Notes in Computer Science, pages 158--173, Tatsunokuchi,
Ishikawa, Japan, September 1997. Springer-Verlag.
[DSA2] National Institute for Standards and Technology.
``Digital signature standard (DSS)'', February 2000.
[GJKR96b] R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin.
``Robust threshold DSS signatures''. In U. Maurer,
editor, Advances in Cryptology - Eurocrypt '96,
volume 1070 of Lecture Notes in Computer Science,
pages 354-371, Zaragoza, Spain, May 12--16 1996.
Springer-Verlag.
[GMP] T. Granlund. ``GNU MP''. Source code available from
http://www.gnu.org/manual/gmp/index.html.
[Liu99] C. Liu. ``Securing an Internet name server''.
Presentation, 1999. Available at
http://www.acmebw.com/papers/securing.pdf.
[RFC1034] P. Mockapetris, ``Domain Names - Concepts and
Facilities,'' RFC 1034, ISI, November 1987.
[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
Specification,'' RFC 1035, ISI, November 1987.
[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound ``Dynamic
Updates in the Domain Name System,'' RFC 2136, ISC &
Bellcore & Cisco & DEC, April 1997.
[RFC2137] D. Eastlake ``Secure Domain Name System Dynamic Update,''
RFC 2137, CyberCash, April 1997.
[RFC2196] B. Fraser. ``Site Security Handbook,'' RFC2196, September
1997.
[RFC2535] D. Eastlake, ``Domain Name System Security Extensions,''
RFC 2535, IBM, March 1999.
[SBM99] R. Sandhu, V. Bhamidipati, and Q. Munawer. ``The ARBAC97
model for role-based administration of roles''. ACM
Transactions on Information System Security, 2(1):105-
135, February 1999.
[Sha79] A. Shamir. ``How to share a secret''. Commun. ACM,
22:612-613, November 1979.
Wang, Huang & Rine [Page 8]
INTERNET-DRAFT June 2000
8 - Author's Address
A postscript of this document is available from
http://www.cs.gmu.edu/~xwang4/dnssecureonline.ps
Send all comments to xwang4@cs.gmu.edu
Xunhua Wang
Department of Computer Science
George Mason University
Fairfax, VA 22030-4444
USA
Phone: +1-703-993-1536
Fax: +1-703-993-1710
EMail: xwang4@cs.gmu.edu
Yih Huang
Department of Computer Science
George Mason University
Fairfax, VA 22030-4444
USA
Phone: +1-703-993-1540
Fax: +1-703-993-1710
EMail: hyangyih@cs.gmu.edu
David Rine
Department of Computer Science
George Mason University
Fairfax, VA 22030-4444
USA
Phone: +1-703-993-1546
Fax: +1-703-993-1710
EMail: drine@cs.gmu.edu
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
Wang, Huang & Rine [Page 9]
INTERNET-DRAFT June 2000
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."
Expires December 2000 [Page 10]
INTERNET-DRAFT Secure Online DNS Dynamic Update June 2000

19
doc/draft/draft-whr-dnsext-secure-online-update-01.txt Normal file
View File

@ -0,0 +1,19 @@
This Internet-Draft has been deleted. Unrevised documents placed in the
Internet-Drafts directories have a maximum life of six months. After
that time, they are deleted. This Internet-Draft was not published as
an RFC.
Internet-Drafts are not an archival document series, and expired
drafts, such as this one, are not available; please do not ask for
copies... they are not available. The Secretariat does not have
information as to future plans of the authors or working groups WRT the
deleted Internet-Draft.
For more information or a copy of the document, contact the author directly.
Draft Author(s):
Y. Huang: huang@infonet.com