+++ /dev/null
-
-
-
-
-Internet-Draft T. Baba
-Expires: August 4, 2003 NTT Data
- February 4, 2003
-
-
- Requirements for Access Control in Domain Name Systems
- draft-baba-dnsext-acl-reqts-00.txt
-
-Status of this Memo
-
- This document is an Internet-Draft and is subject to 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/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Distribution of this memo is unlimited.
-
- This Internet-Draft will expire on August 4, 2003.
-
-Abstract
-
- This document describes the requirements for access control
- mechanisms in the Domain Name System (DNS), which authenticate
- clients and then allow or deny access to resource records in the
- zone according to the access control list (ACL).
-
-1. Introduction
-
- The Domain Name System (DNS) is a hierarchical, distributed, highly
- available database used for bi-directional mapping between domain
- names and IP addresses, for email routing, and for other information
- [RFC1034, 1035]. DNS security extensions (DNSSEC) have been defined
- to authenticate the data in DNS and provide key distribution services
- using SIG, KEY, and NXT resource records (RRs) [RFC2535].
-
-
-
-Baba Expires August 4, 2003 [Page 1]
-\f
-Internet-Draft DNS Access Control Requirements February 2003
-
-
- At the 28th IETF Meeting in Houston in 1993, DNS security design team
- started a discussion about DNSSEC and agreed to accept the assumption
- that "DNS data is public". Accordingly, confidentiality for queries
- or responses is not provided by DNSSEC, nor are any sort of access
- control lists or other means to differentiate inquirers. However,
- about ten years has passed, access control in DNS has been more
- important than before. With DNS access control mechanism, access
- from unauthorized clients can be blocked when they perform DNS name
- resolution. Thus, for example, Denial of Service (DoS) attacks
- against a server used by a closed user group can be prevented using
- this mechanism if IP address of the server is not revealed by other
- sources.
-
- This document describes the requirements for access control
- mechanisms in DNS.
-
-2. Terminology
-
- AC-aware client
- This is the client that understands the DNS access control
- extensions. This client may be an end host which has a stub
- resolver, or a cashing/recursive name server which has a
- full-service resolver.
-
- AC-aware server
- This is the authoritative name server that understands the DNS
- access control extensions.
-
- ACE
- An Access Control Entry. This is the smallest unit of access
- control policy. It grants or denies a given set of access
- rights to a set of principals. An ACE is a component of an ACL,
- which is associated with a resource.
-
- ACL
- An Access Control List. This contains all of the access control
- policies which are directly associated with a particular
- resource. These policies are expressed as ACEs.
-
- Client
- A program or host which issues DNS requests and accepts its
- responses. A client may be an end host or a cashing/recursive name
- server.
-
- RRset
- All resource records (RRs) having the same NAME, CLASS and TYPE
- are called a Resource Record Set (RRset).
-
-
-
-
-Baba Expires August 4, 2003 [Page 2]
-\f
-Internet-Draft DNS Access Control Requirements February 2003
-
-
-3. Requirements
-
- This section describes the requirements for access control in DNS.
-
-3.1 Authentication
-
-3.1.1 Client Identifier / Authentication Mechanism
-
- The AC-aware server must identify AC-aware clients based on IP
- address and/or domain name (user ID or host name), and must
- authenticate them using strong authentication mechanism such as
- digital signature or message authentication code (MAC).
-
- SIG(0) RR [RFC2931] contains a domain name associated with sender's
- public key in its signer's name field, and TSIG RR [RFC2845] also
- contains a domain name associated with shared secret key in its key
- name field. Each of these domain names can be a host name or a user
- name, and can be used as a sender's identifier for access control.
- Furthermore, SIG(0) uses digital signatures, and TSIG uses MACs for
- message authentication. These mechanisms can be used to authenticate
- AC-aware clients.
-
- Server authentication may be also provided.
-
-3.1.2 End-to-End Authentication
-
- In current DNS model, caching/recursive name servers are deployed
- between end hosts and authoritative name servers. Although
- authoritative servers can authenticate caching/recursive name servers
- using SIG(0) or TSIG, they cannot authenticate end hosts behind them.
- For end-to-end authentication, the mechanism for an end host to
- discover the target authoritative name server and directly access to
- it bypassing caching/recursive name servers is needed. For example,
- an end host can get the IP addresses of the authoritative name
- servers by retrieving NS RRs for the zone via local caching/recursive
- name server.
-
-3.1.3 Authentication Key Retrieval
-
- Keys which are used to authenticate clients should be able to be
- automatically retrieved. The KEY RR is used to store a public key
- for a zone or a host that is associated with a domain name. SIG(0)
- RR uses a public key in KEY RR for verifying the signature. If
- DNSSEC is available, the KEY RR would be protected by the SIG RR.
- KEY RR or newly defined RR can be used to automatic key retrieval.
-
-
-
-
-
-
-Baba Expires August 4, 2003 [Page 3]
-\f
-Internet-Draft DNS Access Control Requirements February 2003
-
-
-3.2 Confidentiality
-
-3.2.1 Data Encryption
-
- To avoid disclosure to eavesdroppers, the response containing the
- RRsets which are restricted to access from particular users should be
- encrypted. Although IPsec can be used to encrypt DNS packets, it
- authenticates a peer based on IP address. Currently, no encryption
- mechanism is specified in DNS. Therefore, new RRs must be defined
- for DNS message encryption. In case encryption is applied, entire
- DNS message including DNS header must be encrypted to hide
- information including error code.
-
- Query encryption may be also provided.
-
-3.2.2 Key Exchange
-
- If DNS message encryption is provided, automatic key exchange
- mechanism must be also provided. [RFC2930] specifies a TKEY RR that
- can be used to establish and delete shared secret keys used by TSIG
- between a client and a server. With minor extensions, TKEY can be
- used to establish shared secret keys used for message encryption.
-
-3.2.3 Caching
-
- The RRset that is restricted to access from particular users must not
- be cached. To avoid caching, the TTL of the RR that is restricted to
- access should be set to zero during transit.
-
-3.3 Access Control
-
-3.3.1 Granularity of Access Control
-
- Control of access on a per-user/per-host granularity must be
- supported. Control of access to individual RRset (not just the
- entire zone) must be also supported. However, SOA, NS, SIG, NXT,
- KEY, and DS RRs must be publicly accessible to avoid unexpected
- results.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Baba Expires August 4, 2003 [Page 4]
-\f
-Internet-Draft DNS Access Control Requirements February 2003
-
-
-3.3.2 ACL Representation
-
- Access Control List (ACL) format must be standardized so that both
- the primary and secondary AC-aware servers can recognize the same
- ACL. Although ACL may appear in or out of zone data, it must be
- transferred to the secondary AC-aware server with associated zone
- data. It is a good idea to contain ACL in zone data, because ACL can
- be transferred with zone data using existing zone transfer mechanisms
- automatically. However, ACL must not be published except for
- authorized secondary master servers.
-
- In zone data master files, ACL should be specified using TXT RRs or
- newly defined RRs. In each access control entry (ACE), authorized
- entities (host or user) must be described using domain name (host
- name, user name, or IP address in in-addr.arpa/ip6.arpa format).
- There may be other access control attributes such as access time.
-
- It must be possible to create publicly readable entries, which may be
- read even by unauthenticated clients.
-
-3.3.3 Zone/ACL Transfer
-
- As mentioned above, ACL should be transferred from a primary AC-aware
- server to a secondary AC-aware server with associated zone data.
- When an AC-aware server receives a zone/ACL transfer request, the
- server must authenticate the client, and should encrypt the zone
- data and associated ACL during transfer.
-
-3.4 Backward/co-existence Compatibility
-
- Any new protocols to be defined for access control in DNS must be
- backward compatible with existing DNS protocol. AC-aware servers
- must be able to process normal DNS query without authentication, and
- must respond if retrieving RRset is publicly accessible.
-
- Modifications to root/gTLD/ccTLD name servers are not allowed.
-
-4. Security Considerations
-
- This document discusses the requirements for access control
- mechanisms in DNS.
-
-5. Acknowledgements
-
- This work is funded by the Telecommunications Advancement
- Organization of Japan (TAO).
-
- The author would like to thank the members of the NTT DATA network
- security team for their important contribution to this work.
-
-
-Baba Expires August 4, 2003 [Page 5]
-\f
-Internet-Draft DNS Access Control Requirements February 2003
-
-
-6. References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
- [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, May 2000.
-
- [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)",
- RFC 2930, September 2000.
-
- [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
- (SIG(0)s)", RFC 2931, September 2000.
-
-
-Author's Address
-
- Tatsuya Baba
- NTT Data Corporation
- Research and Development Headquarters
- Kayabacho Tower, 1-21-2, Shinkawa, Chuo-ku,
- Tokyo 104-0033, Japan
-
- Tel: +81 3 3523 8081
- Fax: +81 3 3523 8090
- Email: babatt@nttdata.co.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Baba Expires August 4, 2003 [Page 6]
+++ /dev/null
-
-IETF DNSEXT WG Bill Manning
-draft-dnsext-opcode-discover-01.txt ISI
- Paul Vixie
- ISC
- Erik Guttman
- SUN
- 21 Dec 2002
-
-
- The DISCOVER opcode
-
-This document is an Internet-Draft and is subject to all provisions of
-Section 10 of RFC2026.
-
-Comments may be submitted to the group mailing list at "mdns@zocalo.net"
-or the authors.
-
-Distribution of this memo is unlimited.
-
-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 capitalized keywords "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
-
-0. Abstract:
-
- The QUERY opcode in the DNS is designed for unicast. With the
- development of multicast capabilities in the DNS, it is desireable
- to have a more robust opcode for server interactions since a single
- request may result in replies from multiple responders. So DISCOVER
- is defined to deal with replies from multiple responders.
-
- As such, this document extend the core DNS specifications to allow
- clients to have a method for coping with replies from multiple
- responders. Use of this new opcode may facilitate DNS operations in
- modern networking topologies. A prototype of the DISCOVER opcode
- was developed as part of the TBDS project, funded under DARPA grant
- F30602-99-1-0523.
-
-1. Introduction:
-
- This document describes an experimental extension to the DNS to receive
- multiple responses which is the likely result when using DNS that has
- enabled multicast queries. This approach was developed as part of the
- TBDS research project, funded under DARPA grant F30602-99-1-0523. The
- full processing rules used by TBDS are documented here for possible
- incorporation in a future revision of the DNS specification."
-
-2. Method:
-
- DISCOVER works like QUERY except:
-
- 1. it can be sent to a broadcast or multicast destination QUERY
- isn't defined for non-unicast, and arguably shouldn't be.
-
- 2. the Question section, if present, has <QNAME=zonename,QTYPE=SOA>
- tuples. Our testing tried to augment this structure as follows:
- <QNAME=service,QTYPE=SRV>. While this worked for our purposes in
- TBDS, it is cleaner to place the SRV question in a separate pass.
-
- 3. if QDCOUNT==0 then only servers willing to do recursion should
- answer. Other servers must silently discard the DISCOVER request.
-
- 4. if QDCOUNT!=0 then only servers who are authoritative for the
- zones named by some QNAME should answer.
-
- 5. responses may echo the request's Question section or leave it blank,
- just like QUERY.
-
- 6. responses have "normal" Answer, Authority, and Additional sections.
- e.g. the response is the same as that to a QUERY. It is desireable
- that zero content answers not be sent to avoid badly formed or
- unfulfilled requests. Responses should be sent to the unicast
- address of the requester and the source address should reflect
- the unicast address of the responder.
-
- Example usage for gethostby{name,addr}-style requestors:
-
- Compute the zone name of the enclosing in-addr.arpa, ip6.int, or
- ip6.arpa domain.
-
- DISCOVER whether anyone in-scope is authoritative for this zone.
-
- If so, query these authoritative servers for local
- in-addr/ip6 names.
-
- If not, DISCOVER whether there are recursive servers available.
-
- If so, query these recursive servers for local
- in-addr/ip6 names.
-
- So, a node will issue a multicast request with the DISCOVER opcode at
- some particular multicast scope. Then determine, from the replies,
- whether there are any DNS servers which are authoritative (or support
- recursion) for the zone. Replies to DISCOVER requests MUST set the
- Recursion Available (RA) flag in the DNS message header.
-
- It is important to recognize that a requester must be prepared to
- receive multiple replies from multiple responders.
-
- Once one learns a host's FQDN by the above means, repeat the process
- for discovering the closest enclosing authoritative server of such
- local name.
-
- Cache all NS and A data learned in this process, respecting TTL's.
-
- TBDS usage for SRV requestors:
-
- Do the gethostbyaddr() and gethostbyname() on one's own link-local
- address, using the above process.
-
- Assume that the closest enclosing zone for which an authority server
- answers an in-scope DISCOVER packet is "this host's parent domain".
-
- Compute the SRV name as _service._transport.*.parentdomain.
-
- This is a change to the definition as defined in RFC 1034.
- A wildcard label ("*") in the QNAME used in a DNS message with
- opcode DISCOVER SHOULD be evaluated with special rules. The
- wildcard matches any label for which the DNS server data is
- authoritative. For example 'x.*.example.com.' would match
- 'x.y.example.com.' and 'x.yy.example.com.' provided that the
- server was authoritative for 'example.com.' In this particular
- case, we suggest the follwing considerations be made:
-
- getservbyname() can be satisfied by issuing a request with
- this computed SRV name. The servent structure can be
- populated by values returned from a request as follows:
-
- s_name The name of the service, "_service" without the
- preceding underscore.
- s_aliases The names returned in the SRV RRs in replies
- to the query.
- s_port The port number in the SRV RRs replies to the
- query. If these port numbers disagree - one
- of the port numbers is chosen, and only those
- names which correspond are returned.
- s_proto The transport protocol from named by the
- "_transport" label, without the preceding
- underscore.
-
- Send SRV query for this name to discovered local authority servers.
-
- Usage for disconnected networks with no authority servers:
-
- Hosts should run a "stub server" which acts as though its FQDN is a
- zone name. Computed SOA gives the host's FQDN as MNAME, "." as the
- ANAME, seconds-since-1Jan2000 as the SERIAL, low constants for EXPIRE
- and the other timers. Computed NS gives the host's FQDN. Computed
- glue gives the host's link-local address. Or Hosts may run a
- "DNS stub server" which acts as though its FQDN is a zone name. The
- rules governing the behavior of this stub server are given elsewhere
- [1] [2].
-
- Such stub servers should answer DISCOVER packets for its zone, and
- will be found by the iterative "discover closest enclosing authority
- server" by DISCOVER clients, either in the gethostbyname() or SRV
- cases described above. Note that stub servers only answer with
- zone names which match QNAME's, not with zone names which are owned
- by QNAME's.
-
- The only deviation from the DNS[3][4] model is that a host (like, say, a
- printer offering LPD services) has a DNS server which answers authoritatively
- for something which hasn't been delegated to it. However, the only way that
- such DNS servers can be discovered is with a new opcode, DISCOVER, which
- is explicitly defined to discover undelegated zones for tightly scoped
- purposes. Therefore this isn't officially a violation of DNS's coherency
- principles. In some cases, a responder to DISCOVER, may not be traditional
- DNS software, it could be special purpose software.
-
-3. IANA Considerations
-
- As a new opcode, the IANA will need to assign a numeric value
- for the memnonic. The last OPCODE assigned was "5", for UPDATE.
- Test implementations have used OPCODE "6".
-
-4. Security Considerations
-
- No new security considerations are known to be introduced with a new
- opcode, however using multicast for service discovery has the potential
- for denial of service, primarly from flooding attacks. It may also be
- possible to enable deliberate misconfiguration of clients simply by
- running a malicious DNS resolver that claims to be authoritative for
- things that it is not. One possible way to mitigate this effect is by
- use of credentials, such as CERT resource records within an RR set.
- The TBDS project took this approach.
-
-5. Attribution:
-
- This material was generated in discussions on the mdns mailing list
-hosted by Zocalo in March 2000. Paul Vixie, Stuart Cheshire, Bill Woodcock,
-Erik Guttman and Bill Manning were active contributors.
-
-6. Author's Address
-
- Bill Manning
- PO 12317
- Marina del Rey, CA. 90295
- +1.310.322.8102
- bmanning@karoshi.com
-
- Paul Vixie
- Internet Software Consortium
- 950 Charter Street
- Redwood City, CA 94063
- +1 650 779 7001
- <vixie@isc.org>
-
- Erik Guttman
- Sun Microsystems
- Eichh\367lzelstr. 7
- 74915 Waibstadt Germany
- +49 6227 356 202
- erik.guttman@sun.com
-
-7. References
-
-Informational References:
-
-[1] Esibov, L., Aboba, B., Thaler, D., "Multicast DNS",
- draft-ietf-dnsext-mdns-00.txt, November 2000. Expired
-
-[2] Woodcock, B., Manning, B., "Multicast Domain Name Service",
- draft-manning-dnsext-mdns-00.txt, August 2000. Expired.
-
-Normative References:
-[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES",
- RFC 1034, November 1987.
-[4] Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
- RFC 1035, November 1987
-
+++ /dev/null
-
-
-DNSEXT Working Group Levon Esibov
-INTERNET-DRAFT Stuart Kwan
-Category: Best Current Practice Microsoft
-<draft-esibov-dnsext-dynupdtld-00.txt>
-February 22, 2001
-
-
- Dynamic DNS Update of the Top Level Domain and Root Zones
-
-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.
-
-
-
-Status of this Memo
-
-This document specifies an Internet Best Current Practices for the
-Internet Community, and requests discussion and suggestions for
-improvements. Distribution of this memo is unlimited.
-
-
-Copyright Notice
-
-Copyright (C) The Internet Society (2001). All Rights Reserved.
-
-Abstract
-
-With an increasing number of implementations where the DNS client is
-capable of performing dynamic DNS updates, an increase in the number of
-the dynamic DNS updates sent to the servers hosting top level domain
-zones has been observed. The purpose of this document is to recommend
-DNS client configuration that prevents sending dynamic DNS updates for
-the top level domain zones and root zones.
-
-
-
-
-
-
-Esibov & Kwan BCP [Page 1]
-
-INTERNET-DRAFT Dynamic Update of the TLD DNS Zones 22 February 2001
-
-
-
-1. Introduction
-
-RFC 2136 [1] specifies Dynamic Updates in DNS, but does not
-consider updates of the top level domain zones (e.g. "com", "edu", "ca",
-"uk", etc...) and the root zone as a special case. Usually requests to
-perform dynamic updates of the top level domain zones and the root zone
-are expected to fail because these zones (on the Internet) are
-configured to prohibit any dynamic updates. The same is true for most
-organizations' private internal DNS infrastructures. The unnecessary
-load of the dynamic updates sent by DNS clients attempting dynamic
-updates of these zones consumes the resources of the DNS servers
-authoritative for these zones and consumes network bandwidth.
-
-With an increasing number of implementations where the DNS client is
-capable of performing dynamic DNS updates, an increase in the number of
-the dynamic DNS updates sent to the servers hosting top level domain
-zones has been observed. The purpose of this document is to recommend
-DNS client configuration that prevents sending dynamic DNS updates for
-the top level domain zones and root zones.
-
-In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
-"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
-described in [2].
-
-
-
-2. Dynamic updates of the top level domain zones and root zones.
-
-To prevent dynamic DNS update requests to the top level domain zones and
-root zone, it is recommended that DNS clients are configured by default
-to suppress dynamic DNS updates of the top level domain zones and the
-root zone.
-
-To address the needs of the organizations using top level domain zones
-and/or the root zone in their private internal DNS infrastructures, and
-to allow dynamic updates of such zones, DNS clients MAY be configured to
-allow dynamic DNS updates to be sent to the top level domain zones.
-
-
-
-3. IANA Considerations
-
-IANA's consideration is not required.
-
-
-
-4. Security Considerations
-
-This draft does not introduce any additional security concerns.
-
-
-
-Esibov & Kwan BCP [Page 2]
-
-INTERNET-DRAFT Dynamic Update of the TLD DNS Zones 22 February 2001
-
-
-5. Acknowledgements
-
-Authors would like to thank Aristotle Balogh and Mark Kosters for
-bringing to our attention the raising volume of the dynamic update
-requests sent to the top level domain zones. We would also like to thank
-Michael Cretzman for review of this document.
-
-
-
-6. Authors' Addresses
-
-Levon Esibov
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-EMail: levone@microsoft.com
-
-
-
-Stuart Kwan
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-EMail: skwan@microsoft.com
-
-
-7. References
-
-[1] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates
- in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
-
-[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-
-8. Intellectual Property Statement
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property or other rights that might be claimed to pertain
-to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might or
-might not be available; neither does it represent that it has made any
-effort to identify any such rights. Information on the IETF's
-procedures with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11. Copies of claims of
-rights made available for publication and any assurances of licenses to
-be made available, or the result of an attempt made to obtain a general
-license or permission for the use of such proprietary rights by
-implementors or users of this specification can be obtained from the
-IETF Secretariat.
-
-Esibov & Kwan BCP [Page 3]
-
-INTERNET-DRAFT Dynamic Update of the TLD DNS Zones 22 February 2001
-
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary rights
-which may cover technology that may be required to practice this
-standard. Please address the information to the IETF Executive
-Director.
-
-
-
-9. Full Copyright Statement
-
-Copyright (C) The Internet Society (2001). 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."
-
-10. Expiration Date
-
-This memo is filed as <draft-esibov-dnsext-dynupdtld-00.txt>, and
-expires August 22, 2001.
-
-
-
-
-Esibov & Kwan BCP [Page 4]
-
-
+++ /dev/null
-\r
-This Internet-Draft has been deleted. Unrevised documents placed in the\r
-Internet-Drafts directories have a maximum life of six months. After\r
-that time, they are deleted. This Internet-Draft was not published as\r
-an RFC.\r
-\r
-Internet-Drafts are not an archival document series, and expired\r
-drafts, such as this one, are not available; please do not ask for\r
-copies... they are not available. The Secretariat does not have\r
-information as to future plans of the authors or working groups WRT the\r
-deleted Internet-Draft.\r
-\r
-For more information or a copy of the document, contact the author directly.\r
-\r
-Draft Author(s):\r
-\r
-R. Hibbs: rbhibbs@pacbell.com \r
-\r
-\r
+++ /dev/null
-INTERNET-DRAFT Andreas Gustafsson
-draft-ietf-dnsext-axfr-clarify-03.txt Nominum Inc.
- July 2001
-
-
- DNS Zone Transfer Protocol Clarifications
-
-
-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
-
- In the Domain Name System, zone data is replicated among
- authoritative DNS servers by means of the "zone transfer" protocol,
- also known as the "AXFR" protocol. This memo clarifies, updates, and
- adds missing detail to the original AXFR protocol specification in
- RFC1034.
-
-1. Introduction
-
- The original definition of the DNS zone transfer protocol consists of
- a single paragraph in [RFC1034] section 4.3.5 and some additional
- notes in [RFC1035] section 6.3. It is not sufficiently detailed to
- serve as the sole basis for constructing interoperable
- implementations. This document is an attempt to provide a more
- complete definition of the protocol. Where the text in RFC1034
- conflicts with existing practice, the existing practice has been
- codified in the interest of interoperability.
-
-
-
-
-Expires January 2002 [Page 1]
-\f
-draft-ietf-dnsext-axfr-clarify-03.txt July 2001
-
-
- 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. The zone transfer request
-
- To initiate a zone transfer, the slave server sends a zone transfer
- request to the master server over a reliable transport such as TCP.
- The form of this request is specified in sufficient detail in RFC1034
- and needs no further clarification.
-
- Implementers are advised that one server implementation in widespread
- use sends AXFR requests where the TCP message envelope size exceeds
- the DNS request message size by two octets.
-
-3. The zone transfer response
-
- If the master server is unable or unwilling to provide a zone
- transfer, it MUST respond with a single DNS message containing an
- appropriate RCODE other than NOERROR. If the master is not
- authoritative for the requested zone, the RCODE SHOULD be 9
- (NOTAUTH).
-
- Slave servers should note that some master server implementations
- will simply close the connection when denying the slave access to the
- zone. Therefore, slaves MAY interpret an immediate graceful close of
- the TCP connection as equivalent to a "Refused" response (RCODE 5).
-
- If a zone transfer can be provided, the master server sends one or
- more DNS messages containing the zone data as described below.
-
-3.1. Multiple answers per message
-
- The zone data in a zone transfer response is a sequence of answer
- RRs. These RRs are transmitted in the answer section(s) of one or
- more DNS response messages.
-
- The AXFR protocol definition in RFC1034 does not make a clear
- distinction between response messages and answer RRs. Historically,
- DNS servers always transmitted a single answer RR per message. This
- encoding is wasteful due to the overhead of repeatedly sending DNS
- message headers and the loss of domain name compression
- opportunities. To improve efficiency, some newer servers support a
- mode where multiple RRs are transmitted in a single DNS response
- message.
-
- A master MAY transmit multiple answer RRs per response message up to
- the largest number that will fit within the 65535 byte limit on TCP
-
-
-
-Expires January 2002 [Page 2]
-\f
-draft-ietf-dnsext-axfr-clarify-03.txt July 2001
-
-
- DNS message size. In the case of a small zone, this can cause the
- entire transfer to be transmitted in a single response message.
-
- Slaves MUST accept messages containing any number of answer RRs. For
- compatibility with old slaves, masters that support sending multiple
- answers per message SHOULD be configurable to revert to the
- historical mode of one answer per message, and the configuration
- SHOULD be settable on a per-slave basis.
-
-3.2. DNS message header contents
-
- RFC1034 does not specify the contents of the DNS message header of
- the zone transfer response messages. The header of each message MUST
- be as follows:
-
- ID Copy from request
- QR 1
- OPCODE QUERY
- AA 1, but MAY be 0 when RCODE is not NOERROR
- TC 0
- RD Copy from request, or 0
- RA Set according to availability of recursion, or 0
- Z 0
- AD 0
- CD 0
- RCODE NOERROR on success, error code otherwise
-
- The slave MUST check the RCODE in each message and abort the transfer
- if it is not NOERROR. It SHOULD check the ID of the first message
- received and abort the transfer if it does not match the ID of the
- request. The ID SHOULD be ignored in subsequent messages, and fields
- other than RCODE and ID SHOULD be ignored in all messages, to ensure
- interoperability with certain older implementations which transmit
- incorrect or arbitrary values in these fields.
-
-3.3. Additional section and SIG processing
-
- Zone transfer responses are not subject to any kind of additional
- section processing or automatic inclusion of SIG records. SIG RRs in
- the zone data are treated exactly the same as any other RR type.
-
-3.4. The question section
-
- RFC1034 does not specify whether zone transfer response messages have
- a question section or not. The initial message of a zone transfer
- response SHOULD have a question section identical to that in the
- request. Subsequent messages SHOULD NOT have a question section,
- though the final message MAY. The receiving slave server MUST accept
-
-
-
-Expires January 2002 [Page 3]
-\f
-draft-ietf-dnsext-axfr-clarify-03.txt July 2001
-
-
- any combination of messages with and without a question section.
-
-3.5. The authority section
-
- The master server MUST transmit messages with an empty authority
- section. Slaves MUST ignore any authority section contents they may
- receive from masters that do not comply with this requirement.
-
-3.6. The additional section
-
- The additional section MAY contain additional RRs such as transaction
- signatures. The slave MUST ignore any unexpected RRs in the
- additional section. It MUST NOT treat additional section RRs as zone
- data.
-
-4. Zone data
-
- The purpose of the zone transfer mechanism is to exactly replicate at
- each slave the set of RRs associated with a particular zone at its
- primary master. An RR is associated with a zone by being loaded from
- the master file of that zone at the primary master server, or by some
- other, equivalent method for configuring zone data.
-
- This replication shall be complete and unaltered, regardless of how
- many and which intermediate masters/slaves are involved, and
- regardless of what other zones those intermediate masters/slaves do
- or do not serve, and regardless of what data may be cached in
- resolvers associated with the intermediate masters/slaves.
-
- Therefore, in a zone transfer the master MUST send exactly those
- records that are associated with the zone, whether or not their owner
- names would be considered to be "in" the zone for purposes of
- resolution, and whether or not they would be eligible for use as glue
- in responses. The transfer MUST NOT include any RRs that are not
- associated with the zone, such as RRs associated with zones other
- than the one being transferred or present in the cache of the local
- resolver, even if their owner names are in the zone being transferred
- or are pointed to by NS records in the zone being transferred.
-
- The slave MUST associate the RRs received in a zone transfer with the
- specific zone being transferred, and maintain that association for
- purposes of acting as a master in outgoing transfers.
-
-5. Transmission order
-
- RFC1034 states that "The first and last messages must contain the
- data for the top authoritative node of the zone". This is not
- consistent with existing practice. All known master implementations
-
-
-
-Expires January 2002 [Page 4]
-\f
-draft-ietf-dnsext-axfr-clarify-03.txt July 2001
-
-
- send, and slave implementations expect to receive, the zone's SOA RR
- as the first and last record of the transfer.
-
- Therefore, the quoted sentence is hereby superseded by the sentence
- "The first and last RR transmitted must be the SOA record of the
- zone".
-
- The initial and final SOA record MUST be identical, with the possible
- exception of case and compression. In particular, they MUST have the
- same serial number. The slave MUST consider the transfer to be
- complete when, and only when, it has received the message containing
- the second SOA record.
-
- The transmission order of all other RRs in the zone is undefined.
- Each of them SHOULD be transmitted only once, and slaves MUST ignore
- any duplicate RRs received.
-
-6. Security Considerations
-
- The zone transfer protocol as defined in [RFC1034] and clarified by
- this memo does not have any built-in mechanisms for the slave to
- securely verify the identity of the master server and the integrity
- of the transferred zone data. The use of a cryptographic mechanism
- for ensuring authenticity and integrity, such as TSIG [RFC2845],
- IPSEC, or TLS, is RECOMMENDED.
-
- The zone transfer protocol allows read-only public access to the
- complete zone data. Since data in the DNS is public by definition,
- this is generally acceptable. Sites that wish to avoid disclosing
- their full zone data MAY restrict zone transfer access to authorized
- slaves.
-
- These clarifications are not believed to themselves introduce any new
- security problems, nor to solve any existing ones.
-
-Acknowledgements
-
- Many people have contributed input and commentary to earlier versions
- of this document, including but not limited to Bob Halley, Dan
- Bernstein, Eric A. Hall, Josh Littlefield, Kevin Darcy, Robert Elz,
- Levon Esibov, Mark Andrews, Michael Patton, Peter Koch, Sam
- Trenholme, and Brian Wellington.
-
-References
-
- [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
- November 1987.
-
-
-
-
-Expires January 2002 [Page 5]
-\f
-draft-ietf-dnsext-axfr-clarify-03.txt July 2001
-
-
- [RFC1035] - Domain Names - Implementation and Specifications, P.
- Mockapetris, November 1987.
-
- [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
- S. Bradner, BCP 14, March 1997.
-
- [RFC2845] - Secret Key Transaction Authentication for DNS (TSIG). P.
- Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, May 2000.
-
-Author's Address
-
- Andreas Gustafsson
- Nominum Inc.
- 950 Charter Street
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 381 6004
-
- Email: gson@nominum.com
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000, 2001). 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 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
-
-
-
-Expires January 2002 [Page 6]
-\f
-draft-ietf-dnsext-axfr-clarify-03.txt July 2001
-
-
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires January 2002 [Page 7]
-\f
+++ /dev/null
-
-
-
-
-
-
- DNSEXT Working Group Olafur Gudmundsson
- INTERNET-DRAFT May 2003
- <draft-ietf-dnsext-delegation-signer-14.txt>
-
- Updates: RFC 1035, RFC 2535, RFC 3008, RFC 3090.
-
-
- Delegation Signer Resource Record
-
-
-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 DNSEXT WG mailing list
- namedroppers@ops.ietf.org
-
- This draft expires on December 6, 2003.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2003). All rights reserved.
-
-
-
-Abstract
-
- The delegation signer (DS) resource record is inserted at a zone cut
- (i.e., a delegation point) to indicate that the delegated zone is
- digitally signed and that the delegated zone recognizes the indicated
- key as a valid zone key for the delegated zone. The DS RR is a
- modification to the DNS Security Extensions definition, motivated by
-
-
-
-Gudmundsson Expires December 2003 [Page 1]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
- operational considerations. The intent is to use this resource record
- as an explicit statement about the delegation, rather than relying on
- inference.
-
- This document defines the DS RR, gives examples of how it is used and
- the implications of this record on resolvers. This change is not
- backwards compatible with RFC 2535.
- This document updates RFC1035, RFC2535, RFC3008 and RFC3090.
-
-
-1 Introduction
-
- Familiarity with the DNS system [RFC1035], DNS security extensions
- [RFC2535] and DNSSEC terminology [RFC3090] is important.
-
- Experience shows that when the same data can reside in two
- administratively different DNS zones, the data frequently gets out of
- sync. The presence of an NS RRset in a zone anywhere other than at
- the apex indicates a zone cut or delegation. The RDATA of the NS
- RRset specifies the authoritative servers for the delegated or
- "child" zone. Based on actual measurements, 10-30% of all delegations
- on the Internet have differing NS RRsets at parent and child. There
- are a number of reasons for this, including a lack of communication
- between parent and child and bogus name servers being listed to meet
- registry requirements.
-
- DNSSEC [RFC2535,RFC3008,RFC3090] specifies that a child zone needs to
- have its KEY RRset signed by its parent to create a verifiable chain
- of KEYs. There has been some debate on where the signed KEY RRset
- should reside, whether at the child [RFC2535] or at the parent. If
- the KEY RRset resides at the child, maintaining the signed KEY RRset
- in the child requires frequent two-way communication between the two
- parties. First the child transmits the KEY RRset to the parent and
- then the parent sends the signature(s) to the child. Storing the KEY
- RRset at the parent was thought to simplify the communication.
-
- DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
- an unsecure child zone to indicate that the child is unsecure. A NULL
- KEY record is a waste: an entire signed RRset is used to communicate
- effectively one bit of information--that the child is unsecure.
- Chasing down NULL KEY RRsets complicates the resolution process in
- many cases, because servers for both parent and child need to be
- queried for the KEY RRset if the child server does not return it.
- Storing the KEY RRset only in the parent zone simplifies this and
- would allow the elimination of the NULL KEY RRsets entirely. For
- large delegation zones the cost of NULL keys is a significant barrier
- to deployment.
-
-
-
-
-
-Gudmundsson Expires December 2003 [Page 2]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
- Another complication of the DNSSEC key model is that the KEY record
- can be used to store public keys for other protocols in addition to
- DNSSEC keys. There are number of potential problems with this,
- including:
- 1. The KEY RRset can become quite large if many applications and
- protocols store their keys at the zone apex. Possible protocols
- are IPSEC, HTTP, SMTP, SSH and others that use public key
- cryptography.
- 2. The KEY RRset may require frequent updates.
- 3. The probability of compromised or lost keys, which trigger
- emergency key rollover procedures, increases.
- 4. The parent may refuse sign KEY RRsets with non-DNSSEC zone keys.
- 5. The parent may not meet the child's expectations in turnaround
- time for resigning the KEY RRset.
-
- Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
-
-
-1.2 Reserved Words
-
- The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
- "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
- interpreted as described in RFC2119.
-
-2 Specification of the Delegation key Signer
-
- This section defines the Delegation Signer (DS) RR type (type code
- TBD) and the changes to DNS to accommodate it.
-
-2.1 Delegation Signer Record Model
-
- This document presents a replacement for the DNSSEC KEY record chain
- of trust [RFC2535] that uses a new RR that resides only at the
- parent. This record identifies the key(s) that the child uses to
- self-sign its own KEY RRset.
-
- The chain of trust is now established by verifying the parent KEY
- RRset, the DS RRset from the parent and the KEY RRset at the child.
- This is cryptographically equivalent to using just KEY records.
-
- Communication between the parent and child is greatly reduced, since
- the child only needs to notify the parent about changes in keys that
- sign its apex KEY RRset. The parent is ignorant of all other keys in
- the child's apex KEY RRset. Furthermore, the child maintains full
- control over the apex KEY RRset and its content. The child can
- maintain any policies regarding its KEY usage for DNSSEC with minimal
- impact on the parent. Thus if the child wants to have frequent key
- rollover for its DNS zone keys, the parent does not need to be aware
- of it. The child can use one key to sign only its apex KEY RRset and
-
-
-
-Gudmundsson Expires December 2003 [Page 3]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
- a different key to sign the other RRsets in the zone.
-
- This model fits well with a slow roll out of DNSSEC and the islands
- of security model. In this model, someone who trusts "good.example."
- can preconfigure a key from "good.example." as a trusted key, and
- from then on trusts any data signed by that key or that has a chain
- of trust to that key. If "example." starts advertising DS records,
- "good.example." does not have to change operations by suspending
- self-signing. DS records can also be used to identify trusted keys
- instead of KEY records. Another significant advantage is that the
- amount of information stored in large delegation zones is reduced:
- rather than the NULL KEY record at every unsecure delegation required
- by RFC 2535, only secure delegations require additional information
- in the form of a signed DS RRset.
-
- The main disadvantage of this approach is that verifying a zone's KEY
- RRset requires two signature verification operations instead of the
- one required by RFC 2535. There is no impact on the number of
- signatures verified for other types of RRsets.
-
- Even though DS identifies two roles for KEY's, Key Signing Key (KSK)
- and Zone Signing Key (ZSK), there is no requirement that zone use two
- different keys for these roles. It is expected that many small zones
- will only use one key, while larger organizations will be more likely
- to use multiple keys.
-
-2.2 Protocol Change
-
- All DNS servers and resolvers that support DS MUST support the OK bit
- [RFC3225] and a larger message size [RFC3226]. In order for a
- delegation to be considered secure the delegation MUST contain a DS
- RRset. If a query contains the OK bit, a server returning a referral
- for the delegation MUST include the following RRsets in the authority
- section in this order:
- If DS RRset is present:
- parents copy of childs NS RRset
- DS and SIG(DS)
- If no DS RRset is present:
- parents copy of childs NS RRset
- parents zone NXT and SIG(NXT)
-
- This increases the size of referral messages and possilbly causing
- some or all glue to be omitted. If the DS or NXT RRsets with
- signatures do not fit in the DNS message, the TC bit MUST be set.
- Additional section processing is not changed.
-
- A DS RRset accompanying a NS RRset indicates that the child zone is
- secure. If a NS RRset exists without a DS RRset, the child zone is
- unsecure (from the parents point of view). DS RRsets MUST NOT appear
-
-
-
-Gudmundsson Expires December 2003 [Page 4]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
- at non-delegation points or at a zone's apex.
-
- Section 2.2.1 defines special considerations related to authoritative
- servers responding to DS queries and replaces RFC2535 sections 2.3.4
- and 3.4. Section 2.2.2 replaces RFC3008 section 2.7, and section
- 2.2.3 updates RFC3090.
-
-
-2.2.1 RFC2535 2.3.4 and 3.4: Special Considerations at Delegation Points
-
- DNS security views each zone as a unit of data completely under the
- control of the zone owner with each entry (RRset) signed by a special
- private key held by the zone manager. But the DNS protocol views the
- leaf nodes in a zone that are also the apex nodes of a child zone
- (i.e., delegation points) as "really" belonging to the child zone.
- The corresponding domain names appear in two master files and might
- have RRsets signed by both the parent and child zones' keys. A
- retrieval could get a mixture of these RRsets and SIGs, especially
- since one server could be serving both the zone above and below a
- delegation point [RFC 2181].
-
- Each DS RRset stored in the parent zone MUST be signed by at least
- one of the parent zone's private key. The parent zone MUST NOT
- contain a KEY RRset at any delegation point. Delegations in the
- parent MAY contain only the following RR types: NS, DS, NXT and SIG.
- The NS RRset MUST NOT be signed. The NXT RRset is the exceptional
- case: it will always appear differently and authoritatively in both
- the parent and child zones if both are secure.
-
- A secure zone MUST contain a self-signed KEY RRset at its apex. Upon
- verifying the DS RRset from the parent, a resolver MAY trust any KEY
- identified in the DS RRset as a valid signer of the child's apex KEY
- RRset. Resolvers configured to trust one of the keys signing the KEY
- RRset MAY now treat any data signed by the zone keys in the KEY RRset
- as secure. In all other cases resolvers MUST consider the zone
- unsecure. A DS RRset MUST NOT appear at a zone's apex.
-
- An authoritative server queried for type DS MUST return the DS RRset
- in the answer section.
-
-
-2.2.1.1 Special processing for DS queries
-
- When a server is authoritative for the parent zone at a delegation
- point and receives a query for the DS record at that name, it will
- return the DS from the parent zone. This is true whether or not it
- is also authoritative for the child zone.
-
-
-
-
-
-Gudmundsson Expires December 2003 [Page 5]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
- When the server is authoritative for the child zone at a delegation
- point but not the parent zone, there is no natural response, since
- the child zone is not authoritative for the DS record at the zone's
- apex. As these queries are only expected to originate from recursive
- servers which are not DS-aware, the authoritative server MUST answer
- with:
- RCODE: NOERROR
- AA bit: set
- Answer Section: Empty
- Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
-
- That is, it answers as if it is authoritative and the DS record does
- not exist. DS-aware recursive servers will query the parent zone at
- delegation points, so will not be affected by this.
-
- A server authoritative for only the child zone at a delegation point
- that is also a caching server MAY (if the RD bit is set in the query)
- perform recursion to find the DS record at the delegation point, and
- may return the DS record from its cache. In this case, the AA bit
- MUST not be set in the response.
-
-
-2.2.1.2 Special processing when child and an ancestor share server"
-
- Special rules are needed to permit DS RR aware servers to gracefully
- interact with older caches which otherwise might falsely label a
- server as lame because of the new placement of the DS RR set.
-
- Such a situation might arise when a server is authoritative for both
- a zone and it's grandparent, but not the parent. This sounds like an
- obscure example, but it is very real. The root zone is currently
- served on 13 machines, and "root-servers.net." is served on 4 of the
- same 13, but "net." is served elsewhere.
-
- When a server receives a query for (<QNAME>, DS, IN), the response
- MUST be determined from reading these rules in order:
-
-
- 1) If the server is authoritative for the zone that holds the DS RR
- set (i.e., the zone that delegates <QNAME> away, aka the "parent"
- zone), the response contains the DS RR set as an authoritative
- answer.
-
- 2) If the server is offering recursive service and the RD bit is set
- in the query, the server performs the query itself (according to the
- rules for resolvers described below) and returns it's findings.
-
- 3) If the server is authoritative for the zone that holds the
- <QNAME>'s SOA RR set, the response is an authoritative negative
-
-
-
-Gudmundsson Expires December 2003 [Page 6]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
- answer as described in 2.2.1.1.
-
- 4) If the server is authoritative for a zone or zones above the
- QNAME, a referral to the most enclosing zone's servers is made.
-
- 5) If the server is not authoritative for any part of the QNAME, a
- response indicating a lame server for QNAME is given.
-
- Using these rules will require some special processing on the part of
- a DS RR aware resolver. To illustrate this, an example is used.
-
- Assuming a server is authoritative for roots.example.net. and for the
- root zone but not the intervening two zones (or the intervening two
- label deep zone). Assume that QNAME=roots.example.net., QTYPE=DS,
- and QCLASS=IN.
-
- The resolver will issue this request (assuming no cached data)
- expecting a referral to a net. server. Instead, rule number 3 above
- applies and a negative answer is returned by the server. The
- reaction by the resolver is not to accept this answer as final as it
- can determine from the SOA RR in the negative answer the context
- within which the server has answered.
-
- A solution to this is to instruct the resolver to hunt for the
- authoritative zone of the data in a brute force manner.
-
- This can be accomplished by taking the owner name of the returned SOA
- RR and strip off enough left-hand labels until a successful NS
- response is obtained. A successful response here means that the
- answer has NS records in it. (Entertaining the possibility that a
- cut point may be two labels down in a zone.)
-
- Returning to the example, the response will include a negative answer
- with either the SOA RR for "roots.example.net." or "example.net."
- depending on whether roots.example.net is a delegated domain. In
- either case, removing the least significant label of the SOA owner
- name will lead to the location of the desired data.
-
-
-2.2.1.3 Modification on KEY RR in the construction of Responses
-
- This section updates RFC2535 section 3.5 by replacing it with the
- following:
-
- An query for KEY RR MUST NOT trigger any additional section
- processing. Security aware resolver will include corresponding SIG
- records in the answer section.
-
-
-
-
-
-Gudmundsson Expires December 2003 [Page 7]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
- KEY records SHOULD NOT be added to additional records section in
- response to any query.
-
- RFC2535 included rules to in add KEY records to additional section
- when SOA or NS records where included in an answer. The is was done
- to reduce round trips (in the case of SOA) and to force out NULL
- KEY's (in the NS case), as this document obsoletes NULL keys there is
- no need for the second case, the first case causes redundant
- transfers of KEY RRset as SOA is included in the authority section of
- negative answers.
-
- RFC2535 section 3.5 also included rule for adding KEY RRset to query
- for A and AAAA, as Restrict KEY[RFC3445] eliminated use of KEY RR by
- all applications therfore the rule is not needed anymore.
-
-
-2.2.2 Signer's Name (replaces RFC3008 section 2.7)
-
- The signer's name field of a SIG RR MUST contain the name of the zone
- to which the data and signature belong. The combination of signer's
- name, key tag, and algorithm MUST identify a zone key if the SIG is
- to be considered material. This document defines a standard policy
- for DNSSEC validation; local policy may override the standard policy.
-
- There are no restrictions on the signer field of a SIG(0) record.
- The combination of signer's name, key tag, and algorithm MUST
- identify a key if this SIG(0) is to be processed.
-
-
-2.2.3 Changes to RFC3090
-
- A number of sections of RFC3090 need to be updated to reflect the DS
- record.
-
-
-2.2.3.1 RFC3090: Updates to section 1: Introduction
-
- Most of the text is still relevant but the words ``NULL key'' are to
- be replaced with ``missing DS RRset''. In section 1.3 the last three
- paragraphs discuss the confusion in sections of RFC 2535 that are
- replaced in section 2.2.1 above. Therefore, these paragraphs are now
- obsolete.
-
-
-2.2.3.2 RFC3090 section 2.1: Globally Secured
-
- Rule 2.1.b is replaced by the following rule:
-
-
-
-
-
-Gudmundsson Expires December 2003 [Page 8]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
- 2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
- private key whose public counterpart MUST appear in a zone signing
- KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
- implement algorithm. This KEY RR MUST be identified by a DS RR in a
- signed DS RRset in the parent zone.
-
- If a zone cannot get its parent to advertise a DS record for it, the
- child zone cannot be considered globally secured. The only exception
- to this is the root zone, for which there is no parent zone.
-
-
-2.2.3.3 RFC3090 section 3: Experimental Status.
-
- The only difference between experimental status and globally secured
- is the missing DS RRset in the parent zone. All locally secured zones
- are experimental.
-
-
-2.2.4 NULL KEY elimination
-
- RFC3445 section 3 elminates the top two bits in the flags field of
- KEY RR. These two bits where used to indicate NULL KEY or NO KEY.
- RFC3090 defines that zone that defines that zone is either secure or
- not, eliminates the possible need to put NULL keys in the zone apex
- to indicate that the zone is not secured for a algorithm. Along with
- this document these other two elminate all uses for the NULL KEY,
- Thus this document obsoletes NULL KEY.
-
-2.3 Comments on Protocol Changes
-
- Over the years there have been various discussions surrounding the
- DNS delegation model, declaring it to be broken because there is no
- good way to assert if a delegation exists. In the RFC2535 version of
- DNSSEC, the presence of the NS bit in the NXT bit map proves there is
- a delegation at this name. Something more explicit is needed and the
- DS record addresses this need for secure delegations.
-
- The DS record is a major change to DNS: it is the first resource
- record that can appear only on the upper side of a delegation. Adding
- it will cause interoperabilty problems and requires a flag day for
- DNSSEC. Many old servers and resolvers MUST be upgraded to take
- advantage of DS. Some old servers will be able to be authoritative
- for zones with DS records but will not add the NXT or DS records to
- the authority section. The same is true for caching servers; in
- fact, some may even refuse to pass on the DS or NXT records.
-
-
-
-
-
-
-
-Gudmundsson Expires December 2003 [Page 9]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
-2.4 Wire Format of the DS record
-
- The DS (type=TDB) record contains these fields: key tag, algorithm,
- digest type, and the digest of a public key KEY record that is
- allowed and/or used to sign the child's apex KEY RRset. Other keys
- MAY sign the child's apex KEY RRset.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | key tag | algorithm | Digest type |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | digest (length depends on type) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | (SHA-1 digest is 20 bytes) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The key tag is calculated as specified in RFC2535. Algorithm MUST be
- an algorithm number assigned in the range 1..251 and the algorithm
- MUST be allowed to sign DNS data. The digest type is an identifier
- for the digest algorithm used. The digest is calculated over the
- canonical name of the delegated domain name followed by the whole
- RDATA of the KEY record (all four fields).
-
- digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
-
- KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
-
- Digest type value 0 is reserved, value 1 is SHA-1, and reserving
- other types requires IETF standards action. For interoperabilty
- reasons, as few digest algorithms as possible should be reserved. The
- only reason to reserve additional digest types is to increase
- security.
-
- DS records MUST point to zone KEY records that are allowed to
- authenticate DNS data. The indicated KEY record's protocol field
- MUST be set to 3; flag field bit 7 MUST be set to 1. The value of
- other flag bits is not significant for the purposes of this document.
-
- The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
- of key size, new digest types probably will have larger digests.
-
-
-
-
-
-Gudmundsson Expires December 2003 [Page 10]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
-2.4.1 Justifications for Fields
-
- The algorithm and key tag fields are present to allow resolvers to
- quickly identify the candidate KEY records to examine. SHA-1 is a
- strong cryptographic checksum: it is computationally infeasible for
- an attacker to generate a KEY record that has the same SHA-1 digest.
- Combining the name of the key and the key rdata as input to the
- digest provides stronger assurance of the binding. Having the key
- tag in the DS record adds greater assurance than the SHA-1 digest
- alone, as there are now two different mapping functions that a KEY RR
- must match.
-
- This format allows concise representation of the keys that the child
- will use, thus keeping down the size of the answer for the
- delegation, reducing the probability of DNS message overflow. The
- SHA-1 hash is strong enough to uniquely identify the key and is
- similar to the PGP key footprint. The digest type field is present
- for possible future expansion.
-
- The DS record is well suited to listing trusted keys for islands of
- security in configuration files.
-
-2.5 Presentation Format of the DS Record
-
- The presentation format of the DS record consists of three numbers
- (key tag, algorithm and digest type) followed by the digest itself
- presented in hex:
- example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890
-
-2.6 Transition Issues for Installed Base
-
- No backwards compatibility with RFC2535 is provided.
-
- RFC2535-compliant resolvers will assume that all DS-secured
- delegations are locally secure. This is bad, but the DNSEXT Working
- Group has determined that rather than dealing with both
- RFC2535-secured zones and DS-secured zones, a rapid adoption of DS is
- preferable. Thus the only option for early adopters is to upgrade to
- DS as soon as possible.
-
-2.6.1 Backwards compatibility with RFC2535 and RFC1035
-
- This section documents how a resolver determines the type of
- delegation.
- RFC1035 delegation (in parent) has:
-
- RFC1035 NS
-
- RFC2535 adds the following two cases:
-
-
-
-Gudmundsson Expires December 2003 [Page 11]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
- Secure RFC2535: NS + NXT + SIG(NXT)
- NXT bit map contains: NS SIG NXT
- Unsecure RFC2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
- NXT bit map contains: NS SIG KEY NXT
- KEY must be a NULL key.
-
- DNSSEC with DS has the following two states:
-
- Secure DS: NS + DS + SIG(DS)
- NXT bit map contains: NS SIG NXT DS
- Unsecure DS: NS + NXT + SIG(NXT)
- NXT bit map contains: NS SIG NXT
-
- It is difficult for a resolver to determine if a delegation is secure
- RFC 2535 or unsecure DS. This could be overcome by adding a flag to
- the NXT bit map, but only upgraded resolvers would understand this
- flag, anyway. Having both parent and child signatures for a KEY RRset
- might allow old resolvers to accept a zone as secure, but the cost of
- doing this for a long time is much higher than just prohibiting RFC
- 2535-style signatures at child zone apexes and forcing rapid
- deployment of DS-enabled servers and resolvers.
-
- RFC 2535 and DS can in theory be deployed in parallel, but this would
- require resolvers to deal with RFC 2535 configurations forever. This
- document obsoletes the NULL KEY in parent zones, which is a difficult
- enough change that a flag day is required.
-
-2.7 KEY and corresponding DS record example
-
- This is an example of a KEY record and the corresponding DS record.
-
- dskey.example. KEY 256 3 1 (
- AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
- 4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
- ) ; key id = 28668
- DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Gudmundsson Expires December 2003 [Page 12]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
-3 Resolver
-
-3.1 DS Example
-
- To create a chain of trust, a resolver goes from trusted KEY to DS to
- KEY.
-
- Assume the key for domain "example." is trusted. Zone "example."
- contains at least the following records:
- example. SOA <soa stuff>
- example. NS ns.example.
- example. KEY <stuff>
- example. NXT NS SOA KEY SIG NXT secure.example.
- example. SIG(SOA)
- example. SIG(NS)
- example. SIG(NXT)
- example. SIG(KEY)
- secure.example. NS ns1.secure.example.
- secure.example. DS tag=12345 alg=3 digest_type=1 <foofoo>
- secure.example. NXT NS SIG NXT DS unsecure.example.
- secure.example. SIG(NXT)
- secure.example. SIG(DS)
- unsecure.example NS ns1.unsecure.example.
- unsecure.example. NXT NS SIG NXT example.
- unsecure.example. SIG(NXT)
-
- In zone "secure.example." following records exist:
- secure.example. SOA <soa stuff>
- secure.example. NS ns1.secure.example.
- secure.example. KEY <tag=12345 alg=3>
- secure.example. KEY <tag=54321 alg=5>
- secure.example. NXT <nxt stuff>
- secure.example. SIG(KEY) <key-tag=12345 alg=3>
- secure.example. SIG(SOA) <key-tag=54321 alg=5>
- secure.example. SIG(NS) <key-tag=54321 alg=5>
- secure.example. SIG(NXT) <key-tag=54321 alg=5>
-
- In this example the private key for "example." signs the DS record
- for "secure.example.", making that a secure delegation. The DS record
- states which key is expected to sign the KEY RRset at
- "secure.example.". Here "secure.example." signs its KEY RRset with
- the KEY identified in the DS RRset, thus the KEY RRset is validated
- and trusted.
-
- This example has only one DS record for the child, but parents MUST
- allow multiple DS records to facilitate key rollover and multiple KEY
- algorithms.
-
-
-
-
-
-Gudmundsson Expires December 2003 [Page 13]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
- The resolver determines the security status of "unsecure.example." by
- examining the parent zone's NXT record for this name. The absence of
- the DS bit indicates an unsecure delegation. Note the NXT record
- SHOULD only be examined after verifying the corresponding signature.
-
-3.1 Resolver Cost Estimates for DS Records
-
- From a RFC2535 resolver point of view, for each delegation followed
- to chase down an answer, one KEY RRset has to be verified.
- Additional RRsets might also need to be verified based on local
- policy (e.g., the contents of the NS RRset). Once the resolver gets
- to the appropriate delegation, validating the answer might require
- verifying one or more signatures. A simple A record lookup requires
- at least N delegations to be verified and one RRset. For a DS-enabled
- resolver, the cost is 2N+1. For an MX record, where the target of
- the MX record is in the same zone as the MX record, the costs are N+2
- and 2N+2, for RFC 2535 and DS, respectively. In the case of negatives
- answer the same ratios hold true.
-
- The resolver may require an extra query to get the DS record and this
- may add to the overall cost of the query, but this is never worse
- than chasing down NULL KEY records from the parent in RFC2535 DNSSEC.
-
- DS adds processing overhead on resolvers and increases the size of
- delegation answers, but much less than storing signatures in the
- parent zone.
-
-4 Security Considerations:
-
- This document proposes a change to the validation chain of KEY
- records in DNSSEC. The change is not believed to reduce security in
- the overall system. In RFC2535 DNSSEC, the child zone has to
- communicate keys to its parent and prudent parents will require some
- authentication with that transaction. The modified protocol will
- require the same authentication, but allows the child to exert more
- local control over its own KEY RRset.
-
- There is a remote possibility that an attacker could generate a valid
- KEY that matches all the DS fields, of a specific DS set, and thus
- forge data from the child. This possibility is considered
- impractical, as on average more than
- 2 ^ (160 - <Number of keys in DS set>)
- keys would have to be generated before a match would be found.
-
- An attacker that wants to match any DS record will have to generate
- on average at least 2^80 keys.
-
- The DS record represents a change to the DNSSEC protocol and there is
- an installed base of implementations, as well as textbooks on how to
-
-
-
-Gudmundsson Expires December 2003 [Page 14]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
- set up secure delegations. Implementations that do not understand the
- DS record will not be able to follow the KEY to DS to KEY chain and
- will consider all zones secured that way as unsecure.
-
-5 IANA Considerations:
-
- IANA needs to allocate an RR type code for DS from the standard RR
- type space (type 43 requested).
-
- IANA needs to open a new registry for the DS RR type for digest
- algorithms. Defined types are:
- 0 is Reserved,
- 1 is SHA-1.
- Adding new reservations requires IETF standards action.
-
-6 Acknowledgments
-
- Over the last few years a number of people have contributed ideas
- that are captured in this document. The core idea of using one key to
- sign only the KEY RRset comes from discussions with Bill Manning and
- Perry Metzger on how to put in a single root key in all resolvers.
- Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie, Jakob
- Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt Larson,
- Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker, Miek
- Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
- Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
- Andrews, Harald Alvestrand, and others have provided useful comments.
-
-Normative References:
-
-[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
- Specification'', STD 13, RFC 1035, November 1987.
-
-[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
- 2535, March 1999.
-
-[RFC3008] B. Wellington, ``Domain Name System Security (DNSSEC) Signing
- Authority'', RFC 3008, November 2000.
-
-[RFC3090] E. Lewis `` DNS Security Extension Clarification on Zone
- Status'', RFC 3090, March 2001.
-
-[RFC3225] D. Conrad, ``Indicating Resolver Support of DNSSEC'', RFC
- 3225, December 2001.
-
-[RFC3445] D. Massey, S. Rose ``Limiting the scope of the KEY Resource
- Record (RR)``, RFC 3445, December 2002.
-
-
-
-
-
-Gudmundsson Expires December 2003 [Page 15]
-\f
-INTERNET-DRAFT Delegation Signer Record February 2003
-
-
-Informational References
-
-[RFC2181] R. Elz, R. Bush, ``Clarifications to the DNS Specification'',
- RFC 2181, July 1997.
-
-[RFC3226] O. Gudmundsson, ``DNSSEC and IPv6 A6 aware server/resolver
- message size requirements'', RFC 3226, December 2001.
-
-Author Address
-
- Olafur Gudmundsson
- 3821 Village Park Drive
- Chevy Chase, MD, 20815
- USA
- <ogud@ogud.com>
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). 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."
-
-
-
-
-
-
-
-
-
-Gudmundsson Expires December 2003 [Page 16]
+++ /dev/null
-
-
-DNSEXT Working Group M. Stapp
-Internet-Draft Cisco Systems, Inc.
-Expires: May 2, 2003 T. Lemon
- A. Gustafsson
- Nominum, Inc.
- November 1, 2002
-
-
- A DNS RR for Encoding DHCP Information (DHCID RR)
- <draft-ietf-dnsext-dhcid-rr-06.txt>
-
-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.
-
- This Internet-Draft will expire on May 2, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- It is possible for multiple DHCP clients to attempt to update the
- same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
- the clients themselves perform the DNS updates, conflicts can arise.
- To resolve such conflicts, "Resolution of DNS Name Conflicts"[1]
- proposes storing client identifiers in the DNS to unambiguously
- associate domain names with the DHCP clients to which they refer.
- This memo defines a distinct RR type for this purpose for use by
- DHCP clients and servers, the "DHCID" RR.
-
-
-
-
-Stapp, et. al. Expires May 2, 2003 [Page 1]
-\f
-Internet-Draft The DHCID RR November 2002
-
-
-Table of Contents
-
- 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. The DHCID RR . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3.1 DHCID RDATA format . . . . . . . . . . . . . . . . . . . . . 4
- 3.2 DHCID Presentation Format . . . . . . . . . . . . . . . . . 4
- 3.3 The DHCID RR Type Codes . . . . . . . . . . . . . . . . . . 4
- 3.4 Computation of the RDATA . . . . . . . . . . . . . . . . . . 5
- 3.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.5.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 4. Use of the DHCID RR . . . . . . . . . . . . . . . . . . . . 6
- 5. Updater Behavior . . . . . . . . . . . . . . . . . . . . . . 6
- 6. Security Considerations . . . . . . . . . . . . . . . . . . 7
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
- References . . . . . . . . . . . . . . . . . . . . . . . . . 7
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
- Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et. al. Expires May 2, 2003 [Page 2]
-\f
-Internet-Draft The DHCID RR November 2002
-
-
-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 RFC 2119[2].
-
-2. Introduction
-
- A set of procedures to allow DHCP[3] clients and servers to
- automatically update the DNS (RFC1034[4], RFC1035[5]) is proposed in
- "Resolution of DNS Name Conflicts"[1].
-
- Conflicts can arise if multiple DHCP clients wish to use the same
- DNS name. To resolve such conflicts, "Resolution of DNS Name
- Conflicts"[1] proposes storing client identifiers in the DNS to
- unambiguously associate domain names with the DHCP clients using
- them. In the interest of clarity, it is preferable for this DHCP
- information to use a distinct RR type. This memo defines a distinct
- RR for this purpose for use by DHCP clients or servers, the "DHCID"
- RR.
-
- In order to avoid exposing potentially sensitive identifying
- information, the data stored is the result of a one-way MD5[6] hash
- computation. The hash includes information from the DHCP client's
- REQUEST message as well as the domain name itself, so that the data
- stored in the DHCID RR will be dependent on both the client
- identification used in the DHCP protocol interaction and the domain
- name. This means that the DHCID RDATA will vary if a single client
- is associated over time with more than one name. This makes it
- difficult to 'track' a client as it is associated with various
- domain names.
-
- The MD5 hash algorithm has been shown to be weaker than the SHA-1
- algorithm; it could therefore be argued that SHA-1 is a better
- choice. However, SHA-1 is significantly slower than MD5. A
- successful attack of MD5's weakness does not reveal the original
- data that was used to generate the signature, but rather provides a
- new set of input data that will produce the same signature. Because
- we are using the MD5 hash to conceal the original data, the fact
- that an attacker could produce a different plaintext resulting in
- the same MD5 output is not significant concern.
-
-3. The DHCID RR
-
- The DHCID RR is defined with mnemonic DHCID and type code [TBD]. The
- DHCID RR is only defined in the IN class. DHCID RRs cause no
- additional section processing. The DHCID RR is not a singleton type.
-
-
-
-
-Stapp, et. al. Expires May 2, 2003 [Page 3]
-\f
-Internet-Draft The DHCID RR November 2002
-
-
-3.1 DHCID RDATA format
-
- The RDATA section of a DHCID RR in transmission contains RDLENGTH
- bytes of binary data. The format of this data and its
- interpretation by DHCP servers and clients are described below.
-
- DNS software should consider the RDATA section to be opaque. DHCP
- clients or servers use the DHCID RR to associate a DHCP client's
- identity with a DNS name, so that multiple DHCP clients and servers
- may deterministically perform dynamic DNS updates to the same zone.
- From the updater's perspective, the DHCID resource record RDATA
- consists of a 16-bit identifier type, in network byte order,
- followed by one or more bytes representing the actual identifier:
-
- < 16 bits > DHCP identifier used
- < n bytes > MD5 digest
-
-3.2 DHCID Presentation Format
-
- In DNS master files, the RDATA is represented as a single block in
- base 64 encoding identical to that used for representing binary data
- in RFC2535[7]. The data may be divided up into any number of white
- space separated substrings, down to single base 64 digits, which are
- concatenated to form the complete RDATA. These substrings can span
- lines using the standard parentheses.
-
-3.3 The DHCID RR Type Codes
-
- The DHCID RR Type Code specifies what data from the DHCP client's
- request was used as input into the hash function. The type codes are
- defined in a registry maintained by IANA, as specified in Section 7.
- The initial list of assigned values for the type code is:
-
- 0x0000 = htype, chaddr from a DHCPv4 client's
- DHCPREQUEST (RFC 2131)
- 0x0001 = The data portion from a DHCPv4 client's Client
- Identifier option (RFC 2132)
- 0x0002 = The data portion (i.e., the DUID) from a DHCPv6
- client's Client Identifier option
- (draft-ietf-dhc-dhcpv6-*.txt)
-
- 0x0003 - 0xfffe = Available to be assigned by IANA
-
- 0xffff = RESERVED
-
-
-
-
-
-
-
-Stapp, et. al. Expires May 2, 2003 [Page 4]
-\f
-Internet-Draft The DHCID RR November 2002
-
-
-3.4 Computation of the RDATA
-
- The DHCID RDATA is formed by concatenating the two type bytes with
- some variable-length identifying data.
-
- < type > < data >
-
- The RDATA for all type codes other than 0xffff, which is reserved
- for future expansion, is formed by concatenating the two type bytes
- and a 16-byte MD5 hash value. The input to the hash function is
- defined to be:
-
- data = MD5(< identifier > < FQDN >)
-
- The FQDN is represented in the buffer in unambiguous canonical form
- as described in RFC2535[7], section 8.1. The type code and the
- identifier are related as specified in Section 3.3: the type code
- describes the source of the identifier.
-
- When the updater is using the client's link-layer address as the
- identifier, the first two bytes of the DHCID RDATA MUST be zero. To
- generate the rest of the resource record, the updater computes a
- one-way hash using the MD5 algorithm across a buffer containing the
- client's network hardware type, link-layer address, and the FQDN
- data. Specifically, the first byte of the buffer contains the
- network hardware type as it appeared in the DHCP 'htype' field of
- the client's DHCPREQUEST message. All of the significant bytes of
- the chaddr field in the client's DHCPREQUEST message follow, in the
- same order in which the bytes appear in the DHCPREQUEST message. The
- number of significant bytes in the 'chaddr' field is specified in
- the 'hlen' field of the DHCPREQUEST message. The FQDN data, as
- specified above, follows.
-
- When the updater is using the DHCPv4 Client Identifier option sent
- by the client in its DHCPREQUEST message, the first two bytes of the
- DHCID RR MUST be 0x0001, in network byte order. The rest of the
- DHCID RR MUST contain the results of computing an MD5 hash across
- the payload of the option, followed by the FQDN. The payload of the
- option consists of the bytes of the option following the option code
- and length.
-
- When the updater is using the DHCPv6 DUID sent by the client in its
- REQUEST message, the first two bytes of the DHCID RR MUST be 0x0002,
- in network byte order. The rest of the DHCID RR MUST contain the
- results of computing an MD5 hash across the payload of the option,
- followed by the FQDN. The payload of the option consists of the
- bytes of the option following the option code and length.
-
-
-
-
-Stapp, et. al. Expires May 2, 2003 [Page 5]
-\f
-Internet-Draft The DHCID RR November 2002
-
-
-3.5 Examples
-
-3.5.1 Example 1
-
- A DHCP server allocating the IPv4 address 10.0.0.1 to a client with
- Ethernet MAC address 01:02:03:04:05:06 using domain name
- "client.example.com" uses the client's link-layer address to
- identify the client. The DHCID RDATA is composed by setting the two
- type bytes to zero, and performing an MD5 hash computation across a
- buffer containing the Ethernet MAC type byte, 0x01, the six bytes of
- MAC address, and the domain name (represented as specified in
- Section 3.4).
-
- client.example.com. A 10.0.0.1
- client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU
-
-3.5.2 Example 2
-
- A DHCP server allocates the IPv4 address 10.0.12.99 to a client
- which included the DHCP client-identifier option data
- 01:07:08:09:0a:0b:0c in its DHCP request. The server updates the
- name "chi.example.com" on the client's behalf, and uses the DHCP
- client identifier option data as input in forming a DHCID RR. The
- DHCID RDATA is formed by setting the two type bytes to the value
- 0x0001, and performing an MD5 hash computation across a buffer
- containing the seven bytes from the client-id option and the FQDN
- (represented as specified in Section 3.4).
-
- chi.example.com. A 10.0.12.99
- chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012
-
-4. Use of the DHCID RR
-
- This RR MUST NOT be used for any purpose other than that detailed in
- "Resolution of DNS Name Conflicts"[1]. Although this RR contains
- data that is opaque to DNS servers, the data must be consistent
- across all entities that update and interpret this record.
- Therefore, new data formats may only be defined through actions of
- the DHC Working Group, as a result of revising [1].
-
-5. Updater Behavior
-
- The data in the DHCID RR allows updaters to determine whether more
- than one DHCP client desires to use a particular FQDN. This allows
- site administrators to establish policy about DNS updates. The DHCID
- RR does not establish any policy itself.
-
- Updaters use data from a DHCP client's request and the domain name
- that the client desires to use to compute a client identity hash,
-
-
-Stapp, et. al. Expires May 2, 2003 [Page 6]
-\f
-Internet-Draft The DHCID RR November 2002
-
-
- and then compare that hash to the data in any DHCID RRs on the name
- that they wish to associate with the client's IP address. If an
- updater discovers DHCID RRs whose RDATA does not match the client
- identity that they have computed, the updater SHOULD conclude that a
- different client is currently associated with the name in question.
- The updater SHOULD then proceed according to the site's
- administrative policy. That policy might dictate that a different
- name be selected, or it might permit the updater to continue.
-
-6. Security Considerations
-
- The DHCID record as such does not introduce any new security
- problems into the DNS. In order to avoid exposing private
- information about DHCP clients to public scrutiny, a one-way hash is
- used to obscure all client information. In order to make it
- difficult to 'track' a client by examining the names associated with
- a particular hash value, the FQDN is included in the hash
- computation. Thus, the RDATA is dependent on both the DHCP client
- identification data and on each FQDN associated with the client.
-
- Administrators should be wary of permitting unsecured DNS updates to
- zones which are exposed to the global Internet. Both DHCP clients
- and servers SHOULD use some form of update authentication (e.g.,
- TSIG[10]) when performing DNS updates.
-
-7. IANA Considerations
-
- IANA is requested to allocate an RR type number for the DHCID record
- type.
-
- This specification defines a new number-space for the 16-bit type
- codes associated with the DHCID RR. IANA is requested to establish a
- registry of the values for this number-space.
-
- Three initial values are assigned in Section 3.3, and the value
- 0xFFFF is reserved for future use. New DHCID RR type codes are
- tentatively assigned after the specification for the associated type
- code, published as an Internet Draft, has received expert review by
- a designated expert. The final assignment of DHCID RR type codes is
- through Standards Action, as defined in RFC2434[11].
-
-8. Acknowledgements
-
- Many thanks to Josh Littlefield, Olafur Gudmundsson, Bernie Volz,
- and Ralph Droms for their review and suggestions.
-
-References
-
- [1] Stapp, M., "Resolution of DNS Name Conflicts Among DHCP
-
-
-Stapp, et. al. Expires May 2, 2003 [Page 7]
-\f
-Internet-Draft The DHCID RR November 2002
-
-
- Clients (draft-ietf-dhc-dns-resolution-*)", March 2001.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- Mar 1997.
-
- [4] Mockapetris, P., "Domain names - Concepts and Facilities", RFC
- 1034, Nov 1987.
-
- [5] Mockapetris, P., "Domain names - Implementation and
- Specification", RFC 1035, Nov 1987.
-
- [6] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
- April 1992.
-
- [7] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [8] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
- Extensions", RFC 2132, Mar 1997.
-
- [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
- Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
- (draft-ietf-dhc-dhcpv6-*.txt)", November 2002.
-
- [10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
- [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
- Considerations Section in RFCs", RFC 2434, October 1998.
-
-
-Authors' Addresses
-
- Mark Stapp
- Cisco Systems, Inc.
- 250 Apollo Dr.
- Chelmsford, MA 01824
- USA
-
- Phone: 978.244.8498
- EMail: mjs@cisco.com
-
-
-
-
-
-
-Stapp, et. al. Expires May 2, 2003 [Page 8]
-\f
-Internet-Draft The DHCID RR November 2002
-
-
- Ted Lemon
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- USA
-
- EMail: mellon@nominum.com
-
-
- Andreas Gustafsson
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- USA
-
- EMail: gson@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et. al. Expires May 2, 2003 [Page 9]
-\f
-Internet-Draft The DHCID RR November 2002
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph
- are included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et. al. Expires May 2, 2003 [Page 10]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group R. Austein
-draft-ietf-dnsext-dnsmib-historical-00.txt InterNetShare.com, Inc.
- October 2000
-
-
- Applicability Statement for DNS MIB Extensions
-
-
-Status of this document
-
- 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>
-
- Distribution of this document is unlimited. Please send comments to
- the Namedroppers mailing list <namedroppers@ops.ietf.org>.
-
-Abstract
-
- More than six years after the DNS Server and Resolver MIB extensions
- became proposed standards, there still has not been any significant
- deployment of these MIB extensions. This note examines the reasons
- why these MIB extensions were never deployed, and recommends retiring
- these MIB extensions by moving them to Historical status.
-
-History
-
- The road to the DNS MIB extensions was paved with good intentions.
-
- In retrospect, it's obvious that the working group never had much
- agreement on what belonged in the MIB extensions, just that we should
- have some. This happened during the height of the craze for MIB
- extensions in virtually every protocol that the IETF was working on
-
-
-
-Austein Expires 2 May 2001 [Page 1]
-\f
-draft-ietf-dnsext-dnsmib-historical-00.txt October 2000
-
-
- at the time, so the question of why we were doing this in the first
- place never got a lot of scrutiny. Very late in the development
- cycle we discovered that much of the support for writing the MIB
- extensions in the first place had come from people who wanted to use
- SNMP SET operations to update DNS zones on the fly. Examination of
- the security model involved, however, led us to conclude that this
- was not a good way to do dynamic update and that a separate DNS
- Dynamic Update protocol would be necessary.
-
- The MIB extensions started out being fairly specific to one
- particular DNS implementation (BIND-4.8.3); as work progressed, the
- BIND-specific portions were rewritten to be as implementation-neutral
- as we knew how to make them, but somehow every revision of the MIB
- extensions managed to accrete new counters that just happened to
- closely match statistics kept by some version of BIND. As a result,
- the MIB extensions ended up being much too big, which raised a number
- of concerns with the network management directorate, but the WG
- resisted every attempt to remove any of these variables. In the end,
- large portions of the MIB extensions were moved into optional groups
- in an attempt to get the required subset down to a manageable size.
-
- The DNS Server and Resolver MIB extensions were one of the first
- attempts to write MIB extensions for a protocol usually considered to
- be at the application layer. Fairly early on it became clear that,
- while it was certainly possible to write MIB extensions for DNS, the
- SMI was not really designed with this sort of thing in mind. A case
- in point was the attempt to provide direct indexing into the caches
- in the resolver MIB extensions: while arguably the only sane way to
- do this for a large cache, this required much more complex indexing
- clauses than is usual, and ended up running into known length limits
- for object identifiers in some SNMP implementations.
-
- Furthermore, the lack of either real proxy MIB support in SNMP
- managers or a standard subagent protocol meant that there was no
- reasonable way to implement the MIB extensions in the dominant
- implementation (BIND). When the AgentX subagent protocol was
- developed a few years later, we initially hoped that this would
- finally clear the way for an implementation of the DNS MIB
- extensions, but by the time AgentX was a viable protocol it had
- become clear that nobody really wanted to implement these MIB
- extensions.
-
- Finally, the MIB extensions took much too long to produce. In
- retrospect, this should have been a clear warning sigh, particularly
- when the WG had clearly become so tired of the project that the
- authors found it impossible to elicit any comments whatsoever on the
- documents.
-
-
-
-
-Austein Expires 2 May 2001 [Page 2]
-\f
-draft-ietf-dnsext-dnsmib-historical-00.txt October 2000
-
-
-Lessons
-
- Observations based on the preceding list of mistakes, for the benefit
- of anyone else who ever attempts to write DNS MIB extensions again:
-
- - Define a clear set of goals before writing any MIB extensions.
- Know who the constituency is and make sure that what you write
- solves their problem.
-
- - Keep the MIB extensions short, and don't add variables just because
- somebody in the WG thinks they'd be a cool thing to measure.
-
- - If some portion of the task seems to be very hard to do within the
- SMI, that's a strong hint that SNMP is not the right tool for
- whatever it is that you're trying to do.
-
- - If the entire project is taking too long, perhaps that's a hint
- too.
-
-
-Recommendation
-
- In view of the community's apparent total lack of interest in
- deploying these MIB extensions, we recommend that RFCs 1611 and 1612
- be reclassified as Historical documents.
-
-Security Considerations
-
- Getting rid of the DNS MIB extensions undoubtedly closes a few
- security holes, or would if anybody had ever implemented them.
-
-IANA Considerations
-
- Getting rid of the DNS MIB extensions should not impose any new work
- on IANA.
-
-Acknowledgments
-
- The author would like to thank all the people who were involved in
- this silly project over the years for their optimism and patience,
- misguided though it may have been.
-
-References
-
- [DNS-SERVER-MIB] Austein, R., and Saperia, J., "DNS Server MIB
- Extensions", RFC 1611, May 1994.
-
-
-
-
-
-Austein Expires 2 May 2001 [Page 3]
-\f
-draft-ietf-dnsext-dnsmib-historical-00.txt October 2000
-
-
- [DNS-RESOLVER-MIB] Austein, R., and Saperia, J., "DNS Resolver MIB
- Extensions", RFC 1612, May 1994.
-
- [DNS-DYNAMIC-UPDATE] Vixie, P., Ed., Thomson, S., Rekhter, Y., and
- Bound, J., "Dynamic Updates in the Domain Name System (DNS
- UPDATE)", RFC 2136, April 1997.
-
- [AGENTX] Daniele, M., Wijnen, B., Ellison, M., and Francisco, D.,
- "Agent Extensibility (AgentX) Protocol Version 1", RFC 2741,
- January 2000.
-
-Author's addresses:
-
- Rob Austein
- InterNetShare.com, Inc.
- 505 West Olive Ave., Suite 321
- Sunnyvale, CA 94086
- USA
- sra@hactrn.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Expires 2 May 2001 [Page 4]
+++ /dev/null
-
-
-DNS Extensions R. Arends
-Internet-Draft Telematica Instituut
-Expires: August 15, 2003 R. Austein
- ISC
- M. Larson
- VeriSign
- D. Massey
- USC/ISI
- S. Rose
- NIST
- February 14, 2003
-
-
- DNS Security Introduction and Requirements
- draft-ietf-dnsext-dnssec-intro-05
-
-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.
-
- This Internet-Draft will expire on August 15, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- The Domain Name System Security Extensions (DNSSEC) add data origin
- authentication and data integrity to the Domain Name System. This
- document introduces these extensions, and describes their
- capabilities and limitations. This document also discusses the
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 1]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
- services that the DNS security extensions do and do not provide.
- Last, this document describes the interrelationships between the
- group of documents that collectively describe DNSSEC.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Definitions of Important DNSSEC Terms . . . . . . . . . . . . 4
- 3. Services Provided by DNS Security . . . . . . . . . . . . . . 6
- 3.1 Data Origin Authentication and Data Integrity . . . . . . . . 6
- 3.2 Authenticating Name and Type Non-Existence . . . . . . . . . . 7
- 4. Services Not Provided by DNS Security . . . . . . . . . . . . 9
- 5. Resolver Considerations . . . . . . . . . . . . . . . . . . . 10
- 6. Stub Resolver Considerations . . . . . . . . . . . . . . . . . 11
- 7. Zone Considerations . . . . . . . . . . . . . . . . . . . . . 12
- 7.1 TTL values vs. SIG validity period . . . . . . . . . . . . . . 12
- 7.2 New Temporal Dependency Issues for Zones . . . . . . . . . . . 12
- 8. Name Server Considerations . . . . . . . . . . . . . . . . . . 13
- 9. DNS Security Document Family . . . . . . . . . . . . . . . . . 14
- 9.1 DNS Security Document Roadmap . . . . . . . . . . . . . . . . 14
- 9.2 Categories of DNS Security Documents . . . . . . . . . . . . . 14
- 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
- 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17
- 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
- Normative References . . . . . . . . . . . . . . . . . . . . . 20
- Informative References . . . . . . . . . . . . . . . . . . . . 21
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 23
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 2]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-1. Introduction
-
- This document introduces the Domain Name System Security Extensions
- (DNSSEC). This document and its two companion documents ([13] and
- [14]) update, clarify, and refine the security extensions originally
- defined in RFC 2535 [3]. These security extensions consist of a set
- of new resource record types and modifications to the existing DNS
- protocol [2]. The new records and protocol modifications are not
- fully described in this document, but are described in a family of
- documents outlined in Section 9. Section 3 and Section 4 describe
- the capabilities and limitations of the security extensions in
- greater detail. Section 5, Section 6, Section 7, and Section 8
- discuss the effect that these security extensions will have on
- resolvers, stub resolvers, zones and name servers.
-
- This document and its two companions update and obsolete RFCs 2535,
- 3008, 3090, 3225, 3226, and 3445, as well as several works in
- progress: "Redefinition of the AD bit", "Delegation Signer Resource
- Record", and "DNSSEC Opt-In". See [18] for more details on these
- documents.
-
- The DNS security extensions provide origin authentication and
- integrity protection for DNS data, as well as a means of public key
- distribution. These extensions do not provide protection against
- other types of attack, nor do they provide confidentiality.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 3]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-2. Definitions of Important DNSSEC Terms
-
- authentication chain: In the DNSSEC model, a KEY RR signs a DS RR,
- which hashes one RR in another KEY RRset, which in turn signs
- another DS RR, which hashes one RR in yet another KEY RRset, and
- so forth, finally ending, if all goes well, with a KEY RR which
- signs whatever DNS data the end user was looking for in the first
- place. This alternating succession of KEY RRsets and DS RRs forms
- a chain of signed data, with each link in the chain vouching for
- the next. If a signature somewhere in this chain has been
- generated by an authentication key known to a security-aware
- resolver, then the resolver can attempt to verify and authenticate
- the signed chain of KEY and DS RRs from that point down to the
- target data.
-
- authentication key: A public key which a security-aware resolver
- trusts and can therefore use to verify data. A security-aware
- resolver can discover trusted authentication keys in three ways.
- First, the resolver is generally preconfigured to know about at
- least one key which it should trust. Second, the resolver may be
- able to discover both a new key and an associated DS RR which
- contains a valid hash of the new key and which has been signed by
- a key which the resolver trusts. Third, the resolver may be able
- to determine that a new key has been signed by another key which
- the resolver trusts. Note that the resolver must always be guided
- by local policy when deciding whether to trust a new key, even if
- the local policy is simply to trust any new key for which the
- resolver is able verify the signature.
-
- key signing key: An authentication key which is used to sign one or
- more other authentication keys. Typically, a key signing key will
- sign a zone signing key, which in turn will sign other zone data.
- Local policy may require the zone signing key to be changed
- frequently, while the key signing key may have a longer validity
- period in order to provide a more stable secure entry point into
- the zone. Designating an authentication key as a key signing key
- is purely an operational issue: DNSSEC itself does not distinguish
- between key signing keys and other DNSSEC authentication keys.
- Key signing keys are discussed in more detail in [12].
-
- security-aware name server: An entity acting in the role of a name
- server (defined in section 2.4 of [1]) which understands the DNS
- security extensions defined in this document set. In particular,
- a security-aware name server is an entity which receives DNS
- queries, sends DNS responses, supports the EDNS0 [4] message size
- extension and the DO bit [8], and supports the RR types and
- message header bits defined in this document set.
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 4]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
- security-aware recursive name server: An entity which acts in both
- the security-aware name server and security-aware resolver roles.
- A more cumbersome equivalent phrase would be "a security-aware
- name server which offers recursive service".
-
- security-aware resolver: An entity acting in the role of a resolver
- (defined in section 2.4 of [1]) which understands the DNS security
- extensions defined in this document set. In particular, a
- security-aware resolver is an entity which sends DNS queries,
- receives DNS responses, supports the EDNS0 [4] message size
- extension and the DO bit [8], and is capable of using the RR types
- and message header bits defined in this document set to provide
- DNSSEC services.
-
- security-aware stub resolver: An entity acting in the role of a
- resolver (defined in section 2.4 of [1]) which has at least a
- minimal understanding the DNS security extensions defined in this
- document set, but which trusts one or more security-aware
- recursive name servers to perform most of the tasks discussed in
- this document set on its behalf. In particular, a security-aware
- stub resolver is an entity which sends DNS queries, receives DNS
- responses, and is capable of establishing an appropriately secured
- channel to a security-aware recursive name server which will
- provide these services on behalf of the security-aware stub
- resolver. Note that the distinction between security-aware
- resolvers and security-aware stub resolvers is different from the
- distinction between iterative-mode and recursive-mode resolvers in
- the base DNS specification: a particular security-aware resolver
- may operate exclusively in recursive mode, but still performs its
- own DNSSEC signature validity checks, while a security-aware stub
- resolver does not, by definition.
-
- security-oblivious: The opposite of "security-aware".
-
- signed zone: A zone whose RRsets are signed and which contains
- properly constructed KEY, SIG, NXT and (optionally) DS records.
-
- unsigned zone: The opposite of a "signed zone".
-
- zone signing key: An authentication key which is used to sign a zone.
- See key signing key, above. Typically a zone signing key will be
- part of the same KEY RRset as the key signing key which signs it,
- but is used for a slightly different purpose and may differ from
- the key signing key in other ways, such as validity lifetime.
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 5]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-3. Services Provided by DNS Security
-
- The Domain Name System (DNS) security extensions provide origin
- authentication and integrity assurance services for DNS data,
- including mechanisms for authenticated denial of existence of DNS
- data. These mechanisms are described below.
-
- These mechanisms require minor changes to the DNS protocol. DNSSEC
- adds four new resource record types (SIG, KEY, DS and NXT) and two
- new message header bits (CD and AD). In order to support the larger
- DNS message sizes that result from adding the DNSSEC RRs, DNSSEC also
- requires EDNS0 support [4]. Finally, DNSSEC requires support for the
- DO bit [8], so that a security-aware resolver can indicate in its
- queries that it wishes to receive DNSSEC RRs in response messages.
-
- These services protect against most of the threats to the Domain Name
- System described in [11].
-
-3.1 Data Origin Authentication and Data Integrity
-
- DNSSEC provides authentication by associating cryptographically
- generated digital signatures with DNS RRsets. These digital
- signatures are stored in a new resource record, the SIG record.
- Typically, there will be a single private key that signs a zone's
- data, but multiple keys are possible: for example, there may be keys
- for each of several different digital signature algorithms. If a
- security-aware resolver reliably learns a zone's public key, it can
- authenticate that zone's signed data. An important DNSSEC concept is
- that the key that signs a zone's data is associated with the zone
- itself and not with the zone's authoritative name servers (public
- keys for DNS transaction authentication mechanisms may also appear in
- zones, as described in [7], but DNSSEC itself is concerned with
- object security of DNS data, not channel security of DNS
- transactions).
-
- A security-aware resolver can learn a zone's public key either by
- having the key preconfigured into the resolver or by normal DNS
- resolution. To allow the latter, public keys are stored in a new
- type of resource record, the KEY RR. Note that the private keys used
- to sign zone data must be kept secure, and should be stored offline
- when practical to do so. To discover a public key reliably via DNS
- resolution, the target key itself needs to be signed by either a
- preconfigured authentication key or another key that has been
- authenticated previously. Security-aware resolvers authenticate zone
- information by forming an authentication chain from a newly learned
- public key back to a previously known authentication public key,
- which in turn either must have been preconfigured into the resolver
- or must have been learned and verified previously. Therefore, the
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 6]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
- resolver must be configured with at least one public key: if the
- preconfigured key is a zone signing key, then it will authenticate
- the associated zone; if the preconfigured key is a key signing key,
- it will authenticate a zone signing key. To help security-aware
- resolvers establish this authentication chain, security-aware name
- servers attempt to send the signature(s) needed to authenticate a
- zone's public key in the DNS reply message along with the public key
- itself, provided there is space available in the message.
-
- The authentication chain specified in the original DNS security
- extensions proceeded from signed KEY record to signed KEY record, as
- necessary, and finally to the queried RRset. The current
- specification adds a new Delegation Signer (DS) RR type to simplify
- some of the administrative tasks involved in signing delegations
- across organizational boundaries. The DS RRset resides at a
- delegation point in a parent zone and indicates the key or keys used
- by the delegated child zone to self-sign the KEY RRset at the child
- zone's apex. The child zone, in turn, uses one or more of the keys
- in this KEY RRset to sign its zone data. The authentication chain is
- therefore KEY->[DS->KEY]*->RRset, where "*" denotes zero or more DS-
- >KEY subchains.
-
- This authentication chain is normally constructed from the root of
- the DNS hierarchy down to the leaf zones, and is normally based on
- preconfigured knowledge of the public key for the root. Local
- policy, however, may also allow a security-aware resolver to trust
- one or more preconfigured keys other than the root key, or may not
- provide preconfigured knowledge of the root key, or may even prevent
- the resolver from trusting particular keys for arbitrary reasons even
- if those keys are properly signed with verifiable signatures. DNSSEC
- provides mechanisms by which a security-aware resolver can determine
- whether an RRset's signature is "valid" within the meaning of DNSSEC,
- but authentication and trust, in the final analysis, are matters of
- local policy, which may extend or even override the protocol
- extensions defined in this document set.
-
-3.2 Authenticating Name and Type Non-Existence
-
- The security mechanism described in Section 3.1 only provides a way
- to sign existing RRsets in a zone. The problem of providing negative
- responses with the same level of authentication and integrity
- requires the use of another new resource record type, the NXT record.
- The NXT record allows a security-aware resolver to authenticate a
- negative reply for either name or type non-existence via the same
- mechanisms used to authenticate other DNS replies. Use of NXT
- records require a canonical representation and ordering for domain
- names in zones. Chains of NXT records explicitly describe the gaps,
- or "empty space", between domain names in a zone, as well as listing
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 7]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
- the types of RRsets present at existing names. Each NXT record is
- signed and authenticated using the mechanisms described in Section
- 3.1.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 8]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-4. Services Not Provided by DNS Security
-
- DNS was originally designed with the assumptions that the DNS will
- return the same answer to any given query regardless of who may have
- issued the query, and that all data in the DNS is thus visible.
- Accordingly, DNSSEC is not designed to provide confidentiality,
- access control lists, or other means of differentiating between
- inquirers.
-
- DNSSEC provides no protection against denial of service attacks.
- Security-aware resolvers and security-aware name servers are
- vulnerable to an additional class of denial of service attacks based
- on cryptographic operations. Please see Section 11 for details.
-
- The DNS security extensions provide data and origin authentication
- for DNS data. The mechanisms outlined above extend no protection to
- operations such as zone transfers and dynamic update [16]. Message
- authentication schemes described in [5] and [7] address security
- operations that pertain to these transactions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 9]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-5. Resolver Considerations
-
- A security-aware resolver needs to be able to perform necessary
- cryptographic functions to verify digital signatures using at least
- the mandatory-to-implement algorithms. Security-aware resolvers must
- also be capable of forming a authentication chain from a newly
- learned zone back to a authentication key, as described above. This
- process might require additional queries to intermediate DNS zones to
- obtain necessary KEY, DS and SIG records. A security-aware resolver
- should be configured with at least one authentication key as the
- starting point from which it will attempt to establish authentication
- chains.
-
- If a security-aware resolver is separated from the relevant
- authoritative name servers by a recursive name server or by any sort
- of device which acts as a proxy for DNS, and if the recursive name
- server or proxy is not security-aware, the security-aware resolver
- may not be able to operate in a secure mode. For example, if a
- security-aware resolver's packets are routed through a network
- address translation device that includes a DNS proxy which is not
- security-aware the security-aware resolver may find it difficult or
- impossible to obtain or validate signed DNS data.
-
- If a security-aware resolver must rely on an unsigned zone or a name
- server that is not security aware, the resolver may not be able to
- validate DNS responses, and will need a local policy on whether to
- accept unverified responses.
-
- A security-aware resolver should take a signature's validation period
- into consideration when determining the TTL of data in its cache, to
- avoid caching signed data beyond the validity period of the
- signature, but should also allow for the possibility that the
- security-aware resolver's own clock is wrong. Thus, a security-aware
- resolver which is part of a security-aware recursive name server will
- need to pay careful attention to the DNSSEC "checking disabled" (CD)
- bit [13] in order to avoid blocking valid signatures from getting
- through to other security-aware resolvers which are clients of this
- recursive name server and which are capable of performing their own
- DNSSEC validity checks.
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 10]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-6. Stub Resolver Considerations
-
- Although not strictly required to do so by the protocol, most DNS
- queries originate from stub resolvers. Stub resolvers, by
- definition, are minimal DNS resolvers which use recursive query mode
- to offload most of the work of DNS resolution to a recursive name
- server. Given the widespread use of stub resolvers, the DNSSEC
- architecture has to take stub resolvers into account, but the
- security features needed in a stub resolver differ in some respects
- from those needed in a full security-aware resolver.
-
- Even an unaugmented stub resolver may get some benefit from DNSSEC if
- the recursive name servers it uses are security-aware, but for the
- stub resolver to place any real reliance on DNSSEC services, the stub
- resolver must trust both the recursive name servers in question and
- the communication channels between itself and those name servers.
- The first of these issues is a local policy issue: in essence, a stub
- resolver has no real choice but to place itself at the mercy of the
- recursive name servers that it uses, since it does not perform DNSSEC
- validity checks on its own. The second issue requires some kind of
- channel security mechanism; proper use of DNS transaction
- authentication mechanisms such as SIG(0) or TSIG would suffice, as
- would appropriate use of IPsec, and particular implementations may
- have other choices available, such as operating system specific
- interprocess communication mechanisms. Confidentiality is not needed
- for this channel, but data integrity and message authentication are.
-
- {{AD bit currently ratholed, update this when its fate is settled}}
-
- There is one more step which a security-aware stub resolver can take
- if, for whatever reason, it is not able to establish a useful trust
- relationship with the recursive name servers which it uses: it can
- perform its own signature validation, by setting the Checking
- Disabled (CD) bit in its query messages. Upon taking this step, the
- resolver is no longer really a stub resolver at all anymore (in the
- terminology used in this document set, anyway), and is now a
- security-aware resolver with somewhat limited functionality.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 11]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-7. Zone Considerations
-
- There are several differences between signed and unsigned zones. A
- signed zone will contain additional security-related records (SIG,
- KEY, DS and NXT records). SIG and NXT records may be generated by a
- signing process prior to serving the zone. The SIG records that
- accompany zone data have defined inception and expiration times,
- which establish a validity period for the signatures and the zone
- data the signatures cover.
-
-7.1 TTL values vs. SIG validity period
-
- It is important to note the distinction between an RRset's TTL value
- and the signature validity period specified by the SIG RR covering
- that RRset. DNSSEC does not change the definition or function of the
- TTL value, which is intended to maintain database coherency in
- caches. A caching resolver purges RRsets from its cache no later
- than the end of the time period specified by the TTL fields of those
- RRsets, regardless of whether or not the resolver is security-aware.
-
- The inception and expiration fields in the SIG RR [13], on the other
- hand, specify the time period during which the signature can be used
- to validate the RRset that it covers. The signatures associated with
- signed zone data are only valid for the time period specified by
- these fields in the SIG RRs in question. TTL values cannot extend
- the validity period of signed RRsets in a resolver's cache, but the
- resolver may use the time remaining before expiration of the
- signature validity period of a signed RRset as an upper bound for the
- TTL of the signed RRset and its associated SIG RR in the resolver's
- cache.
-
-7.2 New Temporal Dependency Issues for Zones
-
- Information in a signed zone has a temporal dependency which did not
- exist in the original DNS protocol. A signed zone requires regular
- maintenance to ensure that each RRset in the zone has a current valid
- SIG RR. The signature validity period of a SIG RR is a interval
- during which the signature for one particular signed RRset can be
- considered valid, and the signatures of different RRsets in a zone
- may expire at different times. Re-signing one or more RRsets in a
- zone will change one or more SIG RRs, which in turn will require
- incrementing the zone's SOA serial number to indicate that a zone
- change has occurred and re-signing the SOA RRset itself. Thus, re-
- signing any RRset in a zone may also trigger DNS NOTIFY messages and
- zone transfers operations.
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 12]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-8. Name Server Considerations
-
- A security-aware name server should include the appropriate DNSSEC
- records (SIG, KEY, DS and NXT) in all responses to queries from
- resolvers which have signaled their willingness to receive such
- records via use of the DO bit in the EDNS header, subject to message
- size limitations. For this reason a security-aware name server must
- support the EDNS mechanism size extension, since otherwise inclusion
- of DNSSEC RRs could easily cause UDP message truncation and fallback
- to TCP.
-
- If possible, the private half of each DNSSEC key pair should be kept
- offline, but this will not be possible for a zone for which DNS
- dynamic update has been enabled. In the dynamic update case, the
- primary master server for the zone will have to re-sign the zone when
- updated, so the private half of the zone signing key will have to be
- kept online. This is an example of a situation where the ability to
- separate the zone's KEY RRset into zone signing key(s) and key
- signing key(s) may be useful, since the key singing key(s) in such a
- case can still be kept offline.
-
- DNSSEC, by itself, is not enough to protect the integrity of an
- entire zone during zone transfer operations, since even a signed zone
- contains some unsigned data, so zone maintenance operations will
- require some additional mechanisms (most likely some form of channel
- security, such as TSIG, SIG(0), or IPsec).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 13]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-9. DNS Security Document Family
-
- The DNSSEC set of documents can be partitioned into five main groups
- as depicted in Figure 1. All these documents are in turn under the
- larger umbrella of the DNS base protocol documents described in [18].
-
-9.1 DNS Security Document Roadmap
-
- ---------------------------------------------------------------------
-
-
- +----------------------------------+
- | Base DNS Protocol Documents |
- | [RFC1035, RFC2181, et sequentia] |
- +----------------------------------+
- |
- |
- +-----------+ +----------+
- | DNSSEC | | New |
- | Protocol |--------->| Security |
- | Documents | | Uses |
- +-----------+ +----------+
- |
- |
- +---------------- - - - - - - -+
- | .
- | .
- +------------------+ .
- | Digital | +------------------+
- | Signature | | Transaction |
- | Algorithm | | Authentication |
- | Implementations | | Implementations |
- +------------------+ +------------------+
-
- Figure 1: DNSSEC Document Roadmap
-
- ---------------------------------------------------------------------
-
-
-9.2 Categories of DNS Security Documents
-
- The "DNSSEC protocol document set" refers to the three documents
- which form the core of the DNS security extensions:
-
- 1. DNS Security Introduction and Requirements (this document)
-
- 2. Resource Records for DNS Security Extensions [13]
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 14]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
- 3. Protocol Modifications for the DNS Security Extensions [14]
-
- The "Digital Signature Algorithm Implementations" document set refers
- to the group of documents that describe how specific digital
- signature algorithms should be implemented to fit the DNSSEC resource
- record format. Each of these documents deals with a specific digital
- signature algorithm.
-
- The "Transaction Authentication Implementations" document set refers
- to the group of documents that deal with DNS message authentication,
- including secret key establishment and verification. While not
- strictly part of the DNSSEC specification as defined in this set of
- documents, this group is noted to show its relationship to DNSSEC.
-
- The final document set, "New Security Uses", refers to documents that
- seek to use proposed DNS Security extensions for other security
- related purposes. DNSSEC does not provide any direct security for
- these new uses, but may be used to support them. Documents that fall
- in this category include the use of DNS in the storage and
- distribution of certificates [15] and individual user public keys
- (PGP, e-mail, and so forth) [17].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 15]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-10. IANA Considerations
-
- This document introduces no new IANA considerations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 16]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-11. Security Considerations
-
- This document introduces the DNS security extensions and describes
- the document set that contains the new security records and DNS
- protocol modifications. This document discusses the capabilities and
- limitations of these extensions. The extensions provide data origin
- authentication and data integrity using digital signatures over
- resource record sets.
-
- In order for a security-aware resolver to validate a DNS response,
- all of the intermediate zones must be signed, and all of the
- intermediate name servers must be security-aware, as defined in this
- document set. A security-aware resolver cannot verify responses
- originating from an unsigned zone, from a zone not served by a
- security-aware name server, or for any DNS data which the resolver is
- only able to obtain through a recursive name server which is not
- security-aware. If there is a break in the authentication chain such
- that a security-aware resolver cannot obtain and validate the
- authentication keys it needs, then the security-aware resolver cannot
- validate the affected DNS data.
-
- This document briefly discusses other methods of adding security to a
- DNS query, such as using a channel secured by IPsec or using a DNS
- transaction authentication mechanism, but transaction security is not
- part of DNSSEC per se.
-
- A security-aware stub resolver, by definition, does not perform
- DNSSEC signature validation on its own, and thus is vulnerable both
- to attacks on (and by) the security-aware recursive name servers
- which perform these checks on its behalf and also to attacks on its
- communication with those security-aware recursive name servers.
- Security-aware stub resolvers should use some form of channel
- security to defend against the latter threat. The only known defense
- against the former threat would be for the security-aware stub
- resolver to perform its own signature validation, at which point,
- again by definition, it would no longer be a security-aware stub
- resolver.
-
- DNSSEC does not protect against denial of service attacks. DNSSEC
- makes DNS vulnerable to a new class of denial of service attacks
- based on cryptographic operations against security-aware resolvers
- and security-aware name servers, since an attacker can attempt to use
- DNSSEC mechanisms to consume a victim's resources. This class of
- attacks takes at least two forms. An attacker may be able to consume
- resources in a security-aware resolver's signature validation code by
- tampering with SIG RRs in response messages or by constructing
- needlessly complex signature chains. An attacker may also be able to
- consume resources in a security-aware name server which supports DNS
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 17]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
- dynamic update, by sending a stream of update messages that force the
- security-aware name server to re-sign some RRsets in the zone more
- frequently than would otherwise be necessary.
-
- DNSSEC add the ability for a hostile party to enumerate all the names
- in a zone by following the NXT chain. NXT RRs assert which names do
- not exist in a zone by linking from existing name to existing name
- along a canonical ordering of all the names within a zone. Thus, an
- attacker can query these NXT RRs in sequence to obtain all the names
- in a zone. While not an attack on the DNS itself, this could allow
- an attacker to map network hosts or other resources by enumerating
- the contents of a zone.
-
- DNSSEC does not provide confidentiality, due to a deliberate design
- choice.
-
- DNSSEC does not protect against tampering with unsigned zone data.
- Non-authoritative data at zone cuts (glue and NS RRs in the parent
- zone) are not signed. Thus, while DNSSEC can provide data origin
- authentication and data integrity for RRsets, it cannot do so for
- zones, and other mechanisms must be used to protect zone transfer
- operations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 18]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-12. Acknowledgements
-
- This document was created from the input and ideas of several members
- of the DNS Extensions Working Group. The authors would like to
- acknowledge (in alphabetical order) the following people for their
- contributions and comments on this document:
-
- Derek Atkins
- Donald Eastlake
- Miek Gieben
- Olafur Gudmundsson
- Olaf Kolkman
- Ed Lewis
- Ted Lindgreen
- Bill Manning
- Brian Wellington
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 19]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-Normative References
-
- [1] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [4] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
- [5] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
- [6] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
- 2930, September 2000.
-
- [7] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [8] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
- December 2001.
-
- [9] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
- message size requirements", RFC 3226, December 2001.
-
- [10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
- Record (RR)", RFC 3445, December 2002.
-
- [11] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
- System", draft-ietf-dnsext-dns-threats-02 (work in progress),
- February 2002.
-
- [12] Kolkman, O. and J. Schlyter, "KEY RR Key Signing Key (KSK)
- Flag", draft-ietf-dnsext-keyrr-key-signing-flag-05 (work in
- progress), December 2002.
-
- [13] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource
- Records for DNS Security Extensions", draft-ietf-dnsext-dnssec-
- records-02 (work in progress), November 2002.
-
- [14] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol
- Modifications for the DNS Security Extensions", draft-ietf-
- dnsext-dnssec-protocol-00 (work in progress), October 2002.
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 20]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-Informative References
-
- [15] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
- Domain Name System (DNS)", RFC 2538, March 1999.
-
- [16] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
- [17] Schlyter, J., "Storing application public keys in the DNS",
- draft-schlyter-appkey-02 (work in progress), February 2002.
-
- [18] Rose, S., "DNS Security Document Roadmap", draft-ietf-dnsext-
- dnssec-roadmap-06 (work in progress), November 2001.
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
- Rob Austein
- Internet Software Consortium
- 40 Gavin Circle
- Reading, MA 01867
- USA
-
- EMail: sra@isc.org
-
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: mlarson@verisign.com
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 21]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
- Dan Massey
- USC Information Sciences Institute
- 3811 N. Fairfax Drive
- Arlington, VA 22203
- USA
-
- EMail: masseyd@isi.edu
-
-
- Scott Rose
- National Institute for Standards and Technology
- 100 Bureau Drive
- Gaithersburg, MD 20899-8920
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 22]
-\f
-Internet-Draft DNSSEC Introduction and Requirements February 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 15, 2003 [Page 23]
-\f
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT David Conrad
-draft-ietf-dnsext-dnssec-okbit-02.txt Nominum Inc.
- May, 2001
-
- Indicating Resolver Support of DNSSEC
-
-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
-
- In order to deploy DNSSEC operationally, DNSSEC aware servers should
- only perform automatic inclusion of DNSSEC RRs when there is an
- explicit indication that the resolver can understand those RRs. This
- document proposes the use of a bit in the EDNS0 header to provide
- that explicit indication and the necessary protocol changes to
- implement that notification.
-
-1. Introduction
-
- DNSSEC [RFC2535] has been specified to provide data integrity and
- authentication to security aware resolvers and applications through
- the use of cryptographic digital signatures. However, as DNSSEC is
- deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
- servers. In such situations, the DNSSEC-aware server (responding to
- a request for data in a signed zone) will respond with SIG, KEY,
- and/or NXT records. For reasons described in the subsequent section,
- such responses can have significant negative operational impacts for
- the DNS infrastructure.
-
-
-
-Expires October, 2001 [Page 1]
-\f
-draft-ietf-dnsext-dnssec-okbit-02.txt May, 2001
-
-
- This document discusses a method to avoid these negative impacts,
- namely DNSSEC-aware servers should only respond with SIG, KEY, and/or
- NXT RRs when there is an explicit indication from the resolver that
- it can understand those RRs.
-
- For the purposes of this document, "DNSSEC security RRs" are
- considered RRs of type SIG, KEY, or NXT.
-
- 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. Rationale
-
- 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
- will likely be quite detrimental in terms of increased network
- traffic (typically five packets for a single query/response instead
- of two), increased latency resulting from the additional round trip
- times, increased incidences of queries failing due to timeouts, and
- significantly increased load on nameservers.
-
- In addition, in preliminary and experimental deployment of DNSSEC,
- there have been reports of non-DNSSEC aware resolvers being unable to
- handle responses which contain DNSSEC security RRs, resulting in the
- resolver failing (in the worst case) or entire responses being
- ignored (in the better case).
-
- Given these operational implications, explicitly notifying the
- nameserver that the client is prepared to receive (if not understand)
- DNSSEC security RRs would be prudent.
-
- Client-side support of DNSSEC is assumed to be binary -- either the
- client is willing to receive all DNSSEC security RRs or it is not
- willing to accept any. As such, a single bit is sufficient to
- indicate client-side DNSSEC support. As effective use of DNSSEC
- implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
- enhanced DNS header) are scarce, and there may be situations in which
-
-
-
-Expires October, 2001 [Page 2]
-\f
-draft-ietf-dnsext-dnssec-okbit-02.txt May, 2001
-
-
- non-compliant caching or forwarding servers inappropriately copy data
- from classic headers as queries are passed on to authoritative
- servers, the use of a bit from the EDNS0 header is proposed.
-
- An alternative approach would be to use the existance of an EDNS0
- header as an implicit indication of client-side support of DNSSEC.
- This approach was not chosen as there may be applications in which
- EDNS0 is supported but in which the use of DNSSEC is inappropriate.
-
-3. Protocol Changes
-
- The mechanism chosen for the explicit notification of the ability of
- the client to accept (if not understand) DNSSEC security RRs is using
- the most significant bit of the Z field on the EDNS0 OPT header in
- the query. This bit is referred to as the "DNSSEC OK" (DO) bit. In
- the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
- the the third and fourth bytes of the "extended RCODE and flags"
- portion of the EDNS0 OPT meta-RR, structured as follows:
-
- +0 (MSB) +1 (LSB)
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 0: | EXTENDED-RCODE | VERSION |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 2: |DO| Z |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- Setting the DO bit to one in a query indicates to the server that the
- resolver is able to accept DNSSEC security RRs. The DO bit cleared
- (set to zero) indicates the resolver is unprepared to handle DNSSEC
- security RRs and those RRs MUST NOT be returned in the response
- (unless DNSSEC security RRs are explicitly queried for).
-
- More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
- or NXT RRs to authenticate a response as specified in [RFC2535]
- unless the DO bit was set on the request. Security records that match
- an explicit SIG, KEY, NXT, or ANY query, or are part of the zone data
- for an AXFR or IXFR query, are included whether or not the DO bit was
- set.
-
- A recursive DNSSEC-aware server MUST set the DO bit on recursive
- requests, regardless of the status of the DO bit on the initiating
- resolver request. If the initiating resolver request does not have
- the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
- security RRs before returning the data to the client, however cached
- data MUST NOT be modified.
-
- In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
- to a query that has the DO bit set, the resolver SHOULD NOT expect
-
-
-
-Expires October, 2001 [Page 3]
-\f
-draft-ietf-dnsext-dnssec-okbit-02.txt May, 2001
-
-
- DNSSEC security RRs and SHOULD retry the query without the EDNS0 in
- accordance with section 5.3 of [RFC2671].
-
-Security Considerations
-
- The absence of DNSSEC data in response to a query with the DO bit set
- MUST NOT be taken to mean no security information is available for
- that zone as the response may be forged or a non-forged response of
- an altered (DO bit cleared) query.
-
-IANA considerations:
-
- 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, Steve Bellovin, and Erik Nordmark.
-
-References
-
- [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specifications", RFC 1035, November 1987.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [RFC2671] Vixie, P., Extension Mechanisms for DNS (EDNS0)", RFC 2671,
-
-
-
-Expires October, 2001 [Page 4]
-\f
-draft-ietf-dnsext-dnssec-okbit-02.txt May, 2001
-
-
- August 1999
-
-Author's Address
-
- David Conrad
- Nominum Inc.
- 950 Charter Street
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 779 6003
-
- Email: david.conrad@nominum.com
-
-
-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 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 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 October, 2001 [Page 5]
-\f
+++ /dev/null
-
-
-DNSEXT R. Arends
-Internet-Draft Telematica Instituut
-Expires: August 28, 2003 M. Kosters
- D. Blacka
- Verisign, Inc.
- February 27, 2003
-
-
- DNSSEC Opt-In
- draft-ietf-dnsext-dnssec-opt-in-05
-
-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.
-
- This Internet-Draft will expire on August 28, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- In RFC 2535, delegations to unsigned subzones are cryptographically
- secured. Maintaining this cryptography is not practical or
- necessary. This document describes an "Opt-In" model that allows
- administrators to omit this cryptography and manage the cost of
- adopting DNSSEC with large zones.
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 1]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-Table of Contents
-
- 1. Definitions and Terminology . . . . . . . . . . . . . . . . 3
- 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . 5
- 3.1 Server Considerations . . . . . . . . . . . . . . . . . . . 6
- 3.1.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 6
- 3.1.2 Insecure Delegation Responses . . . . . . . . . . . . . . . 6
- 3.1.3 Wildcards and Opt-In . . . . . . . . . . . . . . . . . . . . 6
- 3.1.4 Dynamic Update . . . . . . . . . . . . . . . . . . . . . . . 7
- 3.2 Client Considerations . . . . . . . . . . . . . . . . . . . 7
- 3.2.1 Delegations Only . . . . . . . . . . . . . . . . . . . . . . 7
- 3.2.2 Validation Process Changes . . . . . . . . . . . . . . . . . 7
- 3.2.3 NXT Record Caching . . . . . . . . . . . . . . . . . . . . . 8
- 3.2.4 Use of the AD bit . . . . . . . . . . . . . . . . . . . . . 8
- 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 11
- 6. Transition Issues . . . . . . . . . . . . . . . . . . . . . 13
- 7. Security Considerations . . . . . . . . . . . . . . . . . . 14
- 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 16
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
- Normative References . . . . . . . . . . . . . . . . . . . . 18
- Informative References . . . . . . . . . . . . . . . . . . . 19
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
- A. Implementing Opt-In using "Views" . . . . . . . . . . . . . 21
- B. Changes from Prior Versions . . . . . . . . . . . . . . . . 23
- Intellectual Property and Copyright Statements . . . . . . . 25
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 2]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-1. Definitions and Terminology
-
- Throughout this document, familiarity with the DNS system, RFC 1035
- [1], DNS security extensions, RFC 2535 [2], and DNSSEC terminology
- RFC 3090 [8] is assumed.
-
- The following abbreviations and terms are used in this document:
-
- RR: is used to refer to a DNS resource record.
-
- RRset: refers to a Resource Record Set, as defined by [6]. In this
- document, the RRset is also defined to include the covering SIG
- records, if any exist.
-
- signed name: refers to a DNS name that has, at minimum, a (signed)
- NXT record.
-
- unsigned name: refers to a DNS name that does not (at least) have a
- NXT record.
-
- covering NXT record/RRset: is the NXT record used to prove
- (non)existence of a particular name or RRset. This means that for
- a RRset or name 'N', the covering NXT record has the name 'N', or
- has an owner name less than 'N' and "next" name greater than 'N'.
-
- delegation: refers to a NS RRset with a name different from the
- current zone apex (non-zone-apex), signifying a delegation to a
- subzone.
-
- secure delegation: refers to a signed name containing a delegation
- (NS RRset), and a signed DS RRset, signifying a delegation to a
- signed subzone.
-
- 2535/DS insecure delegation: refers to a signed name containing a
- delegation (NS RRset), but lacking a DS RRset, signifying a
- delegation to an unsigned subzone.
-
- Opt-In insecure delegation: refers to an unsigned name containing
- only a delegation NS RRset. The covering NXT record uses the
- Opt-In methodology described 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 [5].
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 3]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-2. Overview
-
- The cost to cryptographically secure delegations to unsigned zones is
- high for large delegation-centric zones and zones where insecure
- delegations will be updated rapidly. For these zones, the costs of
- maintaining the NXT record chain may be extremely high relative to
- the gain of cryptographically authenticating existence of unsecured
- zones.
-
- This document describes a method of eliminating the superfluous
- cryptography present in secure delegations to insecure zones. Using
- "Opt-In", a zone administrator can choose to remove insecure
- delegations from the NXT chain. This is accomplished by extending
- the semantics of the NXT record by using a redundant bit in the type
- map.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 4]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-3. Protocol Additions
-
- In RFC 2535, delegation NS RRsets are not signed, but are instead
- accompanied by a NXT RRset of the same name, and possibly a
- ("no-key") KEY RR [2] or DS record [3]. The security status of the
- subzone is determined by the presence of the KEY or DS records,
- cryptographically proven by the NXT record. Opt-In expands this
- definition by allowing insecure delegations to exist within an
- otherwise signed zone without the corresponding NXT record at the
- delegation's owner name. These insecure delegations are proven
- insecure by using a covering NXT record.
-
- Since this represents a change of the interpretation of NXT records,
- resolvers must be able to distinguish between RFC 2535 NXT records
- and Opt-In NXT records. This is accomplished by "tagging" the NXT
- records that cover (or potentially cover) insecure delegation nodes.
- This tag is indicated by the absence of the NXT bit in the type map.
- Since the NXT bit in the type map merely indicates the existence of
- the record itself, this bit is redundant and safe for use as a tag.
-
- An Opt-In tagged NXT record does not assert the (non)existence of the
- delegations that it covers (except for a delegation with the same
- name). This allows for the addition or removal of these delegations
- without recalculating or resigning the NXT chain. However, Opt-In
- tagged NXT records do assert the (non)existence of other RRsets.
-
- An Opt-In NXT record MAY have the same name as an insecure
- delegation. In this case, the delegation is proven insecure by the
- lack of a DS bit in type map, or the presence of a "no-key" KEY
- RRset, and the NXT record does assert the existence of the
- delegation.
-
- Zones using Opt-In MAY contain a mixture of Opt-In tagged NXT records
- and RFC 2535 NXT records. If a NXT record is not Opt-In, there MUST
- NOT be any insecure delegations (or any other records) between it and
- the RRsets indicated by the 'next domain name' in the NXT RDATA. If
- it is Opt-In, there MUST only be insecure delegations between it and
- the next node indicated by the 'next domain name' in the NXT RDATA.
-
- In summary,
-
- o An Opt-In NXT type is identified by a zero-valued (or
- not-specified) NXT bit in the type bit map of the NXT record.
-
- o A RFC2535 NXT type is identified by a one-valued NXT bit in the
- type bit map of the NXT record.
-
- and,
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 5]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- o An Opt-In NXT record does not assert the non-existence of a name
- between its owner name and "next" name, although it does assert
- that any name in this span MUST be an insecure delegation.
-
- o An Opt-In NXT record does assert the (non)existence of RRsets with
- the same owner name.
-
-
-3.1 Server Considerations
-
- Opt-In imposes some new requirements on authoritative DNS servers.
-
-3.1.1 Delegations Only
-
- This specification dictates that only insecure delegations may exist
- between the owner and "next" names of an Opt-In tagged NXT record.
- Signing tools SHOULD NOT generate signed zones that violate this
- restriction. Servers SHOULD refuse to load and/or serve zones that
- violate this restriction.
-
-3.1.2 Insecure Delegation Responses
-
- When returning an Opt-In insecure delegation, the server MUST return
- the covering NXT RRset in the Authority section.
-
- This presents a change from RFC 2535, where the "no-key" KEY RRset
- would be returned instead. However, in the delegation signer
- proposal, NXT records already must be returned along with the
- insecure delegation. The primary difference that this proposal
- introduces is that the Opt-In tagged NXT record will have a different
- owner name from the delegation RRset. This may require
- implementations to do a NXT search on cached responses.
-
-3.1.3 Wildcards and Opt-In
-
- RFC 2535, in section 5.3, describes the practice of returning NXT
- records to prove the non-existence of an applicable wildcard in
- non-existent name responses. This NXT record can be described as a
- "negative wildcard proof". The use of Opt-In NXT records changes the
- necessity for this practice. For non-existent name responses when the
- query name (qname) is covered by an Opt-In tagged NXT record, servers
- MAY choose to omit the wildcard proof record, and clients MUST NOT
- treat the absence of this NXT record as a validation error.
-
- The intent of the RFC 2535 negative wildcard proof requirement is to
- prevent malicious users from undetectably removing valid wildcard
- responses. In order for this cryptographic proof to work, the
- resolver must be able to prove:
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 6]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- 1. The exact qname does not exist. This is done by the "normal" NXT
- record.
-
- 2. No applicable wildcard exists. This is done by returning a NXT
- record proving that the wildcard does not exist (negative
- wildcard proof).
-
- However, if the NXT record covering the exact qname is an Opt-In NXT
- record, the resolver will not be able to prove the first part of this
- equation, as the qname might exist as an insecure delegation. Thus,
- since the total proof cannot be completed, the negative wildcard
- proof record is not useful.
-
- The negative wildcard proof is also not useful when returned as part
- of an Opt-In insecure delegation response for a similar reason: the
- resolver cannot prove that the qname does or does not exist, and
- therefore cannot prove that a wildcard expansion is valid.
-
- The presence of an Opt-In tagged NXT record does not change the
- practice of returning a NXT along with a wildcard expansion. Even
- though the Opt-In NXT will not be able to prove that the wildcard
- expansion is valid, it will prove that the wildcard expansion is not
- masking any signed records.
-
-3.1.4 Dynamic Update
-
- Opt-In changes the semantics of Secure DNS Dynamic Update [7]. In
- particular, it introduces the need for rules that describe when to
- add or remove a delegation name from the NXT chain. This document
- does not attempt to define these rules. Until these rules are
- defined, servers MUST NOT process DNS Dynamic Update requests against
- zones that use Opt-In NXT records.
-
-3.2 Client Considerations
-
- Opt-In imposes some new requirements on DNS resolvers (caching or
- otherwise).
-
-3.2.1 Delegations Only
-
- As stated in the "Server Considerations" section above, this
- specification restricts the namespace covered by Opt-In tagged NXT
- records to insecure delegations only. Thus, resolvers MUST reject as
- invalid any records that fall within an Opt-In NXT record's span that
- are not NS records or corresponding glue records.
-
-3.2.2 Validation Process Changes
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 7]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- This specification does not change the resolver's resolution
- algorithm. However, it does change the DNSSEC validation process.
- Resolvers MUST be able to use Opt-In tagged NXT records to
- cryptographically prove the validity and security status (as
- insecure) of a referral. Resolvers determine the security status of
- the referred-to zone as follows:
-
- o In RFC 2535, the security status is proven by existence of a
- verified "no-key" KEY RRset. The absence of the "no-key" KEY
- RRset indicates that the referred-to zone is secure.
-
- o Using Delegation Signer, the security status is proven by the
- existence or absence of a DS RRset at the same name as the
- delegation. The existence of the DS RRset indicates that the
- referred-to zone is secure. The absence of the DS RRset is proven
- using a verified NXT record of the same name that does not have
- the DS bit set in the type map. This NXT record MAY also be
- tagged as Opt-In.
-
- o Using Opt-In, the security status is proven by the existence of a
- DS record (for secure) or the presence of a verified Opt-In tagged
- NXT record that covers the delegation name. That is, the NXT
- record does not have the NXT bit set in the type map, and the
- delegation name falls between the NXT's owner and "next" name.
-
- Using Opt-In does not substantially change the nature of following
- referrals within DNSSEC. At every delegation point, the resolver
- will have cryptographic proof that the subzone is secure or insecure.
-
- When receiving either an Opt-In insecure delegation response or a
- non-existent name response where that name is covered by an Opt-In
- tagged NXT record, the resolver MUST NOT require proof (in the form
- of a NXT record) that a wildcard did not exist.
-
-3.2.3 NXT Record Caching
-
- Caching resolvers MUST be able to retrieve the appropriate covering
- Opt-In NXT record when returning referrals that need them. This
- requirement differs from Delegation Signer in that the covering NXT
- will not have the same owner name as the delegation. Some
- implementations may have to use new methods for finding these NXT
- records.
-
-3.2.4 Use of the AD bit
-
- The AD bit, as defined by [4], MUST NOT be set when:
-
- o sending a non-existent name (NXDOMAIN) response where the covering
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 8]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- NXT is tagged as Opt-In.
-
- o sending an Opt-In insecure delegation response, unless the
- covering (Opt-In) NXT record's owner name equals the delegation
- name.
-
- This rule is based on what the Opt-In NXT record actually proves.
- For names that exist between the Opt-In NXT record's owner and "next"
- names, the Opt-In NXT record cannot prove the non-existence or
- existence of the name. As such, not all data in the response has
- been cryptographically verified, so the AD bit cannot be set.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 9]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-4. Benefits
-
- Using Opt-In allows administrators of large and/or changing
- delegation-centric zones to minimize the overhead involved in
- maintaining the security of the zone.
-
- Opt-In accomplishes this by eliminating the need for both "no-key"
- KEY (in [2]) and NXT records for insecure delegations. This, in a
- zone with a large number of delegations to unsigned subzones, can
- lead to substantial space savings (both in memory and on disk).
- Additionally, Opt-In allows for the addition or removal of insecure
- delegations without modifying the NXT record chain. Zones that are
- frequently updating insecure delegations (e.g., TLDs) can avoid the
- substantial overhead of modifying and resigning the affected NXT
- records.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 10]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-5. Example
-
- Consider the zone EXAMPLE, shown below. This is a zone where all of
- the NXT records are tagged as Opt-In.
-
- Example A: Fully DS/Opt-In Zone.
-
- EXAMPLE. SOA ...
- EXAMPLE. SIG SOA ...
- EXAMPLE. NS FIRST-SECURE.EXAMPLE.
- EXAMPLE. SIG NS ...
- EXAMPLE. KEY ...
- EXAMPLE. SIG KEY ...
- EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY
- EXAMPLE. SIG NXT ...
-
- FIRST-SECURE.EXAMPLE. A ...
- FIRST-SECURE.EXAMPLE. SIG A ...
- FIRST-SECURE.EXAMPLE. NXT NOT-SECURE-2.EXAMPLE. A SIG
- FIRST-SECURE.EXAMPLE. SIG NXT ...
-
- NOT-SECURE.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
- NS.NOT-SECURE.EXAMPLE. A ...
-
- NOT-SECURE-2.EXAMPLE. NS NS.NOT-SECURE.EXAMPLE.
- NOT-SECURE-2.EXAMPLE NXT SECOND-SECURE.EXAMPLE NS SIG
- NOT-SECURE-2.EXAMPLE SIG NXT ...
-
- SECOND-SECURE.EXAMPLE. NS NS.ELSEWHERE.
- SECOND-SECURE.EXAMPLE. DS ...
- SECOND-SECURE.EXAMPLE. SIG DS ...
- SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG KEY
- SECOND-SECURE.EXAMPLE. SIG NXT ...
-
- UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE.
- NS.UNSIGNED.EXAMPLE. A ...
-
-
- In this example, a query for a signed RRset (e.g.,
- "FIRST-SECURE.EXAMPLE A"), or a secure delegation
- ("WWW.SECOND-SECURE.EXAMPLE A") will result in a standard RFC 2535
- response.
-
- A query for a nonexistent RRset will result in a response that
- differs from RFC 2535 by: the NXT record will be tagged as Opt-In,
- there may be no NXT record proving the non-existence of a matching
- wildcard record, and the AD bit will not be set.
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 11]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- A query for an insecure delegation RRset (or a referral) will return
- both the answer (in the Authority section) and the corresponding
- Opt-In NXT record to prove that it is not secure.
-
- Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A
-
-
- RCODE=NOERROR, AD=0
-
- Answer Section:
-
- Authority Section:
- UNSIGNED.EXAMPLE. NS NS.UNSIGNED.EXAMPLE
- SECOND-SECURE.EXAMPLE. NXT EXAMPLE. NS SIG DS
- SECOND-SECURE.EXAMPLE. SIG NXT ...
-
- Additional Section:
- NS.UNSIGNED.EXAMPLE. A ...
-
- In the Example A.1 zone, the EXAMPLE. node MAY use either style of
- NXT record, because there are no insecure delegations that occur
- between it and the next node, FIRST-SECURE.EXAMPLE. In other words,
- Example A would still be a valid zone if the NXT record for EXAMPLE.
- was changed to the following RR:
-
- EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY NXT
-
- However, the other NXT records (FIRST-SECURE.EXAMPLE. and
- SECOND-SECURE.EXAMPLE.) MUST be tagged as Opt-In because there are
- insecure delegations in the range they define. (NOT-SECURE.EXAMPLE.
- and UNSIGNED.EXAMPLE., respectively).
-
- NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
- part of the NXT chain and also covered by an Opt-In tagged NXT
- record. Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
- removed from the zone without modifying and resigning the prior NXT
- record. Delegations with names that fall between
- NOT-SECURE-2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or
- removed without resigning any NXT records.
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 12]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-6. Transition Issues
-
- Opt-In is not backwards compatible with RFC 2535. RFC 2535 compliant
- DNSSEC implementations will not recognize Opt-In tagged NXT records
- as different from RFC 2535 NXT records. Because of this, RFC 2535
- implementations will reject all Opt-In insecure delegations within a
- zone as invalid.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 13]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-7. Security Considerations
-
- Opt-In allows for unsigned names, in the form of delegations to
- unsigned subzones, to exist within an otherwise signed zone. All
- unsigned names are, by definition, insecure, and their validity or
- existence cannot by cryptographically proven.
-
- In general:
-
- o Records with unsigned names (whether existing or not) suffer from
- the same vulnerabilities as records in an unsigned zone. These
- vulnerabilites are described in more detail in [10] (note in
- particular sections 2.3, "Name Games" and 2.6, "Authenticated
- Denial").
-
- o Records with signed names have the same security whether or not
- Opt-In is used.
-
- Note that with or without Opt-In, an insecure delegation may have its
- contents undetectably altered by an attacker. Because of this, the
- primary difference in security that Opt-In introduces is the loss of
- the ability to prove the existence or nonexistence of an insecure
- delegation within the span of an Opt-In NXT record.
-
- In particular, this means that a malicious entity may be able to
- insert or delete records with unsigned names. These records are
- normally NS records, but this also includes signed wildcard
- expansions (while the wildcard record itself is signed, its expanded
- name is an unsigned name).
-
- For example, if a resolver received the following response from the
- example zone above:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 14]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE. A
-
- RCODE=NOERROR
-
- Answer Section:
-
- Authority Section:
- DOES-NOT-EXIST.EXAMPLE. NS NS.FORGED.
- EXAMPLE. NXT FIRST-SECURE.EXAMPLE. SOA NS SIG KEY
- EXAMPLE. SIG NXT ...
-
- Additional Section:
-
-
- The resolver would have no choice but to believe that the referral to
- NS.FORGED. is valid. If a wildcard existed that would have been
- expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
- have undetectably removed it and replaced it with the forged
- delegation.
-
- Note that being able to add a delegation is functionally equivalent
- to being able to add any record type: an attacker merely has to forge
- a delegation to nameserver under his/her control and place whatever
- records needed at the subzone apex.
-
- While in particular cases, this issue may not present a significant
- security problem, in general it should not be lightly dismissed.
- Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
- In particular, zone signing tools SHOULD NOT default to Opt-In, and
- MAY choose to not support Opt-In at all.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 15]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-8. IANA Considerations
-
- None.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 16]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-9. Acknowledgments
-
- The contributions, suggestions and remarks of the following persons
- (in alphabetic order) to this draft are acknowledged:
-
- Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
- Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
- Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
- Wellington.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 17]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-Normative References
-
- [1] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [2] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [3] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-12 (work in progress),
- December 2002.
-
- [4] Gudmundsson, O. and B. Wellington, "Redefinition of DNS AD bit",
- draft-ietf-dnsext-ad-is-secure-06 (work in progress), June 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 18]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-Informative References
-
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [6] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [7] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
- 2137, April 1997.
-
- [8] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [9] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
- December 2001.
-
- [10] Atkins, D. and R. Austein, "Threat Analysis Of The Domain Name
- System", draft-ietf-dnsext-dns-threats-02 (work in progress),
- November 2002.
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
- Mark Kosters
- Verisign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- EMail: markk@verisign.com
- URI: http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 19]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- David Blacka
- Verisign, Inc.
- 21355 Ridgetop Circle
- Dulles, VA 20166
- US
-
- Phone: +1 703 948 3200
- EMail: davidb@verisign.com
- URI: http://www.verisignlabs.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 20]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-Appendix A. Implementing Opt-In using "Views"
-
- In many cases, it may be convenient to implement an Opt-In zone by
- combining two separately maintained "views" of a zone at request
- time. In this context, "view" refers to a particular version of a
- zone, not to any specific DNS implementation feature.
-
- In this scenario, one view is the secure view, the other is the
- insecure (or legacy) view. The secure view consists of an entirely
- signed zone using Opt-In tagged NXT records. The insecure view
- contains no DNSSEC information. It is helpful, although not
- necessary, for the secure view to be a subset (minus DNSSEC records)
- of the insecure view.
-
- In addition, the only RRsets that may solely exist in the insecure
- view are non-zone-apex NS RRsets. That is, all non-NS RRsets (and the
- zone apex NS RRset) MUST be signed and in the secure view.
-
- These two views may be combined at request time to provide a virtual,
- single Opt-In zone. The following algorithm is used when responding
- to each query:
-
- V_A is the secure view as described above.
-
- V_B is the insecure view as described above.
-
- R_A is a response generated from V_A, following RFC 2535 [2].
-
- R_B is a response generated from V_B, following DNS resolution as
- per RFC 1035 [1].
-
- R_C is the response generated by combining R_A with R_B, as
- described below.
-
- A query is DNSSEC-aware if it either has the DO bit [9] turned on,
- or is for a DNSSEC-specific record type.
-
-
-
-
- 1. If V_A is a subset of V_B and the query is not DNSSEC-aware,
- generate and return R_B, otherwise
-
- 2. Generate R_A.
-
- 3. If R_A's RCODE != NXDOMAIN, return R_A, otherwise
-
- 4. Generate R_B and combine it with R_A to form R_C:
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 21]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
- records from R_A into R_B, EXCEPT the AUTHORITY section SOA
- record, if R_B's RCODE = NOERROR.
-
- 5. Return R_C.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 22]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-Appendix B. Changes from Prior Versions
-
- Changes from version 04:
-
- Added definitions for "signed name" and "unsigned name".
-
- Added text to make it clear that insecure delegations may have
- Opt-In NXT records of the same name. Updated the example to have
- one of these.
-
- Changed Server-side requirements from MUST NOT to SHOULD NOT and
- added some basic description of what action to take in the face of
- violating the delegation-only restriction.
-
- Relaxed requirement that servers drop negative wildcard proof from
- MUST to MAY, reiterated the client requirement.
-
- Added section on Dynamic Update declaring it to be undefined wrt
- Opt-In.
-
- Essentially rewrote the "Security Considerations" section. It does
- not actually say anything different, but hopefully it says it in a
- clearer fashion.
-
- Split references into Normative and Informative.
-
- Fixed the example zone and responses to match Delegation Signer.
-
- Changes from version 03:
-
- Editorial changes for clarification only.
-
- Changes from version 02:
-
- Added text on changes to validation process, use of the AD bit,
- and interactions with wildcards. Added wildcard caveats to the
- "Security Considerations" section. Added "Transition Issues"
- section.
-
- Changes from version 01:
-
- Changed to "delegation only". Strengthened "Security
- Considerations" section. Added "Server Considerations" and "Client
- Considerations" sections. Added AD bit requirement.
-
- Changes from version 00:
-
- Complete rewrite, altering approach from "views" to tagged NXT
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 23]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- records
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 24]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). 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 assignees.
-
- 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
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 25]
-\f
-Internet-Draft DNSSEC Opt-In February 2003
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 28, 2003 [Page 26]
-\f
+++ /dev/null
-
-
-DNS Extensions R. Arends
-Internet-Draft Telematica Instituut
-Expires: September 1, 2003 M. Larson
- VeriSign
- R. Austein
- ISC
- D. Massey
- USC/ISI
- S. Rose
- NIST
- March 3, 2003
-
-
- Protocol Modifications for the DNS Security Extensions
- draft-ietf-dnsext-dnssec-protocol-01
-
-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.
-
- This Internet-Draft will expire on September 1, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document is part of a family of documents which describes the
- DNS Security Extensions (DNSSEC). The DNS Security Extensions are a
- collection of new resource records and protocol modifications which
- add data origin authentication and data integrity to the DNS. This
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 1]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- document describes the DNSSEC protocol modifications. This document
- defines the concept of a signed zone, along with the requirements for
- serving and resolving using DNSSEC. These techniques allow a
- security-aware resolver to authenticate both DNS resource records and
- authoritative DNS error indications.
-
- This document obsoletes RFC 2535 and incorporates changes from all
- updates to RFC 2535.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 Background and Related Documents . . . . . . . . . . . . . . 4
- 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3 Editors' Notes . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4
- 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4
- 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5
- 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . 6
- 2.1 Including KEY RRs in a Zone . . . . . . . . . . . . . . . . 6
- 2.2 Including SIG RRs in a Zone . . . . . . . . . . . . . . . . 7
- 2.3 Including NXT RRs in a Zone . . . . . . . . . . . . . . . . 8
- 2.4 Including DS RRs in a Zone . . . . . . . . . . . . . . . . . 8
- 2.5 Changes to the CNAME Resource Record. . . . . . . . . . . . 8
- 2.6 Example of a Secure Zone . . . . . . . . . . . . . . . . . . 8
- 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 3.1 Including SIG RRs in a Response . . . . . . . . . . . . . . 10
- 3.2 Including KEY RRs In a Response . . . . . . . . . . . . . . 11
- 3.3 Including NXT RRs In a Response . . . . . . . . . . . . . . 11
- 3.3.1 Case 1: Query Name Exists, but RR Type Not Present . . . . . 12
- 3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches . 12
- 3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches . . 13
- 3.4 Including DS RRs In a Response . . . . . . . . . . . . . . . 13
- 3.5 Responding to Queries for DS RRs . . . . . . . . . . . . . . 13
- 3.6 Responding to Queries for Type AXFR or IXFR . . . . . . . . 15
- 3.7 Setting the AD and CD Bits in a Response . . . . . . . . . . 15
- 3.8 Example DNSSEC Responses . . . . . . . . . . . . . . . . . . 16
- 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 4.1 Recursive Name Servers . . . . . . . . . . . . . . . . . . . 23
- 4.2 Stub resolvers . . . . . . . . . . . . . . . . . . . . . . . 24
- 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . 25
- 5.1 Authenticating Referrals . . . . . . . . . . . . . . . . . . 26
- 5.2 Authenticating an RRSet Using a SIG RR . . . . . . . . . . . 27
- 5.2.1 Checking the SIG RR Validity . . . . . . . . . . . . . . . . 27
- 5.2.2 Reconstructing the Signed Data . . . . . . . . . . . . . . . 28
- 5.2.3 Checking the Signature . . . . . . . . . . . . . . . . . . . 30
- 5.2.4 Authenticating A Wildcard Expanded RRset Positive Response . 31
- 5.3 Authenticated Denial of Existence . . . . . . . . . . . . . 31
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 2]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- 5.4 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 32
- 5.4.1 Example of Re-Constructing the Original Owner Name . . . . . 32
- 5.4.2 Examples of Authenticating a Response . . . . . . . . . . . 33
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
- 7. Security Considerations . . . . . . . . . . . . . . . . . . 35
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36
- Normative References . . . . . . . . . . . . . . . . . . . . 37
- Informative References . . . . . . . . . . . . . . . . . . . 38
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38
- A. Algorithm For Handling Wildcard Expansion . . . . . . . . . 40
- Full Copyright Statement . . . . . . . . . . . . . . . . . . 41
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 3]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-1. Introduction
-
- The DNS Security Extensions (DNSSEC) modify several aspects of the
- DNS protocol. Section 2 defines the concept of a signed zone and
- lists the requirements for zone signing. Section 3 describes the
- modifications to authoritative name server behavior necessary to
- handle signed zones. Section 4 describes the behavior of entities
- which include security-aware resolver functions Finally, Section 5
- defines how to use DNSSEC RRs to authenticate a response.
-
-1.1 Background and Related Documents
-
- The reader is assumed to be familiar with the basic DNS concepts
- described in RFC1034 [1] and RFC1035 [2].
-
- This document is part of a family of documents which define the DNS
- security extensions (DNSSEC). The DNS Security Extensions are a
- collection of new resource records and protocol modifications which
- add data origin authentication and data integrity to the DNS. An
- introduction to DNSSEC and definition of common terms can be found in
- [9]. A definition of the DNSSEC resource records can be found in
- [10]. This document defines the DNSSEC protocol modifications.
-
-1.2 Reserved Words
-
- 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. [4].
-
-1.3 Editors' Notes
-
-1.3.1 Open Technical Issues
-
- Use of NXT RRs throughout this document set will have to be modified
- if DNSSEC-Opt-In [11] becomes part of DNSSEC. The use of the NXT
- record requires input from the working group. This text describes
- the NXT record as it was defined in RFC 2535, and substantial
- portions of this document would need to be updated to incorporate
- opt-in. The updates will be made if the WG adopts opt-in.
-
- Use of the AD bit requires input from the working group. Since the
- AD bit usage is not resolved, this text attempts to capture current
- ideas and drafts, but further input from the working group is
- required.
-
-1.3.2 Technical Changes or Corrections
-
- Please report technical corrections to dnssec-editors@east.isi.edu.
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 4]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- To assist the editors, please indicate the text in error and point
- out the RFC that defines the correct behavior. For a technical
- change where no RFC that defines the correct behavior, or if there's
- more than one applicable RFC and the definitions conflict, please
- post the issue to namedroppers.
-
- An example correction to dnssec-editors might be: Page X says
- "DNSSEC RRs SHOULD be automatically returned in responses." This was
- true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
- DNSSEC RR types MUST NOT be included in responses unless the resolver
- indicated support for DNSSEC.
-
-1.3.3 Typos and Minor Corrections
-
- Please report any typos corrections to dnssec-editors@east.isi.edu.
- To assist the editors, please provide enough context for us to find
- the incorrect text quickly.
-
- An example message to dnssec-editors might be: page X says "the
- DNSSEC standard has been in development for over 1 years". It
- should read "over 10 years".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 5]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-2. Zone Signing
-
- DNSSEC defines the concept of a signed zone. A signed zone includes
- KEY, SIG, NXT and (optionally) DS records according to the rules
- specified in Section 2.1, Section 2.2, Section 2.3 and Section 2.4,
- respectively. Any zone which does not include these records
- according to the rules in this section must be considered unsigned.
-
- Editors' note: Should this be "MUST be considered unsigned"?
-
- DNSSEC requires a change to the definition of the CNAME resource
- record. Section 2.5 changes the CNAME RR to allow SIG and NXT RRs to
- appear at the same owner name as a CNAME RR.
-
- Section 2.6 shows a sample signed zone.
-
-2.1 Including KEY RRs in a Zone
-
- Editors' note: Unresolved inconsistency between paragraphs in this
- section, regarding non-zone KEY RRs at the zone apex. SHOULD NOT,
- or MUST NOT?
-
- To sign a zone, the zone's administrator generates one or more
- public/private key pairs and uses the private key(s) to sign
- authoritative RRsets in the zone. For each private key used to
- create SIG RRs, there SHOULD be a corresponding KEY RR stored at the
- zone apex. All KEY RRs at the zone apex MUST be zone keys. (A zone
- key KEY RR has the Zone Key bit of the Flags RDATA field set to one.
- See Section 2.1.1 of [10].) Zone key KEY RRs MUST appear only at the
- zone apex.
-
- A signed zone MUST have at least one zone key KEY RR in its apex KEY
- RRset. The KEY RRset at the zone apex MUST be self-signed by at
- least one private key whose corresponding public key is a zone key
- stored in the apex KEY RRset.
-
- Editors' note: The requirement listed in this paragraph may not be
- necessary anymore, since the KEY RRset is self-signed anyway
- (because the whole zone is signed). This is probably a pre-DS
- relic, but we spotted this a few hours before the I-D deadline and
- were too chicken to remove it on such short notice....
-
- Other public keys associated with other DNS operations can be stored
- in KEY RRs that are not marked as zone keys. Non-zone key KEY RRs
- MUST NOT appear at delegation names. Non-zone key KEY RRs also
- SHOULD NOT appear at the zone apex, because large KEY RRsets add
- processing time at resolvers. Non-zone key KEY RRs MAY appear at any
- other name in the zone.
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 6]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-2.2 Including SIG RRs in a Zone
-
- For each authoritative RRset in the zone (which excludes NS RRsets at
- delegation points and glue RRsets), there MUST be at least one SIG
- record that meets all of the following requirements:
-
- o The SIG owner name is equal to the RRset owner name;
-
- o The SIG class is equal to the RRset class;
-
- o The SIG Type Covered field is equal to the RRset type;
-
- o The SIG Original TTL field is equal to the TTL of the RRset;
-
- o The SIG RR's TTL is equal to the TTL of the RRset;
-
- o The SIG Labels field is equal to the number of labels in the RRset
- owner name, not counting the null root label or any wildcard
- label;
-
- o The SIG Signer's Name field is equal to the name of the zone
- containing the RRset; and
-
- o The SIG Algorithm, Signer's Name, and Key Tag fields identify a
- zone key KEY record at the zone apex.
-
- The process for constructing the SIG RR for a given RRset is
- described in [10]. An RRset MAY have multiple SIG RRs associated
- with it.
-
- A SIG RR itself MUST NOT be signed, since signing a SIG RRset would
- add no value and would create an unterminated dependency loop in the
- signing process.
-
- The NS RRset which appears at the zone apex name MUST be signed, but
- the NS RRsets which appear at delegation points (that is, the NS
- RRsets in the parent zone which delegate the name to the child zone's
- name servers) MUST NOT be signed. Glue address RRsets associated
- with delegations MUST NOT be signed.
-
- The difference between the set of owner names which require SIG
- records and the set of owner names which require NXT records is
- subtle and worth highlighting. SIG records are present at the owner
- names of all authoritative RRsets. NXT records are present at the
- owner names of all names for which the signed zone is authoritative
- and also at the owner names of delegations from the signed zone to
- its children. Neither NXT nor SIG records are present (in the parent
- zone) at the owner names of glue address RRsets. Note, however, that
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 7]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- this distinction is for the most part only visible during the zone
- signing process, because NXT RRsets are authoritative data, and
- therefore are signed, thus any owner name which has an NXT RRset will
- have SIG RRs as well in the signed zone.
-
-2.3 Including NXT RRs in a Zone
-
- Each owner name in the zone MUST have an NXT resource record, except
- for the owner names of any glue address RRsets. The process for
- constructing the NXT RR for a given name is described in [10].
-
-2.4 Including DS RRs in a Zone
-
- The DS resource record establishes authentication chains between DNS
- zones. A DS RRset SHOULD be present at a delegation point when the
- child zone is signed. The DS RRset MAY contain multiple records,
- each referencing a key used by the child zone to sign its apex KEY
- RRset. All DS RRsets in a zone MUST be signed and DS RRsets MUST NOT
- appear at non-delegation points nor at a zone's apex.
-
- A DS RR SHOULD point to a KEY RR which is present in the child's apex
- KEY RRset, and the child's apex KEY RRset SHOULD be signed by the
- corresponding private key.
-
- Construction of a DS RR requires knowledge of the corresponding KEY
- RR in the child zone, which implies communication between the child
- and parent zones. This communication is an operational matter not
- covered by this document.
-
-2.5 Changes to the CNAME Resource Record.
-
- If a CNAME RRset is present at a name in a signed zone, appropriate
- SIG and NXT RRsets are REQUIRED at that name. Other types MUST NOT
- be present at that name.
-
- This is a modification to the original CNAME definition given in [1].
- The original definition of the CNAME RR did not allow any other types
- to co-exist with a CNAME record, but a signed zone requires NXT and
- SIG RRsets for every authoritative name. To resolve this conflict,
- the definition of the CNAME resource record is hereby modified to
- allow for the co-existence of NXT and SIG RRsets.
-
-2.6 Example of a Secure Zone
-
- {{secure zone here}}
-
- Editors' note: Zone file example deferred pending hackery to add
- zone files in a format usable by xml2rfc. Goal here is to show a
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 8]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- (small) complete signed zone.
-
- The apex KEY set includes two KEY RRs, and the KEY RDATA Flags
- indicate that each of these KEY RRs is a zone key. The first zone
- KEY is used to sign the apex KEY RRset, and a DS record for this key
- is provided to the parent zone. The second zone KEY is used to sign
- all the other RRsets in the zone. A non-zone KEY RR is also stored
- at "host1.example.com"; this KEY might be used by SIG(0) to
- authenticate transactions from this host.
-
- The zone includes a wildcard entry "*.a.example.com". Note that the
- "*.a.example.com" name is used in constructing NXT chains, and that
- the SIG covering the "*.a.example.com" MX RRset has a label count of
- 3.
-
- The zone also includes two delegations. The delegation to
- "insecure.example.com" includes an NS RRset, glue address records,
- and an NXT RR, but note that only the NXT RRset is signed. The
- "secure.example.com" delegation provides a DS RR, and note that only
- NXT and DS RRsets are signed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 9]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-3. Serving
-
- This section describes the behavior of a security-aware authoritative
- name server. A security-aware authoritative name server MUST support
- the EDNS0 [6] message size extension, MUST support a message size of
- at least 1220 octets, and SHOULD support a message size of 4000
- octets [8]. Since functions specific to security-aware recursive
- name servers included components of both resolving and serving,
- issues specific to security-aware recursive name servers are
- described in Section 4.
-
- Upon receiving a relevant query which has the EDNS [6] OPT pseudo-RR
- DO [7] bit set to one, a security-aware authoritative name server for
- a signed zone MUST include additional SIG, NXT, and DS RRs according
- to the following rules:
-
- o SIG RRs which can be used to authenticate a response MUST be
- included in the response automatically according to the rules in
- Section 3.1;
-
- o NXT RRs which can be used to provide authenticated denial of
- existence MUST be included in the response automatically according
- to the rules in Section 3.3;
-
- o Either DS RRs or an NXT RR proving that no DS RRs exist MUST be
- included in referrals automatically according to the rules in
- Section 3.4.
-
- DNSSEC does not change the DNS zone transfer protocol. Zone transfer
- requirements are reviewed in Section 3.6.
-
- A security-aware name server which receives a DNS query which does
- not include the EDNS OPT pseudo-RR, or which has the DO bit set to
- zero, MUST treat the SIG, KEY, and NXT RRs as it would any other
- RRset, and MUST NOT perform any of the additional processing
- described above. Since the DS RR type has the peculiar property of
- only existing in the parent zone at delegation points, DS RRs always
- require some special processing, as described in Section 3.5.
-
-3.1 Including SIG RRs in a Response
-
- When a query has the DO bit set to one, the authoritative name server
- SHOULD attempt to send SIG RRs which can be used to authenticate the
- RRsets in the response. Inclusion of SIG RRs in a response is
- subject to the following rules:
-
- o When a signed RRset is placed in the Answer section, its SIG RRs
- are also placed in the Answer section. The SIG RRs have a higher
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 10]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- priority for inclusion than any other RRsets which may need to be
- included. If space does not permit the inclusion of these SIG
- RRs, the response MUST be considered truncated, and the TC bit
- MUST be set.
-
- o When a signed RRset is placed in the Authority section, its SIG
- RRs are also placed in the Authority section. The SIG RRs have a
- higher priority for inclusion than any other RRsets that may need
- to be included. If space does not permit the inclusion of these
- SIG RRs, the response MUST be considered truncated, and the TC bit
- MUST be set.
-
- o When a signed RRset is placed in the Additional section, its SIG
- RRs are also placed in the Additional section. If space does not
- permit the inclusion of these SIG RRs, the response MUST NOT be
- considered truncated just because these SIG RRs didn't fit.
-
-
-3.2 Including KEY RRs In a Response
-
- When a query has the DO bit set to one and requests the SOA or NS RRs
- at the apex of a signed zone, then a security-aware authoritative
- name server for that zone SHOULD return the KEY RRset with the same
- name in the Additional section. If Additional section processing
- results in more data than will fit in the response message, address
- glue RRs have higher priority than KEY RRs. SIG RR(s) associated
- with the KEY RRset SHOULD also be included in the Additional section
- (see Section 3.1).
-
- Editors' note: Didn't the WG decide that DS RR removes the need
- for Additional section processing for KEY RRs? If so, this
- subsection should be deleted.
-
-
-3.3 Including NXT RRs In a Response
-
- Editors' note: This whole section uses the phrase "query name
- exists", which is somewhat ambiguous when discussing internal
- nodes with no RRs. We are reasonably certain that, as used here,
- the phrase only refers to names which are the owner name for least
- one RR. Better phrasing needed.
-
- When a query has the DO bit set to one, security-aware authoritative
- name servers for a signed zone MUST include NXT RRs in each of the
- following cases:
-
- Case 1: The query name exists, but the requested RR type does not
- exist.
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 11]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- Case 2: The query name does not exist, and no wildcard can be
- expanded to answer the query.
-
- Case 3: The query name does not exist, but a wildcard can be expanded
- to positively answer the query.
-
- Note that, in each case, a set of NXT RRs is included to provide
- authenticated denial of existence.
-
- NXT RRs are also included in a referral response when no DS RR is
- present; in this case, the NXT RR proves that no DS RR exists for the
- delegation. Referrals are discussed in more detail in Section 3.4.
-
-3.3.1 Case 1: Query Name Exists, but RR Type Not Present
-
- If the query name exists but the requested RR type is not present at
- the name, then the NXT RR associated with the query name MUST be
- included in the Authority section. Any SIG(s) associated with the
- NXT RRset are also included in the Authority section (see Section
- 3.1) If space does not permit the inclusion of the NXT RR (or its
- associate SIG RRs), the response MUST be considered truncated and the
- TC bit MUST be set.
-
- Note that, since the query name exists, no wildcard expansion applies
- to this query, and a single NXT RR suffices to prove the requested
- type does not exist.
-
-3.3.2 Case 2: Query Name Does Not Exist, and No Wildcard Matches
-
- If the query name does not exist, and no wildcard expansion matches
- the query, then the Authority section of the response MUST include
- the following NXT RRs:
-
- o An NXT RR proving that there was no exact match for the name; and
-
- o An NXT RR proving that there was no wildcard which would have
- matched the query.
-
- If space does not permit the inclusion of these NXT RRs, the response
- MUST be considered truncated, and the TC bit MUST be set. Any SIG(s)
- associated with the NXT RRsets MUST also be included in the Authority
- section (see Section 3.1).
-
- Editors' note: Should lack of space to include the SIGs cause the
- packet to be considered truncated?
-
- Appendix A provides an algorithm which computes the appropriate NXT
- RRs to prove that no wildcard matches a given query name.
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 12]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-3.3.3 Case 3: Query Name Does Not Exist, but Wildcard Matches
-
- If the query name does not exist, but a wildcard expansion can be
- used to return a positive match to the query, then the wildcard-
- expanded answer and any SIG RRs associated with the wildcard RR MUST
- be returned in the Answer section. The Authority section of the
- response MUST include the following NXT RRs:
-
- o An NXT RR which proves that there were no exact matches for the
- QNAME and QTYPE; and
-
- o An NXT RR which proves that there are no closer wildcard entries
- which could have been expanded to match the query.
-
- If space does not permit inclusion of these NXT RRs, the response
- MUST be considered truncated, and the TC bit MUST be set. Any SIG
- RRs associated with the NXT RRsets MUST also be included in the
- response.
-
- Editors' note: Should lack of space to include the SIGs cause the
- packet to be considered truncated?
-
- Appendix A provides an algorithm which computes the appropriate NXT
- RRs to prove that no closer wildcard matches the query name.
-
-3.4 Including DS RRs In a Response
-
- When a query has the DO bit set to one, and a DS RR exists at the
- query name, an authoritative security-aware name server returning a
- referral for the delegation MUST include both the NS RRset and also
- the DS RRset and its associated SIG RR(s). The NS RRset MUST be
- placed before the DS RRset and its associated SIG RRs.
-
- When a query has the DO bit set to one, and no DS RR exists at the
- query name, an authoritative security-aware name server returning a
- referral for the delegation MUST include both the NS RRset and also
- the NXT RR and associated SIG RR(s) which proves that the DS RRset
- does not exist. The NS RRset MUST be placed before the NXT RRset and
- its associated SIG RR(s).
-
- This increases the size of referral messages, and may cause some or
- all glue RRs to be omitted. If space does not permit the inclusion
- of the DS or NXT RRset and associated SIG RRs, the response MUST be
- considered truncated, and the TC bit MUST be set.
-
-3.5 Responding to Queries for DS RRs
-
- The DS record is the first resource record type which appears only on
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 13]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- the parent zone's side of a zone cut. In other words, the DS record
- for the delegation of "example.com" is only stored in the "com" zone.
- This introduces novel name server behavior, since the name server for
- the child zone is authoritative for the name by the normal DNS rules
- but the child zone does not contain the DS RR. A name server's
- response to a DS query depends on whether the name server is
- authoritative for the parent zone, the child zone, or both, as
- described below.
-
- If a name server is authoritative for the parent zone, and receives a
- query for the DS record at the delegated name, then the name server
- MUST return the DS RRset from the parent zone. This rule applies
- regardless of whether or not the name server is also authoritative
- for the child zone.
-
- If the name server is authoritative for the child zone, is not
- authoritative for the parent zone, and receives a query for the DS
- record at the delegated name, there is no obvious response, because
- the child zone is not authoritative for the DS record at the child
- zone's apex, and the authoritative DS RR is only stored at the
- parent.
-
- If the name server allows recursion, and the RD bit is set in the
- query, the name server MAY perform recursion to find the DS record
- for the delegated name from the parent zone, and MAY return the DS
- record from its cache. In this case, the AA bit MUST NOT be set in
- the response.
-
- If the name server does not perform recursion to find the DS RR, the
- name server MUST reply with:
-
- RCODE: NOERROR
- AA bit: set
- Answer Section: Empty
- Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
-
- In other words, a name server which is authoritative for the child
- zone but not for the parent zone answers as if the DS record does not
- exist. Note that security-aware resolvers will query the parent zone
- at delegation points, and thus will not be affected by this behavior.
-
- For example, suppose that "example.com" is a delegation point, and a
- name server receives a query for the "example.com" DS RRset.
-
- o If the name server is authoritative for "com", the name server
- MUST reply with the "example.com" DS RRset from the "com" zone.
-
- o If the name server is authoritative for "example.com", is not
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 14]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- authoritative for "com", and the RD bit is set to one in the
- query, the name server MAY perform recursion to find the
- "example.com" DS record. If the name server does not use
- recursion to obtain the DS RR, the name server MUST reply as
- though the DS RR did not exist:
-
- RCODE: NOERROR
- AA bit: set
- Answer Section: Empty
- Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
-
-
-3.6 Responding to Queries for Type AXFR or IXFR
-
- DNSSEC does not change the DNS zone transfer process. A signed zone
- will contain SIG, KEY, NXT, and DS resource records, but these
- records have no special meaning with respect to a zone transfer
- operation, and these RRs are treated as any other resource record
- type.
-
- An authoritative name server is not required to verify that a zone is
- properly signed before sending or accepting a zone transfer.
- However, an authoritative name server MAY choose to reject the entire
- zone transfer if the zone fails meets any of the signing requirements
- described in Section Section 2. The primary objective of a zone
- transfer to ensure that all authoritative name servers have identical
- copies of the zone. An authoritative name server which chooses to
- perform its own zone validation MUST NOT selectively reject some RRs
- and accept others.
-
- Note that the DS RR appears only in the parental side of a
- delegation, and is authoritative data in the parent zone. For
- example, the DS RR for "example.com" is stored in the "com" zone (the
- parent zone) rather than in the "example.com" zone (the child zone).
- As with any other authoritative RRset, the "example.com" DS RR MUST
- be included the "com" zone transfer.
-
- Note that authoritative NXT RRs appear in both the parent and child
- zones at a delegated name, and that the NXT RRs for the delegated
- name in the parent and child zones are never identical to each other.
- As with any other authoritative RRset, the parental NXT RR at a
- delegated name MUST be included zone transfers of the parent zone,
- while the NXT at the zone apex of the child zone MUST be included in
- zone transfers of the child zone.
-
-3.7 Setting the AD and CD Bits in a Response
-
- Editors' note: This section seems a little lost here. Perhaps we
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 15]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- should rearrange the section ordering slightly, or provide a
- pointer to this subsection at the beginning of Section 3.
-
- DNSSEC allocates two new bits in the DNS message header: The CD
- (Checking Disabled) bit and the AD (Authentic Data) bit.
-
- The CD bit is set in query messages by the resolver, and MUST be
- copied into the response. If the CD bit is set to one, it indicates
- that the resolver is willing to perform authentication, and thus that
- the name server need not perform authentication on the RRsets in the
- response.
-
- Regardless of the setting of the CD bit, the name server MAY choose
- whether or not to perform authentication according to the local name
- server policy. The CD bit MAY be used in constructing the local name
- server policy. If local name server policy does perform
- authentication, any RRsets rejected by the local authentication
- policy MUST NOT be returned in a response (regardless of the CD bit).
-
- The AD bit is set by name servers, and indicates the data in the
- response has been authenticated by the name server, according to the
- local name server policy. The AD bit MUST NOT be set on a response
- unless all of the RRsets in the Answer and Authority sections have
- met the name server's local authentication policy. A resolver MUST
- NOT trust the AD bit unless it communicates with the name server over
- a secure transport mechanism and is explicitly configured to trust
- the name server's policy.
-
-3.8 Example DNSSEC Responses
-
- The examples in this section use the following example zone to
- demonstrate the formation of replies by an authoritative name server.
- The zone has two name servers, a single child, and a wildcard MX RR.
- The zone is completely signed and has a full NXT chain.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 16]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- example.com. SOA (...)
- SIG SOA ...
- NS a.example.com.
- NS b.example.com.
- SIG NS ...
- MX 10 a.example.com
- SIG MX ...
- KEY ...
- SIG KEY ...
- NXT *.example.com.
- * MX 10 a.example.com.
- SIG MX ...
- NXT a.example.com.
- a A 10.10.10.1
- SIG A ...
- NXT b.example.com.
- b A 10.10.10.2
- SIG A ...
- NXT c.example.com.
- c CNAME a.example.com.
- SIG CNAME
- NXT sub.example.com.
- sub NS ns.sub.example.com.
- SIG NS
- DS ...
- SIG DS
- NXT *.example.com.
- ns.sub A 10.10.10.3
- sub-nosig NS ns.sub-nosig.example.com.
- NXT example.com.
- ns.sub-nosig A 10.10.10.4
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 17]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- A query to the authoritative name server for this zone for
- QNAME="c.example.com", QCLASS=IN, QTYPE=A would produce:
-
- Flags: QR=1, AA=1, RCODE=0 (NOERROR)
- EDNS: DO=1, size=4000
- QUERY:
- c.example.com. IN A
- ANSWER:
- c.example.com. IN A a.example.com
- IN SIG CNAME
- a.example.com. IN A 10.10.10.1
- IN SIG A
- AUTHORITY:
- example.com. IN NS a.example.com.
- IN NS b.example.com.
- IN SIG NS ...
- ADDITIONAL:
- a.example.com. IN A 10.10.10.1
- IN SIG A ...
- b.example.com. IN A 10.10.10.2
- IN SIG A ...
- example.com. IN KEY ...
- IN SIG KEY ...
-
- A query for QNAME="www.sub.example.com", QCLASS=IN, QTYPE=A would
- results in a referral to a signed zone. The resolver can determine
- that "sub.example.com" is signed because of the presence of the DS RR
- with the hash of the "sub.example.com" zone key.
-
- Flags: QR=1, AA=1, RCODE=0 (NOERROR)
- EDNS: DO=1, size=4000
- QUERY:
- www.sub.example.com. IN A
- ANSWER:
- ;; empty
- AUTHORITY:
- sub.example.com. IN NS ns.sub.example.com.
- IN DS ...
- IN SIG DS ...
- ADDITIONAL:
- ns.sub.example.com. IN A 10.10.10.3
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 18]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- A query for QNAME="www.sub-nosig.example.com", QCLASS=IN, QTYPE=A
- would result in a referral to an unsigned zone. The resolver knows
- not to expect DNSSEC RRs from "sub-nosig.example.com", because the DS
- bit in the NXT RR bitmap in the referral is not set. Even if DNSSEC
- RRs are present in responses from "sub-nosig.example.com" name
- servers, the resolver will not be able to construct a authentication
- chain, since there is a break between "sub-nosig.example.com" and its
- delegating parent zone.
-
- Flags: QR=1, AA=1, RCODE=0 (NOERROR)
- EDNS: DO=1, size=4000
- QUERY:
- www.sub-nosig.example.com. IN A
- ANSWER:
- ;; empty
- AUTHORITY:
- sub-nosig.example.com. IN NS ns.sub-nosig.example.com.
- IN NXT ;; (DS bit not set)
- IN SIG NXT ...
- ADDITIONAL:
- ns.sub-nosig.example.com. IN A 10.10.10.4
-
- A query for QNAME="f.example.com", QCLASS=IN, QTYPE=A returns a name
- error, because the name does not exist and is not covered by wildcard
- expansion. Therefore, the name server must present proof that the
- name does not exist, and that no wildcard expansion is present which
- could have been used to answer the query.
-
- Flags: QR=1, AA=1, RCODE=3 (NXDOMAIN)
- EDNS: DO=1, size=4000
- QUERY:
- f.example.com. IN A
- ANSWER:
- ;; empty
- AUTHORITY:
- example.com. IN SOA ...
- IN SIG SOA ...
- c.example.com. IN NXT sub.example.com. ...
- IN SIG NXT ...
- *.example.com. IN NXT a.example.com. ...
- IN SIG NXT ...
- ADDITIONAL:
- example.com. IN KEY ...
- IN SIG KEY ...
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 19]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- A query for QNAME="f.example.com" QCLASS=IN, QTYPE=MX returns an MX
- RR synthesized via wildcard expansion. The name server must prove
- that no exact match exists.
-
- Flags: QR=1, AA=1, RCODE=0 (NOERROR)
- EDNS: DO=1, size=4000
- QUERY:
- f.example.com. IN MX
- ANSWER:
- f.example.com. IN MX 10 a.example.com.
- IN SIG MX ...
- AUTHORITY:
- example.com. IN NS a.example.com.
- IN NS b.example.com.
- IN SIG NS ...
- c.example.com. IN NXT sub.example.com.
- IN SIG NXT ...
- ADDITIONAL:
- a.example.com. IN A 10.10.10.1
- IN SIG A ...
- b.example.com. IN A 10.10.10.2
- IN SIG A ...
- example.com. IN KEY ...
- IN SIG KEY ...
-
- If these responses came from a recursive name server which had all of
- the necessary RRsets in its cache instead of from an authoritative
- server, the only differences would be the TTLs and the header flags.
- The AA bit would not be set, and the AD bit would be set if (and only
- if) all the RRsets in a response passed the security policy checks of
- the recursive name server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 20]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-4. Resolving
-
- Editors' note: This section is still very rough, and some of the
- text here duplicates text from other portions of this document.
- This needs to be fixed (one way or another) during final editing.
- Suggestions for better text would be welcome.
-
- This section describes the behavior of entities which include
- security-aware resolver functions. In many cases such functions will
- be part of a security-aware recursive name server, but a stand-alone
- security-aware resolver has many of the same requirements. Functions
- specific to security-aware recursive name servers are described in a
- separate subsection.
-
- A security-aware resolver MUST include an EDNS [6] OPT pseudo-RR with
- the DO [7] bit set to one when sending queries.
-
- A security-aware resolver MUST support a message size of at least
- 1220 octets, SHOULD support a message size of 4000 octets, and MUST
- advertise the supported message size using the "sender's UDP payload
- size" field in the EDNS OPT pseudo-RR. A security-aware resolver
- MUST handle fragmented UDP packets correctly regardless of whether
- any such fragmented packets were received via IPv4 or IPv6. Please
- see [8] for discussion of these requirements.
-
- A security-aware resolver MUST support the signature verification
- mechanisms described in Section 5, and MUST apply them to every
- received response except when:
-
- o The security-aware resolver is part of a security-aware recursive
- name server, and the response is the result of recursion on behalf
- of a query received with the CD bit set;
-
- o The response is the result of a query generated directly via some
- form of application interface which instructed the security-aware
- resolver not to perform validation for this query; or
-
- o Validation for this query has been disabled by local policy.
-
- A security-aware resolver's support for signature verification MUST
- include support for verification of wildcard owner names.
-
- A security-aware resolver MUST attempt to retrieve missing DS, KEY,
- or SIG RRs via explicit queries if the resolver needs these RRs in
- order to perform signature verification.
-
- A security-aware resolver MUST attempt to retrieve missing a NXT RR
- which the resolver needs to authenticate a NODATA response. In
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 21]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- general it is not possible for a resolver to retrieve missing NXT
- RRs, since the resolver will have no way of knowing the owner name of
- the missing NXT RR, but in the specific case of a NODATA response,
- the resolver does know the name of the missing NXT RR, and must
- therefore attempt to retrieve it.
-
- A security-aware resolver MUST be able to determine whether or not it
- should expect a particular RRset to be signed. More precisely, a
- security-aware resolver must be able to distinguish between three
- cases:
-
- 1. An RRset for which the resolver is able to build a chain of
- signed KEY and DS RRs from a trusted starting point to the RRset.
- In this case, the RRset should be signed, and is subject to
- signature validation as described above.
-
- 2. An RRset for which the resolver knows that it has no chain of
- signed KEY and DS RRs from any trusted starting point to the
- RRset. This can occur when the target RRset lies in an unsigned
- zone or in a descendent of an unsigned zone. In this case, the
- RRset may or may not be signed, but the resolver will not be able
- to verify the signature.
-
- 3. An RRset for which the resolver is not able to determine whether
- or not the RRset should be signed, because the resolver is not
- able to obtain the necessary DNSSEC RRs. This can occur due when
- the security-aware resolver is not able to contact security-aware
- name servers for the relevant zones.
-
- A security-aware resolver MUST be capable of being preconfigured with
- at least one trusted public key, and SHOULD be capable of being
- preconfigured with multiple trusted public keys. Since a security-
- aware resolver will not be able to validate signatures without such a
- preconfigured trusted key, the resolver SHOULD have some reasonably
- robust mechanism for obtaining such keys when it boots.
-
- Editors' note: Should support for multiple public keys be a MUST
- rather than a SHOULD?
-
- A security-aware resolver SHOULD cache each response as a single
- atomic entry, indexed by the triple <QNAME, QTYPE, QCLASS>, with the
- single atomic entry containing the entire answer, including the named
- RRset and any associated DNSSEC RRs. The resolver SHOULD discard the
- entire atomic entry when any of the RRs contained in it expire.
-
- Editors' note: This is implementation advice which came out of
- discussions at various workshops and investigations into possible
- implementation issues with the (as yet unsettled) opt-in proposal.
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 22]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- All of this advice has been discussed in WG meetings, and as far
- as the editors know these recommendations are not controversial,
- but it is up to the WG to decide whether this sort of
- implementation advice belongs in this document.
-
-
-4.1 Recursive Name Servers
-
- As explained in [9], a security-aware recursive name server is an
- entity which acts in both the security-aware name server and
- security-aware resolver roles. This section uses the terms "name
- server side" and "resolver side" to refer to the code within a
- security-aware recursive name server which implements the security-
- aware name server role and the code which implements the security-
- aware resolver role, respectively.
-
- The resolver side of a security-aware recursive name server MUST set
- the DO bit when sending requests, regardless of the state of the DO
- bit in the initiating request received by the name server side. If
- the initiating request does not have the DO bit set, the name server
- side MUST remove any DNSSEC RRs from the response sent to the
- initiating resolver, but the resolver side MUST follow the usual
- rules for caching which would apply to any security-aware resolver.
-
- A security-aware recursive name server SHOULD NOT attempt to answer a
- query by piecing together cached data it received in response to
- previous queries that requested different QNAMEs, QTYPEs, or
- QCLASSes. A security-aware recursive name server SHOULD NOT use NXT
- RRs from one negative response to synthesize a response for a
- different query. A security-aware recursive name server SHOULD NOT
- use a previous wildcard expansion to generate a response to a
- different query.
-
- Editors' note: Should any of the SHOULD NOTs in this paragraph be
- MUST NOTs instead?
-
- The name server side of a security-aware recursive name server MUST
- pass the sense of the CD bit to the resolver side along with the rest
- of an initiating query, so that the resolver side will know whether
- whether or not it is required to verify the response data it returns
- to the name server side.
-
- Editors' note: What should a security-aware recursive name server
- do if it receives a query with CD=1 and DO=0?
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 23]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-4.2 Stub resolvers
-
- A security-aware stub resolver MUST include an EDNS [6] OPT pseudo-RR
- with the DO [7] bit set to one when sending queries.
-
- A security-aware stub resolver MUST support a message size of at
- least 1220 octets, SHOULD support a message size of 4000 octets, and
- MUST advertise the supported message size using the "sender's UDP
- payload size" field in the EDNS OPT pseudo-RR. A security-aware stub
- resolver MUST handle fragmented UDP packets correctly regardless of
- whether any such fragmented packets were received via IPv4 or IPv6.
- Please see [8] for discussion of these requirements.
-
- A security-aware stub resolver MUST support the DNSSEC RR types, at
- least to the extent of not mishandling responses just because they
- contain DNSSEC RRs. A security-aware stub resolver MAY include the
- DNSSEC RRs returned by a security-aware recursive name server as part
- of the data that it the stub resolver hands back to the application
- which invoked it, but is not required to do so.
-
- A security-aware stub resolver SHOULD NOT set the CD bit when sending
- queries, since, by definition, a security-aware stub resolver does
- not validate signatures and thus depends on the security-aware
- recursive name server to perform validation on its behalf.
-
- Editors' note: Should this SHOULD NOT be a MUST NOT?
-
- A security-aware stub resolver MUST NOT place any reliance on
- signature validation allegedly performed on its behalf except when
- the security-aware stub resolver obtained the data in question from a
- trusted security-aware recursive name server via a secure channel.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 24]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-5. Authenticating DNS Responses
-
- In order to use DNSSEC RRs for authentication, a security-aware
- resolver requires preconfigured knowledge of at least one
- authenticated KEY RR. The process for obtaining and authenticating
- this initial KEY RR is achieved via some external mechanism. For
- example, a resolver could use some off-line authenticated exchange to
- obtain a zone's KEY RR or obtain a DS RR that identifies and
- authenticates a zone's KEY RR. The remainder of this section assumes
- that the resolver has somehow obtained an initial set of
- authenticated KEY RRs.
-
- An initial KEY RR can be used to authenticate a zone's apex KEY
- RRset. To authenticate an apex KEY RRset using an initial key, the
- resolver MUST:
-
- 1. Verify that the initial KEY RR appears in the apex KEY RRset, and
- verify that the KEY RR has the Zone Key Flag (KEY RDATA bit 7)
- set to one.
-
- 2. Verify that there is some SIG RR which covers the apex KEY RRset,
- and that the combination of the SIG RR and the initial KEY RR
- authenticates the KEY RRset. The process for using a SIG RR to
- authenticate an RRset is described in Section 5.2.
-
- Once the resolver has authenticated the apex KEY RRset using an
- initial KEY RR, delegations from that zone can be authenticated using
- DS RRs. This allows a resolver to start from an initial key, and use
- DS RRsets to proceed recursively down the DNS tree obtaining other
- apex KEY RRsets. If the resolver were preconfigured with a root KEY
- RR, and if every delegation had a DS RR associated with it, then the
- resolver could obtain any apex KEY RRset. The process of using DS
- RRs to authenticate referrals is described in Section 5.1.
-
- Once the resolver has authenticated a zone's apex KEY RRset, Section
- 5.2 shows how the resolver can use KEY RRs in the apex KEY RRset and
- SIG RRs from the zone to authenticate any other RRsets in the zone.
- Section 5.3 shows how the resolver can use authenticated NXT RRsets
- from the zone to prove that an RRset is not present in the zone.
-
- When a resolver indicates support for DNSSEC, a security-aware name
- server should attempt to provide the necessary KEY, SIG, NXT, and DS
- RRsets in a response (see Section 3). However, a security-aware
- resolver may still receive a response which that lacks the
- appropriate DNSSEC RRs, whether due to configuration issues such as a
- security-oblivious recursive name server which accidently interfere
- with DNSSEC RRs or due to a deliberate attack in which an adversary
- forges a response, strips DNSSEC RRs from a response, or modifies a
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 25]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- query so that DNSSEC RRs appear not to be requested. The absence of
- DNSSEC data in a response MUST NOT by itself be taken as an
- indication that no authentication information exists.
-
- A resolver SHOULD expect authentication information from signed
- zones. A resolver SHOULD believe that a zone is signed if the
- resolver has been configured with public key information for the
- zone, or if the zone's parent is signed and the delegation from the
- parent contains a DS RRset.
-
-5.1 Authenticating Referrals
-
- Once the apex KEY RRset for a signed parent zone has been
- authenticated, DS RRsets can be used to authenticate the delegation
- to a signed child zone. A DS RR identifies a KEY RR in the child
- zone's apex KEY RRset, and contains a cryptographic digest of the
- child zone's KEY RR. A strong cryptographic digest algorithm ensures
- that an adversary can not easily generate a KEY RR that matches the
- digest. Thus, authenticating the digest allows a resolver to
- authenticate the matching KEY RR. The resolver can then use this
- child KEY RR to authenticate the entire child apex KEY RRset.
-
- Given a DS RR for a delegation, the child zone's apex KEY RRset can
- be authenticated if all of the following hold:
-
- o The DS RR has been authenticated using some KEY RR in the parent's
- apex KEY RRset (see Section 5.2);
-
- o The Algorithm and Key Tag in the DS RR match the Algorithm field
- and the key tag of a KEY RR in the child zone's apex KEY RRset
- which, when hashed using the digest algorithm specified in the DS
- RR's Digest Type field, results in a digest value which matches
- the Digest field of the DS RR; and
-
- o The matching KEY RR in the child zone has the Zone Flag bit set to
- one, the corresponding private key has signed the child zone's
- apex KEY RRset, and the resulting SIG RR authenticates the child
- zone's apex KEY RRset.
-
- If the referral from the parent zone did not contain a DS RRset, the
- response should have included a signed NXT RRset proving that no DS
- RRset exists for the delegated name (see Section 3.4). A security-
- aware resolver MUST send the parent a query for the DS RRset if the
- referral includes neither a DS RRset nor a NXT RRset proving the
- nonexistence of the DS RRset (see Section 4).
-
- If the resolver authenticates an NXT RRset which proves that no DS
- RRset is present for this zone, then there is no authentication path
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 26]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- leading from the parent to the child. If the resolver has an initial
- KEY RR which belongs to the child zone or to any delegation below the
- child zone, this initial KEY RR MAY be used to re-establish an
- authentication path. If no such initial KEY RR exists, the resolver
- can not authenticate RRsets at or below the child zone.
-
- Note that, for a signed delegation, there are two NXT RRs associated
- with the delegated name. One NXT RR resides in the parent zone, and
- can be used to prove whether a DS RRset exists for the delegated
- name. The second NXT RR resides in the child zone, and identifies
- which RRsets are present at the apex of the child zone. The parent
- NXT RR and child NXT RR can always be distinguished, since the SOA
- bit will be set in the child NXT RR and clear in the parent NXT RR.
- A security-aware resolver MUST use the parent NXT RR when attempting
- to prove that a DS RRset does not exist.
-
-5.2 Authenticating an RRSet Using a SIG RR
-
- A resolver can use a SIG RR and its corresponding KEY RR to attempt
- to authenticate RRsets. The resolver first checks the SIG RR to
- verify that it covers the RRset, has a valid time interval, and
- identifies a valid KEY RR. The resolver then constructs the
- canonical form of the signed data by appending the SIG RDATA
- (excluding the Signature Field) with the canonical form of the
- covered RRset. Finally, resolver uses the public key and signature
- to authenticate the signed data. Section 5.2.1, Section 5.2.2, and
- Section 5.2.3 describe each step in detail.
-
-5.2.1 Checking the SIG RR Validity
-
- A security-aware resolver can use a SIG RR to authenticate an RRset
- if all of the following conditions hold:
-
- o The SIG RR and the RRset MUST have the same owner name and the
- same class;
-
- o The SIG RR's Signer's Name field MUST be the name of the zone that
- contains the RRset;
-
- o The SIG RR's Type Covered field MUST equal the RRset's type;
-
- o The number of labels in the RRset owner name MUST be greater than
- or equal to the value in the SIG RR's Labels field;
-
- o The resolver's notion of the current time MUST be less than or
- equal to the time listed in the SIG RR's Expiration field;
-
- o The resolver's notion of the current time MUST be greater than or
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 27]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- equal to the time listed in the SIG RR's Inception field;
-
- o The SIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
- match the owner name, algorithm, and key tag for some KEY RR in
- the zone's apex KEY RRset;
-
- o The matching KEY RR MUST be present in the zone's apex KEY RRset,
- and MUST have the Zone Flag bit (KEY RDATA Flag bit 7) set to one.
-
- It is possible for more than one KEY RR to match the conditions
- above. In this case, the resolver can not predetermine which KEY RR
- to use to authenticate the signature, MUST try each matching KEY RR
- until the resolver has either validated the signature or has run out
- of matching keys to try.
-
- Note that this authentication process is only meaningful if the
- resolver authenticates the KEY RR before using it to validate
- signatures. The matching KEY RR is considered to be authentic if:
-
- o The apex KEY RRset containing the KEY RR is considered authentic;
- or
-
- o The RRset covered by the SIG RR is the apex KEY RRset itself, and
- the KEY RR either matches an authenticated DS RR from the parent
- zone or matches a DS RR or KEY RR which the resolver has been
- preconfigured to believe to be authentic.
-
-
-5.2.2 Reconstructing the Signed Data
-
- Once the SIG RR has met the validity requirements described in
- Section 5.2.1, the resolver needs to reconstruct the original signed
- data. The original signed data includes SIG RDATA (excluding the
- Signature field) and the canonical form of the RRset. Aside from
- being ordered, the canonical form of the RRset might also differ from
- the received RRset due to DNS name compression, decremented TTLs, or
- wildcard expansion. The resolver should use the following to
- reconstruct the original signed data:
-
- signed_data = SIG_RDATA | RR(1) | RR(2)... where
-
- "|" denotes concatenation
-
- SIG_RDATA is the wire format of the SIG RDATA fields with
- the Signature field excluded and the Signer's Name in
- canonical form.
-
- RR(i) = name | class | type | OrigTTL | RDATA length | RDATA
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 28]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- name is calculated according to the function below
-
- class is the RRset's class
-
- type is the RRset type and all RRs in the class
-
- OrigTTL is the value from the SIG Original TTL field
-
- All names in the RDATA field are in canonical form
-
- The set of all RR(i) is sorted into canonical order.
-
- To calculate the name:
- let sig_labels = the value of the SIG Labels field
-
- let fqdn = RRset's fully qualified domain name in
- canonical form
-
- let fqdn_labels = RRset's fully qualified domain name in
- canonical form
-
- if sig_labels = fqdn_labels,
- name = fqdn
-
- if sig_labels < fqdn_labels,
- name = "*." | the leftmost sig_label labels of the
- fqdn
-
- if sig_labels > fqdn
- the SIG RR did not pass the necessary validation
- checks and MUST NOT be used to authenticate this
- RRset.
-
- Editors' note: The algorithm above needs to be cross-checked very
- carefully against the definitions in [10].
-
- Section 5.4.1 gives an example of original name calculation. The
- canonical forms for names and RRsets are defined in [10].
-
- NXT RRsets at a delegation boundary require special processing.
- There are two distinct NXT RRsets associated with a signed delegated
- name. One NXT RRset resides in the parent zone, and specifies which
- RRset are present at the parent zone. The second NXT RRset resides
- at the child zone, and identifies which RRsets are present at the
- apex in the child zone. The parent NXT RRset and child NXT RRset can
- always be distinguished since only the child NXT RRs will specify an
- SOA RRset exists at the name. When reconstructing the original NXT
- RRset for the delegation from the parent zone, the NXT RRs MUST NOT
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 29]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- be combined with NXT RRs from the child zone, and when reconstructing
- the original NXT RRset for the apex of the child zone, the NXT RRs
- MUST NOT be combined with NXT RRs from the parent zone.
-
- Note also that each of the two NXT RRsets at a delegation point has a
- corresponding SIG RR with an owner name matching the delegated name,
- and each of these SIG RRs is authoritative data associated with the
- same zone which contains the corresponding NXT RRset. If necessary,
- a resolver can tell these SIG RRs apart by checking the Signer's Name
- field.
-
-5.2.3 Checking the Signature
-
- Once the resolver has validated the SIG RR as described in Section
- 5.2.1 and reconstructed the original signed data as described in
- Section 5.2.2, the resolver can attempt to use the cryptographic
- signature to authenticate the signed data, and thus (finally!)
- authenticate the RRset.
-
- The Algorithm field in the SIG RR identifies the cryptographic
- algorithm to generate the signature. The signature itself is
- contained in the Signature field of the SIG RDATA, and the public key
- to used generate the signature is contained in the Public Key field
- of the matching KEY RR(s) (found in Section 5.2.1). [10] provides a
- list of algorithm types, and provides pointers to the documents that
- define each algorithm's use.
-
- Note that it is possible for more than one KEY RR to match the
- conditions in Section 5.2.1. In this case, the resolver can only
- determine which KEY RR by trying each matching key until the resolver
- either succeeds in validating the signature or runs out of keys to
- try.
-
- If the Labels field of the SIG RR is not equal to the number of
- labels in the RRset's fully qualified owner name, then the RRset is
- either invalid or the result of wildcard expansion. The resolver
- MUST verify that wildcard expansion was applied properly before
- considering the RRset to be authentic. Section 5.2.4 describes how
- to determine whether a wildcard was applied properly.
-
- If other SIG RRs also cover this SIG RR, the local resolver security
- policy determines whether the resolver also needs to test these SIG
- RRs, and determines how to resolve conflicts if these SIG RRs lead to
- differing results.
-
- If the resolver accepts the RRset as authentic, the resolver MUST set
- the SIG RR's TTL and the TTL of each RR in the authenticated RRset to
- the minimum of:
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 30]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- o The RRset's TTL as received in the response;
-
- o The SIG RR's TTL as received in the response; and
-
- o The value in the SIG RR's Original TTL field.
-
-
-5.2.4 Authenticating A Wildcard Expanded RRset Positive Response
-
- If the number of labels in an RRset's fully qualified domain name is
- greater than the Labels field in the covering SIG RDATA, then the
- RRset and its covering SIG RR were created as a result of wildcard
- expansion. Once the resolver has verified the signature as described
- in Section 5.2, the resolver must take additional steps to verify the
- non-existence of an exact match or closer wildcard match for the
- query. Section 5.3 discusses these steps.
-
- Note that the response received by the resolver should include all
- NXT RRs needed to authenticate the response (see Section 3.3).
-
-5.3 Authenticated Denial of Existence
-
- A resolver can use authenticated NXT RRs to prove that an RRset is
- not present in a signed zone. Security-aware name servers should
- automatically include any necessary NXT RRs for signed zones in their
- responses to security-aware resolvers.
-
- Security-aware resolvers MUST first authenticate NXT RRsets according
- to the standard RRset authentication rules described in Section 5.2,
- then apply the NXT RRsets as follows:
-
- o If the requested RR name matches the owner name of an
- authenticated NXT RR, then the NXT RR's type bit map field lists
- all RR types present at that owner name, and a resolver can prove
- that the requested RR type does not exist by checking for the RR
- type in the bit map. Since the existence of the authenticated NXT
- RR proves that the owner name exists in the zone, wildcard
- expansion could not have been used to match the requested RR owner
- name and type.
-
- o If the requested RR name would appear after an authenticated NXT
- RR owner name and before the name listed in that NXT RR's Next
- Domain Name field according to the canonical DNS name order
- defined in [10], then no exact match for the requested RR name
- exists in the zone. However, it is possible that a wildcard could
- be used to match the requested RR owner name and type, so proving
- that the requested RRset does not exist also requires proving that
- no possible wildcard exists which could have been used to generate
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 31]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- a positive response.
-
- To prove non-existence of an RRset, the resolver must be able to
- verify both that the queried RRset does not exist and that no
- relevant wildcard RRset exists. Proving this may require more than
- one NXT RRset from the zone. If the complete set of necessary NXT
- RRsets is not present in a response (perhaps due to truncation), then
- a security-aware resolver MUST resend the query in order to attempt
- to obtain the full collection of NXT RRs necessary to verify non-
- existence of the requested RRset. As with all DNS operations,
- however, the resolver MUST bound the work it puts into answering any
- particular query.
-
-5.4 Example
-
-5.4.1 Example of Re-Constructing the Original Owner Name
-
- Suppose that a security-aware resolver receives a response containing
- an answer RRset with an owner name of is "www.a.b.c.example.com".
- This fully qualified domain name has 6 labels: "www", "a", "b", "c",
- "example", and "com". What name the resolver should use when
- reconstructing the original signed data depends on the value of the
- SIG RR's Labels field.
-
- If the value of the SIG RR's Labels field is 6, then the SIG RR's
- Labels field matches the number of labels in the owner name, and the
- resolver should assume that this RRset is not the result of wildcard
- expansion. The resolver should therefore use "www.a.b.c.example.com"
- as the owner name when reconstructing the original signed data for
- the signature check.
-
- If the value of the SIG RR's Labels field is less than 6, then the
- SIG RR's Labels count is less than the number of labels in the
- RRset's owner name, and the resolver should assume that this RRset is
- the result of wildcard expansion. The resolver should therefore
- reconstruct the original owner name by replacing the labels which
- appear to be the result of wildcard expansion with a single "*."
- label. For example, if the SIG RR's Labels field is 3, the resolver
- should reconstruct the original owner name by prepending "*." to the
- last 3 labels of the owner name of the answer RRset. Thus, the
- resolver should use "*.c.example.com" as the owner name when
- reconstructing the original signed data.
-
- If the value of the SIG RR's Labels field is greater than 6, then
- this SIG RR cannot possibly be valid for the answer RRset, and there
- is no point in attempting to validate the signature.
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 32]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-5.4.2 Examples of Authenticating a Response
-
- Editors' note: Eventually this will be an example of the
- authentication process for "www.example.com", starting from an
- initial root key.
-
- Editors' note: Eventually this will be an example of the
- authentication process for non-existent "www.a.b.c.example.com",
- starting from an initial root key.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 33]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-6. IANA Considerations
-
- This document introduces no IANA considerations.
-
- [10] contains a complete review of the IANA considerations introduced
- by DNSSEC.
-
- Editors' note: This may not be true anymore, since the AD and CD
- bit definitions are now in this document rather than in [10].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 34]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-7. Security Considerations
-
- This document describes how the DNS security extensions use public
- key cryptography to sign and authenticate DNS resource record sets.
-
- At this time, at least two substantial elements of the DNSSEC
- specification have yet to be decided by the working group. The open
- opt-in issue would change elements such as what RRsets must be
- signed, would impact how wildcards are used, and would replace
- authenticated denial of existence with authenticated denial of
- security. Handling of the AD bit is also undecided. The AD bit (as
- currently defined) is used to indicate the security status of RRsets
- in the response. These items clearly raise security considerations
- and will be addressed here as these issues are resolved in the
- working group.
-
- DNSSEC introduces a number of denial of service issues. These issues
- will also be addressed in a future version of these security
- considerations.
-
- Please see [9] for general security considerations related to DNSSEC.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 35]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-8. Acknowledgements
-
- This document was created from the input and ideas of several members
- of the DNS Extensions Working Group and working group mailing list.
- The co-authors of this draft would like to express their thanks for
- the comments and suggestions received during the revision of these
- security extension specifications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 36]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-Normative References
-
- [1] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
- August 1996.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [5] Elz, R. and R. Bush, "Clarifications to the DNS Specification",
- RFC 2181, July 1997.
-
- [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
- [7] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
- December 2001.
-
- [8] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
- message size requirements", RFC 3226, December 2001.
-
- [9] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "DNS Security Introduction and Requirements", draft-ietf-
- dnsext-dnssec-intro-05 (work in progress), February 2003.
-
- [10] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "Resource Records for DNS Security Extensions", draft-ietf-
- dnsext-dnssec-records-04 (work in progress), February 2003.
-
- [11] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft-
- ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 37]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-Informative References
-
- [12] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [13] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
- 2930, September 2000.
-
- [14] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [15] Gudmundsson, O., "Delegation Signer Resource Record", draft-
- ietf-dnsext-delegation-signer-12 (work in progress), December
- 2002.
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: mlarson@verisign.com
-
-
- Rob Austein
- Internet Software Consortium
- 40 Gavin Circle
- Reading, MA 01867
- USA
-
- EMail: sra@isc.org
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 38]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
- Dan Massey
- USC Information Sciences Institute
- 3811 N. Fairfax Drive
- Arlington, VA 22203
- USA
-
- EMail: masseyd@isi.edu
-
-
- Scott Rose
- National Institute for Standards and Technology
- 100 Bureau Drive
- Gaithersburg, MD 20899-8920
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 39]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-Appendix A. Algorithm For Handling Wildcard Expansion
-
- For zone (Z) and a name (N) that may occur in Z, the following
- algorithm finds all wildcard RRsets that match N or returns an NXT
- RRset that proves no wildcard expansion matches N. The algorithm was
- written for clarity, not efficiency:
-
- 0. INPUT: a name (N) and a zone (Z).
- INIT: NXT_SET = NULL
-
- 1. Construct S = sequence of all names in Z, sorted
- into canonical order.
-
- 2. If N exists in S
- There is an exact match for N.
- Return all RRsets associated with N
- Else
- Add the name that would immediately
- precede N in S to NXT_SET.
- EndIf
-
- 3. Replace the leftmost label of N with *
-
- 4. If N exists in S
- There is a positive wildcard match for N.
- Return all RRsets associated with N
- Else
- Add the NXT for name that would immediately
- precede N in S to NXT_SET.
- EndIf
-
- 5. Remove the leading * from N.
-
- 6. If N exists in S
- There is a name that terminates the wildcard search.
- Add the NXT for N to NXT_SET and return NXT_SET.
- Else
- Goto Step 3
- EndIf
-
- Note: the algorithm is guaranteed to terminate since
- eventually there will be a match or N will be
- reduced to zone name itself and the zone name
- must exist in S.
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 40]
-\f
-Internet-Draft DNSSEC Protocol Modifications March 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires September 1, 2003 [Page 41]
-\f
+++ /dev/null
-
-
-DNS Extensions R. Arends
-Internet-Draft Telematica Instituut
-Expires: August 26, 2003 R. Austein
- ISC
- M. Larson
- VeriSign
- D. Massey
- USC/ISI
- S. Rose
- NIST
- February 25, 2003
-
-
- Resource Records for the DNS Security Extensions
- draft-ietf-dnsext-dnssec-records-03
-
-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.
-
- This Internet-Draft will expire on August 26, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document is part of a family of documents that describes the DNS
- Security Extensions (DNSSEC). The DNS Security Extensions are a
- collection of resource records and protocol modifications that
- provide source authentication for the DNS. This document defines the
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 1]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- KEY, DS, SIG, and NXT resource records. The purpose and format of
- each resource record is described in detail and an example of each
- resource record is given.
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1 Background and Related Documents . . . . . . . . . . . . . . 4
- 1.2 Reserved Words . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3 Editors Notes . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3.1 Open Technical Issues . . . . . . . . . . . . . . . . . . . 4
- 1.3.2 Technical Changes or Corrections . . . . . . . . . . . . . . 4
- 1.3.3 Typos and Minor Corrections . . . . . . . . . . . . . . . . 5
- 2. The KEY Resource Record . . . . . . . . . . . . . . . . . . 6
- 2.1 KEY RDATA Wire Format . . . . . . . . . . . . . . . . . . . 6
- 2.1.1 The Flags Field . . . . . . . . . . . . . . . . . . . . . . 6
- 2.1.2 The Protocol Field . . . . . . . . . . . . . . . . . . . . . 7
- 2.1.3 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 7
- 2.1.4 The Public Key Field . . . . . . . . . . . . . . . . . . . . 7
- 2.1.5 Notes on KEY RDATA Design . . . . . . . . . . . . . . . . . 7
- 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . . 7
- 2.3 KEY RR Example . . . . . . . . . . . . . . . . . . . . . . . 7
- 3. The SIG Resource Record . . . . . . . . . . . . . . . . . . 9
- 3.1 SIG RDATA Wire Format . . . . . . . . . . . . . . . . . . . 9
- 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . . 10
- 3.1.2 The Algorithm Number Field . . . . . . . . . . . . . . . . . 10
- 3.1.3 The Labels Field . . . . . . . . . . . . . . . . . . . . . . 10
- 3.1.4 Original TTL Field . . . . . . . . . . . . . . . . . . . . . 11
- 3.1.5 Signature Expiration and Inception Fields . . . . . . . . . 11
- 3.1.6 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 11
- 3.1.7 The Signer's Name Field . . . . . . . . . . . . . . . . . . 11
- 3.1.8 The Signature Field . . . . . . . . . . . . . . . . . . . . 12
- 3.2 The SIG RR Presentation Format . . . . . . . . . . . . . . . 12
- 3.3 SIG RR Example . . . . . . . . . . . . . . . . . . . . . . . 13
- 4. The NXT Resource Record . . . . . . . . . . . . . . . . . . 15
- 4.1 NXT RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15
- 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 15
- 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . . 15
- 4.1.3 Inclusion of Wildcard Names in NXT RDATA . . . . . . . . . . 16
- 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . . 16
- 4.3 NXT RR Example . . . . . . . . . . . . . . . . . . . . . . . 16
- 5. The DS Resource Record . . . . . . . . . . . . . . . . . . . 18
- 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . . 18
- 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . . 18
- 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . . 19
- 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . . 19
- 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . . 19
- 5.2 The DS RR Presentation Format . . . . . . . . . . . . . . . 19
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 2]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- 5.3 DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 20
- 6. Canonical Form and Order of Resource Records . . . . . . . . 21
- 6.1 Canonical DNS Name Order . . . . . . . . . . . . . . . . . . 21
- 6.2 Canonical RR Form . . . . . . . . . . . . . . . . . . . . . 21
- 6.3 Canonical RR Ordering Within An RRset . . . . . . . . . . . 22
- 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 23
- 8. Security Considerations . . . . . . . . . . . . . . . . . . 24
- 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 25
- Normative References . . . . . . . . . . . . . . . . . . . . 26
- Informative References . . . . . . . . . . . . . . . . . . . 27
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
- A. DNSSEC Algorithm and Digest Types . . . . . . . . . . . . . 29
- A.1 DNSSEC Algorithm Types . . . . . . . . . . . . . . . . . . . 29
- A.1.1 Private Algorithm Types . . . . . . . . . . . . . . . . . . 29
- A.2 DNSSEC Digest Types . . . . . . . . . . . . . . . . . . . . 30
- B. Key Tag Calculation . . . . . . . . . . . . . . . . . . . . 31
- B.1 Key Tag for Algorithm 1 (RSA/MD5) . . . . . . . . . . . . . 32
- Full Copyright Statement . . . . . . . . . . . . . . . . . . 33
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 3]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-1. Introduction
-
- The DNS Security Extensions (DNSSEC) introduce four new DNS resource
- record types: KEY, SIG, NXT, and DS. This document defines the
- purpose of each resource record (RR), the RR's RDATA format, and its
- ASCII representation.
-
-1.1 Background and Related Documents
-
- The reader is assumed to be familiar with the basic DNS concepts
- described in RFC1034 [1] and RFC1035 [2].
-
- This document is part of a family of documents that define the DNS
- security extensions. The DNS security extensions (DNSSEC) are a
- collection of resource records and DNS protocol modifications that
- add source authentication the Domain Name System (DNS). An
- introduction to DNSSEC and definition of common terms can be found in
- [10]. A description of DNS protocol modifications can be found in
- [11]. This document defines the DNSSEC resource records.
-
-1.2 Reserved Words
-
- 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 [5].
-
-1.3 Editors Notes
-
-1.3.1 Open Technical Issues
-
- The NXT section (Section 4) may be updated in the next version if
- DNSSEC-Opt-In [13] becomes part of DNSSEC.
-
- The cryptographic algorithm types (Appendix A) requires input from
- the working group. The DSA algorithm was moved to OPTIONAL. This
- had strong consensus in workshops and various discussions and a
- separate internet draft solely to move DSA from MANDATORY to OPTIONAL
- seemed excessive. This draft solicits input on that proposed change.
-
-1.3.2 Technical Changes or Corrections
-
- Please report technical corrections to dnssec-editors@east.isi.edu.
- To assist the editors, please indicate the text in error and point
- out the RFC that defines the correct behavior. For a technical
- change where no RFC that defines the correct behavior, or if there's
- more than one applicable RFC and the definitions conflict, please
- post the issue to namedroppers.
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 4]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- An example correction to dnssec-editors might be: Page X says
- "DNSSEC RRs SHOULD be automatically returned in responses." This was
- true in RFC 2535, but RFC 3225 (Section 3, 3rd paragraph) says the
- DNSSEC RR types MUST NOT be included in responses unless the resolver
- indicated support for DNSSEC.
-
-1.3.3 Typos and Minor Corrections
-
- Please report any typos corrections to dnssec-editors@east.isi.edu.
- To assist the editors, please provide enough context for us to find
- the incorrect text quickly.
-
- An example message to dnssec-editors might be: page X says "the
- DNSSEC standard has been in development for over 1 years". It
- should read "over 10 years".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 5]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-2. The KEY Resource Record
-
- DNSSEC uses public key cryptography to sign and authenticate DNS
- resource record sets (RRsets). The public keys are stored in KEY
- resource records and are used in the DNSSEC authentication process
- described in [11]. In a typical example, a zone signs its
- authoritative RRsets using a private key and stores the corresponding
- public key in a KEY RR. A resolver can then use these signatures to
- authenticate RRsets from the zone.
-
- The KEY RR may also be used to store public keys associated with
- other DNS operations such as TKEY [15]. In all cases, the KEY RR
- plays a special role in secure DNS resolution and DNS message
- processing. The KEY RR is not intended as a record for storing
- arbitrary public keys. The KEY RR MUST NOT be used to store
- certificates or public keys that do not directly relate to the DNS
- infrastructure. Examples of certificates and public keys that MUST
- NOT be stored in the KEY RR include X.509 certificates, IPSEC public
- keys, and SSH public keys.
-
- The Type value for the KEY RR type is 25.
-
- The KEY RR is class independent.
-
- There are no special TTL requirements on the KEY record.
-
-2.1 KEY RDATA Wire Format
-
- The RDATA for a KEY RR consists of a 2 octet Flags Field, a 1 octet
- Protocol Field, a 1 octet Algorithm Field , and the Public Key Field.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Flags | Protocol | Algorithm |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / /
- / Public Key /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-2.1.1 The Flags Field
-
- Bit 7 of the Flags field is the Zone Key flag. If bit 7 has value 1,
- then the KEY record holds a DNS zone key and the KEY's owner name
- MUST be the name of a zone. If bit 7 has value 0, then the KEY
- record holds some other type of DNS public key, such as a public key
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 6]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- used by TKEY.
-
- Bits 0-6 and 8-15 are reserved and MUST have value 0 upon creation of
- the KEY RR, and MUST be ignored upon reception.
-
- Editors' Note: draft-ietf-dnsext-keyrr-key-signing-flag changes this
- by allocating bit 15 as the KSK bit.
-
-2.1.2 The Protocol Field
-
- The Protocol Field MUST have value 3.
-
-2.1.3 The Algorithm Field
-
- The Algorithm field identifies the public key's cryptographic
- algorithm and determines the format of the Public Key field. A list
- of DNSSEC algorithm types can be found in Appendix A.1
-
-2.1.4 The Public Key Field
-
- The Public Key Field holds the public key material.
-
-2.1.5 Notes on KEY RDATA Design
-
- Although the Protocol Field always has value 3, it is retained for
- backward compatibility with an earlier version of the KEY record.
-
-2.2 The KEY RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Flag field is represented as an unsigned decimal integer with a
- value of either 0 or 256.
-
- The Protocol Field is represented as an unsigned decimal integer with
- a value of 3.
-
- The Algorithm field is represented either as an unsigned decimal
- integer or as an algorithm mnemonic as specified in Appendix A.1.
-
- The Public Key field is represented as a Base64 encoding of the
- Public Key. Whitespace is allowed within the Base64 text. For a
- definition of Base64 encoding, see [3] Section 5.2.
-
-2.3 KEY RR Example
-
- The following KEY RR stores a DNS zone key for example.com.
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 7]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- example.com. 86400 IN KEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3Cbl
- +BBZH4b/0PY1kxkmvHjcZc8nokfzj31
- GajIQKY+5CptLr3buXA10hWqTkF7H6R
- foRqXQeogmMHfpftf6zMv1LyBUgia7z
- a6ZEzOJBOztyvhjL742iU/TpPSEDhm2
- SNKLijfUppn1UaNvv4w== )
-
- The first four text fields specify the owner name, TTL, Class, and RR
- type (KEY). Value 256 indicates that the Zone Key bit (bit 7) in the
- Flags field has value 1. Value 3 is the fixed Protocol value. Value
- 5 indicates the public key algorithm. Appendix A.1 identifies
- algorithm type 5 as RSA/SHA1 and indicates that the format of the
- RSA/SHA1 public key field is defined in [8]. The remaining text is a
- base 64 encoding of the public key.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 8]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-3. The SIG Resource Record
-
- DNSSEC uses public key cryptography to sign and authenticate DNS
- resource record sets (RRsets). Signatures are stored in SIG resource
- records and are used in the DNSSEC authentication process described
- in [11]. In a typical example, a zone signs its authoritative RRsets
- using a private key and stores the corresponding signatures in SIG
- RRs. A resolver can then use these SIG RRs to authenticate RRsets
- from the zone.
-
- A SIG record contains the signature for an RRset with a particular
- name, class, and type. The SIG RR specifies a validity interval for
- the signature and uses the Algorithm, the Signer's Name, and the Key
- Tag to identify the public key (KEY RR) that can be used to verify
- the signature.
-
- The SIG RR may cover a transaction instead of an RRset. In this
- case, the "Type Covered" field value is 0, the SIG RR MUST NOT appear
- in any zone, and its use and processing are outside the scope of this
- document. Please see [7] for further details.
-
- The Type value for the SIG RR type is 24.
-
- The SIG RR MUST have the same class as the RRset it covers.
-
- The SIG RR TTL value SHOULD match the TTL value of the RRset it
- covers.
-
-3.1 SIG RDATA Wire Format
-
- The RDATA for a SIG RR consists of a 2 octet Type Covered field, a 1
- octet Algorithm field, a 1 octet Labels field, a 4 octet Original TTL
- field, a 4 octet Signature Expiration field, a 4 octet Signature
- Inception field, a 2 octet Key tag, the Signer's Name field, and the
- Signature field.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type Covered | Algorithm | Labels |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Original TTL |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Signature Expiration |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Signature Inception |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Key Tag | /
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 9]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Signer's Name /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / /
- / Signature /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-3.1.1 The Type Covered Field
-
- The Type Covered field identifies the type of the RRset which is
- covered by this SIG record.
-
- If Type Covered field has a value of 0, the record is referred to as
- a transaction signature; please see [7] for further details.
-
-3.1.2 The Algorithm Number Field
-
- The Algorithm Number field identifies the cryptographic algorithm
- used to create the signature. A list of DNSSEC algorithm types can
- be found in Appendix A.1
-
-3.1.3 The Labels Field
-
- The Labels field specifies the number of labels in the original SIG
- RR owner name. It is included to handle signatures associated with
- wildcard owner names.
-
- To validate a signature, the validator requires the original owner
- name that was used when the signature was created. If the original
- owner name contains a wildcard label ("*"), the owner name may have
- been expanded by the server during the response process, in which
- case the validator will need to reconstruct the original owner name
- in order to validate the signature. [11] describes how to use the
- Labels field to reconstruct the original owner name.
-
- The value of the Label field MUST NOT count either the null (root)
- label that terminates the owner name or the wildcard label (if
- present). The value of the Label field MUST be less than or equal to
- the number of labels in the SIG owner name. For example,
- "www.example.com." has a Label field value of 3, and "*.example.com."
- has a Label field value of 2. Root (".") has a Label field value of
- 0.
-
- Note that, although the wildcard label is not included in the count
- stored in the Label field of the SIG RR, the wildcard label is part
- of the RRset's owner name when generating or verifying the signature.
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 10]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-3.1.4 Original TTL Field
-
- The Original TTL field specifies the TTL of the covered RRset as it
- appears in the authoritative zone.
-
- The Original TTL field is necessary because a caching resolver
- decrements the TTL value of a cached RRset. In order to validate a
- signature, a resolver requires the original TTL. [11] describes how
- to use the Original TTL field value to reconstruct the original TTL.
-
- The Original TTL value MUST be greater than or equal to the TTL value
- of the SIG record itself.
-
-3.1.5 Signature Expiration and Inception Fields
-
- The Signature Expiration and Inception fields specify a validity
- period for the signature. The SIG record MUST NOT be used for
- authentication prior to the inception date and MUST NOT be used for
- authentication after the expiration date.
-
- Signature Expiration and Inception field values are in POSIX.1 time
- format, a 32-bit unsigned number of seconds elapsed since 1 January
- 1970 00:00:00 UTC, ignoring leap seconds, in network byte order. The
- longest interval which can be expressed by this format without
- wrapping is approximately 136 years. A SIG RR can have an Expiration
- field value which is numerically smaller than the Inception field
- value if the expiration field value is near the 32-bit wrap-around
- point or if the signature is long lived. Because of this, all
- comparisons involving these fields MUST use "Serial number
- arithmetic" as defined in [4]. As a direct consequence, the values
- contained in these fields cannot refer to dates more than 68 years in
- either the past or the future.
-
-3.1.6 The Key Tag Field
-
- The Key Tag field contains the key tag value of the KEY RR that
- validates this signature. The process of calculating the Key Tag
- value is given in Appendix B.
-
-3.1.7 The Signer's Name Field
-
- The Signer's Name field value identifies the owner name of the KEY RR
- used to authenticate this signature. The Signer's Name field MUST
- contain the name of the zone of the covered RRset, unless the Type
- Covered field value is 0. A sender MUST NOT use DNS name compression
- on the Signer's Name field when transmitting a SIG RR. A receiver
- which receives a SIG RR containing a compressed Signer's Name field
- SHOULD decompress the field value.
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 11]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-3.1.8 The Signature Field
-
- The Signature field contains the cryptographic signature which covers
- the SIG RDATA (excluding the Signature field) and the RRset specified
- by the SIG owner name, SIG class, and SIG Type Covered field.
-
-3.1.8.1 Signature Calculation
-
- A signature covers the SIG RDATA (excluding the Signature Field) and
- covers the RRset specified by the SIG owner name, SIG class, and SIG
- Type Covered field. The RRset is in canonical form (see Section 6)
- and the set RR(1),...RR(n) is signed as follows:
-
- signature = sign(SIG_RDATA | RR(1) | RR(2)... ) where
-
- "|" denotes concatenation;
-
- SIG_RDATA is the wire format of the SIG RDATA fields with
- the Signer's Name field in canonical form and
- the Signature field excluded;
-
- RR(i) = owner | class | type | TTL | RDATA length | RDATA;
-
- "owner" is the fully qualified owner name of the RRset in
- canonical form (for RRs with wildcard owner names, the
- wildcard label is included in the owner name);
-
- Each RR MUST have the same owner name as the SIG RR;
-
- Each RR MUST have the same class as the SIG RR;
-
- Each RR in the RRset MUST have the RR type listed in the
- SIG RR's Type Covered field;
-
- Each RR in the RRset MUST have the TTL listed in the SIG
- Original TTL Field;
-
- Any DNS names in the RDATA field of each RR MUST be in
- canonical form; and
-
- The RRset MUST be sorted in canonical order.
-
-
-3.2 The SIG RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Type Covered field value is represented either as an unsigned
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 12]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- decimal integer or as the mnemonic for the covered RR type.
-
- The Algorithm field value is represented either as an unsigned
- decimal integer or as an algorithm mnemonic as specified in Appendix
- A.1.
-
- The Labels field value is represented as an unsigned decimal integer.
-
- The Original TTL field value is represented as an unsigned decimal
- integer.
-
- The Signature Inception Time and Expiration Time field values are
- represented in the form YYYYMMDDHHmmSS in UTC, where:
-
- YYYY is the year (0000-9999, but see Section 3.1.5);
-
- MM is the month number (01-12);
-
- DD is the day of the month (01-31);
-
- HH is the hour in 24 hours notation (00-23);
-
- mm is the minute (00-59);
-
- SS is the second (00-59).
-
- The Key Tag field is represented as an unsigned decimal integer.
-
- The Signer's Name field value is represented as a fully qualified
- domain name.
-
- The Signature field is represented as a Base64 encoding of the
- signature. Whitespace is allowed within the Base64 text. For a
- definition of Base64 encoding see [3] Section 5.2.
-
-3.3 SIG RR Example
-
- The following a SIG RR stores the signature for the A RRset of
- host.example.com:
-
- host.example.com. 86400 IN SIG A 5 3 86400 20030322173103 (
- 20030220173103 2642 example.com.
- oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
- PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
- B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
- GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
- J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 13]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- The first four fields specify the owner name, TTL, Class, and RR type
- (SIG). The "A" represents the Type Covered field. The value 5
- identifies the Algorithm used (RSA-SHA1) to create the signature.
- The value 3 is the number of Labels in the original owner name. The
- value 86400 in the SIG RDATA is the Original TTL for the covered A
- RRset. 20030322173103 and 20030220173103 are the expiration and
- inception dates, respectively. 2642 is the Key Tag, and example.com.
- is the Signer's Name. The remaining text is a Base64 encoding of the
- signature.
-
- Note that combination of SIG RR owner name, class, and Type Covered
- indicate that this SIG covers the "host.example.com" A RRset. The
- Label value of 3 indicates that no wildcard expansion was used. The
- Algorithm, Signer's Name, and Key Tag indicate this signature can be
- authenticated using an example.com zone KEY RR whose algorithm is 5
- and key tag is 2642.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 14]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-4. The NXT Resource Record
-
- The NXT resource record lists two separate things: the owner name of
- the next authoritative RRset in the canonical ordering of the zone,
- and the set of RR types present at the NXT RR's owner name. The
- complete set of NXT RRs in a zone both indicate which authoritative
- RRsets exist in a zone and also form a chain of authoritative owner
- names in the zone. This information is used to provide authenticated
- denial of existence for DNS data, as described in [11].
-
- The type value for the NXT RR is 30.
-
- The NXT RR is class independent.
-
-4.1 NXT RDATA Wire Format
-
- The RDATA of the NXT RR is as shown below:
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / Next Domain Name /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / Type Bit Map /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-4.1.1 The Next Domain Name Field
-
- The Next Domain Name field contains the owner name of the next
- authoritative RRset in the canonical ordering of the zone; see
- Section 6.1 for an explanation of canonical ordering. The value of
- the Next Domain Name field in the last NXT record in the zone is the
- name of the zone apex (the owner name name of the zone's SOA RR).
-
- A sender MUST NOT use DNS name compression on the Next Domain Name
- field when transmitting an NXT RR. A receiver which receives an NXT
- RR containing a compressed Next Domain Name field SHOULD decompress
- the field value.
-
- Owner names of non-authoritative RRsets (such as glue records) MUST
- NOT be listed in the Next Domain Name unless at least one
- authoritative RRset exists at the same owner name.
-
-4.1.2 The Type Bit Map Field
-
- The Type Bit Map field identifies the RRset types which exist at the
- NXT RR's owner name.
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 15]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- Each bit in the Type Bit Map field corresponds to an RR type. Bit 1
- corresponds to RR type 1 (A), bit 2 corresponds to RR type 2 (NS),
- and so forth. If a bit is set to 1, it indicates that an RRset of
- that type is present for the NXT's owner name. If a bit is set to 0,
- it indicates that no RRset of that type present for the NXT's owner
- name.
-
- Bit 1 MUST NOT indicate glue address records.
-
- Bit 41 MUST have the value of 0, since the OPT pseudo-RR [6] can
- never appear in zone data.
-
- Trailing zero octets MUST be omitted. The length of the Type Bit Map
- field varies, and is determined by the type code with the largest
- numerical value among the set of RR types present at the NXT RR's
- owner name. Trailing zero octets not specified MUST be interpreted
- as zero octets.
-
- The above Type Bit Map format MUST NOT be used when an RR type code
- with numerical value greater than 127 is present.
-
- Bit 0 in the Type Bit Map field indicates the Type Bit Map format. A
- value of 0 in bit 0 denotes the format described above, therefore bit
- 0 MUST have a value of 0. The format and meaning of a Type Bit Map
- with a value of 1 in bit 0 is undefined.
-
-4.1.3 Inclusion of Wildcard Names in NXT RDATA
-
- If a wildcard owner name appears in a zone, the wildcard label ("*")
- is treated as a literal symbol and is treated the same as any other
- owner name for purposes of generating NXT RRs. Wildcard owner names
- appear in the Next Domain Name field without any wildcard expansion.
- [11] describes the impact of wildcards on authenticated denial of
- existence.
-
-4.2 The NXT RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Next Domain Name field is represented as a domain name.
-
- The Type Bit Map field is represented either as a sequence of RR type
- mnemonics or as a sequence of unsigned decimal integers denoting the
- RR type codes.
-
-4.3 NXT RR Example
-
- The following NXT RR identifies the RRsets associated with
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 16]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- alfa.example.com. and identifies the next authoritative name after
- alfa.example.com.
-
- alfa.example.com. 86400 IN NXT host.example.com. A MX SIG NXT
-
- The first four text fields specify the name, TTL, Class, and RR type
- (NXT). The entry host.example.com. is the next authoritative name
- after alfa.example.com. (in canonical order). The A, MX, SIG and
- NXT mnemonics indicate there are A, MX, SIG and NXT RRsets associated
- with the name alfa.example.com.
-
- Note the NXT record can be used for authenticated denial of
- existence. If the example NXT record were authenticated, it could be
- used to prove that beta.example.com. does not exist, or could be
- used to prove there is no AAAA record associated with
- alfa.example.com. Authenticated denial of existence is discussed in
- [11]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 17]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-5. The DS Resource Record
-
- The DS Resource Record refers to a KEY RR and is used in the DNS KEY
- authentication process. A DS RR refers to a KEY RR by storing the
- key tag, algorithm number, and a digest of KEY RR. Note that while
- the digest should be sufficient to identify the key, storing the key
- tag and key algorithm helps make the identification process more
- efficient. By authenticating the DS record, a resolver can
- authenticate the KEY RR to which the DS record points. The key
- authentication process is described in [11].
-
- The DS RR and its corresponding KEY RR have the same owner name, but
- they are stored in different locations. The DS RR appears only on
- the upper (parental) side of a delegation, and is authoritative data
- in the parent zone. For example, the DS RR for "example.com" is
- stored in the "com" zone (the parent zone) rather than in the
- "example.com" zone (the child zone). The corresponding KEY RR is
- stored in the "example.com" zone (the child zone). This simplifies
- DNS zone management and zone signing, but introduces special response
- processing requirements for the DS RR; these are described in [11].
-
- The type number for the DS record is 43.
-
- The DS resource record is class independent.
-
- There are no special TTL requirements on the DS resource record.
-
-5.1 DS RDATA Wire Format
-
- The RDATA for a DS RR consists of 2 octet Key Tag field, a one octet
- Algorithm field, a one octet Digest Type field, and a Digest field.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Key Tag | Algorithm | Digest Type |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / /
- / Digest /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-5.1.1 The Key Tag Field
-
- The Key Tag field lists the key tag of the KEY RR referred to by the
- DS record. The KEY RR MUST be a zone key. The KEY RR Flags MUST
- have Flags bit 7 set to value 1.
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 18]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- The Key Tag used by the DS RR is identical to the Key Tag used by the
- SIG RR and Appendix B describes how to compute a Key Tag.
-
-5.1.2 The Algorithm Field
-
- The Algorithm field lists the algorithm number of the KEY RR referred
- to by the DS record.
-
- The algorithm number used by the DS RR is identical to the algorithm
- number used by the SIG RR and KEY RR. Appendix A.1 lists the
- algorithm number types.
-
-5.1.3 The Digest Type Field
-
- The DS RR refers to a KEY RR by including a digest of that KEY RR.
- The Digest Type field identifies the algorithm used to construct the
- digest and Appendix A.2 lists the possible digest algorithm types.
-
-5.1.4 The Digest Field
-
- The DS record refers to a KEY RR by including a digest of that KEY
- RR. The Digest field holds the digest.
-
- The digest is calculated by concatenating the canonical form of the
- fully qualified owner name of the KEY RR (abbreviated below as "key
- RR name") with the KEY RDATA, and then applying the digest algorithm.
-
- digest = digest_algorithm( KEY RR name | KEY RDATA);
-
- "|" denotes concatenation
-
- KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key.
-
-
- The size of the digest may vary depending on the digest algorithm and
- KEY RR size. Currently, the defined digest algorithm is SHA-1, which
- produces a 20 octet digest.
-
-5.2 The DS RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Key Tag field is represented as an unsigned decimal integer.
-
- The Algorithm field is represented either as an unsigned decimal
- integer or as an algorithm mnemonic specified in Appendix A.1.
-
- The Digest Type field is represented as an unsigned decimal integer.
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 19]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- The Digest is represented as a sequence of case-insensitive
- hexadecimal digits. Whitespace is allowed within the hexadecimal
- text.
-
-5.3 DS RR Example
-
- The following example shows a KEY RR and its corresponding DS RR.
-
- dskey.example.com. 86400 IN KEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
- fwJr1AYtsmx3TGkJaNXVbfi/
- 2pHm822aJ5iI9BMzNXxeYCmZ
- DRD99WYwYqUSdjMmmAphXdvx
- egXd/M5+X7OrzKBaMbCVdFLU
- Uh6DhweJBjEVv5f2wwjM9Xzc
- nOf+EPbtG9DMBmADjFDc2w/r
- ljwvFw==
- ) ; key id = 60485
-
- dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
- 98631FAD1A292118 )
-
-
- The first four text fields specify the name, TTL, Class, and RR type
- (DS). Value 60485 is the key tag for the corresponding
- "dskey.example.com." KEY RR, and value 5 denotes the algorithm used
- by this "dskey.example.com." KEY RR. The value 1 is the algorithm
- used to construct the digest, and the rest of the RDATA text is the
- digest in hexadecimal.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 20]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-6. Canonical Form and Order of Resource Records
-
- This section defines a canonical form for resource records, a
- canonical ordering of DNS names, and a canonical ordering of resource
- records within an RRset. A canonical name order is required to
- construct the NXT name chain. A canonical RR form and ordering
- within an RRset are required to construct and verify SIG RRs.
-
-6.1 Canonical DNS Name Order
-
- For purposes of DNS security, owner names are ordered by treating
- individual labels as unsigned left-justified octet strings. The
- absence of a octet sorts before a zero value octet, and upper case
- US-ASCII letters are treated as if they were lower case US-ASCII
- letters.
-
- To compute the canonical ordering of a set of DNS names, start by
- sorting the names according to their most significant (rightmost)
- labels. For names in which the most significant label is identical,
- continue sorting according to their next most significant label, and
- so forth.
-
- For example, the following names are sorted in canonical DNS name
- order. The most significant label is "example". At this level,
- "example" sorts first, followed by names ending in "a.example", then
- names ending "z.example". The names within each level are sorted in
- the same way.
-
- example
- a.example
- yljkjljk.a.example
- Z.a.example
- zABC.a.EXAMPLE
- z.example
- \001.z.example
- *.z.example
- \200.z.example
-
-
-6.2 Canonical RR Form
-
- For purposes of DNS security, the canonical form of an RR is the wire
- format of the RR where:
-
- 1. Every domain name in the RR is fully expanded (no DNS name
- compression) and fully qualified;
-
- 2. All uppercase US-ASCII letters in the owner name of the RR are
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 21]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- replaced by the corresponding lowercase US-ASCII letters;
-
- 3. If the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
- HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
- SRV, DNAME, or A6, all uppercase US-ASCII letters in the DNS
- names within the RDATA of the RR are replaced by the
- corresponding lowercase US-ASCII letters;
-
- 4. If the owner name of the RR is a wildcard name, the owner name is
- in its original unexpanded form, including the "*" label (no
- wildcard substitution); and
-
- 5. The RR's TTL is set to its original value as it appears in the
- authoritative zone containing the RR or the Original TTL field of
- the covering SIG RR.
-
- Editors' Note: the above definition sacrifices readability for an
- attempt at precision. Please send better text!
-
-6.3 Canonical RR Ordering Within An RRset
-
- For purposes of DNS security, RRs with same owner name, same class,
- and same type are sorted by sorting the canonical forms of the RRs
- while treating the RDATA portion of the canonical form of each RR as
- a left justified unsigned octet sequence. The absence of an octet
- sorts before the zero octet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 22]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-7. IANA Considerations
-
- This document introduces one new IANA consideration. RFC 2535 [14]
- created an IANA registry for DNS Security Algorithm Numbers. This
- document re-assigns DNS Security Algorithm Number 252 to be
- "reserved". This value is no longer available for assignment by
- IANA.
-
- This document clarifies the use of existing DNS resource records.
- For completeness, the IANA considerations from the previous documents
- which defined these resource records are summarized below. No IANA
- changes are made by this document other than the one change described
- in the first paragraph of this section.
-
- [14] updated the IANA registry for DNS Resource Record Types, and
- assigned types 24,25, and 30 to the SIG, KEY, and NXT RRs,
- respectively. [9] assigned DNS Resource Record Type 43 to DS.
-
- [14] created an IANA registry for DNSSEC Resource Record Algorithm
- Numbers. Values to 1-4, and 252-255 were assigned by [14]. Value 5
- was assigned by [8]. Value 252 is re-assigned by this document, as
- noted above.
-
- [9] created an IANA registry for DNSSEC DS Digest Types, and assigned
- value 0 to reserved and value 1 to SHA-1.
-
- [14] created an IANA Registry for KEY Protocol Values, but [16] re-
- assigned all assigned values other than 3 to reserved and closed this
- IANA registry. The registry remains closed, and all KEY records are
- required to have Protocol Octet value of 3.
-
- The Flag bits in the KEY RR are not assigned by IANA, and there is no
- IANA registry for these flags. All changes to the meaning of the KEY
- RR Flag bits require a standards action.
-
- The meaning of a value of 1 in bit zero of the Type Bit Map of an NXT
- RR can only be assigned by a standards action.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 23]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-8. Security Considerations
-
- This document describes the format of four DNS resource records used
- by the DNS security extensions, and presents an algorithm for
- calculating a key tag for a public key. Other than the items
- described below, the resource records themselves introduce no
- security considerations. The use of these records is specified in a
- separate document, and security considerations related to the use
- these resource records are discussed in that document.
-
- The DS record points to a KEY RR using a cryptographic digest, the
- key algorithm type and a key tag. The DS record is intended to
- identify an existing KEY RR, but it is theoretically possible for an
- attacker to generate a KEY that matches all the DS fields. The
- probability of constructing such a matching KEY depends on the type
- of digest algorithm in use. The only currently defined digest
- algorithm is SHA-1, and the working group believes that constructing
- a public key which would match the algorithm, key tag, and SHA-1
- digest given in a DS record would be a sufficiently difficult problem
- that such an attack is not a serious threat at this time.
-
- The key tag is used to help select KEY resource records efficiently,
- but it does not uniquely identify a single KEY resource record. It
- is possible for two distinct KEY RRs to have the same owner name, the
- same algorithm type, and the same key tag. An implementation which
- used only the key tag to select a KEY RR might select the wrong
- public key in some circumstances. Implementations MUST NOT assume
- the key tag is unique public key identifier; this is clearly stated
- in Appendix B.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 24]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-9. Acknowledgments
-
- This document was created from the input and ideas of several members
- of the DNS Extensions Working Group and working group mailing list.
- The co-authors of this draft would like to express their thanks for
- the comments and suggestions received during the revision of these
- security extension specifications.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 25]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-Normative References
-
- [1] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
- Extensions) Part One: Mechanisms for Specifying and Describing
- the Format of Internet Message Bodies", RFC 1521, September
- 1993.
-
- [4] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
- August 1996.
-
- [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [6] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
- [7] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
- System (DNS)", RFC 3110, May 2001.
-
- [9] Gudmundsson, O., "Delegation Signer Resource Record", draft-
- ietf-dnsext-delegation-signer-12 (work in progress), December
- 2002.
-
- [10] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "DNS Security Introduction and Requirements", draft-ietf-
- dnsext-dnssec-intro-05 (work in progress), February 2003.
-
- [11] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
- "Protocol Modifications for the DNS Security Extensions",
- draft-ietf-dnsext-dnssec-protocol-00 (work in progress),
- Februari 2003.
-
- [12] Gustafsson, A., "Handling of Unknown DNS RR Types", draft-ietf-
- dnsext-unknown-rrs-04 (work in progress), September 2002.
-
- [13] Kosters, M., Blacka, D. and R. Arends, "DNSSEC Opt-in", draft-
- ietf-dnsext-dnssec-opt-in-04 (work in progress), February 2003.
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 26]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-Informative References
-
- [14] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [15] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
- 2930, September 2000.
-
- [16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
- Record (RR)", RFC 3445, December 2002.
-
-
-Authors' Addresses
-
- Roy Arends
- Telematica Instituut
- Drienerlolaan 5
- 7522 NB Enschede
- NL
-
- EMail: roy.arends@telin.nl
-
-
- Rob Austein
- Internet Software Consortium
- 40 Gavin Circle
- Reading, MA 01867
- USA
-
- EMail: sra@isc.org
-
-
- Matt Larson
- VeriSign, Inc.
- 21345 Ridgetop Circle
- Dulles, VA 20166-6503
- USA
-
- EMail: mlarson@verisign.com
-
-
- Dan Massey
- USC Information Sciences Institute
- 3811 N. Fairfax Drive
- Arlington, VA 22203
- USA
-
- EMail: masseyd@isi.edu
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 27]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- Scott Rose
- National Institute for Standards and Technology
- 100 Bureau Drive
- Gaithersburg, MD 20899-8920
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 28]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-Appendix A. DNSSEC Algorithm and Digest Types
-
- The DNS security extensions are designed to be independent of the
- underlying cryptographic algorithms. The KEY, SIG, and DS resource
- records all use a DNSSEC Algorithm Number to identify the
- cryptographic algorithm in use by the resource record. The DS
- resource record also specifies a Digest Algorithm Number to identify
- the digest algorithm used to construct the DS record. The currently
- defined Algorithm and Digest Types are listed below. Additional
- Algorithm or Digest Types could be added as advances in cryptography
- warrant.
-
- A DNSSEC aware resolver or name server MUST implement all MANDATORY
- algorithms.
-
-A.1 DNSSEC Algorithm Types
-
- An "Algorithm Number" field in the KEY, SIG, and DS resource record
- types identifies the cryptographic algorithm used by the resource
- record. Algorithm specific formats are described in separate
- documents. The following table lists the currently defined algorithm
- types and provides references to their supporting documents:
-
- VALUE Algorithm RFC STATUS
- 0 Reserved - -
- 1 RSA/MD5 RFC 2537 NOT RECOMMENDED
- 2 Diffie-Hellman RFC 2539 OPTIONAL
- 3 DSA RFC 2536 OPTIONAL
- 4 elliptic curve TBA OPTIONAL
- 5 RSA/SHA1 RFC 3110 MANDATORY
- 6-251 available for assignment -
- 252 reserved -
- 253 private see below OPTIONAL
- 254 private see below OPTIONAL
- 255 reserved - -
-
-
-A.1.1 Private Algorithm Types
-
- Algorithm number 253 is reserved for private use and will never be
- assigned to a specific algorithm. The public key area in the KEY RR
- and the signature area in the SIG RR begin with a wire encoded domain
- name. Only local domain name compression is permitted. The domain
- name indicates the private algorithm to use and the remainder of the
- public key area is determined by that algorithm. Entities should
- only use domain names they control to designate their private
- algorithms.
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 29]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- Algorithm number 254 is reserved for private use and will never be
- assigned to a specific algorithm. The public key area in the KEY RR
- and the signature area in the SIG RR begin with an unsigned length
- byte followed by a BER encoded Object Identifier (ISO OID) of that
- length. The OID indicates the private algorithm in use and the
- remainder of the area is whatever is required by that algorithm.
- Entities should only use OIDs they control to designate their private
- algorithms.
-
-A.2 DNSSEC Digest Types
-
- A "Digest Type" field in the DS resource record types identifies the
- cryptographic digest algorithm used by the resource record. The
- following table lists the currently defined digest algorithm types.
-
- VALUE Algorithm STATUS
- 0 Reserved -
- 1 SHA-1 MANDATORY
- 2-255 Unassigned -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 30]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-Appendix B. Key Tag Calculation
-
- The Key Tag field in the SIG and DS resource record types provides a
- mechanism for selecting a public key efficiently. In most cases, a
- combination of owner name, algorithm, and key tag can efficiently
- identify a KEY record. Both the SIG and DS resource records have
- corresponding KEY records. The Key Tag field in the SIG and DS
- records can be used to help select the corresponding KEY RR
- efficiently when more than one candidate KEY RR is available.
-
- However, it is essential to note that the key tag is not a unique
- identifier. It is theoretically possible for two distinct KEY RRs to
- have the same owner name, the same algorithm, and the same key tag.
- The key tag is used to limit the possible candidate keys, but it does
- not uniquely identify a KEY record. Implementations MUST NOT assume
- that the key tag uniquely identifies a KEY RR.
-
- The key tag is the same for all KEY algorithm types except algorithm
- 1 (please see Appendix B.1 for the definition of the key tag for
- algorithm 1). For all algorithms other than algorithm 1, the key tag
- is defined to be the output which would be generated by running the
- ANSI C function shown below with the RDATA portion of the KEY RR as
- input. It is not necessary to use the following reference code
- verbatim, but the numerical value of the Key Tag MUST be identical to
- what the reference implementation would generate for the same input.
-
- Please note that the algorithm for calculating the Key Tag is almost
- but not completely identical to the familiar ones complement checksum
- used in many other Internet protocols. Key Tags MUST be calculated
- using the algorithm described below rather than the ones complement
- checksum.
-
- The following ANSI C reference implementation calculates the value of
- a Key Tag. This reference implementation applies to all algorithm
- types except algorithm 1 (see Appendix B.1). The input is the wire
- format of the RDATA portion of the KEY RR. The code is written for
- clarity, not efficiency.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 31]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
- /*
- * Assumes that int is at least 16 bits.
- * First octet of the key tag is the most significant 8 bits of the
- * return value;
- * Second octet of the key tag is the least significant 8 bits of the
- * return value.
- */
-
- unsigned int
- keytag (
- unsigned char key[], /* the RDATA part of the KEY RR */
- unsigned int keysize /* the RDLENGTH */
- )
- {
- unsigned long ac; /* assumed to be 32 bits or larger */
- int i; /* loop index */
-
- for ( ac = 0, i = 0; i < keysize; ++i )
- ac += (i & 1) ? key[i] : key[i] << 8;
- ac += (ac >> 16) & 0xFFFF;
- return ac & 0xFFFF;
- }
-
-
-B.1 Key Tag for Algorithm 1 (RSA/MD5)
-
- The key tag for algorithm 1 (RSA/MD5) is defined differently than the
- key tag for all other algorithms, for historical reasons. For a KEY
- RR with algorithm 1, the key tag is defined to be the most
- significant 16 bits of the least significant 24 bits in the public
- key modulus (in other words, the 4th to last and 3rd to last octets
- of the public key modulus).
-
- Please note that Algorithm 1 is NOT RECOMMENDED.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 32]
-\f
-Internet-Draft DNSSEC Resource Records February 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arends, et al. Expires August 26, 2003 [Page 33]
-\f
+++ /dev/null
-
-
-DNS Extensions S. Rose
-Internet-Draft NIST
-Expires: August 5, 2003 February 4, 2003
-
-
- DNS Security Document Roadmap
- draft-ietf-dnsext-dnssec-roadmap-07
-
-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.
-
- This Internet-Draft will expire on August 5, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- DNS Security (DNSSEC) technology is composed of extensions to the
- Domain Name System (DNS) protocol that provide data integrity and
- authentication to security aware resolvers and applications through
- the use of cryptographic digital signatures. Several documents exist
- to describe these extensions and the implementation-specific details
- regarding specific digital signing schemes. The interrelationship
- between these different documents is discussed here. A brief
- overview of what to find in which document and author guidelines for
- what to include in new DNS Security documents, or revisions to
- existing documents, is described.
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 1]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Interrelationship of DNS Security Documents . . . . . . . . . 4
- 3. Relationship of DNS Security Documents to other DNS
- Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- 4. Recommended Content for new DNS Security Documents . . . . . . 9
- 4.1 Security Related Resource Records . . . . . . . . . . . . . . 9
- 4.2 Digital Signature Algorithm Implementations . . . . . . . . . 9
- 4.3 Refinement of Security Procedures . . . . . . . . . . . . . . 10
- 4.4 The Use of DNS Security Extensions with Other Protocols . . . 10
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
- Normative References . . . . . . . . . . . . . . . . . . . . . 13
- Informative References . . . . . . . . . . . . . . . . . . . . 15
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 2]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-1. Introduction
-
- This document is intended to provide guidelines for the development
- of supplemental documents describing security extensions to the
- Domain Name System (DNS).
-
- The main goal of the DNS Security (DNSSEC) extensions is to add data
- authentication and integrity services to the DNS protocol. These
- protocol extensions should be differentiated from DNS operational
- security issues, which are beyond the scope of this effort. DNS
- Security documents fall into one or possibly more of the following
- sub-categories: new DNS security resource records, implementation
- details of specific digital signing algorithms for use in DNS
- Security and DNS transaction authentication. Since the goal of DNS
- Security extensions is to become part of the DNS protocol standard,
- additional documents that seek to refine a portion of the security
- extensions will be introduced as the specifications progress along
- the IETF standards track.
-
- There is a set of basic guidelines for each sub-category of documents
- that explains what should be included, what should be considered a
- protocol extension, and what should be considered an operational
- issue. Currently, there are at least two documents that fall under
- operational security considerations that deal specifically with the
- DNS security extensions: the first is RFC 2541 [6] which deals with
- the operational side of implementing the security extensions; the
- other is the CAIRN DNSSEC testbed Internet draft [CAIRN]. These
- documents should be considered part of the operational side of DNS,
- but will be addressed as a supplemental part of the DNS Security
- roadmap. That is not to say that these two documents are not
- important to securing a DNS zone, but they do not directly address
- the proposed DNS security extensions. Authors of documents that seek
- to address the operational concerns of DNS security should be aware
- of the structure of DNS Security documentation.
-
- It is assumed the reader has some knowledge of the Domain Name System
- [2] and the Domain Name System Security Extensions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 3]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-2. Interrelationship of DNS Security Documents
-
- The DNSSEC set of documents can be partitioned into five main groups
- as depicted in Figure 1. All of these documents in turn are under
- the larger umbrella group of DNS base protocol documents. It is
- possible that some documents fall into more than one of these
- categories, such as RFC 2535, and should follow the guidelines for
- the all of the document groups it falls into. However, it is wise to
- limit the number of "uberdocuments" that try to be everything to
- everyone. The documents listed in each category are current as to
- the time of writing.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 4]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
- ---------------------------------------------------------------------
-
-
-
- +--------------------------------+
- | |
- | Base DNS Protocol Docs. |
- | [RFC1035, RFC2181, etc.] |
- | |
- +--------------------------------+
- |
- |
- |
- +------------+ +-----------+ +-------------+
- | New | | DNSSEC | | New |
- | Security |----------| protocol |----------| Security |
- | RRs | | | | Uses |
- +------------+ | | +-------------+
- +-----------+
- |
- |
- +----------------------+***********************
- | * *
- | * *
- +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+
- | DS | | | | Implementation |
- | Algorithm | | Transactions | * Notes *
- | Impl. | | | | |
- +------------+ +---------------+ +-*-*-*-*-*-*-*-*-+
-
-
-
-
- DNSSEC Document Roadmap
-
- ---------------------------------------------------------------------
-
- The "DNSSEC protocol" document set refers to the document that makes
- up the groundwork for adding security to the DNS protocol [1]and
- updates to this document. RFC 2535 laid out the goals and
- expectations of DNS Security and the new security-related Resource
- Records KEY, SIG, DS, and NXT [23]. Expanding from this document,
- related document groups include the implementation documents of
- various digital signature algorithms with DNSSEC, and documents
- further refining the transaction of messages. It is expected that
- RFC 2535 will be obsoleted by one or more documents that refine the
- set of security extensions [22], [23], [24]. Documents that seek to
- modify or clarify the base protocol documents should state so clearly
-
-
-
-Rose Expires August 5, 2003 [Page 5]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
- in the introduction of the document (as well as proscribe to the IETF
- guidelines 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 [1], [11], [12], [9], [14],
- [15], [21], [16], [OPTIN], [17] 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
- types. These new records can be related to securing the DNS protocol
- [1], [8], or using DNS security for other purposes such as storing
- certificates [5]. Another related document is [26]. While not
- detailing a new RR type, it defines a flag bit in the existing KEY
- RR. This flag bit does not affect the protocol interpretation of the
- RR, only a possible operational difference. Therefore, this draft is
- place here and not with the protocol document set.
-
- The "DS Algorithm Impl" document set refers to the group of documents
- that describe how a specific digital signature algorithm is
- implemented to fit the DNSSEC Resource Record format. Each one of
- these documents deals with one specific digital signature algorithm.
- Examples of this set include [4], [5], [25], [19][18] and [13].
-
- The "Transactions" document set refers to the group of documents that
- deal with the message transaction sequence of security-related DNS
- operations. The contents and sequence for operations such as dynamic
- update [3], [11] and transaction signatures [10] are described in
- this document category. Additional message transaction schemes to
- support DNSSEC operation would also fall under this group, including
- secret key establishment [7], [RENEW], and verification.
-
- The final document set, "New Security Uses", refers to documents that
- seek to use proposed DNS Security extensions for other security
- related purposes. Documents that fall in this category include the
- use of DNS in the storage and distribution of certificates and
- individual 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
- support other protocols; only how existing DNS security records and
- transactions can be used to support other protocols. Such documents
- include [SSH-DNS] and [IPSEC-DNS] which deals with storing SSH and
- IPSec keying information the DNS using new records and utilizing
- DNSSEC to provide authentication and integrity checking.
-
- Lastly, there is a set of documents that should be classified as
- "Implementation Notes". Because the DNS security extensions are
- still in the developmental stage, there is an audience for documents
-
-
-
-Rose Expires August 5, 2003 [Page 6]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
- that detail the transition and implementation of the security
- extensions. These have more to do with the practical side of DNS
- operations, but can also point to places in the protocol
- specifications that need improvement. An example of this type is the
- report on the CAIRN DNSSEC testbed [CAIRN] This document was
- submitted through the DNSOP Working Group at the time of this
- writing, however the main concern of this document is the
- implementation 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. Authors of documents that
- deal with the implementation and operational side of the DNSSEC
- specifications would be advised/encouraged to submit their documents
- to any other relevant DNS related WG meeting in the problem space.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 7]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-3. Relationship of DNS Security Documents to other DNS Documents
-
- The DNS security-related extensions should be considered a subset of
- the DNS protocol. Therefore, all DNS security-related documents
- should be seen as a subset of the main DNS architecture documents.
- It is a good idea for authors of future DNS security documents to be
- familiar with the contents of these base protocol documents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 8]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-4. Recommended Content for new DNS Security Documents
-
- Documents that seek to make additions or revisions to the DNS
- protocol 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. 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 Working Group documents.
-
- Since the addition of security to the DNS protocol is now considered
- a general extension to the DNS protocol, any guideline for the
- contents of a DNS Security document could be taken as a framework
- suggestion for the contents of any DNS extension document. The
- development process of the DNS security extensions could be used as a
- model framework for any, more general DNS extensions.
-
-4.1 Security Related Resource Records
-
- Documents describing a new type of DNS Security Resource Record (RR)
- should contain information describing the structure and use of the
- new RR type. It is a good idea to only discuss one new type in a
- document, unless the set of new resource records are closely related
- or a protocol extension requires the use of more than one new record
- type. Specifically, each document detailing a new security-related
- RR type should include the following information:
-
- o The format of the new RR type, both "on the wire" (bit format) and
- ASCII representation (for text zone files), if appropriate;
-
- o when and in what section of a DNS query/response this new RR type
- is to be included;
-
- o at which level of the DNS hierarchy this new RR type is to be
- considered authoritative (i.e. in a zone, in a zone's superzone)
- and who is authoritative to sign the new RR;
-
-
-4.2 Digital Signature Algorithm Implementations
-
- Documents describing the implementation details of a specific digital
- signature algorithm such as [4] ,[13] (and others as new digital
- signatures schemes are introduced) for use with DNS Security should
- include the following information:
-
-
-
-Rose Expires August 5, 2003 [Page 9]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
- o The format/encoding of the algorithm's public key for use in a KEY
- Resource Record;
-
- o the acceptable key size for use with the algorithm;
-
- o the current known status of the algorithm (as one of REQUIRED,
- RECOMMENDED, or OPTIONAL).
-
- In addition, authors are encouraged to include any necessary
- description 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
- extensions to the DNS protocol, not cryptographic research.
-
-4.3 Refinement of Security Procedures
-
- This set of documents includes DNS protocol operations that
- specifically relate to DNS Security, such as DNS secret key
- establishment [7] and security extensions to pre-existing or
- proposed DNS operations such as dynamic update [3]. Documents that
- describe a new set of DNS message transactions, or seek to refine a
- current series of transactions that make up a DNS operation should
- include the following information:
-
- o The order in which the DNS messages are sent by the operation
- initiator and target;
-
- o the format of these DNS messages;
-
- o any required authentication mechanisms for each stage of the
- operation and the required authority for that mechanism (i.e.
- zone, host, or some other trusted authority such as a DNS
- administrator or certificate authority);
-
-
-4.4 The Use of DNS Security Extensions with Other Protocols
-
- Because of the flexibility and ubiquity of the DNS, there may exist
- other Internet protocols and applications that could make use of, or
- extend, the DNS security protocols. Examples of this type of
- document include the use of DNS to support IPSEC [IPSEC-DNS], SSH
- [SSH-DNS] the Public Key Infrastructure (PKI). It is beyond the
- scope of this roadmap to describe the contents of this class of
- documents. However, if uses or extensions require the addition or
- modification of a DNS Resource Record type or DNS query/response
- transactions, then the guidelines laid out in the previous sections
- of this document should be adhered to.
-
-
-
-
-Rose Expires August 5, 2003 [Page 10]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-5. Security Considerations
-
- This document provides a roadmap and guidelines for writing DNS
- Security related documents. This document does not discuss the
- aspects of the DNS security extensions. The reader should refer to
- the documents outlined here for the details of the services and
- shortcomings of DNS security.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 11]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-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
- not be able to access these documents through the RFC repositories.
- All of these documents are "Work in Progress" and are subject to
- change; therefore a version number is not supplied for the current
- revision. Some Internet Drafts are in the RFC editor's queue or
- nearing WG Last Call at the time of writing. These Drafts have been
- placed in the References section. The drafts below are still subject
- to agreement in the IETF.
-
- o CAIRN: D. Massey, T. Lehman, and E. Lewis. "DNSSEC
- Implementation in the CAIRN Testbed". draft-ietf-dnsop-
- dnsseccairn-NN.txt
-
- o OPTIN: M. Kosters. "DNSSEC Opt-in for Large Zones" draft-
- kosters-dnsext-dnssec-opt-in-NN.txt
-
- o SSH-DNS: W. Griffin, J. Schlyter. "Using DNS to securely
- publish SSH key fingerprints" draft-ietf-secsh-dns-NN.txt
-
- o IPSEC-DNS: M. Richardson. "A method for storing IPsec keying
- material in DNS". draft-richardson-ipsec-rr-NN.txt
-
- o RENEW: Y. Kamite, M. Nakayama. "TKEY Secret Key Renewal Mode".
- draft-ietf-dnsext-tkey-renewal-mode-NN.txt
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 12]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-Normative References
-
- [1] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
- 2137, April 1997.
-
- [4] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
- (DNS)", RFC 2536, March 1999.
-
- [5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
- Domain Name System (DNS)", RFC 2538, March 1999.
-
- [6] Eastlake, D., "DNS Security Operational Considerations", RFC
- 2541, March 1999.
-
- [7] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
- 2930, September 2000.
-
- [8] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [9] Lewis, E., "DNS Security Extension Clarification on Zone
- Status", RFC 3090, March 2001.
-
- [10] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
- [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
- [12] Wellington, B., "Domain Name System Security (DNSSEC) Signing
- Authority", RFC 3008, April 2000.
-
- [13] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
- System (DNS)", RFC 3110, May 2001.
-
- [14] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
- December 2001.
-
- [15] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
- message size requirements", RFC 3226, December 2001.
-
-
-
-
-Rose Expires August 5, 2003 [Page 13]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
- [16] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
- Record (RR)", RFC 3445, December 2002.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 14]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-Informative References
-
- [17] Austein, R. and D. Atkins, "Threat Analysis of the Domain Name
- System (Work in Progress)", RFC XXXX.
-
- [18] Eastlake, R., "Storage of Diffie-Hellman Keys in the Domain
- Name System (DNS) (Work in Progress)", RFC XXXX.
-
- [19] Eastlake, D. and R. Schroeppel, "Elliptic Curve KEYs in the DNS
- (Work in Progress)", RFC XXXX.
-
- [20] Gundmundsson, O., "Delegation Signer Record in Parent (Work in
- Progress)", RFC XXXX.
-
- [21] Wellington, B., "Redefinition of the DNS AD bit (Work in
- Progress)", RFC XXXX.
-
- [22] Arends, R., Larson, M., Massey, D. and S. Rose, "DNS Security
- Introduction and Requirements (Work in Progress)", RFC XXXX.
-
- [23] Arends, R., Larson, M., Massey, D. and S. Rose, "Resource
- Records for DNS Security Extensions (Work in Progress)", RFC
- XXXX.
-
- [24] Arends, R., Larson, M., Massey, D. and S. Rose, "Protocol
- Modifications for the DNS Security Extensions (Work in
- Progress)", RFC XXXX.
-
- [25] Kwan, S., Garg, P., Gilroy, J. and L. Esibov, "GSS Algorithm
- for TSIG (Work in Progress)", RFC XXXX.
-
- [26] Kolkman, O. and J. Schlyter, "KEY RR Key-Signing-Key (KSK) Flag
- (Work in Progress)", RFC XXXX.
-
-
-Author's Address
-
- Scott Rose
- National Institute for Standards and Technology
- 100 Bureau Drive
- Gaithersburg, MD 20899-3460
- USA
-
- EMail: scott.rose@nist.gov
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 15]
-\f
-Internet-Draft DNSSEC Document Roadmap February 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rose Expires August 5, 2003 [Page 16]
-\f
+++ /dev/null
-
-INTERNET-DRAFT ECC Keys in the DNS
-Expires: June 2003 December 2002
-
-
-
-
- Elliptic Curve KEYs in the DNS
- -------- ----- ---- -- --- ---
- <draft-ietf-dnsext-ecc-key-03.txt>
-
- Richard C. Schroeppel
- Donald Eastlake 3rd
-
-
-Status of This Document
-
- This draft is intended to be become a Proposed Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNS mailing list <namedroppers@internic.com> or to the
- authors.
-
- 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
-
- A standard method for storing elliptic curve cryptographic keys in
- the Domain Name System is described which utilizes DNS KEY resource
- record.
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 1]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-Acknowledgement
-
- The assistance of Hilarie K. Orman in the production of this document
- is greatfully acknowledged.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Acknowledgement............................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. Elliptic Curve KEY Resource Records.....................3
- 3. The Elliptic Curve Equation.............................9
- 4. How do I Compute Q, G, and Y?..........................10
- 5. Performance Considerations.............................11
- 6. Security Considerations................................11
- 7. IANA Considerations....................................11
-
- References................................................13
-
- Authors' Addresses........................................14
- Expiration and File Name..................................14
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 2]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information. The DNS has been extended to include digital
- signatures and cryptographic keys as described in [RFC 2535].
-
- This document describes how to store elliptic curve cryptographic
- (ECC) keys in the DNS so they can be used for a variety of security
- purposes. A DNS elliptic curve SIG resource record is not defined.
- Familiarity with ECC cryptography is assumed [Menezes].
-
- 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. Elliptic Curve KEY Resource Records
-
- Elliptic curve public keys are stored in the DNS as KEY RRs using
- algorithm number 4 (see [RFC 2535]). The structure of the RDATA
- portion of this RR is as shown below. The first 4 octets, including
- the flags, protocol, and algorithm fields are common to all KEY RRs.
- The remainder is the "public key" part of the KEY RR.
-
- The period of key validity is not in the KEY RR but is indicated by
- the SIG RR(s) which signs and authenticates the KEY RR(s) at that
- domain name and class.
-
- The research world continues to work on the issue of which is the
- best elliptic curve system, which finite field to use, and how to
- best represent elements in the field. So, we have defined
- representations for every type of finite field, and every type of
- elliptic curve. The reader should be aware that there is a unique
- finite field with a particular number of elements, but many possible
- representations of that field and its elements. If two different
- representations of a field are given, they are interconvertible with
- a tedious but practical precomputation, followed by a fast
- computation for each field element to be converted. It is perfectly
- reasonable for an algorithm to work internally with one field
- representation, and convert to and from a different external
- representation.
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 3]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | KEY flags | protocol | algorithm=4 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S M -FMT- A B Z|
- +-+-+-+-+-+-+-+-+
- | LP |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | P (length determined from LP) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LF |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | F (length determined from LF) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEG |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGH |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGI |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | DEGJ |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | TRDV |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S| LH |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | H (length determined from LH) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |S| LK |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | K (length determined from LK) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LQ |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Q (length determined from LQ) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LA |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | A (length determined from LA) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | ALTA |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LB |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | B (length determined from LB) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LC |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | C (length determined from LC) .../
-
-
-R. Schroeppel, et al [Page 4]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LG |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | G (length determined from LG) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | LY |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Y (length determined from LY) .../
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- SMFMTABZ is a flags octet as follows:
-
- S = 1 indicates that the remaining 7 bits of the octet selects
- one of 128 predefined choices of finite field, element
- representation, elliptic curve, and signature parameters.
- MFMTABZ are omitted, as are all parameters from LP through G.
- LY and Y are retained.
-
- If S = 0, the remaining parameters are as in the picture and
- described below.
-
- M determines the type of field underlying the elliptic curve.
-
- M = 0 if the field is a GF[2^N] field;
-
- M = 1 if the field is a (mod P) or GF[P^D] field with P>2.
-
- FMT is a three bit field describing the format of the field
- representation.
-
- FMT = 0 for a (mod P) field.
- > 0 for an extension field, either GF[2^D] or GF[P^D].
- The degree D of the extension, and the field polynomial
- must be specified. The field polynomial is always monic
- (leading coefficient 1.)
-
- FMT = 1 The field polynomial is given explicitly; D is implied.
-
- If FMT >=2, the degree D is given explicitly.
-
- = 2 The field polynomial is implicit.
- = 3 The field polynomial is a binomial. P>2.
- = 4 The field polynomial is a trinomial.
- = 5 The field polynomial is the quotient of a trinomial by a
- short polynomial. P=2.
- = 6 The field polynomial is a pentanomial. P=2.
-
- Flags A and B apply to the elliptic curve parameters.
-
-
-
-
-R. Schroeppel, et al [Page 5]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- A = 1 When P>=5, the curve parameter A is negated. If P=2, then
- A=1 indicates that the A parameter is special. See the
- ALTA parameter below, following A. The combination A=1,
- P=3 is forbidden.
-
- B = 1 When P>=5, the curve parameter B is negated. If P=2 or 3,
- then B=1 indicates an alternate elliptic curve equation is
- used. When P=2 and B=1, an additional curve parameter C
- is present.
-
- The Z bit SHOULD be set to zero on creation of KEY RR and MUST
- be ignored when processing a KEY RR (when S=0).
-
- Most of the remaining parameters are present in some formats and
- absent in others. The presence or absence of a parameter is
- determined entirely by the flags. When a parameter occurs, it is in
- the order defined by the picture.
-
- Of the remaining parameters, PFHKQABCGY are variable length. When
- present, each is preceded by a one-octet length field as shown in the
- diagram above. The length field does not include itself. The length
- field may have values from 0 through 110. The parameter length in
- octets is determined by a conditional formula: If LL<=64, the
- parameter length is LL. If LL>64, the parameter length is 16 times
- (LL-60). In some cases, a parameter value of 0 is sensible, and MAY
- be represented by an LL value of 0, with the data field omitted. A
- length value of 0 represents a parameter value of 0, not an absent
- parameter. (The data portion occupies 0 space.) There is no
- requirement that a parameter be represented in the minimum number of
- octets; high-order 0 octets are allowed at the front end. Parameters
- are always right adjusted, in a field of length defined by LL. The
- octet-order is always most-significant first, least-significant last.
- The parameters H and K may have an optional sign bit stored in the
- unused high-order bit of their length fields.
-
- LP defines the length of the prime P. P must be an odd prime. The
- parameters LP,P are present if and only if the flag M=1. If M=0, the
- prime is 2.
-
- LF,F define an explicit field polynomial. This parameter pair is
- present only when FMT = 1. The length of a polynomial coefficient is
- ceiling(log2 P) bits. Coefficients are in the numerical range
- [0,P-1]. The coefficients are packed into fixed-width fields, from
- higher order to lower order. All coefficients must be present,
- including any 0s and also the leading coefficient (which is required
- to be 1). The coefficients are right justified into the octet string
- of length specified by LF, with the low-order "constant" coefficient
- at the right end. As a concession to storage efficiency, the higher
- order bits of the leading coefficient may be elided, discarding high-
- order 0 octets and reducing LF. The degree is calculated by
-
-
-R. Schroeppel, et al [Page 6]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- determining the bit position of the left most 1-bit in the F data
- (counting the right most bit as position 0), and dividing by
- ceiling(log2 P). The division must be exact, with no remainder. In
- this format, all of the other degree and field parameters are
- omitted. The next parameters will be LQ,Q.
-
- If FMT>=2, the degree of the field extension is specified explicitly,
- usually along with other parameters to define the field polynomial.
-
- DEG is a two octet field that defines the degree of the field
- extension. The finite field will have P^DEG elements. DEG is
- present when FMT>=2.
-
- When FMT=2, the field polynomial is specified implicitly. No other
- parameters are required to define the field; the next parameters
- present will be the LQ,Q pair. The implicit field poynomial is the
- lexicographically smallest irreducible (mod P) polynomial of the
- correct degree. The ordering of polynomials is by highest-degree
- coefficients first -- the leading coefficient 1 is most important,
- and the constant term is least important. Coefficients are ordered
- by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial
- of degree D is X^D (which is not irreducible). The next is X^D+1,
- which is sometimes irreducible, followed by X^D-1, which isn't.
- Assuming odd P, this series continues to X^D - (P-1)/2, and then goes
- to X^D + X, X^D + X + 1, X^D + X - 1, etc.
-
- When FMT=3, the field polynomial is a binomial, X^DEG + K. P must be
- odd. The polynomial is determined by the degree and the low order
- term K. Of all the field parameters, only the LK,K parameters are
- present. The high-order bit of the LK octet stores on optional sign
- for K; if the sign bit is present, the field polynomial is X^DEG - K.
-
- When FMT=4, the field polynomial is a trinomial, X^DEG + H*X^DEGH +
- K. When P=2, the H and K parameters are implicitly 1, and are
- omitted from the representation. Only DEG and DEGH are present; the
- next parameters are LQ,Q. When P>2, then LH,H and LK,K are
- specified. Either or both of LH, LK may contain a sign bit for its
- parameter.
-
- When FMT=5, then P=2 (only). The field polynomial is the exact
- quotient of a trinomial divided by a small polynomial, the trinomial
- divisor. The small polynomial is right-adjusted in the two octet
- field TRDV. DEG specifies the degree of the field. The degree of
- TRDV is calculated from the position of the high-order 1 bit. The
- trinomial to be divided is X^(DEG+degree(TRDV)) + X^DEGH + 1. If
- DEGH is 0, the middle term is omitted from the trinomial. The
- quotient must be exact, with no remainder.
-
- When FMT=6, then P=2 (only). The field polynomial is a pentanomial,
- with the degrees of the middle terms given by the three 2-octet
-
-
-R. Schroeppel, et al [Page 7]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- values DEGH, DEGI, DEGJ. The polynomial is X^DEG + X^DEGH + X^DEGI +
- X^DEGJ + 1. The values must satisfy the inequality DEG > DEGH > DEGI
- > DEGJ > 0.
-
- DEGH, DEGI, DEGJ are two-octet fields that define the degree of
- a term in a field polynomial. DEGH is present when FMT = 4,
- 5, or 6. DEGI and DEGJ are present only when FMT = 6.
-
- TRDV is a two-octet right-adjusted binary polynomial of degree <
- 16. It is present only for FMT=5.
-
- LH and H define the H parameter, present only when FMT=4 and P
- is odd. The high bit of LH is an optional sign bit for H.
-
- LK and K define the K parameter, present when FMT = 3 or 4, and
- P is odd. The high bit of LK is an optional sign bit for K.
-
- The remaining parameters are concerned with the elliptic curve and
- the signature algorithm.
-
- LQ defines the length of the prime Q. Q is a prime > 2^159.
-
- In all 5 of the parameter pairs LA+A,LB+B,LC+C,LG+G,LY+Y, the data
- member of the pair is an element from the finite field defined
- earlier. The length field defines a long octet string. Field
- elements are represented as (mod P) polynomials of degree < DEG, with
- DEG or fewer coefficients. The coefficients are stored from left to
- right, higher degree to lower, with the constant term last. The
- coefficients are represented as integers in the range [0,P-1]. Each
- coefficient is allocated an area of ceiling(log2 P) bits. The field
- representation is right-justified; the "constant term" of the field
- element ends at the right most bit. The coefficients are fitted
- adjacently without regard for octet boundaries. (Example: if P=5,
- three bits are used for each coefficient. If the field is GF[5^75],
- then 225 bits are required for the coefficients, and as many as 29
- octets may be needed in the data area. Fewer octets may be used if
- some high-order coefficients are 0.) If a flag requires a field
- element to be negated, each non-zero coefficient K is replaced with
- P-K. To save space, 0 bits may be removed from the left end of the
- element representation, and the length field reduced appropriately.
- This would normally only happen with A,B,C, because the designer
- chose curve parameters with some high-order 0 coefficients or bits.
-
- If the finite field is simply (mod P), then the field elements are
- simply numbers (mod P), in the usual right-justified notation. If
- the finite field is GF[2^D], the field elements are the usual right-
- justified polynomial basis representation.
-
-
-
-
-
-R. Schroeppel, et al [Page 8]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- LA,A is the first parameter of the elliptic curve equation.
- When P>=5, the flag A = 1 indicates A should be negated (mod
- P). When P=2 (indicated by the flag M=0), the flag A = 1
- indicates that the parameter pair LA,A is replaced by the two
- octet parameter ALTA. In this case, the parameter A in the
- curve equation is x^ALTA, where x is the field generator.
- Parameter A often has the value 0, which may be indicated by
- LA=0 (with no A data field), and sometimes A is 1, which may
- be represented with LA=1 and a data field of 1, or by setting
- the A flag and using an ALTA value of 0.
-
- LB,B is the second parameter of the elliptic curve equation.
- When P>=5, the flag B = 1 indicates B should be negated (mod
- P). When P=2 or 3, the flag B selects an alternate curve
- equation.
-
- LC,C is the third parameter of the elliptic curve equation,
- present only when P=2 (indicated by flag M=0) and flag B=1.
-
- LG,G defines a point on the curve, of order Q. The W-coordinate
- of the curve point is given explicitly; the Z-coordinate is
- implicit.
-
- LY,Y is the user's public signing key, another curve point of
- order Q. The W-coordinate is given explicitly; the Z-
- coordinate is implicit. The LY,Y parameter pair is always
- present.
-
-
-
-3. The Elliptic Curve Equation
-
- (The coordinates of an elliptic curve point are named W,Z instead of
- the more usual X,Y to avoid confusion with the Y parameter of the
- signing key.)
-
- The elliptic curve equation is determined by the flag octet, together
- with information about the prime P. The primes 2 and 3 are special;
- all other primes are treated identically.
-
- If M=1, the (mod P) or GF[P^D] case, the curve equation is Z^2 = W^3
- + A*W + B. Z,W,A,B are all numbers (mod P) or elements of GF[P^D].
- If A and/or B is negative (i.e., in the range from P/2 to P), and
- P>=5, space may be saved by putting the sign bit(s) in the A and B
- bits of the flags octet, and the magnitude(s) in the parameter
- fields.
-
- If M=1 and P=3, the B flag has a different meaning: it specifies an
- alternate curve equation, Z^2 = W^3 + A*W^2 + B. The middle term of
- the right-hand-side is different. When P=3, this equation is more
-
-
-R. Schroeppel, et al [Page 9]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- commonly used.
-
- If M=0, the GF[2^N] case, the curve equation is Z^2 + W*Z = W^3 +
- A*W^2 + B. Z,W,A,B are all elements of the field GF[2^N]. The A
- parameter can often be 0 or 1, or be chosen as a single-1-bit value.
- The flag B is used to select an alternate curve equation, Z^2 + C*Z =
- W^3 + A*W + B. This is the only time that the C parameter is used.
-
-
-
-4. How do I Compute Q, G, and Y?
-
- The number of points on the curve is the number of solutions to the
- curve equation, + 1 (for the "point at infinity"). The prime Q must
- divide the number of points. Usually the curve is chosen first, then
- the number of points is determined with Schoof's algorithm. This
- number is factored, and if it has a large prime divisor, that number
- is taken as Q.
-
- G must be a point of order Q on the curve, satisfying the equation
-
- Q * G = the point at infinity (on the elliptic curve)
-
- G may be chosen by selecting a random [RFC 1750] curve point, and
- multiplying it by (number-of-points-on-curve/Q). G must not itself
- be the "point at infinity"; in this astronomically unlikely event, a
- new random curve point is recalculated.
-
- G is specified by giving its W-coordinate. The Z-coordinate is
- calculated from the curve equation. In general, there will be two
- possible Z values. The rule is to choose the "positive" value.
-
- In the (mod P) case, the two possible Z values sum to P. The smaller
- value is less than P/2; it is used in subsequent calculations. In
- GF[P^D] fields, the highest-degree non-zero coefficient of the field
- element Z is used; it is chosen to be less than P/2.
-
- In the GF[2^N] case, the two possible Z values xor to W (or to the
- parameter C with the alternate curve equation). The numerically
- smaller Z value (the one which does not contain the highest-order 1
- bit of W (or C)) is used in subsequent calculations.
-
- Y is specified by giving the W-coordinate of the user's public
- signature key. The Z-coordinate value is determined from the curve
- equation. As with G, there are two possible Z values; the same rule
- is followed for choosing which Z to use.
-
-
-
-
-
-
-R. Schroeppel, et al [Page 10]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- During the key generation process, a random [RFC 1750] number X must
- be generated such that 1 <= X <= Q-1. X is the private key and is
- used in the final step of public key generation where Y is computed
- as
-
- Y = X * G (as points on the elliptic curve)
-
- If the Z-coordinate of the computed point Y is wrong (i.e., Z > P/2
- in the (mod P) case, or the high-order non-zero coefficient of Z >
- P/2 in the GF[P^D] case, or Z sharing a high bit with W(C) in the
- GF[2^N] case), then X must be replaced with Q-X. This will
- correspond to the correct Z-coordinate.
-
-
-
-5. Performance Considerations
-
- Elliptic curve signatures use smaller moduli or field sizes than RSA
- and DSA. Creation of a curve is slow, but not done very often. Key
- generation is faster than RSA or DSA.
-
- DNS implementations have been optimized for small transfers,
- typically less than 512 octets including DNS overhead. Larger
- transfers will perform correctly and and extensions have been
- standardized to make larger transfers more efficient [RFC 2671].
- However, it is still advisable at this time to make reasonable
- efforts to minimize the size of KEY RR sets stored within the DNS
- consistent with adequate security. Keep in mind that in a secure
- zone, an authenticating SIG RRset will also be returned.
-
-
-
-6. Security Considerations
-
- Many of the general security consideration in [RFC 2535] apply. Some
- specific key generation considerations are given above. Of course,
- the elliptic curve key stored in the DNS for an entity should not be
- trusted unless it has been obtain via a trusted DNS resolver that
- vouches for its security or unless the application using the key has
- done a similar authentication.
-
-
-
-7. IANA Considerations
-
- Assignment of meaning to the remaining ECC KEY flag bits or to values
- of ECC fields outside the ranges for which meaning in defined in this
- document requires an IETF consensus as defined in [RFC 2434].
-
- This specification uses algorithm number 4 for DNS elliptic curve KEY
-
-
-R. Schroeppel, et al [Page 11]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
- RRs that was reserved for this purpose in [RFC 2535]. An elliptic
- curve (algorithm = 4) SIG RR is not defined. Assignment of a meaning
- to it requires an IETF Standards action.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 12]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-References
-
- [RFC 1034] - P. Mockapetris, "Domain names - concepts and
- facilities", 11/01/1987.
-
- [RFC 1035] - P. Mockapetris, "Domain names - implementation and
- specification", 11/01/1987.
-
- [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness
- Recommendations for Security", 12/29/1994.
-
- [RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", March 1997.
-
- [RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", October 1998.
-
- [RFC 2535] - D. Eastlake,"Domain Name System Security Extensions",
- March 1999.
-
- [RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August
- 1999.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C", 1996, John Wiley and Sons
-
- [Menezes] - Alfred Menezes, "Elliptic Curve Public Key
- Cryptosystems", 1993 Kluwer.
-
- [Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves",
- 1986, Springer Graduate Texts in mathematics #106.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 13]
-\f
-
-INTERNET-DRAFT ECC Keys in the DNS
-
-
-Authors' Addresses
-
- Rich Schroeppel
- 500 S. Maple Drive
- Woodland Hills, UT 84653 USA
-
- Telephone: 1-801-423-7998(h)
- 1-505-844-9079(w)
- Email: rcs@cs.arizona.edu
- rschroe@sandia.gov
-
-
- Donald E. Eastlake 3rd
- Motorola
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1 508-634-2066 (h)
- +1 508-851-8280 (w)
- FAX: +1 508-851-8507 (w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in June 2003.
-
- Its file name is draft-ietf-dnsext-ecc-key-03.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-R. Schroeppel, et al [Page 14]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group R. Austein
-draft-ietf-dnsext-edns0dot5-02.txt InterNetShare.com, Inc.
- H. Alvestrand
- Cisco Systems
- November 2000
-
-
- A Proposed Enhancement to the EDNS0 Version Mechanism
-
-
-Status of this document
-
- 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>
-
- Distribution of this document is unlimited. Please send comments to
- the Namedroppers mailing list <namedroppers@ops.ietf.org>.
-
-Motivation and Scope
-
- EDNS0 [EDNS0] specifies a general framework for extending the packet
- format used by the Domain Name System protocols. The framework
- includes a simple version numbering scheme to allow the parties in a
- DNS protocol exchange to determine which extension features the other
- party understands. While having the advantage of simplicity, the
- version numbering scheme as specified has drawbacks:
-
- - It provides no way to deprecate a protocol feature;
-
- - It provides no way to deploy experimental protocol features.
-
-
-
-
-
-Austein & Alvestrand Expires 22 May 2001 [Page 1]
-\f
-draft-ietf-dnsext-edns0dot5-02.txt November 2000
-
-
- This note proposes to augument the monolithic version numbering
- mechanism with a mechanism for listing an explicit set of protocol
- features that a particular implementation supports. We retain
- version numbering as a way of abbreviating the feature sets that we
- expect to see in common use.
-
-Model
-
- Our revised extension model for the DNS is designed with three goals
- in mind:
-
- - We want the protocol to be as simple as possible for the common
- case of a client or server that implements "mainstream standard
- DNS";
-
- - We want to provide a safe way to experiment with new protocol
- features, both inside and outside the deployed DNS;
-
- - We want to provide a safe way to deprecate protocol features.
-
- Our revised extension model has two parts, both of which are carried
- in the OPT pseudo-RR: the VERSION, which stored in the second octet
- of the TTL field of the OPT RR, and a variable-length list of
- FEATURES, stored in the variable part of the OPT RR.
-
- All FEATUREs are extensions of the DNS. We reserve the range of
- FEATURE numbers from 1 to 100 for describing features of the original
- RFC 1034/1035 DNS specification that we might eventually choose to
- deprecate.
-
- Any query/response pair can be described as using a set of DNS
- FEATUREs. Such features might for instance be:
-
- - Domain binary labels according to [BINARY-LABELS];
-
- - Extended RCODEs (the general principle, not specific values);
-
- - Multi-packet UDP response;
-
- - Increased maximum UDP payload size;
-
- - Character set identification in DNS labels;
-
- - SIG record parsing and checking;
-
- FEATURE numbers are handed out by IANA on a first-come-first-served
- basis within their appropriate ranges. Any revised specification of
- a format or function should have its own FEATURE number; in the IETF
-
-
-
-Austein & Alvestrand Expires 22 May 2001 [Page 2]
-\f
-draft-ietf-dnsext-edns0dot5-02.txt November 2000
-
-
- process, any significantly changed Internet-Draft should have a new
- FEATURE number assigned for experimentation.
-
- An assigned VERSION number names a set of FEATUREs. VERSION numbers
- are assigned by the IETF through a standards action.
-
- Normally, any VERSION number encompasses every FEATURE of all lower
- VERSION numbers, but the possibility of removing FEATUREs exists for
- two reasons:
-
- - To remove the need for supporting FEATUREs that turned out to be a
- Really Bad Idea;
-
- - To allow replacing a badly specified FEATURE with a better
- specified FEATURE performing the same function that has a new
- FEATURE number.
-
-Mechanism
-
- We transport explicit feature sets as lists of integers carried in
- the variable RDATA portion of the EDNS0 OPT pseudo-RR.
-
- The OPTION-CODE for FEATURES is [TBD].
-
- The OPTION-DATA for FEATURES is an ordered list of "feature numbers";
- a feature number is represented as a big-endian 16-bit unsigned
- integer, and the list is sorted into numerically increasing order.
-
- Each feature number names a particular protocol feature that is
- supported by the implementation that generated this OPT pseudo-RR.
-
-Usage
-
- In most respects, the FEATURE mechanism is used symmetrically by
- clients and servers; exceptions to this rule are stated after the
- general explanation.
-
- When composing a DNS message, a client or server includes an OPT
- record indicating a set of FEATUREs that:
-
- - MUST include all FEATUREs that the client or server believes are
- relevant to this message;
-
- - MAY include all FEATURES that the client or server is prepared to
- receive.
-
- This set is expressed as a VERSION and any additional FEATURES
- required.
-
-
-
-Austein & Alvestrand Expires 22 May 2001 [Page 3]
-\f
-draft-ietf-dnsext-edns0dot5-02.txt November 2000
-
-
- In general, we expect that a client or server will include an OPT
- pseudo-RR that indicates:
-
- - The highest VERSION number that the entity generating the message
- supports; and
-
- - A small (possibly empty) set of additional FEATUREs not encompassed
- by the VERSION that the entity deems necessary or desirable.
-
- The above symmetry notwithstanding, we impose one important
- constraint on the server: while a server is allowed to indicate
- whatever FEATUREs it believes are relevant or useful, a server MUST
- NOT make use of any FEATURE in a response that is not within the set
- of FEATUREs indicated by the client that generated the corresponding
- request. That is, a response may say "I support FEATURE FOO"
- regardless of what the client supports, but the rest of the response
- must not use FEATURE FOO unless the client also supports it.
-
- As a special case, if a client explicitly queries for the OPT RR of
- the root zone, the server returns an OPT record including all
- FEATUREs that the server supports. This functionality is provided
- strictly for diagnostic purposes.
-
-Life Cycle
-
- We expect the life cycle of new features to proceed as follows:
-
- - VERSION X is defined and deployed.
-
- - A new FEATURE is defined and experimentally implemented. All
- clients and servers taking part in the experiment use FEATURE to
- indicate support.
-
- - Community consensus is reached that this FEATURE is genuinely
- useful.
-
- - VERSION X+1 is defined, encompassing all FEATUREs from VERSION X,
- plus the new FEATURE (and perhaps others).
-
- - The next generation of DNS software supports VERSION X+1, and never
- use FEATURE.
-
-Risks
-
- While we have tried to provide the ability to deprecate old bad
- protocol features, such an ability should be used only rarely, if at
- all, since by any realistic estimate it takes years (decades?) to
- upgrade all the DNS implementations already in the field.
-
-
-
-Austein & Alvestrand Expires 22 May 2001 [Page 4]
-\f
-draft-ietf-dnsext-edns0dot5-02.txt November 2000
-
-
- A flexible extension mechanism of this type increases the risk that
- some implementors might chose to deploy features designed to hinder
- interoperability (so-called "labeled noninteroperability").
-
-Security Considerations
-
- We do not believe that this protocol enhancement adds any major new
- security risks, but we do believe that it would be helpful in getting
- complicated DNS extensions such as [DNSSEC] deployed more quickly.
-
- As with any enhancement to or complication of the DNS protocol, this
- enhancement offers attackers yet another way to increase the load on
- a name server. Root, TLD and other "major" name servers should view
- excessively complicated FEATURE sets with suspicion, and should not
- allow themselves to be tricked into performing more work than is
- really necessary.
-
-IANA Considerations
-
- IANA will need to allocate an EDNS0 option code for FEATURES.
-
- IANA will need to create a new registry of feature numbers.
-
-Acknowledgments
-
- The authors would like to thank the following people for their help
- in improving this document: Randy Bush, Patrik Faltstrom, Olafur
- Gudmundsson, Bob Halley, and XXX.
-
-References
-
- [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and
- facilities", RFC 1034, November 1987.
-
- [DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation
- and specification", RFC 1035, November 1987.
-
- [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
- [BINARY-LABELS] Crawford, M., "Binary Labels in the Domain Name
- System", RFC 2673 August 1999.
-
-
-
-
-
-
-Austein & Alvestrand Expires 22 May 2001 [Page 5]
-\f
-draft-ietf-dnsext-edns0dot5-02.txt November 2000
-
-
-Author's addresses:
-
- Rob Austein
- InterNetShare.com, Inc.
- 505 West Olive Ave., Suite 321
- Sunnyvale, CA 94086
- USA
-
- sra@hactrn.net
-
- Harald Tveit Alvestrand
- Cisco Systems
- Weidemanns vei 27
- N-7043 Trondheim
- NORWAY
-
- +47 73 50 33 52
- Harald@Alvestrand.no
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein & Alvestrand Expires 22 May 2001 [Page 6]
+++ /dev/null
-
-INTERNET-DRAFT Stuart Kwan
-<draft-ietf-dnsext-gss-tsig-06.txt> Praerit Garg
-February 28, 2003 James Gilroy
-Expires August 28, 2003 Levon Esibov
- Jeff Westhead
- Microsoft Corp.
- Randy Hall
- Lucent Technologies
-
-
-
- GSS Algorithm for TSIG (GSS-TSIG)
-
-
-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 TSIG protocol provides transaction level authentication for DNS.
-TSIG is extensible through the definition of new algorithms. This
-document specifies an algorithm based on the Generic Security Service
-Application Program Interface (GSS-API) (RFC2743). This document updates
-RFC 2845.
-
-
-
-
-
-
-
-
-
-
-
-Expires August 28, 2003 [Page 1]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-Table of Contents
-
-1: Introduction......................................................2
-2: Algorithm Overview................................................3
- 2.1: GSS Details...................................................4
- 2.2: Modifications to the TSIG protocol (RFC 2845).................4
-3: Client Protocol Details...........................................4
- 3.1: Negotiating Context...........................................5
- 3.1.1: Call GSS_Init_sec_context.................................5
- 3.1.2: Send TKEY Query to Server.................................7
- 3.1.3: Receive TKEY Query-Response from Server...................7
- 3.2: Context Established..........................................10
- 3.2.1: Terminating a Context....................................10
-4: Server Protocol Details..........................................10
- 4.1: Negotiating Context..........................................10
- 4.1.1: Receive TKEY Query from Client...........................11
- 4.1.2: Call GSS_Accept_sec_context..............................11
- 4.1.3: Send TKEY Query-Response to Client.......................12
- 4.2: Context Established..........................................13
- 4.2.1: Terminating a Context....................................13
-5: Sending and Verifying Signed Messages............................14
- 5.1: Sending a Signed Message - Call GSS_GetMIC...................14
- 5.2: Verifying a Signed Message - Call GSS_VerifyMIC..............15
-6: Example usage of GSS-TSIG algorithm..............................16
-7: Security Considerations..........................................20
-8: IANA Considerations..............................................20
-9: Conformance......................................................20
-10:Acknowledgements.................................................20
-11:References.......................................................20
-
-1. Introduction
-
-The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
-protocol was developed to provide a lightweight authentication and
-integrity of messages between two DNS entities, such as client and
-server or server and server. TSIG can be used to protect dynamic
-update messages, authenticate regular message or to off-load
-complicated DNSSEC [RFC2535] processing from a client to a server and
-still allow the client to be assured of the integrity of the answers.
-
-The TSIG protocol [RFC2845] is extensible through the definition of new
-algorithms. This document specifies an algorithm based on the Generic
-Security Service Application Program Interface (GSS-API) [RFC2743].
-GSS-API is a framework that provides an abstraction of security to the
-application protocol developer. The security services offered can
-include authentication, integrity, and confidentiality.
-
-The GSS-API framework has several benefits:
-* Mechanism and protocol independence. The underlying mechanisms that
-realize the security services can be negotiated on the fly and varied
-over time. For example, a client and server MAY use Kerberos [RFC1964]
-for one transaction, whereas that same server MAY use SPKM [RFC2025]
-with a different client.
-
-Expires August 28, 2003 [Page 2]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-* The protocol developer is removed from the responsibility of
-creating and managing a security infrastructure. For example, the
-developer does not need to create new key distribution or key
-management systems. Instead the developer relies on the security
-service mechanism to manage this on its behalf.
-
-The scope of this document is limited to the description of an
-authentication mechanism only. It does not discuss and/or propose an
-authorization mechanism. Readers that are unfamiliar with GSS-API
-concepts are encouraged to read the characteristics and concepts section
-of [RFC2743] before examining this protocol in detail. It is also
-assumed that the reader is familiar with [RFC2845], [RFC2930], [RFC1034]
-and [RFC1035].
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
-"RECOMMENDED", and "MAY" in this document are to be interpreted as
-described in RFC 2119 [RFC2119].
-
-
-2. Algorithm Overview
-
-In GSS, client and server interact to create a "security context".
-The security context can be used to create and verify transaction
-signatures on messages between the two parties. A unique security
-context is required for each unique connection between client and
-server.
-
-Creating a security context involves a negotiation between client and
-server. Once a context has been established, it has a finite lifetime
-for which it can be used to secure messages. Thus there are three
-states of a context associated with a connection:
-
- +----------+
- | |
- V |
- +---------------+ |
- | Uninitialized | |
- | | |
- +---------------+ |
- | |
- V |
- +---------------+ |
- | Negotiating | |
- | Context | |
- +---------------+ |
- | |
- V |
- +---------------+ |
- | Context | |
- | Established | |
- +---------------+ |
- | |
- +----------+
-
-Expires August 28, 2003 [Page 3]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-Every connection begins in the uninitialized state.
-
-
-2.1 GSS Details
-
-Client and server MUST be locally authenticated and have acquired
-default credentials before using this protocol as specified in
-Section 1.1.1 "Credentials" in RFC 2743 [RFC2743].
-
-The GSS-TSIG algorithm consists of two stages:
-
-I. Establish security context. The Client and Server use the
-GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate the
-tokens that they pass to each other using [RFC2930] as a transport
-mechanism.
-
-II. Once the security context is established it is used to generate and
-verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs. These
-signatures are exchanged by the Client and Server as a part of the TSIG
-records exchanged in DNS messages sent between the Client and Server,
-as described in [RFC2845].
-
-
-2.2 Modifications to the TSIG protocol (RFC 2845)
-
-Modification to RFC 2845 allows use of TSIG through signing server's
-response in an explicitly specified place in multi message exchange
-between two DNS entities even if client's request wasn't signed.
-
-Specifically Section 4.2 of RFC 2845 MUST be modified as follows.
-
-Replace:
-"The server MUST not generate a signed response to an unsigned
-request."
-
-With:
-"The server MUST not generate a signed response to an unsigned request,
-except in case of response to client's unsigned TKEY query if secret
-key is established on server side after server processed client's
-query. Signing responses to unsigned TKEY queries MUST be explicitly
-specified in the description of an individual secret key establishment
-algorithm."
-
-
-
-3. Client Protocol Details
-
-A unique context is required for each server to which the client sends
-secure messages. A context is identified by a context handle. A
-client maintains a mapping of servers to handles,
-
- (target_name, key_name, context_handle)
-
-Expires August 28, 2003 [Page 4]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-The value key_name also identifies a context handle. The key_name is
-the owner name of the TKEY and TSIG records sent between a client and a
-server to indicate to each other which context MUST be used to process
-the current request.
-
-DNS client and server MAY use various underlying security mechanisms to
-establish security context as described in sections 3 and 4. At the
-same time, in order to guarantee interoperability between DNS clients
-and servers that support GSS-TSIG it is REQUIRED that security
-mechanism used by client enables use of Kerberos v5 (see Section 9
-for more information).
-
-
-3.1 Negotiating Context
-
-In GSS, establishing a security context involves the passing of opaque
-tokens between the client and the server. The client generates the
-initial token and sends it to the server. The server processes the
-token and if necessary, returns a subsequent token to the client. The
-client processes this token, and so on, until the negotiation is
-complete. The number of times the client and server exchange tokens
-depends on the underlying security mechanism. A completed negotiation
-results in a context handle.
-
-The TKEY resource record [RFC2930] is used as the vehicle to transfer
-tokens between client and server. The TKEY record is a general
-mechanism for establishing secret keys for use with TSIG. For more
-information, see [RFC2930].
-
-
-3.1.1 Call GSS_Init_sec_context
-
-To obtain the first token to be sent to a server, a client MUST call
-GSS_Init_sec_context API.
-The following input parameters MUST be used. The outcome of the call is
-indicated with the output values below. Consult Sections 2.2.1
-"GSS_Init_sec_context call" of [RFC2743] for syntax definitions.
-
- INPUTS
- CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use
- default"). Client MAY instead specify some other valid handle
- to its credentials.
- CONTEXT HANDLE input_context_handle = 0
- INTERNAL NAME targ_name = "DNS@<target_server_name>"
- OBJECT IDENTIFIER mech_type = Underlying security
- mechanism chosen by implementers. To guarantee
- interoperability of the implementations of the GSS-TSIG
- mechanism client MUST specify a valid underlying security
- mechanism that enables use of Kerberos v5 (see Section 9 for
- more information).
- OCTET STRING input_token = NULL
- BOOLEAN replay_det_req_flag = TRUE
-
-Expires August 28, 2003 [Page 5]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
- BOOLEAN mutual_req_flag = TRUE
- BOOLEAN deleg_req_flag = TRUE
- BOOLEAN sequence_req_flag = TRUE
- BOOLEAN anon_req_flag = FALSE
- BOOLEAN integ_req_flag = TRUE
- INTEGER lifetime_req = 0 (0 requests a default
- value). Client MAY instead specify another upper bound for the
- lifetime of the context to be established in seconds.
- OCTET STRING chan_bindings = Any valid channel bindings
- as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
-
- OUTPUTS
- INTEGER major_status
- CONTEXT HANDLE output_context_handle
- OCTET STRING output_token
- BOOLEAN replay_det_state
- BOOLEAN mutual_state
- INTEGER minor_status
- OBJECT IDENTIFIER mech_type
- BOOLEAN deleg_state
- BOOLEAN sequence_state
- BOOLEAN anon_state
- BOOLEAN trans_state
- BOOLEAN prot_ready_state
- BOOLEAN conf_avail
- BOOLEAN integ_avail
- INTEGER lifetime_rec
-
-If returned major_status is set to one of the following errors
-
- GSS_S_DEFECTIVE_TOKEN
- GSS_S_DEFECTIVE_CREDENTIAL
- GSS_S_BAD_SIG (GSS_S_BAD_MIC)
- GSS_S_NO_CRED
- GSS_S_CREDENTIALS_EXPIRED
- GSS_S_BAD_BINDINGS
- GSS_S_OLD_TOKEN
- GSS_S_DUPLICATE_TOKEN
- GSS_S_NO_CONTEXT
- GSS_S_BAD_NAMETYPE
- GSS_S_BAD_NAME
- GSS_S_BAD_MECH
- GSS_S_FAILURE
-
-then the the client MUST abandon the algorithm and MUST NOT use the
-GSS-TSIG algorithm to establish this security contex. This document
-does not prescribe which other mechanism could be used to establish
-a security context. Next time when this client needs to establish
-security context, the client MAY use GSS-TSIG algorithm.
-
-Success values of major_status are GSS_S_CONTINUE_NEEDED and
-GSS_S_COMPLETE. The exact success code is important during later
-processing.
-
-Expires August 28, 2003 [Page 6]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-The values of replay_det_state and mutual_state indicate if the
-security package provides replay detection and mutual authentication,
-respectively. If returned major_status is GSS_S_COMPLETE AND one or both
-of these values are FALSE, the client MUST abandon this algorithm.
-
-Client's behavior MAY depend on other OUTPUT parameters according
-to the policy local to the client.
-
-The handle output_context_handle is unique to this negotiation and
-is stored in the client's mapping table as the context_handle that
-maps to target_name.
-
-
-
-3.1.2 Send TKEY Query to Server
-
-An opaque output_token returned by GSS_Init_sec_context is transmitted
-to the server in a query request with QTYPE=TKEY. The token itself
-will be placed in a Key Data field of the RDATA field in the TKEY
-resource record in the additional records section of the query. The
-owner name of the TKEY resource record set queried for and the owner
-name of the supplied TKEY resource record in the additional records
-section MUST be the same. This name uniquely identifies the security
-context to both the client and server, and thus the client SHOULD use
-a value which is globally unique as described in [RFC2930]. To achieve
-global uniqueness, the name MAY contain a UUID/GUID [ISO11578].
-
- TKEY Record
- NAME = client-generated globally unique domain name string
- (as described in [RFC2930])
- RDATA
- Algorithm Name = gss-tsig
- Mode = 3 (GSS-API negotiation - per [RFC2930])
- Key Size = size of output_token in octets
- Key Data = output_token
-
-The remaining fields in the TKEY RDATA, i.e. Inception, Expiration,
-Error, Other Size and Data Fields, MUST be set according to [RFC2930].
-
-The query is transmitted to the server.
-
-Note: if the original client call to GSS_Init_sec_context returned any
-major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE, then
-the client MUST NOT send TKEY query. Client's behavior in this case is
-described above in Section 3.1.1.
-
-
-3.1.3 Receive TKEY Query-Response from Server
-
-Upon the reception of the TKEY query DNS server MUST respond according
-to the description in Section 4. This Section specifies the behavior
-of the client after it receives the matching response to its query.
-
-Expires August 28, 2003 [Page 7]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-The next processing step depends on the value of major_status from the
-most recent call that client performed to GSS_Init_sec_context: either
-GSS_S_COMPLETE or GSS_S_CONTINUE.
-
-
-3.1.3.1 Value of major_status == GSS_S_COMPLETE
-
-If the last call to GSS_Init_sec_context yielded a major_status value
-of GSS_S_COMPLETE and a non-NULL output_token was sent to the server,
-then the client side component of the negotiation is complete and the
-client is awaiting confirmation from the server.
-
-Confirmation is in the form of a query response with RCODE=NOERROR
-and with the last client supplied TKEY record in the answer section
-of the query. The response MUST be signed with a TSIG record. Note
-that server is allowed to sign a response to unsigned client's query
-due to modification to the RFC 2845 specified in Section 2.2 above.
-The signature in the TSIG record MUST be verified using the procedure
-detailed in section 5, Sending and Verifying Signed Messages. If the
-response is not signed, OR if the response is signed but signature is
-invalid, then an attacker has tampered with the message in transit or
-has attempted to send the client a false response. In this case the
-client MAY continue waiting for a response to its last TKEY query until
-the time period since the client sent last TKEY query expires. Such a
-time period is specified by the policy local to the client. This is a
-new option that allows DNS client to accept multiple answers for one
-query ID and select one (not necessarily the first one) based on some
-criteria.
-
-If the signature is verified the context state is advanced to Context
-Established. Proceed to section 3.2 for usage of the security context.
-
-
-3.1.3.2 Value of major_status == GSS_S_CONTINUE
-
-If the last call to GSS_Init_sec_context yielded a major_status value
-of GSS_S_CONTINUE, then the negotiation is not yet complete. The server
-will return to the client a query-response with a TKEY record in the
-Answer section. If the DNS message error is not NO_ERROR or error field
-in the TKEY record is not 0 (i.e. no error), then the client MUST
-abandon this negotiation sequence. The client MUST delete an active
-context by calling GSS_Delete_sec_context providing the associated
-context_handle. The client MAY repeat the negotiation sequence starting
-with the uninitialized state as described in section 3.1. To prevent
-infinite looping the number of attempts to establish a security context
-MUST be limited to ten or less.
-
-If the DNS message error is NO_ERROR and error filed in the TKEY record
-is 0 (i.e. no error), then the client MUST pass a token specified in the
-Key Data field in the TKEY resource record to GSS_Init_sec_context
-using the same parameters values as in previous call except values for
-CONTEXT HANDLE input_context_handle and OCTET STRING input_token as
-described below:
-
-Expires August 28, 2003 [Page 8]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
- INPUTS
- CONTEXT HANDLE input_context_handle = context_handle (this is the
- context_handle corresponding to the key_name which is the
- owner name of the TKEY record in the answer section in the
- TKEY query response)
- OCTET STRING input_token = token from Key field of
- TKEY record
-
-Depending on the following OUTPUT values of GSS_Init_sec_context
- INTEGER major_status
- OCTET STRING output_token
-the client MUST take one of the following actions:
-
-If OUTPUT major_status is set to one of the following values
- GSS_S_DEFECTIVE_TOKEN
- GSS_S_DEFECTIVE_CREDENTIAL
- GSS_S_BAD_SIG (GSS_S_BAD_MIC)
- GSS_S_NO_CRED
- GSS_S_CREDENTIALS_EXPIRED
- GSS_S_BAD_BINDINGS
- GSS_S_OLD_TOKEN
- GSS_S_DUPLICATE_TOKEN
- GSS_S_NO_CONTEXT
- GSS_S_BAD_NAMETYPE
- GSS_S_BAD_NAME
- GSS_S_BAD_MECH
- GSS_S_FAILURE
-
-the client MUST abandon this negotiation sequence. This means that the
-client MUST delete an active context by calling GSS_Delete_sec_context
-providing the associated context_handle. The client MAY repeat the
-negotiation sequence starting with the uninitialized state as described
-in section 3.1. To prevent infinite looping the number of attempts to
-establish a security context MUST be limited to ten or less.
-
-If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE then
-client MUST act as described below.
-
-If the response from the server was signed, and the OUTPUT major_status
-is GSS_S_COMPLETE,then the signature in the TSIG record MUST be verified
-using the procedure detailed in section 5, Sending and Verifying Signed
-Messages. If the signature is invalid, then the client MUST abandon this
-negotiation sequence. This means that the client MUST delete an active
-context by calling GSS_Delete_sec_context providing the associated
-context_handle. The client MAY repeat the negotiation sequence starting
-with the uninitialized state as described in section 3.1. To prevent
-infinite looping the number of attempts to establish a security context
-MUST be limited to ten or less.
-
-If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
-finished. The token output_token MUST be passed to the server in a TKEY
-record by repeating the negotiation sequence beginning with section
-
-Expires August 28, 2003 [Page 9]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-3.1.2. The client MUST place a limit on the number of continuations in
-a context negotiation to prevent endless looping. Such limit SHOULD NOT
-exceed value of 10.
-
-If major_status is GSS_S_COMPLETE and output_token is non-NULL, the
-client-side component of the negotiation is complete but the token
-output_token MUST be passed to the server by repeating the negotiation
-sequence beginning with section 3.1.2.
-
-If major_status is GSS_S_COMPLETE and output_token is NULL, context
-negotiation is complete. The context state is advanced to Context
-Established. Proceed to section 3.2 for usage of the security context.
-
-
-3.2 Context Established
-
-When context negotiation is complete, the handle context_handle MUST be
-used for the generation and verification of transaction signatures.
-
-The procedures for sending and receiving signed messages are described
-in section 5, Sending and Verifying Signed Messages.
-
-
-3.2.1 Terminating a Context
-
-When the client is not intended to continue using the established
-security context, the client SHOULD delete an active context by
-calling GSS_Delete_sec_context providing the associated context_handle,
-AND client SHOULD delete the established context on the DNS server
-by using TKEY RR with the Mode field set to 5, i.e. "key deletion"
-[RFC2930].
-
-
-
-4. Server Protocol Details
-
-As on the client-side, the result of a successful context negotiation
-is a context handle used in future generation and verification of the
-transaction signatures.
-
-A server MAY be managing several contexts with several clients.
-Clients identify their contexts by providing a key name in their
-request. The server maintains a mapping of key names to handles:
-
- (key_name, context_handle)
-
-
-
-4.1 Negotiating Context
-
-A server MUST recognize TKEY queries as security context negotiation
-messages.
-
-Expires August 28, 2003 [Page 10]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-4.1.1 Receive TKEY Query from Client
-
-Upon receiving a query with QTYPE = TKEY, the server MUST examine
-whether the Mode and Algorithm Name fields of the TKEY record in the
-additional records section of the message contain values of 3 and
-gss-tsig, respectively. If they do, then the (key_name, context_handle)
-mapping table is searched for the key_name matching the owner name of
-the TKEY record in the additional records section of the query. If the
-name is found in the table and the security context for this name is
-established and not expired, then the server MUST respond to the query
-with BADNAME error in the TKEY error field. If the name is found in the
-table and the security context is not established, the corresponding
-context_handle is used in subsequent GSS operations. If the name is
-found but the security context is expired, then the server deletes this
-security context, as described in Section 4.2.1, and interprets this
-query as a start of new security context negotiation and performs
-operations described in Section 4.1.2 and 4.1.3. If the name is not
-found, then the server interprets this query as a start of new security
-context negotiation and performs operations described in Section 4.1.2
-and 4.1.3.
-
-
-
-4.1.2 Call GSS_Accept_sec_context
-
-The server performs its side of a context negotiation by calling
-GSS_Accept_sec_context. The following input parameters MUST be used. The
-outcome of the call is indicated with the output values below. Consult
-Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743[RFC2743]
-for syntax definitions.
-
- INPUTS
- CONTEXT HANDLE input_context_handle = 0 if new negotiation,
- context_handle matching
- key_name if ongoing negotiation
- OCTET STRING input_token = token specified in the Key
- field from TKEY RR (from Additional records Section of
- the client's query)
- CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use
- default"). Server MAY instead specify some other valid handle
- to its credentials.
- OCTET STRING chan_bindings = Any valid channel bindings
- as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
-
- OUTPUTS
- INTEGER major_status
- CONTEXT_HANDLE output_context_handle
- OCTET STRING output_token
- INTEGER minor_status
- INTERNAL NAME src_name
- OBJECT IDENTIFIER mech_type
- BOOLEAN deleg_state
-
-Expires August 28, 2003 [Page 11]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
- BOOLEAN mutual_state
- BOOLEAN replay_det_state
- BOOLEAN sequence_state
- BOOLEAN anon_state
- BOOLEAN trans_state
- BOOLEAN prot_ready_state
- BOOLEAN conf_avail
- BOOLEAN integ_avail
- INTEGER lifetime_rec
- CONTEXT_HANDLE delegated_cred_handle
-
-If this is the first call to GSS_Accept_sec_context in a new
-negotiation, then output_context_handle is stored in the server's
-key-mapping table as the context_handle that maps to the name of the
-TKEY record.
-
-
-4.1.3 Send TKEY Query-Response to Client
-
-The server MUST respond to the client with a TKEY query response with
-RCODE = NOERROR, that contains a TKEY record in the answer section.
-
-If OUTPUT major_status is one of the following errors the error field
-in the TKEY record set to BADKEY.
-
- GSS_S_DEFECTIVE_TOKEN
- GSS_S_DEFECTIVE_CREDENTIAL
- GSS_S_BAD_SIG (GSS_S_BAD_MIC)
- GSS_S_DUPLICATE_TOKEN
- GSS_S_OLD_TOKEN
- GSS_S_NO_CRED
- GSS_S_CREDENTIALS_EXPIRED
- GSS_S_BAD_BINDINGS
- GSS_S_NO_CONTEXT
- GSS_S_BAD_MECH
- GSS_S_FAILURE
-
-If OUTPUT major_status is set to GSS_S_COMPLETE or
-GSS_S_CONTINUE_NEEDED then server MUST act as described below.
-
-If major_status is GSS_S_COMPLETE the server component of the
-negotiation is finished. If output_token is non-NULL, then it MUST be
-returned to the client in a Key Data field of the RDATA in TKEY. The
-error field in the TKEY record is set to NOERROR. The message MUST be
-signed with a TSIG record as described in section 5, Sending and
-Verifying Signed Messages. Note that server is allowed to sign a
-response to unsigned client's query due to modification to the RFC
-2845 specified in Section 2.2 above. The context state is advanced to
-Context Established. Section 4.2 discusses the usage of the security
-context.
-
-
-
-Expires August 28, 2003 [Page 12]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-If major_status is GSS_S_COMPLETE and output_token is NULL, then the
-TKEY record received from the client MUST be returned in the Answer
-section of the response. The message MUST be signed with a TSIG record
-as described in section 5, Sending and Verifying Signed Messages. Note
-that server is allowed to sign a response to unsigned client's query
-due to modification to the RFC 2845 specified in section 2.2 above. The
-context state is advanced to Context Established. Section 4.2 discusses
-the usage of the security context.
-
-If major_status is GSS_S_CONTINUE, the server component of the
-negotiation is not yet finished. The server responds to the TKEY
-query with a standard query response, placing in the answer section a
-TKEY record containing output_token in the Key Data RDATA field. The
-error field in the TKEY record is set to NOERROR. The server MUST limit
-the number of times that a given context is allowed to repeat, to
-prevent endless looping. Such limit SHOULD NOT exceed value of 10.
-
-In all cases except if major_status is GSS_S_COMPLETE and output_token
-is NULL other TKEY record fields MUST contain the following values:
- NAME = key_name
- RDATA
- Algorithm Name = gss-tsig
- Mode = 3 (GSS-API negotiation - per [RFC2930])
- Key Size = size of output_token in octets
-
-The remaining fields in the TKEY RDATA, i.e. Inception, Expiration,
-Error, Other Size and Data Fields, MUST be set according to [RFC2930].
-
-
-
-4.2 Context Established
-
-When context negotiation is complete, the handle context_handle
-is used for the generation and verification of transaction signatures.
-The handle is valid for a finite amount of time determined by the
-underlying security mechanism. A server MAY unilaterally terminate
-a context at any time (see section 4.2.1).
-
-Server SHOULD limit the amount of memory used to cache established
-contexts.
-
-The procedures for sending and receiving signed messages are given in
-section 5, Sending and Verifying Signed Messages.
-
-
-4.2.1 Terminating a Context
-
-A server can terminate any established context at any time. The
-server MAY hint to the client that the context is being deleted by
-including a TKEY RR in a response with the Mode field set to 5, i.e.
-"key deletion" [RFC2930].
-An active context is deleted by calling GSS_Delete_sec_context
-providing the associated context_handle.
-
-Expires August 28, 2003 [Page 13]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-5. Sending and Verifying Signed Messages
-
-5.1 Sending a Signed Message - Call GSS_GetMIC
-
-The procedure for sending a signature-protected message is specified
-in [RFC2845]. The data to be passed to the signature routine includes
-the whole DNS message with specific TSIG variables appended. For the
-exact format, see [RFC2845]. For this protocol, use the following
-TSIG variable values:
-
- TSIG Record
- NAME = key_name that identifies this context
- RDATA
- Algorithm Name = gss-tsig
-
-Assign the remaining fields in the TSIG RDATA appropriate values
-as described in [RFC2845].
-
-The signature is generated by calling GSS_GetMIC. The following input
-parameters MUST be used. The outcome of the call is indicated with the
-output values specified below. Consult Sections 2.3.1 "GSS_GetMIC
-call" of the RFC 2743[RFC2743] for syntax definitions.
-
- INPUTS
- CONTEXT HANDLE context_handle = context_handle for key_name
- OCTET STRING message = outgoing message plus TSIG
- variables (per [RFC2845])
- INTEGER qop_req = 0 (0 requests a default
- value). Caller MAY instead specify other valid value (for
- details see Section 1.2.4 in [RFC2743])
-
- OUTPUTS
- INTEGER major_status
- INTEGER minor_status
- OCTET STRING per_msg_token
-
-If major_status is GSS_S_COMPLETE, then signature generation
-succeeded. The signature in per_msg_token is inserted into the
-Signature field of the TSIG RR and the message is transmitted.
-
-If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED or
-GSS_S_FAILURE the caller MUST delete the security context, return to the
-uninitialized state and SHOULD negotiate a new security context, as
-described above in Section 3.1
-
-If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry
-for key_name from the (target_ name, key_name, context_handle) mapping
-table, return to the uninitialized state and SHOULD negotiate a new
-security context, as described above in Section 3.1
-
-If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the
-GSS_GetMIC call with allowed QOP value. The number of such repetitions
-MUST be limited to prevent infinite loops.
-
-Expires August 28, 2003 [Page 14]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-5.2 Verifying a Signed Message - Call GSS_VerifyMIC
-
-The procedure for verifying a signature-protected message is specified
-in [RFC2845].
-The NAME of the TSIG record determines which context_handle maps to
-the context that MUST be used to verify the signature. If the NAME
-does not map to an established context, the server MUST send a
-standard TSIG error response to the client indicating BADKEY in the
-TSIG error field (as described in [RFC2845]).
-
-For the GSS algorithm, a signature is verified by using GSS_VerifyMIC:
- INPUTS
- CONTEXT HANDLE context_handle = context_handle for key_name
- OCTET STRING message = incoming message plus TSIG
- variables (per [RFC2845])
- OCTET STRING per_msg_token = Signature field from TSIG RR
-
- OUTPUTS
- INTEGER major_status
- INTEGER minor_status
- INTEGER qop_state
-
-If major_status is GSS_S_COMPLETE, the signature is authentic and the
-message was delivered intact. Per [RFC2845], the timer values of the
-TSIG record MUST also be valid before considering the message to be
-authentic. The caller MUST not act on the request or response in the
-message until these checks are verified.
-
-When a server is processing a client request,
-the server MUST send a standard TSIG error response to the client
-indicating BADKEY in the TSIG error field as described in [RFC2845],
-if major_status is set to one of the following values
- GSS_S_DEFECTIVE_TOKEN
- GSS_S_BAD_SIG (GSS_S_BAD_MIC)
- GSS_S_DUPLICATE_TOKEN
- GSS_S_OLD_TOKEN
- GSS_S_UNSEQ_TOKEN
- GSS_S_GAP_TOKEN
- GSS_S_CONTEXT_EXPIRED
- GSS_S_NO_CONTEXT
- GSS_S_FAILURE
-
-
-If the timer values of the TSIG record are invalid, the message MUST
-NOT be considered authentic. If this error checking fails when a server
-is processing a client request, the appropriate error response MUST be
-sent to the client according to [RFC2845].
-
-
-
-
-
-
-Expires August 28, 2003 [Page 15]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-6. Example usage of GSS-TSIG algorithm
-
-This Section describes an example where a Client, client.example.com,
-and a Server, server.example.com, establish a security context according
-to the algorithm described above.
-
-
- I. Client initializes security context negotiation
- To establish a security context with a server, server.example.com, the
- Client calls GSS_Init_sec_context with the following parameters
- (Note that some INPUT and OUTPUT parameters not critical for this
- algorithm are not described in this example)
- CONTEXT HANDLE input_context_handle = 0
- INTERNAL NAME targ_name = "DNS@server.example.com"
- OCTET STRING input_token = NULL
- BOOLEAN replay_det_req_flag = TRUE
- BOOLEAN mutual_req_flag = TRUE
-
- The OUTPUTS parameters returned by GSS_Init_sec_context include
- INTEGER major_status = GSS_S_CONTINUE_NEEDED
- CONTEXT HANDLE output_context_handle context_handle
- OCTET STRING output_token output_token
- BOOLEAN replay_det_state = TRUE
- BOOLEAN mutual_state = TRUE
-
- Client verifies that replay_det_state and mutual_state values are
- TRUE. Since the major_status is GSS_S_CONTINUE_NEEDED, which is a
- success OUTPUT major_status value, client stores context_handle that
- maps to "DNS@server.example.com" and proceeds to the next step.
-
-
- II. Client sends a query with QTYPE = TKEY to server
- Client sends a query with QTYPE = TKEY for a client-generated globally
- unique domain name string, 789.client.example.com.server.example.com.
- Query contains a TKEY record in its Additional records section with
- the following fields (Note that some fields not specific to this
- algorithm are not specified)
-
- NAME = 789.client.example.com.server.example.com.
- RDATA
- Algorithm Name = gss-tsig
- Mode = 3 (GSS-API negotiation - per [RFC2930])
- Key Size = size of output_token in octets
- Key Data = output_token
-
- After the key_name 789.client.example.com.server.example.com.
- is generated it is stored in the client's (target_name, key_name,
- context_handle) mapping table.
-
-
-
-
-
-Expires August 28, 2003 [Page 16]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
- III. Server receives a query with QTYPE = TKEY
- When server receives a query with QTYPE = TKEY, the server verifies
- that Mode and Algorithm fields in the TKEY record in the Additional
- records section of the query are set to 3 and "gss-tsig" respectively.
- It finds that the key_name 789.client.example.com.server.example.com.
- is not listed in its (key_name, context_handle) mapping table.
-
-
- IV. Server calls GSS_Accept_sec_context
- To continue security context negotiation server calls
- GSS_Accept_sec_context with the following parameters (Note that some
- INPUT and OUTPUT parameters not critical for this algorithm are not
- described in this example)
- INPUTS
- CONTEXT HANDLE input_context_handle = 0
- OCTET STRING input_token = token specified in the Key
- field from TKEY RR (from Additional
- records section of the client's query)
- The OUTPUTS parameters returned by GSS_Accept_sec_context include
- INTEGER major_status = GSS_S_CONTINUE_NEEDED
- CONTEXT_HANDLE output_context_handle context_handle
- OCTET STRING output_token output_token
-
- Server stores the mapping of the
- 789.client.example.com.server.example.com. to OUTPUT context_handle
- in its (key_name, context_handle) mapping table.
-
-
- V. Server responds to the TKEY query
- Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's
- call to GSS_Accept_sec_context, the server responds to the TKEY query
- placing in the answer section a TKEY record containing output_token in
- the Key Data RDATA field. The error field in the TKEY record is set to
- 0. The RCODE in the query response is set to NOERROR.
-
-
- VI. Client processes token returned by server
- When the client receives the TKEY query response from the server, the
- client calls GSS_Init_sec_context with the following parameters (Note
- that some INPUT and OUTPUT parameters not critical for this algorithm
- are not described in this example)
- CONTEXT HANDLE input_context_handle = the context_handle stored
- in the client's mapping table entry (DNS@server.example.com.,
- 789.client.example.com.server.example.com., context_handle)
- INTERNAL NAME targ_name = "DNS@server.example.com"
- OCTET STRING input_token = token from Key field of TKEY
- record from the Answer section of the server's response
- BOOLEAN replay_det_req_flag = TRUE
- BOOLEAN mutual_req_flag = TRUE
-
-
- The OUTPUTS parameters returned by GSS_Init_sec_context include
- INTEGER major_status = GSS_S_COMPLETE
-
-Expires August 28, 2003 [Page 17]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
- CONTEXT HANDLE output_context_handle = context_handle
- OCTET STRING output_token = output_token
- BOOLEAN replay_det_state = TRUE
- BOOLEAN mutual_state = TRUE
-
- Since the major_status is set to GSS_S_COMPLETE the client side
- security context is established, but since the output_token is not
- NULL client MUST send a TKEY query to the server as described below.
-
-
- VII. Client sends a query with QTYPE = TKEY to server
- Client sends to the server a TKEY query for the
- 789.client.example.com.server.example.com. name. Query contains a TKEY
- record in its Additional records section with the following fields
- (Note that some INPUT and OUTPUT parameters not critical to this
- algorithm are not described in this example)
- NAME = 789.client.example.com.server.example.com.
- RDATA
- Algorithm Name = gss-tsig
- Mode = 3 (GSS-API negotiation - per [RFC2930])
- Key Size = size of output_token in octets
- Key Data = output_token
-
-
- VIII. Server receives a TKEY query
- When the server receives a TKEY query, the server verifies that Mode
- and Algorithm fields in the TKEY record in the Additional records
- section of the query are set to 3 and gss-tsig, repectively. It
- finds that the key_name 789.client.example.com.server.example.com. is
- listed in its (key_name, context_handle) mapping table.
-
-
- IX. Server calls GSS_Accept_sec_context
- To continue security context negotiation server calls
- GSS_Accept_sec_context with the following parameters (Note that some
- INPUT and OUTPUT parameters not critical for this algorithm are not
- described in this example)
- INPUTS
- CONTEXT HANDLE input_context_handle = context_handle from the
- (789.client.example.com.server.example.com., context_handle)
- entry in the server's mapping table
- OCTET STRING input_token = token specified in the Key
- field of TKEY RR (from Additional records Section of
- the client's query)
-
- The OUTPUTS parameters returned by GSS_Accept_sec_context include
- INTEGER major_status = GSS_S_COMPLETE
- CONTEXT_HANDLE output_context_handle = context_handle
- OCTET STRING output_token = NULL
-
-
-
-
-Expires August 28, 2003 [Page 18]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
- Since major_status = GSS_S_COMPLETE, the security context on the
- server side is established, but the server still needs to respond to
- the client's TKEY query, as described below. The security context
- state is advanced to Context Established.
-
-
- X. Server responds to the TKEY query
- Since the major_status = GSS_S_COMPLETE in the last server's call to
- GSS_Accept_sec_context and the output_token is NULL, the server
- responds to the TKEY query placing in the answer section a TKEY record
- that was sent by the client in the Additional records section of the
- client's latest TKEY query. In addition to this server places a
- TSIG record in additional records section of its response. Server
- calls GSS_GetMIC to generate a signature to include it in the TSIG
- record. The server specifies the following GSS_GetMIC INPUT
- parameters:
- CONTEXT HANDLE context_handle = context_handle from the
- (789.client.example.com.server.example.com., context_handle)
- entry in the server's mapping table
- OCTET STRING message = outgoing message plus TSIG
- variables (as described in [RFC2845])
-
- The OUTPUTS parameters returned by GSS_GetMIC include
- INTEGER major_status = GSS_S_COMPLETE
- OCTET STRING per_msg_token
-
- Signature field in the TSIG record is set to per_msg_token.
-
-
- XI. Client processes token returned by server
- Client receives the TKEY query response from the server. Since the
- major_status was GSS_S_COMPLETE in the last client's call to
- GSS_Init_sec_context, the client verifies that the server's response
- is signed. To validate the signature client calls GSS_VerifyMIC with
- the following parameters:
-
- INPUTS
- CONTEXT HANDLE context_handle = context_handle for
- 789.client.example.com.server.example.com. key_name
- OCTET STRING message = incoming message plus TSIG
- variables (as described in [RFC2845])
- OCTET STRING per_msg_token = Signature field from TSIG RR
- included in the server's query response
-
- Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the
- signature is validated, security negotiation is complete and the
- security context state is advanced to Context Established. These
- client and server will use the established security context to sign
- and validate the signatures when they exchange packets with each
- other until the context expires.
-
-
-
-Expires August 28, 2003 [Page 19]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-7. Security Considerations
-
-This document describes a protocol for DNS security using GSS-API.
-The security provided by this protocol is only as effective as the
-security provided by the underlying GSS mechanisms.
-
-All the security considerations from RFC2845, RFC2930 and RFC 2743
-apply to the protocol described in this document.
-
-
-8. IANA Considerations
-
-The authors request that the IANA reserve the TSIG Algorithm name
-gss-tsig for the use in the Algorithm fields of TKEY and TSIG resource
-records. This Algorithm name refers to the algorithm described in this
-document. The requirement to have this name registered with IANA is
-specified in RFC 2845.
-
-
-9. Conformance
-
-The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
-choose the underlying security mechanisms that enables security context
-negotiation. GSS API using SPNEGO [RFC2478] enables client and server to
-negotiate and choose such underlying security mechanisms on the fly. To
-support such flexibility, DNS clients and servers SHOULD specify SPNEGO
-mech_type in their GSS API calls. At the same time, in order to
-guarantee interoperability between DNS clients and servers that support
-GSS-TSIG it is required that
-- DNS servers specify SPNEGO mech_type
-- GSS APIs called by DNS client support Kerberos v5
-- GSS APIs called by DNS server support SPNEGO [RFC2478] and
- Kerberos v5.
-
-In addition to these, GSS APIs used by DNS client and server MAY also
-support other underlying security mechanisms.
-
-
-10. Acknowledgements
-
-The authors of this document would like to thank the following people
-for their contribution to this specification: Chuck Chan, Mike Swift,
-Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake 3rd and Erik
-Nordmark.
-
-
-11. References
-
-[RFC2743] J. Linn, "Generic Security Service Application Program
- Interface, Version 2 , Update 1", RFC 2743, RSA Laboratories,
- January 2000.
-
-
-
-Expires August 28, 2003 [Page 20]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, ISC, NAI Labs, Motorola, Nominum, May, 2000,
-
-[RFC2930] D. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY RR)",
- RFC 2930, Motorola, September 2000.
-
-[RFC2535] D. Eastlake 3rd, "Domain Name System Security Extensions,"
- RFC 2535, IBM, March 1999.
-
-[RFC2137] D. Eastlake 3rd, "Secure Domain Name System Dynamic Update,"
- RFC 2137, CyberCash, April 1997.
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, November 1987.
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1034, November 1987.
-
-[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
- RFC 1964, OpenVision Technologies, June 1996.
-
-[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
- RFC 2025, Bell-Northern Research, October 1996.
-
-[RFC2478] Baize, E., Pinkas, D., "The Simple and Protected GSS-API
- Negotiation Mechanism", RFC 2478, Bull, December 1998.
-
-[ISO11578]"Information technology", "Open Systems
- Interconnection", "Remote Procedure Call",
- ISO/IEC 11578:1996, http://www.iso.ch/cate/d2229.html.
-
-
-12. Author's Addresses
-
-Stuart Kwan Praerit Garg
-Microsoft Corporation Microsoft Corporation
-One Microsoft Way One Microsoft Way
-Redmond, WA 98052 Redmond, WA 98052
-USA USA
-skwan@microsoft.com praeritg@microsoft.com
-
-James Gilroy Levon Esibov
-Microsoft Corporation Microsoft Corporation
-One Microsoft Way One Microsoft Way
-Redmond, WA 98052 Redmond, WA 98052
-USA USA
-jamesg@microsoft.com levone@microsoft.com
-
-
-
-Expires August 28, 2003 [Page 21]
-
-INTERNET-DRAFT GSS-TSIG February 28, 2003
-
-
-Randy Hall Jeff Westhead
-Lucent Technologies Microsoft Corporation
-400 Lapp Road One Microsoft Way
-Malvern PA 19355 Redmond, WA 98052
-USA USA
-randyhall@lucent.com jwesth@microsoft.com
-
-
-
-Expires August 28, 2003 [Page 22]
+++ /dev/null
-
-INTERNET-DRAFT Donald E. Eastlake 3rd
-Clarifies STD0013 Motorola Laboratories
-Expires September 2003 April 2003
-
-
-
- Domain Name System (DNS) Case Insensitivity Clarification
- ------ ---- ------ ----- ---- ------------- -------------
- <draft-ietf-dnsext-insensitive-03.txt>
-
- Donald E. Eastlake 3rd
-
-
-
-Status of This Document
-
- Distribution of this document is unlimited. Comments should be sent
- to the DNSEXT working group at namedroppers@ops.ietf.org.
-
- 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
-
- Domain Name System (DNS) names are "case insensitive". This document
- explains exactly what that means and provides a clear specification
- of the rules. This clarification should not have any interoperability
- consequences.
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Acknowledgements
-
- The contributions to this document of Rob Austein, Olafur
- Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
- Andreas Gustafsson, Andrew Main, and Scott Seligman are gratefully
- acknowledged.
-
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Acknowledgements...........................................2
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. Case Insensitivity of DNS Labels........................3
- 2.1 Escaping Unusual DNS Label Octets......................3
- 2.2 Example Labels with Escapes............................4
- 2.3 Name Lookup Case Insensitivity.........................4
- 2.4 Original DNS Label Types...............................5
- 3. Additional DNS Case Insensitivity Considerations........5
- 3.1 CLASS Case Insensitivity Considerations................5
- 3.2 Extended Label Type Case Insensitivity Considerations..5
- 4. Case on Input and Output................................6
- 4.1 DNS Output Case Preservation...........................6
- 4.2 DNS Input Case Preservation............................6
- 4.3 Wildcard Matching......................................7
- 5. Internationalized Domain Names..........................7
- 6. Security Considerations.................................7
-
- Normative References.......................................9
- Informative References.....................................9
- -02 to -03 Changes........................................10
- Author's Address..........................................10
- Expiration and File Name..................................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information. Each node in the DNS tree has a name consisting of
- zero or more labels [STD 13][RFC 1591, 2606] that are treated in a
- case insensitive fashion. This document clarifies the meaning of
- "case insensitive" for the DNS.
-
- 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. Case Insensitivity of DNS Labels
-
- DNS was specified in the era of [ASCII]. DNS names were expected to
- look like most host names or Internet email address right halves (the
- part after the at-sign, "@") or be numeric as in the in-addr.arpa
- part of the DNS name space. For example,
-
- foo.example.net.
- aol.com.
- www.gnu.ai.mit.edu.
- or 69.2.0.192.in-addr.arpa.
-
- Case varied alternatives to the above would be DNS names like
-
- Foo.ExamplE.net.
- AOL.COM.
- WWW.gnu.AI.mit.EDU.
- or 69.2.0.192.in-ADDR.ARPA.
-
- The individual octets of which DNS names consist are not limited to
- valid ASCII character codes. They are as 8-bit bytes and all values
- are allowed. Many applications, however, interprete them as ASCII
- characters.
-
-
-
-2.1 Escaping Unusual DNS Label Octets
-
- In Master Files [STD 13] and other human readable and writable ASCII
- contexts, an escape is needed for the byte value for period (0x2E,
- ".") and all octet values outside of the inclusive range of 0x21 ("!")
- to 0x7E ("~"). That is to say, 0x2E and all octet values in the two
- inclusive ranges 0x00 to 0x20 and 0x7F to 0xFF.
-
- One typographic convention for octets that do not correspond to an
-
-
-D. Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- ASCII printing graphic is to use a back-slash followed by the value of
- the octet as an unsigned integer represented by exactly three decimal
- digits.
-
- The same convention can be used for printing ASCII characters so that
- they will be treated as a normal label character. This includes the
- back-slash character used in this convention itself and the special
- label separator period (".") which can be expressed as \092 and \046
- respectively. It is advisable to avoid using a backslash to quote an
- immediately following non-printing ASCII character code to avoid
- implementation difficulties.
-
- A back-slash followed by only one or two decimal digits is
- undefined. A back-slash followed by four decimal digits produces two
- octets, the first octet having the value of the first three digits
- considered as a decimal number and the second octet being the
- character code for the fourth decimal digit.
-
-
-
-2.2 Example Labels with Escapes
-
- The first example below shows embedded spaces and a period (".")
- within a label. The second one show a 5 octet label where the second
- octet has all bits zero, the third is a backslahs,
- and the fourth octet has all bits one.
-
- Donald\032E\.\032Eastlake\0323rd.example.
- and a\000\\\255z.example.
-
-
-
-2.3 Name Lookup Case Insensitivity
-
- The design decision was made that comparisons on name lookup for DNS
- queries should be case insensitive [STD 13]. That is to say, a lookup
- string octet with a value in the inclusive range of 0x41 to 0x5A, the
- upper case ASCII letters, MUST match the identical value and also
- match the corresponding value in the inclusive range 0x61 to 0x7A,
- the lower case ASCII letters. And a lookup string octet with a lower
- case ASCII letter value MUST similarly match the identical value and
- also match the corresponding value in the upper case ASCII letter
- range.
-
- (Historical Note: the terms "upper case" and "lower case" were
- invented after movable type. The terms originally referred to the
- two font trays for storing, in partitioned areas, the different
- physical type elements. Before movable type, the nearest equivalent
- terms were "majuscule" and "minuscule".)
-
-
-
-D. Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- One way to implement this rule would be, when comparing octets, to
- subtract 0x20 from all octets in the inclusive range 0x61 to 0x7A
- before the comparison. Such an operation is commonly known as "case
- folding" but implementation via case folding is not required. Note
- that the DNS case insensitivity does NOT correspond to the case
- folding specified in iso-8859-1 or iso-8859-2. For example, the
- octets 0xDD (\221) and 0xFD (\253) do NOT match although in other
- contexts, where they are interpreted as the upper and lower case
- version of "Y" with an acute accent, they might.
-
-
-
-2.4 Original DNS Label Types
-
- DNS labels in wire encoded names have a type associated with them.
- The original DNS standard [RFC 1035] had only two types. ASCII
- labels, with a length of from zero to 63 octets and indirect labels
- which consist of an offset pointer to a name location elsewhere in
- the wire encoding on a DNS message. (The ASCII label of length zero
- is reserved for use as the name of the root node of the name tree.)
- ASCII labels follow the ASCII case conventions described above.
- Indirect labels are, in effect, replaced by the name to which they
- point which is then treated with the case insensitivity rules in this
- document.
-
-
-
-3. Additional DNS Case Insensitivity Considerations
-
- This section clarifies the effect of DNS CLASS and extended Label
- Type on case insensitivity.
-
-
-
-3.1 CLASS Case Insensitivity Considerations
-
- As described in [STD 13] and [RFC 2929], DNS has an additional axis
- for data location called CLASS. The only CLASS in global use at this
- time is the "IN" or Internet CLASS.
-
- The handling of DNS label case is not CLASS dependent.
-
-
-
-3.2 Extended Label Type Case Insensitivity Considerations
-
- DNS was extended by [RFC 2671] to have additional label type numbers
- available. (The only such type defined so far is the BINARY type [RFC
- 2673].)
-
-
-
-D. Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- The ASCII case insensitivity conventions, or case folding, only apply
- to ASCII labels, that is to say, label type 0x0, whether appearing
- directly or invoked by indirect labels.
-
-
-
-4. Case on Input and Output
-
- While ASCII label comparisons are case insensitive, case MUST be
- preserved on output, except when output is optimized by the use of
- indirect labels, and preserved when convenient on input.
-
-
-
-4.1 DNS Output Case Preservation
-
- [STD 13] views the DNS namespace as a node tree. ASCII output is as
- if a name was marshalled by taking the label on the node whose name
- is to be output, converting it to a typographically encoded ASCII
- string, walking up the tree outputting each label encountered, and
- preceding all labels but the first with a period ("."). Wire output
- follows the same sequence but each label is wire encoded and no
- periods inserted. No "case conversion" or "case folding" is done
- during such output operations. However, to optimize output, indirect
- labels may be used to point to names elsewhere in the DNS answer. In
- determining whether the name to be pointed to is the "same" as the
- remainder of the name being optimized, the case insensitive
- comparison specified above is done. Thus such optimization MAY
- destroy the output preservation of case. This type of optimization is
- commonly called "name compression".
-
-
-
-4.2 DNS Input Case Preservation
-
- Originally, DNS input came from an ASCII Master File as defined in
- [STD 13]. DNS Dynamic update has been added as a source of DNS data
- [RFC 2136, 3007]. When a node in the DNS name tree is created by such
- input, no case conversion is done and the case of ASCII labels is
- preserved if they are for nodes being created. However, when a name
- label is input for a node that already exist in DNS data being
- augmented or updated, the situation is more complex. Implemenations
- may retain the case first input for such a label or allow new input
- to override the old case or maintain separate copies preserving the
- input case.
-
- For example, if data with owner name "foo.bar.example" is input and
- then later data with owner name "xyz.BAR.example" is input, the name
- of the label on the "bar.example" node, i.e. "bar", might or might
- not be changed to "BAR" or the actual input case could be preserved.
-
-
-D. Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- Thus later retrieval of data stored under "xyz.bar.example" in this
- case can easily result is obtaining data with "xyz.BAR.example". The
- same considerations apply when inputting multiple data records with
- owner names differing only in case. From the example above, if an "A"
- record is stored under owner name "xyz.BAR.example" and then a second
- "A" record under "XYZ.BAR.example", the second MAY be stored with the
- first (lower case initial label) name.
-
- Note that the order of insertion into a server database of the DNS
- name tree nodes that appear in a Master File is not defined so that
- the results of inconsistent capitalization in a Master File are
- unpredicatable output capitalization.
-
-
-
-4.3 Wildcard Matching
-
- There is one additional instance of note, which reflects the general
- rules that output case reflects input case unless there is
- conflicting capitalization in the DNS database or the output case is
- hidden by name compression. This is when a query matches a wildcard
- in the DNS database at a server. In that case, the answer SHOULD
- reflect the input case of the label or labels that matched the
- wildcard unless they are replaced by an indirect label which MAY
- point to a name with different capitalization.
-
-
-
-5. Internationalized Domain Names
-
- A scheme has been adopted for "internationalized domain names" and
- "internationalized labels" as described in [RFC 3490, 3454, 3491, and
- 3492]. It makes most of [UNICODE] available through a separate
- application level transformation from internationalized domain name
- to DNS domain name and from DNS domain name to internationalized
- domain name. Any case insensitivity that internationalized domain
- names and labels have varies depending on the script and is handled
- entirely as part of the transformation described in [RFC 3454] and
- [RFC 3491] which should be seen for further details. This is not a
- part of the DNS as standardized in STD 13.
-
-
-
-6. Security Considerations
-
- The equivalence of certain DNS label types with case differences, as
- clarified in this document, can lead to security problems. For
- example, a user could be confused by believing two domain names
- differing only in case were actually different names.
-
-
-
-D. Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- Furthermore, a domain name may be used in contexts other than the
- DNS. It could be used as a case sensitive index into some data base
- system. Or it could be interpreted as binary data by some integrity
- or authentication code system. These problems can usually be handled
- by using a standardized or "canonical" form of the DNS ASCII type
- labels, that is, always map the ASCII letter value octets in ASCII
- labels to some specific pre-chosen case, either upper case or lower
- case. An example of a canonical form for domain names (and also a
- canonical ordering for them) appears in Section 8 of [RFC 2535]. See
- also [UNKRR].
-
- Finally, a non-DNS name may be stored into DNS with the false
- expectation that case will always be preserved. For example, although
- this would be quite rare, on a system with case sensitive email
- address local parts, an attempt to store two "RP" records that
- differed only in case would probably produce unexpected results that
- might have security implications. That is because the entire email
- address, including the possibly case sensitive local or left hand
- part, is encoded into a DNS name in a readable fashion where the case
- of some letters might be changed on output as described above.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-D. Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
-Normative References
-
- [ASCII] - ANSI, "USA Standard Code for Information Interchange",
- X3.4, American National Standards Institute: New York, 1968.
-
- [RFC 1034, 1035] - See [STD 13].
-
- [RFC 2119] - "Key words for use in RFCs to Indicate Requirement
- Levels", S. Bradner, March 1997.
-
- [RFC 2136] - P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound,
- "Dynamic Updates in the Domain Name System (DNS UPDATE)", April 1997.
-
- [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions",
- March 1999.
-
- [RFC 3007] - B. Wellington, "Secure Domain Name System (DNS) Dynamic
- Update", November 2000.
-
- [STD 13]
- - P. Mockapetris, "Domain names - concepts and facilities", RFC
- 1034, November 1987.
- - P. Mockapetris, "Domain names - implementation and
- specification", RFC 1035, November 1987.
-
- [UNKRR] - Andreas Gustafsson, "Handling of Unknown DNS RR Types",
- draft-ietf-dnsext-unknown-rrs-05.txt, March 2003.
-
-
-
-Informative References
-
- [RFC 1591] - J. Postel, "Domain Name System Structure and
- Delegation", March 1994.
-
- [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names",
- June 1999.
-
- [RFC 2929] - D. Eastlake, E. Brunner-Williams, B. Manning, "Domain
- Name System (DNS) IANA Considerations", September 2000.
-
- [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August
- 1999.
-
- [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System",
- August 1999.
-
- [RFC 3454] - P. Hoffman, M. Blanchet, "Preparation of
- Internationalized String ("stringprep")", December 2002.
-
-
-
-D. Eastlake 3rd [Page 9]
-\f
-
-INTERNET-DRAFT DNS Case Insensitivity
-
-
- [RFC 3490] - P. Faltstrom, P. Hoffman, A. Costello,
- "Internationalizing Domain Names in Applications (IDNA)", March 2003.
-
- [RFC 3491] - P. Hoffman, M. Blanchet, "Nameprep: A Stringprep Profile
- for Internationalized Domain Names (IDN)", March 2003.
-
- [RFC 3492] - A. Costello, "Punycode: A Bootstring encoding of Unicode
- for Internationalized Domain Names in Applications (IDNA)", March
- 2003.
-
- [UNICODE] - The Unicode Consortium, "The Unicode Standard",
- <http://www.unicode.org/unicode/standard/standard.html>.
-
-
-
--02 to -03 Changes
-
- The following changes were made between draft version -02 and -03:
-
- 1. Add internationalized domain name section and references.
-
- 2. Change to indicate that later input of a label for an existing DNS
- name tree node may or may not be normalized to the earlier input or
- override it or both may be preserved.
-
- 3. Numerous minor wording changes.
-
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola Laboratories
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1 508-851-8280 (w)
- +1 508-634-2066 (h)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires September 2003.
-
- Its file name is draft-ietf-dnsext-insensitive-03.txt.
-
-
-
-
-
-D. Eastlake 3rd [Page 10]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group R. Austein
-draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt InterNetShare, Inc.
- July 2001
-
-
- Tradeoffs in DNS support for IPv6
-
-
-Status of this document
-
- 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>
-
- Distribution of this document is unlimited. Please send comments to
- the Namedroppers mailing list <namedroppers@ops.ietf.org>.
-
-Abstract
-
- The IETF has two different proposals on the table for how to do DNS
- support for IPv6, and has thus far failed to reach a clear consensus
- on which approach is better. This note attempts to examine the pros
- and cons of each approach, in the hope of clarifying the debate so
- that we can reach closure and move on.
-
-Introduction
-
- RFC 1886 [Tweedledee] specified straightforward mechanisms to support
- IPv6 addresses in the DNS. These mechanisms closely resemble the
- mechanisms used to support IPv4, and with a minor improvement to the
- reverse mapping mechanism based on experience with CIDR. RFC 1886 is
- currently listed as a Proposed Standard.
-
-
-
-
-Austein Expires 12 January 2002 [Page 1]
-\f
-draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
-
-
- RFC 2874 [Tweedledum] specified enhanced mechanisms to support IPv6
- addresses in the DNS. These mechanisms provide new features that
- make it possible for an IPv6 address stored in the DNS to be broken
- up into multiple DNS resource records in ways that can reflect the
- network topology underlying the address, thus making it possible for
- the data stored in the DNS to reflect certain kinds of network
- topology changes or routing architectures that are either impossible
- or more difficult to represent without these mechanisms. RFC 2874 is
- also currently listed as a Proposed Standard.
-
- Both of these Proposed Standards were the output of the IPNG Working
- Group. Both have been implemented, although implementation of
- [Tweedledee] is more widespread, both because it was specified
- earlier and because it's simpler to implement.
-
- There's little question that the mechanisms proposed in [Tweedledum]
- are more general than the mechanisms proposed in [Tweedledee], and
- that these enhanced mechanisms might be valuable if IPv6's evolution
- goes in certain directions. The questions are whether we really need
- the more general mechanism, what new usage problems might come along
- with the enhanced mechanisms, and what effect all this will have on
- IPv6 deployment.
-
- The one thing on which there does seem to be widespread agreement is
- that we should make up our minds about all this Real Soon Now.
-
-Main advantages of going with A6
-
- While the A6 RR proposed in [Tweedledum] is very general and provides
- a superset of the functionality provided by the AAAA RR in
- [Tweedledee], many of the features of A6 can also be implemented with
- AAAA RRs via preprocessing during zone file generation.
-
- There is one specific area where A6 RRs provide something that cannot
- be provided using AAAA RRs: A6 RRs can represent addresses in which a
- prefix portion of the address can change without any action (or
- perhaps even knowledge) by the parties controlling the DNS zone
- containing the terminal portion (least significant bits) of the
- address. This includes both so-called "rapid renumbering" scenarios
- (where an entire network's prefix may change very quickly) and
- routing architectures such as GSE (where the "routing goop" portion
- of an address may be subject to change without warning). A6 RRs do
- not completely remove the need to update leaf zones during all
- renumbering events (for example, changing ISPs would usually require
- a change to the upward delegation pointer), but careful use of A6 RRs
- could keep the number of RRs that need to change during such an event
- to a minimum.
-
-
-
-
-Austein Expires 12 January 2002 [Page 2]
-\f
-draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
-
-
- Note that constructing AAAA RRs via preprocessing during zone file
- generation requires exactly the sort of information that A6 RRs store
- in the DNS. This begs the question of where the hypothetical
- preprocessor obtains that information if it's not getting it from the
- DNS.
-
- Note also that the A6 RR, when restricted to its zero-length-prefix
- form ("A6 0"), is semantically equivalent to an AAAA RR (with one
- "wasted" octet in the wire representation), so anything that can be
- done with an AAAA RR can also be done with an A6 RR.
-
-Main advantages of going with AAAA
-
- The AAAA RR proposed in [Tweedledee], while providing only a subset
- of the functionality provided by the A6 RR proposed in [Tweedledum],
- has two main points to recommend it:
-
- - AAAA RRs are essentially identical (other than their length) to
- IPv4's A RRs, so we have more than 15 years of experience to help
- us predict the usage patterns, failure scenarios and so forth
- associated with AAAA RRs.
-
- - The AAAA RR is "optimized for read", in the sense that, by storing
- a complete address rather than making the resolver fetch the
- address in pieces, it minimizes the effort involved in fetching
- addresses from the DNS (at the expense of increasing the effort
- involved in injecting new data into the DNS).
-
-
-Less compelling arguments in favor of A6
-
- Since the A6 RR allows a zone administrator to write zone files whose
- description of addresses maps to the underlying network topology, A6
- RRs can be construed as a "better" way of representing addresses than
- AAAA. This may well be a useful capability, but in and of itself
- it's more of an argument for better tools for zone administrators to
- use when constructing zone files than a justification for changing
- the resolution protocol used on the wire.
-
-Less compelling arguments in favor of AAAA
-
- Some of the pressure to go with AAAA instead of A6 appears to be
- based on the wider deployment of AAAA. Since it is possible to
- construct transition tools (see discussion of AAAA synthesis, later
- in this note), this does not appear to be a compelling argument if A6
- provides features that we really need.
-
- Another argument in favor of AAAA RRs over A6 RRs appears to be that
-
-
-
-Austein Expires 12 January 2002 [Page 3]
-\f
-draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
-
-
- the A6 RR's advanced capabilities increase the number of ways in
- which a zone administrator could build a non-working configuration.
- While operational issues are certainly important, this is more of
- argument that we need better tools for zone administrators than it is
- a justification for turning away from A6 if A6 provides features that
- we really need.
-
-Potential problems with A6
-
- The enhanced capabilities of the A6 RR, while interesting, are not in
- themselves justification for choosing A6 if we don't really need
- those capabilities. The A6 RR is "optimized for write", in the sense
- that, by making it possible to store fragmented IPv6 addresses in the
- DNS, it makes it possible to reduce the effort that it takes to
- inject new data into the DNS (at the expense of increasing the effort
- involved in fetching data from the DNS). This may be justified if we
- expect the effort involved in maintaining AAAA-style DNS entries to
- be prohibitive, but in general, we expect the DNS data to be read
- more frequently than it is written, so we need to evaluate this
- particular tradeoff very carefully.
-
- There are also several potential issues with A6 RRs that stem
- directly from the feature that makes them different from AAAA RRs:
- the ability to build up address via chaining.
-
- Resolving a chain of A6 RRs involves resolving a series of what are
- almost independent queries, but not quite. Each of these sub-queries
- takes some non-zero amount of time, unless the answer happens to be
- in the resolver's local cache already. Assuming that resolving an
- AAAA RR takes time T as a baseline, we can guess that, on the
- average, it will take something approaching time N*T to resolve an N-
- link chain of A6 RRs, although we would expect to see a fairly good
- caching factor for the A6 fragments representing the more significant
- bits of an address. This leaves us with two choices, neither of
- which is very good: we can decrease the amount of time that the
- resolver is willing to wait for each fragment, or we can increase the
- amount of time that a resolver is willing to wait before returning
- failure to a client. What little data we have on this subject
- suggests that users are already impatient with the length of time it
- takes to resolve A RRs in the IPv4 Internet, which suggests that they
- are not likely to be patient with significantly longer delays in the
- IPv6 Internet. At the same time, terminating queries prematurely is
- both a waste of resources and another source of user frustration.
- Thus, we are forced to conclude that indiscriminate use of long A6
- chains is likely to lead to problems.
-
- To make matters worse, the places where A6 RRs are likely to be most
- critical for rapid renumbering or GSE-like routing are situations
-
-
-
-Austein Expires 12 January 2002 [Page 4]
-\f
-draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
-
-
- where the prefix name field in the A6 RR points to a target that is
- not only outside the DNS zone containing the A6 RR, but is
- administered by a different organization (for example, in the case of
- an end user's site, the prefix name will most likely point to a name
- belonging to an ISP that provides connectivity for the site). While
- pointers out of zone are not a problem per se, pointers to other
- organizations are somewhat more difficult to maintain and less
- susceptible to automation than pointers within a single organization
- would be. Experience both with glue RRs and with PTR RRs in the IN-
- ADDR.ARPA tree suggests that many zone administrators do not really
- understand how to set up and maintain these pointers properly, and we
- have no particular reason to believe that these zone administrators
- will do a better job with A6 chains than they do today. To be fair,
- however, the alternative case of building AAAA RRs via preprocessing
- before loading zones has many of the same problems; at best, one can
- claim that using AAAA RRs for this purpose would allow DNS clients to
- get the wrong answer somewhat more efficiently than with A6 RRs.
-
- Finally, assuming near total ignorance of how likely a query is to
- fail, the probability of failure with an N-link A6 chain would appear
- to be roughly proportional to N, since each of the queries involved
- in resolving an A6 chain would have the same probability of failure
- as a single AAAA query. Note again that this comment applies to
- failures in the the process of resolving a query, not to the data
- obtained via that process. Arguably, in an ideal world, A6 RRs would
- increase the probability of the answer a client (finally) gets being
- right, assuming that nothing goes wrong in the query process, but we
- have no real idea how to quantify that assumption at this point even
- to the hand-wavey extent used elsewhere in this note.
-
- One potential problem that has been raised in the past regarding A6
- RRs turns out not to be a serious issue. The A6 design includes the
- possibility of there being more than one A6 RR matching the prefix
- name portion of a leaf A6 RR. That is, an A6 chain may not be a
- simple linked list, it may in fact be a tree, where each branch
- represents a possible prefix. Some critics of A6 have been concerned
- that this will lead to a wild expansion of queries, but this turns
- out not to be a problem if a resolver simply follows the "bounded
- work per query" rule described in RFC 1034 (page 35). That rule
- applies to all work resulting from attempts to process a query,
- regardless of whether it's a simple query, a CNAME chain, an A6 tree,
- or an infinite loop. The client may not get back a useful answer in
- cases where the zone has been configured badly, but a proper
- implementation should not produce a query explosion as a result of
- processing even the most perverse A6 tree, chain, or loop.
-
-
-
-
-
-
-Austein Expires 12 January 2002 [Page 5]
-\f
-draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
-
-
-Interactions with DNSSEC
-
- One of the areas where AAAA and A6 RRs differ is in the precise
- details of how they interact with DNSSEC. The following comments
- apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are
- semantically equivalent to AAAA RRs).
-
- Other things being equal, the time it takes to re-sign all of the
- addresses in a zone after a renumbering event is longer with AAAA RRs
- than with A6 RRs (because each address record has to be re-signed
- rather than just signing a common prefix A6 RR and a few A6 0 RRs
- associated with the zone's name servers). Note, however, that in
- general this does not present a serious scaling problem, because the
- re-signing is performed in the leaf zones.
-
- Other things being equal, there's more work involved in verifying the
- signatures received back for A6 RRs, because each address fragment
- has a separate associated signature. Similarly, a DNS message
- containing a set of A6 address fragments and their associated
- signatures will be larger than the equivalent packet with a single
- AAAA (or A6 0) and a single associated signature.
-
- Since AAAA RRs cannot really represent rapid renumbering or GSE-style
- routing scenarios very well, it should not be surprising that DNSSEC
- signatures of AAAA RRs are also somewhat problematic. In cases where
- the AAAA RRs would have to be changing very quickly to keep up with
- prefix changes, the time required to re-sign the AAAA RRs may be
- prohibitive.
-
- Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that
- 333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the
- BIND-9 dnssec-signzone program under NetBSD can generate roughly 40
- 1024-bit RSA signatures per second. Extrapolating from this,
- assuming one A RR, one AAAA RR, and one NXT RR per host, this
- suggests that it would take this laptop a few hours to sign a zone
- listing 10**5 hosts, or about a day to sign a zone listing 10**6
- hosts using AAAA RRs.
-
- This suggests that the additional effort of re-signing a large zone
- full of AAAA RRs during a re-numbering event, while noticeable, is
- only likely to be prohibitive in the rapid renumbering case where
- AAAA RRs don't work well anyway.
-
-Interactions with dynamic update
-
- DNS dynamic update appears to work equally well for AAAA or A6 RRs,
- with one minor exception: with A6 RRs, the dynamic update client
- needs to know the prefix length and prefix name. At present, no
-
-
-
-Austein Expires 12 January 2002 [Page 6]
-\f
-draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
-
-
- mechanism exists to inform a dynamic update client of these values,
- but presumably such a mechanism could be provided via an extension to
- DHCP, or some other equivalent could be devised.
-
-Transition from AAAA to A6 via AAAA synthesis
-
- While AAAA is at present more widely deployed than A6, it is possible
- to transition from AAAA-aware DNS software to A6-aware DNS software.
- A rough plan for this was presented at IETF-50 in Minneapolis and has
- been discussed on the ipng mailing list. So if the IETF concludes
- that A6's enhanced capabilities are necessary, it should be possible
- to transition from AAAA to A6.
-
- The details of this transition have been left to a separate document,
- but the general idea is that the resolver that is performing
- iterative resolution on behalf of a DNS client program could
- synthesize AAAA RRs representing the result of performing the
- equivalent A6 queries. Note that in this case it is not possible to
- generate an equivalent DNSSEC signature for the AAAA RR, so clients
- that care about performing DNSSEC validation for themselves would
- have to issue A6 queries directly rather than relying on AAAA
- synthesis.
-
-Bitlabels
-
- While the differences between AAAA and A6 RRs have generated most of
- the discussion to date, there are also two proposed mechanisms for
- building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
- ADDR.ARPA tree).
-
- [Tweedledee] proposes a mechanism very similar to the IN-ADDR.ARPA
- mechanism used for IPv4 addresses: the RR name is the hexadecimal
- representation of the IPv6 address, reversed and concatenated with a
- well-known suffix, broken up with a dot between each hexadecimal
- digit. The resulting DNS names are somewhat tedious for humans to
- type, but are very easy for programs to generate. Making each
- hexadecimal digit a separate label means that delegation on arbitrary
- bit boundaries will result in a maximum of 16 NS RRs per label;
- again, the mechanism is somewhat tedious for humans, but is very easy
- to program. As with IPv4's IN-ADDR.ARPA tree, the one place where
- this scheme is weak is in handling delegations in the least
- significant label; however, since there appears to be no real need to
- delegate the least significant four bits of an IPv6 address, this
- does not appear to be a serious restriction.
-
- [Tweedledum] proposed a radically different way of naming entries in
- the reverse mapping tree: rather than using textual representations
- of addresses, it proposes to use a new kind of DNS label (a "bit
-
-
-
-Austein Expires 12 January 2002 [Page 7]
-\f
-draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
-
-
- label") to represent binary addresses directly in the DNS. This has
- the advantage of being significantly more compact than the textual
- representation, and arguably might have been a better solution for
- DNS to use for this purpose if it had been designed into the protocol
- from the outset. Unfortunately, experience to date suggests that
- deploying a new DNS label type is very hard: all of the DNS name
- servers that are authoritative for any portion of the name in
- question must be upgraded before the new label type can be used, as
- must any resolvers involved in the resolution process. Any name
- server that has not been upgraded to understand the new label type
- will reject the query as being malformed.
-
- Since the main benefit of the bit label approach appears to be an
- ability that we don't really need (delegation in the least
- significant four bits of an IPv6 address), and since the upgrade
- problem is likely to render bit labels unusable until a significant
- portion of the DNS code base has been upgraded, it is difficult to
- escape the conclusion that the textual solution is good enough.
-
-DNAME RRs
-
- [Tweedledum] also proposes using DNAME RRs as a way of providing the
- equivalent of A6's fragmented addresses in the reverse mapping tree.
- That is, by using DNAME RRs, one can write zone files for the reverse
- mapping tree that have the same ability to cope with rapid
- renumbering or GSE-style routing that the A6 RR offers in the main
- portion of the DNS tree. Consequently, the need to use DNAME in the
- reverse mapping tree appears to be closely tied to the need to use
- fragmented A6 in the main tree: if one is necessary, so is the other,
- and if one isn't necessary, the other isn't either.
-
- Other uses have also been proposed for the DNAME RR, but since they
- are outside the scope of the IPv6 address discussion, they will not
- be addressed here.
-
-Other topics ???
-
-Recommendation
-
- Distilling the above feature comparisons down to their key elements,
- the important questions appear to be:
-
- (a) Is IPv6 going to do rapid renumber or GSE-like routing?
- (b) Is the reverse mapping tree for IPv6 going to require delegation
- in the least significant four bits of the address?
-
- Question (a) appears to be the key to the debate. This is really a
- decision for the IPv6 community to make, not the DNS community.
-
-
-
-Austein Expires 12 January 2002 [Page 8]
-\f
-draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
-
-
- Question (b) is also for the IPv6 community to make, but it seems
- fairly obvious that the answer is "no".
-
- Recommendations based on these questions:
-
- (1) If the IPv6 working groups seriously intend to specify and deploy
- rapid renumbering or GSE-like routing, we should transition to
- using the A6 RR in the main tree and to using DNAME RRs as
- necessary in the reverse tree.
- (2) Otherwise, we should keep the simpler AAAA solution in the main
- tree and should not use DNAME RRs in the reverse tree.
- (3) In either case, the reverse tree should use the textual
- representation described in [Tweedledee] rather than the bit
- label representation described in [Tweedledum].
- (4) If we do go to using A6 RRs in the main tree and to using DNAME
- RRs in the reverse tree, we should write applicability statements
- and implementation guidelines designed to discourage excessively
- complex uses of these features; in general, any network that can
- be described adequately using A6 0 RRs and without using DNAME
- RRs should be described that way, and the enhanced features
- should be used only when absolutely necessary, at least until we
- have much more experience with them and have a better
- understanding of their failure modes.
-
-Security Considerations
-
- ???
-
-IANA Considerations
-
- None, since all of these RR types have already been allocated.
-
-Acknowledgments
-
- This note is based on a number of discussions both public and private
- over a period of (at least) eight years, but particular thanks go to
- Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
- Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
- and Sue Thomson, none of whom are responsible for what the author did
- with their ideas.
-
-References
-
- [Tweedledee] Thomson, S., and Huitema, C., "DNS Extensions to support
- IP version 6", RFC 1886, December 1995.
-
- [Tweedledum] Crawford, M., and Huitema, C., "DNS Extensions to
- Support IPv6 Address Aggregation and Renumbering" RFC 2874, July
-
-
-
-Austein Expires 12 January 2002 [Page 9]
-\f
-draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt July 2001
-
-
- 2000.
-
- [Sommerfeld] Private message to the author from Bill Sommerfeld dated
- 21 March 2001, summarizing the result of experiments he
- performed on a copy of the MIT.EDU zone.
-
-Author's addresses:
-
- Rob Austein
- InterNetShare, Inc.
- 505 West Olive Ave., Suite 321
- Sunnyvale, CA 94086
- USA
- sra@hactrn.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Austein Expires 12 January 2002 [Page 10]
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT H. Kitamura
-<draft-ietf-dnsext-ipv6-name-auto-reg-00.txt> NEC Corporation
-Expires in six months 2 December 2002
-
- Domain Name Auto-Registration for Plugged-in IPv6 Nodes
- <draft-ietf-dnsext-ipv6-name-auto-reg-00.txt>
-
-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 scheme of "Domain Name Auto-Registration
- for Plugged-in IPv6 Nodes" mechanism that makes it possible to
- register both regular and inverse domain name information of plugged-
- in IPv6 nodes to DNS servers automatically.
-
- Since IPv6 addresses are too long to remember and EUI64-based
- addresses are too complicated to remember, there are strong
- requirements to use logical names that are easy to remember instead
- of IPv6 addresses to specify IPv6 nodes and to register domain name
- information of plugged-in IPv6 nodes automatically.
-
- In order to meet the requirements, a mechanism is proposed as one of
- the IPv6 auto-configuration (plug and play) functions. After the
- Address Autoconfiguration [ADDR-AUTO] has been executed, it works as
- a succeeding plug and play mechanism.
-
- This document clarifies problems that we meet when we apply the
- Dynamic Updates in the DNS [DYN-DNS] to automatic domain name
- information registration mechanisms. This document describes the
- Domain Name Auto-Registration mechanism as a solution to these
- problems.
-
-
-
-H. Kitamura [Page 1]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- The Domain Name Auto-Registration mechanism, in addition to its main
- functionality, provides two types of additional benefits.
-
- One is that IP address information that should be registered to the
- DNS is collected automatically. The mechanism can also be used under
- (non plug and play) manual configuration situations in a different
- manner from its main functionality. Under such situations, network
- administrators meet a problem that it is not easy to collect IP
- address information to register to the DNS. The mechanism solves it.
-
- The other is that a plugged-in IPv6 node can obtain its domain name
- information (FQDN and DNS zone suffix) without having new functions
- installed into it. By simply executing inverse DNS name resolving
- procedures with its IPv6 address argument, the plugged-in IPv6 node
- can obtain its FQDN and DNS zone suffix with ease.
-
-
-1. Introduction
-
- This document describes a scheme of "Domain Name Auto-Registration
- for Plugged-in IPv6 Nodes" mechanism that makes it possible to
- register both regular and inverse domain name information of plugged-
- in IPv6 nodes to DNS servers automatically.
-
- In order to specify destination nodes to communicate, SOME
- identifiers are necessary for users. Since IPv6 addresses are too
- long to remember and EUI64-based addresses are too complicated to
- remember, they are not suitable for such identifiers. Logical names
- are suitable identifiers because they are easy to remember.
- Therefore, there are strong requirements to use logical names instead
- of IPv6 addresses to specify IPv6 destination nodes and to register
- domain name information of plugged-in IPv6 nodes automatically.
-
- In order to meet the requirements, a mechanism is proposed as one of
- the IPv6 auto-configuration (plug and play) functions. After the
- Address Autoconfiguration [ADDR-AUTO] has been executed, it works as
- a succeeding plug and play mechanism.
-
- It is known that the Dynamic Updates in the DNS [DYN-DNS] have
- already been defined and that they can help automatic domain name
- information registration mechanisms. However, some problems need to
- be solved to apply this idea to actual situations.
-
- This document clarifies problems that we meet when we apply the
- Dynamic Updates in the DNS [DYN-DNS] to automatic domain name
- information registration mechanisms. This document describes the
- Domain Name Auto-Registration mechanism as a solution to these
- problems.
-
-
-
-H. Kitamura [Page 2]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- Basic target situations for the mechanism are plug and play
- situations. Accordingly, it has been designed for plugged-in IPv6
- nodes under plug and play situations.
-
- We have to consider the following issues to design the "Domain Name
- Auto-Registration for Plugged-in IPv6 Nodes" mechanism.
-
- 1. Plugged-in IPv6 nodes do not have sufficient capability to show
- their preferences. In most cases, it is difficult for plugged-in
- IPv6 nodes to show their preferences for their domain names.
-
- 2. Since it is not easy to install new function to all IPv6 nodes, it
- is desirable to achieve the mechanism without installing new
- functions into plugged-in IPv6 nodes.
-
- 3. It is essential to have (register) SOME domain name for a
- plugged-in node. It is NOT main concern for a plugged-in node
- which actual name is assigned to it.
-
- Thus, the idea of "default domain name" is introduced. When a new
- plugged-in IPv6 node appears, its appearance is automatically
- detected and a default domain name is selected for it, and both
- regular and inverse information of the default domain name are
- registered to appropriate DNS servers.
-
- This document does not deal with cases where IPv6 nodes want to
- register domain names that they absolutely prefer. Such cases do not
- fall within the target range of plug and play situations; they will
- be supported under manual configuration situations.
-
- There are various types of plugged-in IPv6 nodes that can/cannot show
- their preferences for their domain names. In order to meet various
- plug and play situations, this document considers several cases.
-
- The Domain Name Auto-Registration mechanism is basically designed for
- domain name registrations for global unicast addresses. By setting
- the query scope of the target DNS server appropriately, the mechanism
- will be able to be applied to domain name registrations for site-
- local and link-local scope unicast addresses.
-
- The Domain Name Auto-Registration mechanism, in addition to its main
- functionality, provides two types of additional benefits.
-
- One is that IP address information that should be registered to the
- DNS is collected automatically. The mechanism can also be used under
- (non plug and play) manual configuration situations in a different
- manner from its main functionality. Under such situations where
- network is maintained by administrators manually, administrators meet
-
-
-
-H. Kitamura [Page 3]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- a problem that it is not easy to collect IP address information to
- register to the DNS. The mechanism solves the problem, and IP address
- information to register to the DNS is collected automatically.
-
- Under manual configuration situations, the automatic DNS registration
- procedure that is the last procedure of the mechanism can be replaced
- by the administrators' manual registration (not by the Dynamic
- Updates).
-
-
- The other is that a plugged-in IPv6 node can obtain its domain name
- information (FQDN and DNS zone suffix) with ease. The plugged-in IPv6
- nodes know its IPv6 address that are automatically configured by the
- Address Autoconfiguration [ADDR-AUTO]. By simply executing inverse
- DNS name resolving procedures with the IPv6 address argument, the
- plugged-in IPv6 node can obtain information on its domain names (FQDN
- and DNS zone suffix) easily. Since all IPv6 nodes have DNS name
- resolving functions for both regular and inverse queries, this
- procedure can be achieved without installing new functions into IPv6
- nodes.
-
-
-2. Problems in applying the Dynamic Updates mechanism
-
- This section clarifies problems that we meet when we apply the
- Dynamic Updates in the DNS [DYN-DNS] to automatic domain name
- information registration mechanisms.
-
- 1: Ordinary DNS servers accept Dynamic Updates messages only from
- trusted nodes.
-
- Since it is difficult for plugged-in IPv6 nodes to become trusted
- nodes of the DNS servers, Dynamic Updates messages from plugged-in
- IPv6 nodes are usually not accepted by the DNS servers.
-
- 2: It is difficult for plugged-in IPv6 nodes to know the location of
- the appropriate DNS server to register their domain name
- information to.
- ([DNS-DISC] discusses on issues of this type.)
-
- 3: It is difficult for plugged-in IPv6 nodes to prepare sufficient
- domain name information to register. They need to know their DNS
- zone suffix information to prepare FQDN for registration, but it
- is difficult for them to acquire it.
- ([DNS-DISC] also discusses on issues of this type.)
-
- 4: There is no explicit method to avoid duplicated, conflicting name
- registrations.
-
-
-
-H. Kitamura [Page 4]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- When a DNS server receives Dynamic Updates messages that are
- correctly formatted and authenticated, the server accepts them and
- updates DNS database with them without checking for duplication.
- (It is essentially difficult for a DNS server to distinguish
- overwrite (update) registrations from duplicate registrations.)
-
- 5: Basically, there is no mechanism to control (restrict) the number
- of issued Dynamic Updates messages for plugged-in nodes.
-
- In order to minimize the effects of malicious or misconfigured
- registration requests, it is necessary to control them.
-
- 6: It is not clear when domain name registration requests must be
- issued. It is necessary to define trigger timings to start
- registrations.
-
-
-3. Basic Design of the Domain Name Auto-Registration
-
- This section describes the basic design of the Domain Name Auto-
- Registration mechanism. The mechanism solves all of the above-
- mentioned problems.
-
-
-3.1 Design Policies
-
- The Domain Name Auto-Registration mechanism is composed of two new
- functions. One is the "Detector" function, which detects appearances
- of new plugged-in IPv6 nodes. The other is the "Registrar" function,
- which registers detected domain name information to DNS servers.
- These functions are introduced into the IPv6 network system to
- achieve the mechanism.
-
- There are several reasons why the mechanism is implemented as two
- functions.
-
- 1. To make the mechanism easy to control
-
- By concentrating administrative operations only on the Registrar
- side, administrative costs are reduced and the mechanism is
- basically maintained by administering only Registrars.
-
- The number of DNS servers' trusted nodes that require much
- administrative operation is reduced.
-
- Since registration information is aggregated at Registrars, it
- becomes easy to control registrations and minimize the effects of
- malicious or misconfigured registration requests.
-
-
-
-H. Kitamura [Page 5]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- 2. To make Detector easy to implement
-
- There are certain constraints in placing Detectors on the IPv6
- network. Thus, it is necessary for Detectors to be simple enough
- to be installed on IPv6 nodes of any type.
-
- This need is filled by putting all the intelligent operations into
- Registrars.
-
- Furthermore, the system becomes well balanced since intelligent
- operations are not placed on each end link.
-
- 3. To make the mechanism flexible and enable it to be applied
- to various environments (office networks, home networks, etc.)
-
- If the mechanism is applied to home networks, Registrars can be
- placed at the Provider side, and Detectors can be placed at the
- User side.
-
-
- Figure 1 and 2 show typical examples that indicate locations where
- Detector and Registrar functions are placed on the IPv6 network.
-
- Figure 1 shows a case for a single link, and Figure 2 shows a case
- for multiple links.
-
-
-
-
- | +------------+
- | | DNS Server |
- +-+-+ %%%%%%%%%%%% ############# +------+-----+
- | R | % Detector % # Registrar # /
- +-+-+ %%%%%%%%%%%% ############# +---+
- | | | /
- ----+---------+-------+------+---------------+-----
- |
- +===========+
- | Plugged-in|
- | IPv6 Node |
- +===========+
-
- Fig. 1 Single-Link Case Example
-
-
-
-
-
-
-
-
-H. Kitamura [Page 6]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- +------------+
- | DNS Server |
- ############# +------+-----+
- # Registrar # /
- ############# +---+
- | /
- ----+-----------+------------+-------+------
- | |
- +-+-+ %%%%%%%%%%%%% +-+-+ %%%%%%%%%%%%%
- | R1| % Detector1 % | R2| % Detector2 %
- +-+-+ %%%%%%%%%%%%% +-+-+ %%%%%%%%%%%%%
- | | | |
- ----+-----+-----+----- ----+-----+-----+-----
- | |
- +===========+ +===========+
- | Plugged-in| | Plugged-in|
- | IPv6 Node | | IPv6 Node |
- +===========+ +===========+
-
- Fig. 2 Multiple-Link Case Example
-
-
- One Registrar can take charge of multiple Detectors, and one
- Registrar can cover multiple DNS zones.
-
- Multiple Detectors can provide detected information for one DNS zone.
- If the corresponding Registrars of these Detectors are different,
- multiple Registrars can cover one DNS zone.
-
- Therefore, Registrars must be designed to support both cases.
-
-
-
-3.2 Detector Function
-
- The role of a "Detector" is to detect appearances of new plugged-in
- IPv6 nodes and to send the detected information to a "Registrar"
- without applying any selection rules to it.
-
- Detectors are NOT required to perform any "intelligent" operations.
-
- A Detector knows the location of its corresponding Registrar. (This
- location is configured manually.) Detected information must be sent
- securely from the Detector to the Registrar by using some kind of
- secure communication method (e.g., [TSIG]-like authentication, IPsec
- (AH, ESP), [TLS]).
-
-
-
-
-
-H. Kitamura [Page 7]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- Since a Detector must be placed where appearances of new plugged-in
- IPv6 nodes can be detected, the Detector location is restricted.
-
- In typical cases, appearances are detected by watching for DAD
- packets that are issued from plugged-in IPv6 nodes (see section 3.4).
- So, the Detector must be placed where it can listen to link-local
- scope multicast packets. In other words, a Detector must be placed on
- each link to achieve the mechanism.
-
- The Detector function can be implemented on routers, because its
- operations are simple and lightweight and routers are located at
- suitable places for listening to link-local scope multicast packets
- that are issued from plugged-in IPv6 nodes.
-
- In order to identify Detectors, each Detector must have its own
- Detector ID. Since a Detector is placed on each link, the Detector's
- IP address that is connected to its watching link can be used for the
- Detector ID. (Default Address Selection for IPv6 [DEF-ADDR] algorithm
- is also applied here.) When a Detector sends detected information to
- a Registrar, the Detector ID is attached to it.
-
- In order to meet "temporary address" [RFC3041] issues (see section
- 5), a link-layer address of a detected IP address is also attached to
- detected information.
-
- Some simple protocol is necessary to send detected information from
- the Detector to the Registrar. In Appendix A, [HTTP]-based or [TLS-
- HTTP]-based simple protocol is shown.
-
-3.3 Registrar Function
-
- The role of a "Registrar" is to prepare appropriate domain name
- information for registration and to register it by sending Dynamic
- Update messages to the corresponding "DNS servers".
-
- Appropriate domain name information for registration is created from
- detected information that is sent from the Detector. Some sort of
- intelligent algorithm is necessary in such procedures. One of the
- roles of the algorithm is to minimize the effects of malicious or
- misconfigured registration requests.
-
- Registrars are required to perform "intelligent" operations.
-
- By using some sort of algorithm, the Registrar verifies (checks)
- whether detected information must be registered (see section 3.5).
- After the verification procedures are completed, the Registrar
- selects a "default domain name" for the detected information.
-
-
-
-
-H. Kitamura [Page 8]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- In order to prepare appropriate domain name information, the
- Registrar must know the appropriate DNS zone suffix for detected
- information. (The suffix is configured manually.) The DNS zone suffix
- depends on the Detector ID information.
-
- A Registrar must know the locations of "DNS servers" that correspond
- to detected information for registration (both regular DNS zone
- prefix and its inverse zone). Registrars must be trusted nodes of the
- DNS servers and Dynamic Update messages must be sent securely from
- the Registrar to the DNS servers by using some sort of secure
- communication methods. The [TSIG] technique would be suitable for
- authenticating the messages.
-
- A Registrar has a database table to manage such knowledge. The
- following elements are managed in the database table:
- Detector IDs, DNS zone suffixes, locations of DNS servers, applied
- algorithms (naming rules, how to deal with link-local or site-local
- scope addresses, etc.) and keys for secure communications.
-
- A Registrar can be placed anywhere in the IPv6 network, because the
- Registrar communicates only with Detectors and DNS servers, all
- communications are unicast.
-
- In order to optimize the communication path for packets between them,
- the Registrar is usually placed in the network upstream from the
- Detectors (see Fig.2).
-
- Detected information that is sent from Detectors is aggregated at the
- Registrar.
-
- The Registrar may frequently execute inverse DNS name resolving
- procedures to verify (check) whether detected information must be
- registered. It is recommended to put a DNS cache server function on
- the same node where the Registrar is placed to reduce inverse DNS
- name resolving traffic (see section 3.5).
-
-3.4 Methods of Detecting Appearances of New Plugged-in IPv6 Nodes
-
- In order to detect appearances of new plugged-in IPv6 nodes, the
- Detector must watch or receive packets from new plugged-in nodes.
- Accordingly, detection methods on the Detector are categorized into
- two types.
-
- One is detection of the appearance of "standard" plugged-in nodes
- that do not issue special packets to show their appearance. The other
- is detection of the appearance of "active" plugged-in nodes that
- issue special packets to show their appearance.
-
-
-
-
-H. Kitamura [Page 9]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- We can assume there will be complex cases in which standard and
- active plugged-in nodes are mixed together. For purposes of
- simplification, such cases are not discussed here.
-
-3.4.1 Detecting Appearance of "Standard" Plugged-in IPv6 Nodes
-
- In this case, plugged-in nodes do NOT issue special dedicated packets
- to show their appearance. (Current standard networks are composed of
- such nodes.) So, the Detector must watch for packets that are issued
- somewhere from new plugged-in nodes.
-
- The initial procedure for a standard plugged-in IPv6 node is to auto-
- configure its address and do DAD (Duplicate Address Detection) [ADDR-
- AUTO].
-
- DAD packets have sufficient characteristics for an appearance-
- detection method, because they are issued only when IPv6 nodes are
- plugged in, and address information for the plugged-in IPv6 nodes is
- included in DAD packets.
-
- By watching for only DAD packets, the Detector can detect appearances
- of new plugged-in IPv6 nodes, and DAD packets become triggers to
- start Domain Name Auto-Registration.
-
- This method enables the mechanism to function without introducing new
- protocols and without installing new functions into plugged-in IPv6
- nodes.
-
-
- DAD packets are issued not only for global addresses but also for
- link-local or site-local scope addresses. All detected information is
- sent to the Registrar, and the manner of dealing with information for
- non-global addresses is determined by Registrar algorithms that are
- indicated by Detector IDs of the detected information.
-
-
- This method works effectively on ordinary IPv6 links where DAD
- packets are issued. However, on extraordinary IPv6 links where DAD
- packets are not issued, it does not work. On such links, there must
- be another initial procedure that substitutes the DAD function. Such
- a procedure can be used as a trigger for a detection method on
- extraordinary IPv6 links.
-
- (IP addresses can be assigned by other methods (e.g., DHCP). Domain
- name registration mechanisms for such cases will be discussed further
- in other documents.)
-
-
-
-
-
-H. Kitamura [Page 10]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
-3.4.2 Detecting Appearance of "Active" Plugged-in Nodes
-
- In this case, plugged-in nodes issue special dedicated packets to
- show their appearance. The Detector must listen for and receive
- packets from the new plugged-in nodes.
-
- Since plugged-in nodes do not know the location of the Detector,
- anycast or multicast packets are used for the special dedicated
- packets.
-
- In this method, plugged-in nodes can actively show their preference
- for their domain names. However, it will be difficult to show their
- preference under plug and play situations.
-
- In order to achieve the method, new protocols must be defined and new
- functions must be installed into plugged-in IPv6 nodes.
- (This will be discussed further in other documents.)
-
-3.5 Methods of Controlling Registration
-
- If received Dynamic Update messages are correctly formatted and
- authenticated, the DNS server accepts them without checking for any
- duplication, because the DNS server can not distinguish overwrite
- (update) registrations from duplicate registrations. It is difficult
- to achieve a mechanism for avoiding duplicated registrations on the
- DNS server side.
-
- Therefore, registrations by the Dynamic Update messages must be
- controlled on the Registrar side. This control mechanism also helps
- to minimize the effects of malicious or misconfigured registration
- requests.
-
- Plugged-in nodes may switch on and off frequently and issue DAD
- packets frequently. Since the Detector sends detected information
- without applying any selection rules to it, all detected information
- is sent to the Registrar. Thus, the Registrar must have some
- information verification mechanism to avoid duplicated registrations.
-
- All candidate information (detected addresses) for registration is
- checked by using inverse DNS resolving queries of them. If there is
- FQDN information that matches the detected address, such registration
- candidates are not registered.
-
- Only when FQDN information for it is NOT found and it is verified
- that the detected information is based on first appearance of the
- plugged-in node, appropriate domain name information for registration
- is prepared and both regular and inverse domain name information for
- it are registered to the DNS servers by the Dynamic Update messages.
-
-
-
-H. Kitamura [Page 11]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- By using this verification mechanism, the Registrar does not have to
- have a local database to maintain the status of the detected
- information and no DNS registration inconsistency problems are
- caused.
-
- By restricting the number of Dynamic Update messages that are sent
- from the Registrar per unit of time, the effects of malicious or
- misconfigured registration requests are minimized.
-
-
-3.6 Naming Rules for Default Domain Names
-
- This section describes a method of setting "default domain names" for
- plugged-in nodes.
-
- A fully qualified "default domain name" is composed of a node's
- original prefix part and a DNS zone suffix part that is the same for
- each site or link.
-
- Since a DNS zone suffix is given to the Registrar manually, only the
- naming rules for a node's original prefix are discussed here. A
- naming rule algorithm for a node's prefix is given to the Registrar
- manually.
-
- It is not necessary to define naming rules for a node's prefix
- explicitly in this document. Each site can define its own naming
- rules (algorithms) per link according to site policy.
-
- This document shows some example naming rules for a node's prefix
- name.
-
- 1. Prefix Letter(s) + Number
-
- This is the easiest rule. First, prefix letter(s) that depends on
- each link (Detector ID) is/are selected, and the following number
- is selected after that.
-
- The following numbers comprise sequential numbers. In order to
- achieve this, the Registrar must remember the last selected
- number.
-
- There are some situations where using sequential numbers is not
- favorable because the next number could be easily predicted. In
- those cases, random numbers can be used, which makes it necessary
- to implement the Registrar with a duplicate number check
- mechanism.
-
-
-
-
-
-H. Kitamura [Page 12]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- 2. Predefined Names
-
- The Registrar prepares predefined names (e.g., names of flowers)
- that are used for prefix names for plugged-in nodes. Random or
- sequential numbers can be used to prepare predefined names.
-
- This method can be used for an environment where the number of
- plugged-in nodes can be estimated and the number is not
- excessively large.
-
- 3. Use Preferences of Plugged-in Nodes.
-
- The Registrar inquires the preference or property of a plugged-in
- node, and uses the obtained information as a hint to define a
- prefix name for the plugged-in node.
-
- There are two types of methods for plugged-in nodes to indicate
- their preference or property.
-
-
- One is "passive" indication. Plugged-in nodes do NOT become an
- initiator to indicate their preferences. The Registrar becomes an
- initiator and issues query packets to plugged-in nodes. Existing
- protocol (e.g., Node Information Query [NIQ], SNMP) is used for
- it.
-
- For a detected global address, the Registrar can use Node
- Information Query [NIQ] to obtain hint information to define a
- name for the plugged-in node.
-
- By using [SNMP], the Registrar can also obtain hint information to
- define a name for the plugged-in node. Plugged-in nodes use parts
- of MIB to indicate their preferences or properties. It is possible
- to define a special MIB for this purpose. Also, some parts of
- currently existing MIB can be used for it. Most plugged-in nodes
- have already set some property information (OS type, version,
- etc.) to their MIB when they are plugged in. Such information can
- be used for a hint to define a prefix name. (The Registrar must
- have an appropriate read access right to such MIB information.)
-
- The other is "active" indication. Plugged-in nodes become an
- initiator to indicate their preferences and issue special
- dedicated packets for it. Since plugged-in nodes do not know the
- location of the Detector or Registrar, anycast or multicast
- packets are used for them. It is possible to attach name
- preference information to packets that are used for showing the
- appearance of plugged-in nodes. The Registrar can receive such
- information via the Detector.
-
-
-
-H. Kitamura [Page 13]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- In order to achieve the "active" indication method, new protocols
- must be defined and new functions must be installed into plugged-
- in IPv6 nodes.
- (This will be discussed further in other documents.)
-
-
-4. Procedures of the Domain Name Auto-Registration
-
- Figure 3 shows an example of typical Domain Name Auto-Registration
- procedures at IPv6 links where DAD packets are issued. DAD packets
- are used for the appearance detection method (for standard plugged-in
- IPv6 nodes).
-
- Plugged-in Router Detector Registrar DNS servers
- IPv6 Node
- | link local | | | |
- (a)|---DAD NS--->----------->| | |
- (b)| no NA | | | |
- (c)| | |----------->| |
- | | | | |
- | global | | | |
- (d)|(----RS--->)| | | |
- (e)|<----RA-----| | | |
- (f)|---DAD NS--->----------->| | |
- (g)| no NA | | | |
- (h)| | |----------->| |
- | | | | |
- (i)| | | |----------->|
- (j)| | | |<-----------|
- | | | | |
- (k)|(<-----------------------------------)| |
- (l)|(----------------------------------->)| |
- | | | | |
- (m)| | | |----------->|
- (n)| | | |<-----------|
- | | | | |
- (o)| | | |----------->|
- (p)| | | |<-----------|
- (q)| | | |----------->|
- (r)| | | |<-----------|
- | | | | |
-
- Fig. 3 Example of Typical Auto-Registration Procedures
-
- (a) and (b) are DAD procedures for the link-local address of the
- Plugged-in Node. (b) is a procedure to verify that there is no NA
- (reply to NS) and the link-local address is not duplicated on the
- link.
-
-
-
-H. Kitamura [Page 14]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- The Detector watches (a) and (b), and detects the appearance of new
- plugged-in IPv6 nodes. (c) is a procedure for sending the detected
- information, to which the Detector ID is attached. The scope of the
- detected address is not checked at the Detector.
-
- After the Registrar receives the detected information by the
- procedure (c), the scope of the detected address and the decision
- algorithm (which depends on the Detector ID) are checked on the
- Registrar.
-
- In typical cases, the decision algorithm shows that link-local
- addresses are not candidates for registration. In such cases, the
- detected information for the link-local address is discarded at this
- point.
-
- (d)(e)(f) and (g) are DAD procedures for the global address of the
- Plugged-in Node. (d) is an optional procedure. (g) is a procedure to
- verify that there is no NA (reply to NS) and that the global address
- is not duplicated.
-
- The Detector watches (f) and (g), and detects the appearance of new
- plugged-in IPv6 nodes. (h) is a procedure for sending the detected
- information, to which the Detector ID is attached.
-
- After the Registrar receives the detected information by the
- procedure (h), the scope of the detected address and decision
- algorithm (which depends on Detector ID) are checked on the
- Registrar.
-
- In typical cases, the decision algorithm shows that global addresses
- are candidates for registration. In such cases, check procedures to
- avoid duplicated registrations are started at this point.
-
- (i) and (j) are check procedures to verify that the detected address
- is must be registered to the DNS. The Registrar checks for the
- existence of FQDN information for the detected address by executing
- "inverse DNS name resolving" procedures with the detected address
- argument.
-
- If the existence of FQDN information for the detected address is
- verified, such detected address information for registration is
- canceled and discarded at this point.
-
- If the existence is not verified, the Registrar starts preparing
- "default domain name" information for the candidate IPv6 address. DNS
- zone suffix information that depends on the Detector ID is taken from
- the Registrar's manually configured database table, and the naming
- rule algorithm that depends on the Detector ID is also taken from it.
-
-
-
-H. Kitamura [Page 15]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- By following the defined naming rule algorithm, the plugged-in node's
- prefix name is selected.
-
- (k) and (l) are optional procedures for preparing "default domain
- name." If the naming rule that is applied for the detected address
- stipulates inquiring the preference or property of the node, (k) and
- (l) are executed and such information is obtained by the Registrar.
- The obtained information is used as a hint to select the prefix name
- of the plugged-in node.
-
- A candidate "default domain name" for the detected address is
- prepared here.
-
- (m) and (n) are check procedures to verify that the candidate
- "default domain name" is not used by anyone. The Registrar checks for
- the existence of the candidate "default domain name" by executing
- "regular DNS name resolving" procedures with the candidate "default
- domain name."
-
- If the existence is not verified, it becomes fully qualified "default
- domain name." If the existence is verified, the Registrar restarts
- and repeats preparing a candidate "default domain name" for the
- detected address.
-
-
- After fully qualified "default domain name" information to register
- is prepared, (o)(p)(q) and (r) are executed to register both regular
- and inverse domain name information to the DNS servers by the Dynamic
- Update messages.
-
- (Under manual configuration situations, (o)(p)(q) and (r) procedures
- are replaced by the administrators' manual registration (not by the
- Dynamic Updates).)
-
-
-5. Treatment of "Temporary Addresses" in the Mechanism
-
- "Temporary address" is defined in [RFC3041]. Temporary addresses are
- detected in this mechanism, because DAD packets are issued when
- temporary address are generated.
-
- There are two views whether domain names for temporary addresses
- should be registered to the DNS or not.
-
- One view is that domain names for temporary addresses should NOT be
- registered to the DNS, because temporary addresses are temporary and
- they are introduced to lessen privacy concerns.
-
-
-
-
-H. Kitamura [Page 16]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- The other view is domain names for temporary addresses should be
- registered to the DNS. [RFC3041] discusses on this issue at section 4
- of [RFC3041]. In order to meet conventional inverse-DNS-based
- "authentication," nodes could register temporary addresses in the DNS
- using random names. The Domain Name Auto-Registration mechanism can
- provide a solution for this issue.
-
- Since there are two views for domain names registration of temporary
- addresses, which view should be chosen is depends on site policies.
-
-
-
-5.1 How to Distinguish "Temporary Addresses" from Public Addresses
-
- In order to apply above discussed policies, it is necessary to
- distinguish "temporary addresses" from public addresses.
-
- Only with IP address information, it is difficult to tell that a
- detected address is a temporary address or a public addresses. So,
- link-layer address information is utilized to achieve this operation
- (see section 3.2).
-
- By utilizing link-layer address information, we can easily tell that
- a detected address is a EUI64-based address or not. (This operation
- is called a "EUI64 check" operation.)
-
- If a detected address is a EUI64-based, it is not a temporary
- address. It is a normal target address for the Domain Name Auto-
- Registration mechanism.
-
- If not, it must be a either temporary address or manually configured
- address. We can assume that a domain name for a manually configured
- address must have been registered in the DNS manually.
-
- In the mechanism, an IP address whose domain name has been already
- registered does not become a candidate. It is verified by "inverse
- DNS name resolving" check procedures (see (i) and (j) procedures in
- Figure 3).
-
- By applying a "EUI64 check" operation after "inverse DNS name
- resolving" check procedures, we can assume that non EUI64-based
- address must be a temporary address. Since temporary addresses are
- distinguished from public addresses, we can apply above discussed
- policies to temporary addresses.
-
-
-
-
-
-
-
-H. Kitamura [Page 17]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
-6. Security Considerations
-
- After the Address Autoconfiguration [ADDR-AUTO] has been executed,
- the Domain Name Auto-Registration works as a succeeding of the plug
- and play mechanism. The plugged-in IPv6 nodes' appearances detection
- method is depend on the Address Autoconfiguration.
-
- Thus, the items that are described in the Security Considerations
- section of the Address Autoconfiguration [ADDR-AUTO] are also
- applicable to this document.
-
- In addition, the following security issues are considered.
-
- Since the Detector must send detected information to the Registrar
- securely, some sort of secure communication method (e.g., [TSIG]-like
- authentication, IPsec (AH, ESP), [TLS]) must be used.
-
- The Registrars must be trusted nodes of the DNS servers and Dynamic
- Update messages must be sent securely from the Registrar to the DNS
- servers by using some sort of secure communication method. The [TSIG]
- technique would be suitable for authenticating the messages.
-
- In order to minimize the effects of malicious or misconfigured
- registration requests, the Registrar restricts the number of Dynamic
- Update messages that are sent from the Registrar per unit of time.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-H. Kitamura [Page 18]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
-Appendix A. HTTP-based simple protocol between Detector and Registrar
-
- a. Design of HTTP parameters
-
- - Request Parameters
- method = <registration protocol>
- detectorID = <detector identifier(address)>
- IP-address = <detected IP address>
- link-layer-address = <detected link-layer address>
- source = <source type>
- time-detected = <detected time>
-
- - Response Parameters
- result = <result>
- address = <registered address>
- hostname = <registered hostname>
- namehint = <name hint>
- error = <error>
- time-accepted = <accepted time>
-
- b. Message Examples
-
- - Request message
- POST /cgi-bin/registrar.cgi HTTP/1.1
- Host: registrar-host
- Content-Length: mmm
- User-Agent: DAD-detector
- Content-type: application/x-pnp-dnar
-
- method=register/2.0
- detectorID=3ffe:xxxx::2a0:c9ff:fea6:7ff1
- IP-address=3ffe:yyyy::202:b3ff:fe2d:68c0
- link-layer-address=00:00:4c:zz:zz:zz
- source=DAD-detector
- time-detected=1013078377
-
- - Response message
- HTTP/1.1 200 OK
- Content-Type : text/plain
- Content-Length : nnn
- Connection : close
-
- result=REGISTER
- address=3ffe:yyyy::202:b3ff:fe2d:68c0
- hostname=host.example.com
- namehint=none
- time-accepted=1013078378
-
-
-
-
-H. Kitamura [Page 19]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
-References
-
- [IPv6] S. Deering, R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification," RFC2460, December 1998.
-
- [ND] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery
- for IP Version 6 (IPv6)," RFC 2461, December 1998.
-
- [ADDR-AUTO] S. Thomson, T. Narten, "IPv6 Stateless Address
- Autoconfiguration," RFC2462, December 1998.
-
- [DYN-DNS] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound, "Dynamic
- Updates in the Domain Name System," RFC 2136, April 1997.
-
- [TSIG] P. Vixie, O. Gudmundsson, D. Eastlake, D. and B.
- Wellington, "Secret Key Transaction Signatures for DNS
- (TSIG)," RFC 2845, May 2000.
-
- [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0",
- RFC2246, January 1999
-
- [DNS-SIG0] D. Eastlake, "DNS Request and Transaction Signatures
- ( SIG(0)s)," RFC2931, September 2000.
-
- [DYN-DNSSEC] B. Wellington, "Secure Domain Name System (DNS) Dynamic
- Update," RFC3007, November 2000.
-
- [DNSSEC] B. Wellington, "Domain Name System Security (DNSSEC) Signing
- Authority," RFC 3008, November 2000.
-
- [SNMP] J. Case, K. McCloghrie, M. Rose, S.Waldbusser, "Protocol
- Operations for Version 2 of the Simple Network Management
- Protocol (SNMPv2)," RFC1905, January 1996.
-
- [RFC3041] T. Narten, R. Draves, "Privacy Extensions for Stateless
- Address Autoconfiguration in IPv6," RFC3041, January 2001
-
- [HTTP] R. Fielding, et al, "Hypertext Transfer Protocol -- HTTP/1.1"
- RFC2616, June 1999
-
- [TLS-HTTP] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1"
- RFC2817, May 2000
-
-
-
-
-
-
-
-
-
-H. Kitamura [Page 20]
-\f
-INTERNET-DRAFT Domain Name Auto-Registration December 2002
-
-
- [DNS-DISC] A. Durand, J. Hagino, D. Thaler, "Well known site local
- unicast addresses for DNS resolver,"
- <draft-ietf-ipv6-dns-discovery-07.txt>, October 2002
-
- [DEF-ADDR] R. Draves, "Default Address Selection for IPv6,"
- <draft-ietf-ipngwg-default-addr-select-09.txt>, August 2002
-
-
- [NIQ] M. Crawford, "IPv6 Node Information Queries,"
- <draft-ietf-ipngwg-icmp-name-lookups-09.txt>, May 2002
-
-
-
-
-
-
-Author's Address:
-
- Hiroshi Kitamura
- NEC Corporation
- Development Laboratories
- (Igarashi Building 4F) 11-5, Shibaura 2-Chome,
- Minato-Ku, Tokyo 108-8557, JAPAN
-
- Phone: +81 (3) 5476-1071
- Fax: +81 (3) 5476-1005
- Email: kitamura@da.jp.nec.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-H. Kitamura [Page 21]
+++ /dev/null
-
-
-DNS Extensions O. Kolkman
-Internet-Draft RIPE NCC
-Expires: August 18, 2003 J. Schlyter
- Carlstedt Research &
- Technology
- E. Lewis
- ARIN
- February 17, 2003
-
-
- KEY RR Key-Signing Key (KSK) Flag
- draft-ietf-dnsext-keyrr-key-signing-flag-06
-
-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.
-
- This Internet-Draft will expire on August 18, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- With the DS resource record the concept of key-signing and
- zone-signing keys has been introduced. During key-exchanges with the
- parent there is a need to differentiate between these zone- and
- key-signing keys. We propose a flag to indicate which key is used as
- key-signing key.
-
-
-
-
-
-
-Kolkman, et al. Expires August 18, 2003 [Page 1]
-
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. The Key-Signing Key (KSK) Flag . . . . . . . . . . . . . . . . 4
- 3. DNSSEC Protocol Changes . . . . . . . . . . . . . . . . . . . 4
- 4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
- 7. Internationalization Considerations . . . . . . . . . . . . . 5
- 8. Document Changes . . . . . . . . . . . . . . . . . . . . . . . 6
- 8.1 draft version 00 -> 01 . . . . . . . . . . . . . . . . . . . . 6
- 8.2 draft version 01 -> 02 . . . . . . . . . . . . . . . . . . . . 6
- 8.3 draft version 02 -> 03 . . . . . . . . . . . . . . . . . . . . 6
- 8.4 draft version 03 -> 04 . . . . . . . . . . . . . . . . . . . . 6
- 8.5 draft version 04 -> 05 . . . . . . . . . . . . . . . . . . . . 6
- 8.6 draft version 05 -> 06 . . . . . . . . . . . . . . . . . . . . 7
- 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
- Normative References . . . . . . . . . . . . . . . . . . . . . 7
- Informative References . . . . . . . . . . . . . . . . . . . . 8
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
- Intellectual Property and Copyright Statements . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires August 18, 2003 [Page 2]
-
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
-
-
-1. Introduction
-
- "All keys are equal but some keys are more equal than others" [6]
-
- With the definition of the DS Resource Record [5] the concept of a
- key being either a key-signing key (KSK) or zone-signing key(ZSK) has
- been introduced into DNSSEC[3]. A KSK is one that signs the zone's
- KEY RR set, and is a key that is either used to generate a DS RR or
- is distributed to resolvers that use the key as the root of a trusted
- subtree[4].
-
- In early deployment tests, the use of two keys has been prevalent,
- one key for exchange with delegating zone and the other key to sign
- the zone. These dual roles were defined to allow a zone to more
- rapidly change the ZSK without a high volume of traffic needed to
- make new DS RRs. Because of this, participants have had to manage
- two keys at all times, one acting as a KSK and the other ZSK (per
- cryptographic algorithm). In practice, participants used a longer
- key for the KSK or resorted to writing the footprints on paper.
-
- There is a need to differentiate between a KSK and a ZSK by the zone
- administrator. This need is driven by knowing which keys are to be
- sent for DS RRs, which keys are to be distributed to resolvers, and
- which keys are fed to the signer application at the appropriate time.
-
- While addressing this need it is important that the distinction is
- made in a way compatible with single key zone, those whose KSK and
- ZSK is one in the same. The best way to address this is to define a
- bit setting in the KEY RR flags field that is ignored in the
- resolver. This allows for both dual key and single key management to
- be workable.
-
- The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
- "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
- interpreted as described in RFC2119.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires August 18, 2003 [Page 3]
-
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
-
-
-2. The Key-Signing Key (KSK) Flag
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | flags |K| protocol | algorithm |
- | |S| | |
- | |K| | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | /
- / public key /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- KEY RR Format
-
- The KSK bit (TBD) in the flags field is assigned to be the
- key-signing key flag. If the the bit is set to 1 the key is intended
- to be used as key-signing key. One SHOULD NOT assign special meaning
- to the key if the bit is set to 0. The document proposes using the
- current 15th bit [1] as the KSK bit. This way operators can recognize
- the key-signing by the even or odd-ness of the decimal representation
- of the flag field.
-
-3. DNSSEC Protocol Changes
-
- The bit MUST NOT be used during the resolving and verification
- process. The KSK flag is only used to provide a hint about the
- different administrative properties of the key and therefore the use
- of the KSK flag does not change the DNS resolution and resolution
- protocol.
-
-4. Operational Guidelines
-
- The KSK bit is set by the key-generator and used by the zone signer:
-
- The KSK bit is used to indicate that the key represented in the KEY
- RR is intended to sign the KEY RR set of the zone. As the KSK bit is
- within the data that is used to compute a KEY RR's footprint,
- changing the KSK bit will change the identity of the key within DNS.
-
- When a key pair is created, the operator needs to indicate whether
- the KSK bit is to be set in the KEY RR. The KSK bit is recommended
- whenever the public key of the key pair will be distributed to the
- parent zone to build the authentication chain or if the public key is
- to be distributed for static configuration in verifiers.
-
- When signing a zone, it is intended that the key(s) with the KSK bit
-
-
-
-Kolkman, et al. Expires August 18, 2003 [Page 4]
-
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
-
-
- set (if such keys exist) are used to sign the KEY RR set of the zone.
- The same key can be used to sign the rest of the zone data too. It
- is conceivable that not all keys with a KSK bit set will sign the KEY
- RR set, such keys might be pending retirement or not yet in use.
-
- When verifying a RR set, the KSK bit is not intended to play a role.
- How the key is used by the verifier is not intended to be a
- consideration at key creation time.
-
- Although the KSK flag provides a hint on which key to be used as
- trusted root, administrators can choose to ignore the flag when
- configuring a trusted root for their resolvers.
-
- Using the flag a key roll over can be automated. The parent can use
- an existing trust relation to verify key sets in which a new key with
- the KSK flag appears.
-
-5. Security Considerations
-
- As stated in Section 3 the flag is not to used in the resolution
- protocol or to determine the security status of a key. The flag is to
- be used for administrative purposes only.
-
- No trust in a key should be inferred from this flag - trust MUST be
- inferred from an existing chain of trust or an out-of-band exchange.
-
- Since this flag might be used for automating key exchanges, we think
- the following consideration is in place.
-
- Automated mechanisms for roll over of the DS RR might be vulnerable
- to a class of replay attacks. This might happen after a key exchange
- where a key set, containing two keys with the KSK flag set, is sent
- to the parent. The parent verifies the key set with the existing
- trust relation and creates the new DS RR from the key that the
- current DS is not pointing to. This key exchange might be replayed.
- Parents are encouraged to implement a replay defence. A simple
- defence can be based on a registry of keys that have been used to
- generate DS RRs during the most recent roll over.
-
-6. IANA Considerations
-
- draft-ietf-dnsext-restrict-key-for-dnssec [1] eliminates all flags
- field except for the zone key flag in the KEY RR. We propose to use
- the 15'th bit as the KSK bit; the decimal representation of the
- flagfield will then be odd for key-signing keys.
-
-7. Internationalization Considerations
-
-
-
-
-Kolkman, et al. Expires August 18, 2003 [Page 5]
-
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
-
-
- There are no internationalization considerations.
-
-8. Document Changes
-
-8.1 draft version 00 -> 01
-
- Clean up of references and correction of typos;
-
- modified Abstract text a little;
-
- Added explicit warning for replay attacks to the security section;
-
- Removed the text that hinted on a distinction between a
- key-signing key configured in resolvers and in parent zones.
-
-
-8.2 draft version 01 -> 02
-
- Added IANA and Internationalization section.
-
- Split references into informational and normative.
-
- Spelling and style corrections.
-
-
-8.3 draft version 02 -> 03
-
- Changed the name from KS to KSK, this to prevent confusion with
- NS, DS and other acronyms in DNS.
-
- In the security section: Rewrote the section so that it does not
- suggest to use a particular type of registry and that it is clear
- that a key registry is only one of the defences possible.
-
- Spelling and style corrections.
-
-
-8.4 draft version 03 -> 04
-
- Text has been made consistent with the statement: 'No special
- meaning should be assigned to the bit not being set.'
-
- Made explicit that the keytag changes in SIG RR.
-
-
-8.5 draft version 04 -> 05
-
- One occurrence of must and one occurrence of should uppercased
-
-
-
-Kolkman, et al. Expires August 18, 2003 [Page 6]
-
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
-
-
- (RFC2119).
-
- Reordering of sentences in section 3, so that the point of the bit
- NOT being used in resolving is made directly.
-
- To make explicit that the KSK is used at key generation and at
- signing time I added the first sentence to section 4.
-
- Some minor style and spelling corrections.
-
-
-8.6 draft version 05 -> 06
-
- References and acronyms where stripped from the Abstract. the
- Introduction and the the Operational Guideline section were
- rewritten in such a way that the draft does not suggest any use of
- the bit in the verification process and that the draft does not
- enforce, but suggests, the use of a key- and zone-signing key.
-
- Added 'and verification' in the sentence "MUST NOT be used during
- the resolving and verification process" (protocol changes
- section).
-
-
-9. Acknowledgements
-
- The ideas documented in this document are inspired by communications
- we had with numerous people and ideas published by other folk. Among
- others Mark Andrews, Olafur Gudmundsson, Daniel Karrenberg, Dan
- Massey, Marcos Sanz and Sam Weiler have contributed ideas and
- provided feedback.
-
- This document saw the light during a workshop on DNSSEC operations
- hosted by USC/ISI.
-
-Normative References
-
- [1] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
- Record out", draft-ietf-dnsext-restrict-key-for-dnssec-04 (work
- in progress), September 2002.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [3] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [4] Lewis, E., "DNS Security Extension Clarification on Zone
-
-
-
-Kolkman, et al. Expires August 18, 2003 [Page 7]
-
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
-
-
- Status", RFC 3090, March 2001.
-
-Informative References
-
- [5] Gudmundsson, O., "Delegation Signer Resource Record",
- draft-ietf-dnsext-delegation-signer-12 (work in progress),
- December 2002.
-
- [6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
- Story"", ISBN 0151002177 (50th anniversery edition), April 1996.
-
-
-Authors' Addresses
-
- Olaf M. Kolkman
- RIPE NCC
- Singel 256
- Amsterdam 1016 AB
- NL
-
- Phone: +31 20 535 4444
- EMail: olaf@ripe.net
- URI: http://www.ripe.net/
-
-
- Jakob Schlyter
- Carlstedt Research & Technology
- Stora Badhusgatan 18-20
- Goteborg SE-411 21
- Sweden
-
- EMail: jakob@crt.se
- URI: http://www.crt.se/~jakob/
-
-
- Edward P. Lewis
- ARIN
- 3635 Concorde Parkway Suite 200
- Chantilly, VA 20151
- US
-
- Phone: +1 703 227 9854
- EMail: edlewis@arin.net
- URI: http://www.arin.net/
-
-
-
-
-
-
-
-Kolkman, et al. Expires August 18, 2003 [Page 8]
-
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). 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 assignees.
-
- 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
-
-
-
-Kolkman, et al. Expires August 18, 2003 [Page 9]
-
-Internet-Draft KEY RR Key-Signing Key (KSK) Flag February 2003
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kolkman, et al. Expires August 18, 2003 [Page 10]
-
+++ /dev/null
-
-
-
-
-
-
-DNSEXT Working Group Levon Esibov
-INTERNET-DRAFT Bernard Aboba
-Category: Standards Track Dave Thaler
-<draft-ietf-dnsext-mdns-19.txt> Microsoft
-12 May 2003
-
-
- Linklocal Multicast Name Resolution (LLMNR)
-
-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.
-
-Copyright Notice
-
-Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
-Today, with the rise of home networking, there are an increasing number
-of ad-hoc networks operating without a Domain Name System (DNS) server.
-In order to allow name resolution in such environments, Link-Local
-Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all
-current and future DNS formats, types and classes, while operating on a
-separate port from DNS, and with a distinct resolver cache.
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 1]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-Table of Contents
-
-1. Introduction .......................................... 3
- 1.1 Requirements .................................... 4
- 1.2 Terminology ..................................... 4
-2. Name resolution using LLMNR ........................... 4
- 2.1 Sender behavior ................................. 5
- 2.2 Responder behavior .............................. 5
- 2.3 Unicast queries ................................. 6
- 2.4 Addressing ...................................... 7
- 2.5 Off-link detection .............................. 8
- 2.6 Retransmissions ................................. 8
- 2.7 DNS TTL ......................................... 9
-3. Usage model ........................................... 9
- 3.1 Unqualified names ............................... 10
- 3.2 LLMNR configuration ............................. 10
-4. Conflict resolution ................................... 12
- 4.1 Considerations for multiple interfaces .......... 13
- 4.2 API issues ...................................... 14
-5. Security considerations ............................... 15
- 5.1 Scope restriction ............................... 15
- 5.2 Usage restriction ............................... 16
- 5.3 Cache and port separation ....................... 17
- 5.4 Authentication .................................. 17
-6. IANA considerations ................................... 17
-7. Normative References .................................. 17
-8. Informative References ................................ 18
-Acknowledgments .............................................. 19
-Authors' Addresses ........................................... 19
-Intellectual Property Statement .............................. 20
-Full Copyright Statement ..................................... 20
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 2]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-1. Introduction
-
-This document discusses Link Local Multicast Name Resolution (LLMNR),
-which operates on a separate port from the Domain Name System (DNS),
-with a distinct resolver cache, but does not change the format of DNS
-packets. LLMNR supports all current and future DNS formats, types and
-classes. However, since LLMNR only operates on the local link, it
-cannot be considered a substitute for DNS.
-
-The goal of LLMNR is to enable name resolution in scenarios in which
-conventional DNS name resolution is not possible. These include
-scenarios in which hosts are not configured with the address of a DNS
-server, where configured DNS servers do not reply to a query, or where
-they respond with errors, as described in Section 3.
-
-LLMNR queries are sent to and received on port TBD. Link-scope
-multicast addresses are used to prevent propagation of LLMNR traffic
-across routers, potentially flooding the network; for details, see
-Section 2.4. LLMNR queries can also be sent to a unicast address, as
-described in Section 2.3.
-
-Propagation of LLMNR packets on the local link is considered sufficient
-to enable name resolution in small networks. The assumption is that if
-a network has a home gateway, then the network either has DNS and DHCPv4
-servers or the home gateway provides DHCPv4 and DNS server
-functionality. By providing Dynamic Host Configuration Service for
-IPv4 (DHCPv4), as well as a DNS server with support for dynamic DNS,
-which is also authoritative for the A RRs of local hosts, it is possible
-to support resolution of local host names over IPv4.
-
-For small IPv6 networks, equivalent functionality can be provided by
-implementing Dynamic Host Configuration Service for IPv6 (DHCPv6) for
-DNS configuration [DHCPv6DNS], as well providing a DNS server with
-support for dynamic DNS, which is also authoritative for the AAAA RRs of
-local hosts, it is possible to support the resolution of local host
-names over IPv6 as well as IPv4.
-
-In the future, LLMNR may be defined to support greater than link-scope
-multicast. This would occur if LLMNR deployment is successful, the
-assumption that LLMNR is not needed on multiple links proves incorrect,
-and multicast routing becomes ubiquitous. For example, it is not clear
-that this assumption will be valid in large ad hoc networking scenarios.
-
-Once we have experience in LLMNR deployment in terms of administrative
-issues, usability and impact on the network it will be possible to
-reevaluate which multicast scopes are appropriate for use with multicast
-name resolution mechanisms.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 3]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-Service discovery in general, as well as discovery of DNS servers using
-LLMNR in particular, is outside of the scope of this document, as is
-name resolution over non-multicast capable media.
-
-1.1. Requirements
-
-In this document, several words are used to signify the requirements of
-the specification. These words are often capitalized. 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].
-
-1.2. Terminology
-
-Responder A host that listens to LLMNR queries, and responds to
- those for which it is authoritative.
-
-Sender A host that sends an LLMNR query. Typically a host is
- configured as both a sender and a responder. However, a
- host may be configured as a sender, but not a responder
- or as a responder, but not a sender.
-
-Routable address
- An address other than a linklocal address. This includes
- site local and globally routable addresses, as well as
- private addresses.
-
-2. Name resolution using LLMNR
-
-A typical sequence of events for LLMNR usage is as follows:
-
-[1] A sender needs to resolve a query for a name "host.example.com",
- so it sends an LLMNR query to the link-scope multicast address.
-
-[2] A responder responds to this query only if it is authoritative
- for the domain name "host.example.com". The responder sends
- a response to the sender via unicast over UDP.
-
-[3] Upon the reception of the response, the sender performs the checks
- described in Section 2.5. If these conditions are met, then the
- sender uses and caches the returned response. If not, then the
- sender ignores the response and continues waiting for the response.
-
-Further details of sender and responder behavior are provided in the
-sections that follow.
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 4]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-2.1. Sender behavior
-
-A sender sends an LLMNR query for any legal resource record type (e.g.
-A/AAAA, SRV, PTR, etc.) to the link-scope multicast address. As
-described in Section 2.3, a sender may also send a unicast query. An
-LLMNR sender MAY send a request for any name.
-
-The RD (Recursion Desired) bit MUST NOT be set in a query. If a
-responder receives a query with the header containing RD set bit, the
-responder MUST ignore the RD bit.
-
-The sender MUST anticipate receiving no replies to some LLMNR queries,
-in the event that no responders are available within the link-scope or
-in the event no positive non-null responses exist for the transmitted
-query. If no positive response is received, a resolver treats it as a
-response that no records of the specified type and class exist for the
-specified name (it is treated the same as a response with RCODE=0 and an
-empty answer section).
-
-2.2. Responder behavior
-
-A responder MUST listen on UDP port TBD on the link-scope multicast
-address(es) and on UDP and TCP port TBD on the unicast address(es) that
-could be set as the source address(es) when the responder responds to
-the LLMNR query. A host configured as a responder MUST act as a sender
-to verify the uniqueness of names as described in Section 4.
-
-Responders MUST NOT respond to LLMNR queries for names they are not
-authoritative for, except in the event of a discovered conflict, as
-described in Section 4. Responders SHOULD respond to LLMNR queries for
-names and addresses they are authoritative for. This applies to both
-forward and reverse lookups.
-
-As an example, a computer "host.example.com." configured to respond to
-LLMNR queries is authoritative for the name "host.example.com.". On
-receiving an LLMNR A/AAAA resource record query for the name
-"host.example.com." the host authoritatively responds with A/AAAA
-record(s) that contain IP address(es) in the RDATA of the resource
-record.
-
-If a responder is authoritative for a name, it MAY respond with RCODE=0
-and an empty answer section, if the type of query does not match a RR
-owned by the responder. For example, if the host has a AAAA RR, but no
-A RR, and an A RR query is received, the host would respond with RCODE=0
-and an empty answer section.
-
-If a DNS server is running on a host that supports LLMNR, the DNS server
-MUST respond to LLMNR queries only for the RRSets owned by the host on
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 5]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-which the server is running, but MUST NOT respond for other records for
-which the server is authoritative.
-
-In conventional DNS terminology a DNS server authoritative for a zone is
-authoritative for all the domain names under the zone root except for
-the branches delegated into separate zones. Contrary to conventional
-DNS terminology, an LLMNR responder is authoritative only for the zone
-root.
-
-For example the host "host.example.com." is not authoritative for the
-name "child.host.example.com." unless the host is configured with
-multiple names, including "host.example.com." and
-"child.host.example.com.". As a result, "host" cannot reply to a query
-for "child" with NXDOMAIN. The purpose of limiting the name authority
-scope of a responder is to prevent complications that could be caused by
-coexistence of two or more hosts with the names representing child and
-parent (or grandparent) nodes in the DNS tree, for example,
-"host.example.com." and "child.host.example.com.".
-
-In this example (unless this limitation is introduced) an LLMNR query
-for an A resource record for the name "child.host.example.com." would
-result in two authoritative responses: a name error received from
-"host.example.com.", and a requested A record - from
-"child.host.example.com.". To prevent this ambiguity, LLMNR enabled
-hosts could perform a dynamic update of the parent (or grandparent) zone
-with a delegation to a child zone. In this example a host
-"child.host.example.com." would send a dynamic update for the NS and
-glue A record to "host.example.com.", but this approach significantly
-complicates implementation of LLMNR and would not be acceptable for
-lightweight hosts.
-
-A response to a LLMNR query is composed in exactly the same manner as a
-response to the unicast DNS query as specified in [RFC1035]. Responders
-MUST NOT respond using cached data, and the AA (Authoritative Answer)
-bit MUST be set. The response is sent to the sender via unicast. A
-response to an LLMNR query MUST have RCODE set to zero. Responses with
-RCODE set to zero are referred to in this document as "positively
-resolved". LLMNR responders may respond only to queries which they can
-resolve positively.
-
-2.3. Unicast queries and responses
-
-Unicast queries SHOULD be sent when:
-
- a. A sender repeats a query after it received a response
- with the TC bit set to the previous LLMNR multicast query, or
-
- b. The sender's LLMNR cache contains an NS resource record that
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 6]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
- enables the sender to send a query directly to the hosts
- authoritative for the name in the query, or
-
- c. The sender queries for a PTR RR.
-
-If a TC (truncation) bit is set in the response, then the sender MAY use
-the response if it contains all necessary information, or the sender MAY
-discard the response and resend the query over TCP using the unicast
-address of the responder. The RA (Recursion Available) bit in the
-header of the response MUST NOT be set. If the RA bit is set in the
-response header, the sender MUST ignore the RA bit.
-
-Unicast LLMNR queries SHOULD be sent using TCP. Responses to TCP
-unicast LLMNR queries MUST be sent using TCP, using the same connection
-as the query. If the sender of a TCP query receives a response not
-using TCP, the response MUST be silently discarded. Unicast UDP queries
-MAY be responded to with an empty answer section and the TC bit set, so
-as to require the sender to resend the query using TCP. Senders MUST
-support sending TCP queries, and Responders MUST support listening for
-TCP queries. The Responder SHOULD set the TTL or Hop Limit settings on
-the TCP listen socket to one (1) so that SYN-ACK packets will have TTL
-(IPv4) or Hop Limit (IPv6) set to one (1). This prevents an incoming
-connection from off-link since the Sender will not receive a SYN-ACK
-from the Responder.
-
-If an ICMP "Time Exceeded" message is received in response to a unicast
-UDP query, or if TCP connection setup cannot be completed in order to
-send a unicast TCP query, this is treated as a response that no records
-of the specified type and class exist for the specified name (it is
-treated the same as a response with RCODE=0 and an empty answer
-section). The UDP sender receiving an ICMP "Time Exceeded" message
-SHOULD verify that the ICMP error payload contains a valid LLMNR query
-packet, which matches a query that is currently in progress, so as to
-guard against a potential Denial of Service (DoS) attack. If a match
-cannot be made, then the sender relies on the retransmission and timeout
-behavior described in Section 2.6.
-
-2.4. Addressing
-
-IPv4 administratively scoped multicast usage is specified in
-"Administratively Scoped IP Multicast" [RFC2365]. The IPv4 link-scope
-multicast address a given responder listens to, and to which a sender
-sends queries, is 224.0.0.251. The IPv6 link-scope multicast address a
-given responder listens to, and to which a sender sends all queries, is
-TBD.
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 7]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-2.5. Off-link detection
-
-The source address of LLMNR queries and responses MUST be "on link".
-The destination address of an LLMNR query MUST be a link-scope multicast
-address or an "on link" unicast address; the destination address of an
-LLMNR response MUST be an "on link" unicast address. On receiving an
-LLMNR query, the responder MUST check whether it was sent to the LLMNR
-multicast address; if it was sent to another multicast address, then the
-query MUST be silently discarded.
-
-For IPv4, an "on link" address is defined as a link-local address or an
-address whose prefix belongs to a subnet on the local link; for IPv6
-[RFC2460] an "on link" address is either a link-local address, defined
-in [RFC2373], or an address whose prefix belongs to a subnet on the
-local link. A sender SHOULD prefer RRs including reachable addresses
-where RRs involving both reachable and unreachable addresses are
-returned in response to a query.
-
-In composing LLMNR queries, the sender MUST set the Hop Limit field in
-the IPv6 header and the TTL field in IPv4 header of the response to one
-(1). Even when LLMNR queries are sent to a link-scope multicast
-address, it is possible that some routers may not properly implement
-link-scope multicast, or that link-scope multicast addresses may leak
-into the multicast routing system. Therefore setting the IPv6 Hop Limit
-or IPv4 TTL field to one provides an additional precaution against
-leakage of LLMNR queries.
-
-In composing a response to an LLMNR query, the responder MUST set the
-Hop Limit field in the IPv6 header and the TTL field in IPv4 header of
-the response to one (1). This is done so as to prevent the use of LLMNR
-for denial of service attacks across the Internet.
-
-Implementation note:
-
- In the sockets API for IPv4, the IP_TTL and IP_MULTICAST_TTL socket
- options are used to set the TTL of outgoing unicast and multicast
- packets. The IP_RECVTTL socket option is available on some platforms
- to retrieve the IPv4 TTL of received packets with recvmsg().
- [RFC2292] specifies similar options for setting and retrieving the
- IPv6 Hop Limit.
-
-2.6. Retransmissions
-
-In order to avoid synchronization, LLMNR queries and responses are
-delayed by a time uniformly distributed between 0 and 200 ms.
-
-If an LLMNR query sent over UDP is not resolved within the timeout
-interval (LLMNR_TIMEOUT), then a sender MAY repeat the transmission of
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 8]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-the query in order to assure that it was received by a host capable of
-responding to it. Since a multicast query sender cannot know beforehand
-whether it will receive no response, one response, or more than one
-response, it SHOULD wait for LLMNR_TIMEOUT in order to collect all
-possible responses, rather than considering the multicast query answered
-after the first response is received. A unicast query sender considers
-the query answered after the first response is received, so that it only
-waits for LLMNR_TIMEOUT if no response has been received.
-
-LLMNR implementations SHOULD dynamically estimate the timeout value
-(LLMNR_TIMEOUT) based on the last response received, on a per-interface
-basis, using the algorithms described in [RFC2988], with a minimum
-timeout value of 300 ms. Retransmission of UDP queries SHOULD NOT be
-attempted more than 3 times. Where LLMNR queries are sent using TCP,
-retransmission is handled by the transport layer.
-
-2.7. DNS TTL
-
-The responder should use a pre-configured TTL value in the records
-returned in the LLMNR query response. Due to the TTL minimalization
-necessary when caching an RRset, all TTLs in an RRset MUST be set to the
-same value. In the additional and authority section of the response the
-responder includes the same records as a DNS server would insert in the
-response to the unicast DNS query.
-
-3. Usage model
-
-LLMNR is a peer-to-peer name resolution protocol that is not intended as
-a replacement for DNS. By default, LLMNR requests SHOULD be sent only
-when no manual or automatic DNS configuration has been performed, when
-DNS servers do not respond, or when they respond to a query with RCODE=3
-(Authoritative Name Error) or RCODE=0, and an empty answer section.
-
-As noted in [DNSPerf], even when DNS servers are configured, a
-significant fraction of DNS queries do not receive a response, or result
-in a negative responses due to missing inverse mappings or NS records
-that point to nonexistent or inappropriate hosts. Given this, support
-for LLMNR as a secondary name resolution mechanism has the potential to
-result in a large number of inappropriate queries without the following
-additional restrictions:
-
-[1] If a DNS query does not receive a response, prior to falling
- back to LLMNR, the query SHOULD be retransmitted at least
- once.
-
-[2] Where a DNS server is configured, by default a sender
- SHOULD send LLMNR queries only for names that are either
- unqualified or exist within the default domain. Where no
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 9]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
- DNS server is configured, an LLMNR query MAY be sent for
- any name.
-
-[3] A responder with both link-local and routable addresses
- MUST respond to LLMNR queries for A/AAAA RRs only with
- routable address(es). This encourages use of routable
- address(es) for establishment of new connections.
-
-[4] A sender SHOULD send LLMNR queries for PTR RRs
- via unicast, as specified in Section 2.3.
-
-RRs returned in LLMNR responses MUST only include values that are valid
-on the local interface, such as IPv4 or IPv6 addresses valid on the
-local link or names defended using the mechanism described in Section 4.
-In particular:
-
-[1] If a link-scope IPv6 address is returned in a AAAA RR, that
- address MUST be valid on the local link over which LLMNR is
- used.
-
-[2] If an IPv4 address is returned, it must be reachable through
- the link over which LLMNR is used.
-
-[3] If a name is returned (for example in a CNAME, MX
- or SRV RR), the name MUST be valid on the local interface.
-
-3.1. Unqualified names
-
-The same host MAY use LLMNR queries for the resolution of unqualified
-host names, and conventional DNS queries for resolution of other DNS
-names.
-
-If a name is not qualified and does not end in a trailing dot, for the
-purposes of LLMNR, the implicit search order is as follows:
-
-[1] Request the name with the current domain appended.
-[2] Request just the name.
-
-This is the behavior suggested by [RFC1536]. LLMNR uses this technique
-to resolve unqualified host names.
-
-3.2. LLMNR configuration
-
-LLMNR usage MAY be configured manually or automatically on a per
-interface basis. By default, LLMNR responders SHOULD be enabled on all
-interfaces, at all times.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 10]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-Since IPv4 and IPv6 utilize distinct configuration mechanisms, it is
-possible for a dual stack host to be configured with the address of a
-DNS server over IPv4, while remaining unconfigured with a DNS server
-suitable for use over IPv6. In these situations, a dual stack host will
-send AAAA queries to the configured DNS server over IPv4.
-
-However, an IPv6-only host unconfigured with a DNS server suitable for
-use over IPv6 will be unable to resolve names using DNS. Since
-automatic IPv6 DNS configuration mechanisms (such as [DHCPv6DNS] and
-[DNSDisc]) are not yet widely deployed, and not all DNS servers support
-IPv6, lack of IPv6 DNS configuration may be a common problem in the
-short term, and LLMNR may prove useful in enabling linklocal name
-resolution over IPv6.
-
-For example, a home network may provide a DHCPv4 server but may not
-support DHCPv6 for DNS configuration [DHCPv6DNS]. In such a
-circumstance, IPv6-only hosts will not be configured with a DNS server.
-Where a DNS server is configured but does not support dynamic client
-update over IPv6 or DHCPv6-based dynamic update, hosts on the home
-network will not be able to dynamically register or resolve the names of
-local IPv6 hosts. If the configured DNS server responds to AAAA RR
-queries sent over IPv4 or IPv6 with an authoritative name error
-(RCODE=3), then it will not be possible to resolve the names of
-IPv6-only hosts. In this situation, LLMNR over IPv6 can be used for
-local name resolution.
-
-Where DHCPv4 or DHCPv6 is implemented, DHCP options can be used to
-configure LLMNR on an interface. The LLMNR Enable Option, described in
-[LLMNREnable], can be used to explicitly enable or disable use of LLMNR
-on an interface. The LLMNR Enable Option does not determine whether or
-in which order DNS itself is used for name resolution. The order in
-which various name resolution mechanisms should be used can be specified
-using the Name Service Search Option for DHCP [RFC2937].
-
-3.2.1. Configuration consistency
-
-It is possible that DNS configuration mechanisms will go in and out of
-service. In these circumstances, it is possible for hosts within an
-administrative domain to be inconsistent in their DNS configuration.
-
-For example, where DHCP is used for configuring DNS servers, one or more
-DHCP servers can go down. As a result, hosts configured prior to the
-outage will be configured with a DNS server, while hosts configured
-after the outage will not. Alternatively, it is possible for the DNS
-configuration mechanism to continue functioning while configured DNS
-servers fail.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 11]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-Unless unconfigured hosts periodically retry configuration, an outage in
-the DNS configuration mechanism will result in hosts continuing to
-prefer LLMNR even once the outage is repaired. Since LLMNR only enables
-linklocal name resolution, this represents an unnecessary degradation in
-capabilities. As a result, it is recommended that hosts without a
-configured DNS server periodically attempt to obtain DNS configuration.
-A default retry interval of two (2) minutes is RECOMMENDED.
-
-4. Conflict resolution
-
-The sender MUST anticipate receiving multiple replies to the same LLMNR
-query, in the event that several LLMNR enabled computers receive the
-query and respond with valid answers. When this occurs, the responses
-MAY first be concatenated, and then treated in the same manner that
-multiple RRs received from the same DNS server would.
-
-There are some scenarios when multiple responders MAY respond to the
-same query. There are other scenarios when only one responder MAY
-respond to a query. Resource records for which the latter queries are
-submitted are referred as UNIQUE throughout this document. The
-uniqueness of a resource record depends on a nature of the name in the
-query and type of the query. For example it is expected that:
-
- - multiple hosts may respond to a query for an SRV type record
- - multiple hosts may respond to a query for an A or AAAA type
- record for a cluster name (assigned to multiple hosts in
- the cluster)
- - only a single host may respond to a query for an A or AAAA
- type record for a hostname.
-
-Every responder that responds to an LLMNR query AND includes a UNIQUE
-record in the response:
-
- 1. MUST verify that there is no other host within the scope of the
- LLMNR query propagation that can return a resource record
- for the same name, type and class.
- 2. MUST NOT include a UNIQUE resource record in the
- response without having verified its uniqueness.
-
-Where a host is configured to respond to LLMNR queries on more than one
-interface, each interface should have its own independent LLMNR cache.
-For each UNIQUE resource record in a given interface's configuration,
-the host MUST verify resource record uniqueness on that interface. To
-accomplish this, the host MUST send an LLMNR query for each UNIQUE
-resource record.
-
-By default, a host SHOULD be configured to behave as though all RRs are
-UNIQUE. Uniqueness verification is carried out when the host:
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 12]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
- - starts up or
- - is configured to respond to the LLMNR queries on an interface or
- - is configured to respond to the LLMNR queries using additional
- UNIQUE resource records.
-
-When a host that owns a UNIQUE record receives an LLMNR query for that
-record, the host MUST respond. After the client receives a response, it
-MUST check whether the response arrived on another interface. If this
-is the case, then the client can use the UNIQUE resource record in
-response to LLMNR queries. If not, then it MUST NOT use the UNIQUE
-resource record in response to LLMNR queries.
-
-The name conflict detection mechanism doesn't prevent name conflicts
-when previously partitioned segments are connected by a bridge. In such
-a situation, name conflicts are detected when a sender receives more
-than one response to its LLMNR multicast query. In this case, the
-sender sends the first response that it received to all responders that
-responded to this query except the first one, using UDP unicast. A host
-that receives a query response containing a UNIQUE resource record that
-it owns, even if it didn't send such a query, MUST verify that no other
-host within the LLMNR scope is authoritative for the same name, using
-the mechanism described above. Based on the result, the host detects
-whether there is a name conflict and acts accordingly.
-
-4.1. Considerations for Multiple Interfaces
-
-A multi-homed host may elect to configure LLMNR on only one of its
-active interfaces. In many situations this will be adequate. However,
-should a host need to configure LLMNR on more than one of its active
-interfaces, there are some additional precautions it MUST take.
-Implementers who are not planning to support LLMNR on multiple
-interfaces simultaneously may skip this section.
-
-A multi-homed host checks the uniqueness of UNIQUE records as described
-in Section 4. The situation is illustrated in figure 1.
-
- ---------- ----------
- | | | |
- [A] [myhost] [myhost]
-
- Figure 1. Link-scope name conflict
-
-In this situation, the multi-homed myhost will probe for, and defend,
-its host name on both interfaces. A conflict will be detected on one
-interface, but not the other. The multi-homed myhost will not be able
-to respond with a host RR for "myhost" on the interface on the right
-(see Figure 1). The multi-homed host may, however, be configured to use
-the "myhost" name on the interface on the left.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 13]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-Since names are only unique per-link, hosts on different links could be
-using the same name. If an LLMNR client sends requests over multiple
-interfaces, and receives replies from more than one, the result returned
-to the client is defined by the implementation. The situation is
-illustrated in figure 2.
-
- ---------- ----------
- | | | |
- [A] [myhost] [A]
-
-
- Figure 2. Off-segment name conflict
-
-If host myhost is configured to use LLMNR on both interfaces, it will
-send LLMNR queries on both interfaces. When host myhost sends a query
-for the host RR for name "A" it will receive a response from hosts on
-both interfaces.
-
-Host myhost will then send the first responder's response to the second
-responder, who will attempt to verify the uniqueness of host RR for its
-name, but will not discover a conflict, since the conflicting host
-resides on a different link. Therefore it will continue using its name.
-
-Host myhost cannot distinguish between the situation shown in Figure 2,
-and that shown in Figure 3 where no conflict exists.
-
- [A]
- | |
- ----- -----
- | |
- [myhost]
-
- Figure 3. Multiple paths to same host
-
-This illustrates that the proposed name conflict resolution mechanism
-does not support detection or resolution of conflicts between hosts on
-different links. This problem can also occur with unicast DNS when a
-multi-homed host is connected to two different networks with separated
-name spaces. It is not the intent of this document to address the issue
-of uniqueness of names within DNS.
-
-4.2. API issues
-
-[RFC2553] provides an API which can partially solve the name ambiguity
-problem for applications written to use this API, since the sockaddr_in6
-structure exposes the scope within which each scoped address exists, and
-this structure can be used for both IPv4 (using v4-mapped IPv6
-addresses) and IPv6 addresses.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 14]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-Following the example in Figure 2, an application on 'myhost' issues the
-request getaddrinfo("A", ...) with ai_family=AF_INET6 and
-ai_flags=AI_ALL|AI_V4MAPPED. LLMNR requests will be sent from both
-interfaces and the resolver library will return a list containing
-multiple addrinfo structures, each with an associated sockaddr_in6
-structure. This list will thus contain the IPv4 and IPv6 addresses of
-both hosts responding to the name 'A'. Link-local addresses will have a
-sin6_scope_id value that disambiguates which interface is used to reach
-the address. Of course, to the application, Figures 2 and 3 are still
-indistinguishable, but this API allows the application to communicate
-successfully with any address in the list.
-
-5. Security Considerations
-
-LLMNR is by nature a peer-to-peer name resolution protocol. It is
-therefore inherently more vulnerable than DNS, since existing DNS
-security mechanisms are difficult to apply to LLMNR and an attacker only
-needs to be misconfigured to answer an LLMNR query with incorrect
-information.
-
-In order to address the security vulnerabilities, the following
-mechanisms are contemplated:
-
-[1] Scope restrictions.
-
-[2] Usage restrictions.
-
-[3] Cache and port separation.
-
-[4] Authentication.
-
-These techniques are described in the following sections.
-
-5.1. Scope restriction
-
-With LLMNR it is possible that hosts will allocate conflicting names for
-a period of time, or that attackers will attempt to deny service to
-other hosts by allocating the same name. Such attacks also allow hosts
-to receive packets destined for other hosts.
-
-Since LLMNR is typically deployed in situations where no trust model can
-be assumed, it is likely that LLMNR queries and responses will be
-unauthenticated. In the absence of authentication, LLMNR reduces the
-exposure to such threats by utilizing queries sent to a link-scope
-multicast address, as well as setting the TTL (IPv4) or Hop Limit (IPv6)
-fields to one (1) on both queries and responses.
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 15]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-While this limits the ability of off-link attackers to spoof LLMNR
-queries and responses, it does not eliminate it. For example, it is
-possible for an attacker to spoof a response to a frequent query (such
-as an A/AAAA query for a popular Internet host), and using a TTL or Hop
-Limit field larger than one (1), for the forged response to reach the
-LLMNR sender. There also are scenarios such as public "hotspots" where
-attackers can be present on the same link.
-
-These threats are most serious in wireless networks such as 802.11,
-since attackers on a wired network will require physical access to the
-home network, while wireless attackers may reside outside the home.
-Link-layer security can be of assistance against these threats if it is
-available.
-
-5.2. Usage restriction
-
-As noted in Section 3, LLMNR is intended for usage in a limited set of
-scenarios.
-
-If an interface has been configured via any automatic configuration
-mechanism which is able to supply DNS configuration information, then
-LLMNR SHOULD NOT be used as the primary name resolution mechanism on
-that interface, although it MAY be used as a name resolution mechanism
-of last resort.
-
-Note: enabling LLMNR for use in situations where a DNS server has been
-configured will result in upgraded hosts changing their default behavior
-without a simultaneous update to configuration information. Where this
-is considered undesirable, LLMNR SHOULD NOT be enabled by default, so
-that hosts will neither listen on the link-scope multicast address, nor
-will it send queries to that address.
-
-Use of LLMNR as a name resolution mechanism increases security
-vulnerabilities. For example, if an LLMNR query is sent whenever a DNS
-server does not respond in a timely way, then an attacker can execute a
-denial of service attack on the DNS server(s) and then poison the LLMNR
-cache by responding to the resulting LLMNR queries with incorrect
-information.
-
-The vulnerability is more serious if LLMNR is given higher priority than
-DNS among the enabled name resolution mechanisms. In such a
-configuration, a denial of service attack on the DNS server would not be
-necessary in order to poison the LLMNR cache, since LLMNR queries would
-be sent even when the DNS server is available. In addition, the LLMNR
-cache, once poisoned, would take precedence over the DNS cache,
-eliminating the benefits of cache separation. As a result, LLMNR is
-best thought of as a name resolution mechanism of last resort.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 16]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-5.3. Cache and port separation
-
-In order to prevent responses to LLMNR queries from polluting the DNS
-cache, LLMNR implementations MUST use a distinct, isolated cache for
-LLMNR on each interface. The use of separate caches is most effective
-when LLMNR is used as a name resolution mechanism of last resort, since
-this minimizes the opportunities for poisoning the LLMNR cache, and
-decreases reliance on it.
-
-LLMNR operates on a separate port from DNS, reducing the likelihood that
-a DNS server will unintentionally respond to an LLMNR query.
-
-5.4. Authentication
-
-LLMNR does not require use of DNSSEC, and as a result, responses to
-LLMNR queries may be unauthenticated. If authentication is desired, and
-a pre-arranged security configuration is possible, then IPsec ESP with a
-null-transform MAY be used to authenticate LLMNR responses. In a small
-network without a certificate authority, this can be most easily
-accomplished through configuration of a group pre-shared key for trusted
-hosts.
-
-6. IANA Considerations
-
-This specification does not create any new name spaces for IANA
-administration. LLMNR requires allocation of a port TBD for both TCP
-and UDP. Assignment of the same port for both transports is requested.
-LLMNR utilizes a link-scope multicast IPv4 address (224.0.0.251) that
-has been previously allocated to LLMNR by IANA. It also requires
-allocation of a link-scope multicast IPv6 address.
-
-7. Normative References
-
-[RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November 1987.
-
-[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992.
-
-[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-[RFC2136] Vixie, P., et al., "Dynamic Updates in the Domain Name
- System (DNS UPDATE)", RFC 2136, April 1997.
-
-[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
- 23, RFC 2365, July 1998.
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 17]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, July 1998.
-
-[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
- (IPv6) Specification", RFC 2460, December 1998.
-
-[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, March 1999.
-
-[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
- Timer", RFC 2988, November 2000.
-
-8. Informative References
-
-[RFC1536] Kumar, A., et. al., "DNS Implementation Errors and
- Suggested Fixes", RFC 1536, October 1993.
-
-[RFC2292] Stevens, W. and M. Thomas, "Advanced Sockets API for
- IPv6", RFC 2292, February 1998.
-
-[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
-[RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
- "Basic Socket Interface Extensions for IPv6", RFC 2553,
- March 1999.
-
-[RFC2937] Smith, C., "The Name Service Search Option for DHCP", RFC
- 2937, September 2000.
-
-[DHCPv6DNS] Droms, R., "A Guide to Implementing Stateless DHCPv6
- Service", Internet draft (work in progress), draft-droms-
- dhcpv6-stateless-guide-01.txt, October 2002.
-
-[DNSPerf] Jung, J., et al., "DNS Performance and the Effectiveness
- of Caching", IEEE/ACM Transactions on Networking, Volume
- 10, Number 5, pp. 589, October 2002.
-
-[DNSDisc] Durand, A., Hagino, I. and D. Thaler, "Well known site
- local unicast addresses to communicate with recursive DNS
- servers", Internet draft (work in progress), draft-ietf-
- ipv6-dns-discovery-07.txt, October 2002.
-
-[IPV4Link] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic
- Configuration of IPv4 Link-Local Addresses", Internet
- draft (work in progress), draft-ietf-zeroconf-
- ipv4-linklocal-07.txt, August 2002.
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 18]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-[LLMNREnable] Guttman, E., "DHCP LLMNR Enable Option", Internet draft
- (work in progress), draft-guttman-mdns-enable-02.txt,
- April 2002.
-
-[NodeInfo] Crawford, M., "IPv6 Node Information Queries", Internet
- draft (work in progress), draft-ietf-ipn-gwg-icmp-name-
- lookups-09.txt, May 2002.
-
-Acknowledgments
-
-This work builds upon original work done on multicast DNS by Bill
-Manning and Bill Woodcock. Bill Manning's work was funded under DARPA
-grant #F30602-99-1-0523. The authors gratefully acknowledge their
-contribution to the current specification. Constructive input has also
-been received from Mark Andrews, Stuart Cheshire, Randy Bush, Robert
-Elz, Rob Austein, James Gilroy, Olafur Gudmundsson, Erik Guttman, Myron
-Hattig, Thomas Narten, Christian Huitema, Erik Nordmark, Sander Van-
-Valkenburg, Tomohide Nagashima, Brian Zill, Keith Moore and Markku
-Savela.
-
-Authors' Addresses
-
-Levon Esibov
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-EMail: levone@microsoft.com
-
-Bernard Aboba
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-Phone: +1 425 706 6605
-EMail: bernarda@microsoft.com
-
-Dave Thaler
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-
-Phone: +1 425 703 8835
-EMail: dthaler@microsoft.com
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 19]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-Intellectual Property Statement
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property or other rights that might be claimed to pertain
-to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might or
-might not be available; neither does it represent that it has made any
-effort to identify any such rights. Information on the IETF's
-procedures with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11. Copies of claims of
-rights made available for publication and any assurances of licenses to
-be made available, or the result of an attempt made to obtain a general
-license or permission for the use of such proprietary rights by
-implementors or users of this specification can be obtained from the
-IETF Secretariat.
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary rights
-which may cover technology that may be required to practice this
-standard. Please address the information to the IETF Executive
-Director.
-
-Full Copyright Statement
-
-Copyright (C) The Internet Society (2003). 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.
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 20]
-
-
-
-
-
-INTERNET-DRAFT LLMNR 12 May 2003
-
-
-Open Issues
-
-Open issues with this specification are tracked on the following web
-site:
-
-http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html
-
-Expiration Date
-
-This memo is filed as <draft-ietf-dnsext-mdns-19.txt>, and expires
-November 22, 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Esibov, Aboba & Thaler Standards Track [Page 21]
-
-
+++ /dev/null
-
-
-
-
-
-
-DNSEXT Working Group Olafur Gudmundsson (NAI Labs)
-INTERNET-DRAFT October 2000
-
-<draft-ietf-dnsext-message-size-01.txt>
-
-Updates: RFC 2535, RFC 2874
-
-
-
- DNSSEC and IPv6 A6 aware server/resolver message size requirements
-
-
-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 DNSEXT WG mailing list
- namedroppers@ops.ietf.org
-
- This draft expires on March 29, 2001.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (2000). All rights reserved.
-
-
-
-
-
-
-
-
-
-
-Expires March 2001 [Page 1]
-\f
-INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000
-
-
-Abstract
-
- This document mandates support for EDNS0 in DNS entities claiming to
- support DNS Security Extensions and A6 records. This requirement is
- necessary because these new features increase the size of DNS
- messages. If EDNS0 is not supported fall back to TCP will happen,
- having a detrimental impact on query latency and DNS server load.
-
-
-
-
-1 - Introduction
-
- Familiarity with the DNS[RFC1034, RFC1035], DNS Security
- Extensions[RFC2535], EDNS0[RFC2671] and A6[RFC2874] is helpful.
-
- RFC 1035[RFC1035] Section 2.3.4 requires that DNS messages over UDP
- have a data payload of 512 octets or less. Most DNS software today
- will not accept larger size UDP datagrams. Thus, any answer that
- requires more than 512 octets will result in a partial and probably
- useless reply with the Truncation Bit set; in most cases the
- requester will then retry using TCP. Some DNS servers send back an
- answer truncating the message at the last RR boundary before
- truncation, other servers truncate at the previous set, some send
- back empty answer with TC bit set.
-
- Compared to UDP, TCP is an expensive protocol to use for a simple
- transaction like DNS: a TCP connection requires 5 packets for setup
- and tear down, excluding data packets, thus requiring at least 3
- round trips on top of the one for the original UDP query. The DNS
- server also needs to keep a state of the connection during this
- transaction. As many DNS servers answer thousands of queries per
- second, requiring them to use TCP will cause significant overhead and
- delays.
-
-
-1.1 - DNSSEC motivations
-
- DNSSEC[RFC2535] secures DNS by adding a Public Key signature on each
- RR set. These signatures range in size from about 80 octets to 800
- octets most are going to be in the range of 80..200 octets. The
- addition of these signatures on each or most RR sets in an answer
- will significantly increase the size of DNS answers from secure
- zones.
-
- It is important that security aware servers and resolvers get all the
- data in Answer and Authority section in one query without truncation.
- In some cases it is important that some Additional Data be sent
-
-
-
-Expires March 2001 [Page 2]
-\f
-INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000
-
-
- along, mainly in delegation cases.
-
- TSIG[RFC2845] allows for the light weight authentication of DNS
- messages, but increases the size of the messages by at least 70
- octets. DNSSEC allows for computationally expensive message
- authentication with a standard public key signature. As only one TSIG
- or SIG(0) can be attached to each DNS answer the size increase of
- message authentication is not significant, but may still lead to a
- truncation.
-
-
-1.2 - IPv6 Motivations
-
- IPv6 addresses[RFC2874] are 128 bits and are represented in the DNS
- by multiple A6 records, each consisting of a domain name and a bit
- field. The domain name refers to an address prefix that may require
- additional A6 RRs to be included in the answer. Answers where
- queried name has multiple A6 addresses may overflow a 512-octet UDP
- packet size.
-
-
-1.3 Root server and TLD server motivations
-
- The current number of root servers is limited to 13 as that is the
- maximum number of name servers and their address records that fit in
- one 512-octet DNS message. If root servers start advertising A6 or
- KEY records then the root zone answer for NS records will not fit in
- an single 512-octet DNS message. Resulting in a large number of TCP
- connections to the root servers.
-
- It is important that a high level domains have a high number of
- domain name servers for redundancy, latency and load balancing
- reasons.
-
-
-1.4 UDP vs TCP for DNS messages
-
- Given all these factors, it is essential that any implementations
- that supports DNSSEC and or A6 be able to use larger DNS messages
- than 512 octets.
-
- The original 512 restriction was put in place to avoid fragmentation
- of DNS responses. A fragmented UDP message that suffers a loss off
- one of the fragments renders the answer useless and DNS must
- retransmit the query. TCP connection requires number of round trips
- for establishment, data transfer and tear down, but only the lost
- data segments are retransmitted.
-
-
-
-
-Expires March 2001 [Page 3]
-\f
-INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000
-
-
- In the early days number of IP implementations did not handle
- fragmentation well, but all modern operating systems have overcome
- that issue thus sending fragmented messages is fine from that
- standpoint. The open issue is the effect of losses on fragmented
- messages. If connection has high loss ratio only TCP will allow
- reliable transfer of DNS data, most links have low loss ratios thus
- sending fragmented UDP packet in one round trip is better than
- establishing a TCP connection to transfer few thousand octets.
-
-
-1.5 EDNS0 and large UDP messages
-
- EDNS0[RFC2671] allows clients to declare the maximum size of UDP
- message they are willing to handle. Thus, if the expected answer is
- between 512 octets and the maximum size that the client can accept,
- the additional overhead of a TCP connection can be avoided.
-
-1.7 - Requirements
-
- The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
- in this document are to be interpreted as described in RFC 2119.
-
-
-2 - Protocol changes:
-
- This document updates [RFC2535] and [RFC2874], by adding new
- requirements.
-
- All RFC2535-compliant servers and resolvers MUST support EDNS0 and
- advertise message size of at least 1220 octets, but SHOULD advertise
- message size of 4000. This value might be too low to get full
- answers for high level servers and successor of this document may
- require a larger value.
-
- All RFC2874-compliant servers and resolver MUST support EDNS0 and
- advertise message size of at least 1024 octets, but SHOULD advertise
- message size of 2048.
-
- All RFC2535 and RFC2874 compliant entities MUST be able to handle
- fragmented IP and IPv6 UDP packets.
-
- All hosts supporting both RFC2535 and RFC2874 MUST use the larger
- required value in EDNS0 advertisements.
-
-
-
-
-
-
-
-
-Expires March 2001 [Page 4]
-\f
-INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000
-
-
-3 Acknowledgments
-
- Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas
- Gustafsson, Bob Halley, Edward Lewis and Kazu Yamamoto where
- instrumental in motivating and shaping this document.
-
-4 - Security Considerations:
-
- There are no additional security considerations other than those in
- RFC2671.
-
-
-5 - IANA Considerations:
-
- None
-
-References:
-
-
-[RFC1034] P. Mockapetris, ``Domain Names - Concepts and Facilities''
- STD 13, RFC 1034, November 1987.
-
-[RFC1035] P. Mockapetris, ``Domain Names - Implementation and
- Specification'', STD 13, RFC 1035, November 1987.
-
-
-[RFC2535] D. Eastlake, ``Domain Name System Security Extensions'', RFC
- 2535, March 1999.
-
-
-[RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0)'', RFC
- 2671, August 1999.
-
-
-[RFC2845] P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington,
- ``Secret Key Transaction Authentication for DNS (TSIG)'', RFC
- 2845, May 2000.
-
-
-[RFC2874] M. Crawford, C. Huitema, S. Thompson, ``DNS Extensions to
- Support IPv6 Address Aggregation and Renumbering'', RFC2874,
- Sometime 2000.
-
-
-
-
-
-
-
-
-
-Expires March 2001 [Page 5]
-\f
-INTERNET-DRAFT DNSSEC and IPng message size requirement October 2000
-
-
-Author Address
-
-
- Olafur Gudmundsson
- NAI Labs
- Network Associates
- 3060 Washington Road (Rt. 97)
- Glenwood, MD 21738
- USA
- +1 443 259 2389
- <ogud@tislabs.com>
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-Expires March 2001 [Page 6]
+++ /dev/null
-
-
-Network Working Group S. Josefsson
-Internet-Draft RSA Security
-Expires: May 25, 2001 November 24, 2000
-
-
- Authenticating denial of existence in DNS with minimum disclosure
- (or; An alternative to DNSSEC NXT records)
- draft-ietf-dnsext-not-existing-rr-01
-
-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.
-
- This Internet-Draft will expire on May 25, 2001.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Abstract
-
- This draft present an alternative to NXT records, used to achieve
- authenticated denial of existence of a domain name, class and type.
- Problems with NXT records, as specified in RFC 2535, are identified.
- One solution, the NO record, is presented.
-
- The NO record differ from the NXT record by using a cryptographic
- hash value instead of the domain name. This prevent an adversery
- from collecting information by "chaining" through a zone. It also
- remove delegation point concerns that was a side effect of NXT
- records. The document also describe hash truncation and record
- merging that reduces storage/network load.
-
-
-
-Josefsson Expires May 25, 2001 [Page 1]
-\f
-Internet-Draft The NO Record November 2000
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Context . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 3. The NO Resource Record . . . . . . . . . . . . . . . . . . 4
- 3.1 Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3.2 NO RDATA Format . . . . . . . . . . . . . . . . . . . . . 4
- 3.3 NO RDATA on-the-wire format example . . . . . . . . . . . 6
- 3.4 Owner Names . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.5 Additional Complexity Due To Wildcards . . . . . . . . . . 7
- 3.6 No Considerations at Delegation Points . . . . . . . . . . 7
- 3.7 Hash Truncation and Dynamic Updates . . . . . . . . . . . 8
- 3.8 Reducing Number of Records . . . . . . . . . . . . . . . . 9
- 3.9 Hash Collisions . . . . . . . . . . . . . . . . . . . . . 9
- 3.10 Authenticating Denial of NO Records . . . . . . . . . . . 9
- 3.11 Case Considerations . . . . . . . . . . . . . . . . . . . 10
- 3.12 Presentation Format . . . . . . . . . . . . . . . . . . . 10
- 3.13 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
- 3.13.1 Adding NO Records to a Zone . . . . . . . . . . . . . . . 10
- 3.13.2 Simple NO creating entity . . . . . . . . . . . . . . . . 11
- 3.13.3 Advanced NO creating entity . . . . . . . . . . . . . . . 11
- 3.13.4 Resolver Query for Non-existing Domain . . . . . . . . . . 11
- 3.13.5 Resolver Query for Non-existing Type At Existing Domain . 12
- 4. Comparing NO and NXT . . . . . . . . . . . . . . . . . . . 13
- 4.1 Denial Of Existence Of Non-Existing Names . . . . . . . . 13
- 4.2 Denial Of Types Of Existing Names . . . . . . . . . . . . 13
- 4.3 Information disclosure (chain problem) . . . . . . . . . . 13
- 4.4 Delegation problem . . . . . . . . . . . . . . . . . . . . 13
- 4.5 Zone size (Bytes) . . . . . . . . . . . . . . . . . . . . 13
- 4.6 Zone size (Number Of Records) . . . . . . . . . . . . . . 13
- 4.7 Zone size (Number Of Owner names) . . . . . . . . . . . . 14
- 4.8 SIG Labels field and Wildcard records . . . . . . . . . . 14
- 4.9 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 14
- 5. Security Considerations . . . . . . . . . . . . . . . . . 15
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 15
- References . . . . . . . . . . . . . . . . . . . . . . . . 16
- Author's Address . . . . . . . . . . . . . . . . . . . . . 16
- Full Copyright Statement . . . . . . . . . . . . . . . . . 17
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 2]
-\f
-Internet-Draft The NO Record November 2000
-
-
-1. Introduction
-
- "Domain Name Security Extensions", RFC 2535 [1], specifies several
- extensions to DNS that provides data integrity and authentication.
- Among them is the NXT record, used to achieve authenticated denial
- of existence of domains, and authenticated denial of existence on
- certain class/types on existing domains.
-
- As a consequence of NXT records it is possible to "chain" through a
- zone secured by DNS security extensions, collecting all names and/or
- records in the zone. NXT records also introduce a complication at
- delegation points. These are the main problems that motivated this
- draft.
-
-2. Context
-
- There have been arguments that the "chain" problem of NXT records is
- a non-issue. Often used is the argument that information in DNS is
- public, and if you wish to keep information private, you shouldn't
- publish it in DNS. This might be true, but nonetheless major
- service providers and companies are restricting access to zone
- transfers. Also, people have debated whether NXT records should be
- part of DNSSEC at all because of this problem [5].
-
- Another aspect exist. When DNS is used to store certificates, as
- described in RFC 2538 [2], certificates can identify individuals
- and/or carry authentication information for special purposes. This
- context has been the motivation for developing this draft.
-
- The "chain" problem is not the only concern with NXT records. The
- delegation considerations for NXT records (different RRsets in the
- parent and child for the same domain) has also been regarded as a
- flaw of the NXT records.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 3]
-\f
-Internet-Draft The NO Record November 2000
-
-
-3. The NO Resource Record
-
- This section describe the NO Resource Record.
-
-3.1 Idea
-
- A straight-forward extension to the NXT record that minimize
- disclosure of information is to store a one-way function value
- instead of the actual domain name. This is similar to NXT records;
- where NXT records secure a interval where no existing domain names
- are to be found, NO records secure a interval where no one-way value
- of existing domain names are to be found.
-
- The benefit, of course, is that an adversary does not yield any
- useful information from the record. Specifically, "chaining"
- through a zone to collect all records is no longer possible.
-
- This idea has been extended in this document into allowing (but not
- requiring) one record to deny existence of several records, and
- truncating the hash value to the shortest unique prefix to preserve
- space.
-
-3.2 NO RDATA Format
-
- The RDATA for a NO RR consists of one or more fields with the
- following structure. The structure have the following elements: a
- zero-terminated list of RR types, a hash length specifier, and a
- hash value, as shown below. Both the "RR type" list and the "next
- hash value" fields are of variable width.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | /
- / owner RR type list /
- / |
- +---------------+-----------------------------------------------+
- | # hash octets | SHA-1 hash value /
- +---------------+ /
- / /
- +---------------------------------------------------------------+
-
- Replacing the NXT RR "type bit map" field is a variable length list
- of RR types. Each RR type is 16 bits. As the list is of variable
- length, a end-of-list indicator is require. End of the list is
- signalled by a all-zero RR type. Each element is a 2 byte RR type.
- The list MUST be sorted in RR type order. The change from NXT's
- bitmap field removes the limit of authenticating only the first 127
- RR types.
-
-
-Josefsson Expires May 25, 2001 [Page 4]
-\f
-Internet-Draft The NO Record November 2000
-
-
- The RR type list indicates what types exist at the previous hash
- value -- i.e. the first RR type list in the RRdata of a NO record
- indicate what RR types exist at the domain name that hashes to the
- owner name of that NO record. The second RR type list, if any, in
- the RRdata of a NO record indicate what RR types exist at the domain
- name that hashes the first SHA-1 value in the RRdata. And so on.
- See below for a complete example of the on-the-wire-format of a NO
- record with hash truncation and record merging and its
- interpretation.
-
- Length of the hash value field is denoted by the # hash octets
- fields, it is a unsigned integer ranging from 0 to 255. The meaning
- of a zero length integer is reserved.
-
- The SHA-1 hash value field is a variable length field containing the
- actual hash value.
-
- The NO RRs for a zone SHOULD be automatically calculated and added
- to the zone when SIGs are added. The NO RR's TTL SHOULD NOT exceed
- the zone minimum TTL.
-
- The type number for the NO RR is TBD.
-
- NO RR's MUST only be signed by zone level keys [7].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 5]
-\f
-Internet-Draft The NO Record November 2000
-
-
-3.3 NO RDATA on-the-wire format example
-
- The following is a example of the on-the-wire-format of a complete
- NO resource record were hash truncation and record merging is used.
- It is the on-the-wire format of the NO record in section 3.13.1.2.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | RR type 1 (A) | RR type 0 (end-of-list) |
- +---------------+-----------------------------------------------+
- | 1 hash octet | Hash 0x22 | RR type 2 (NS) |
- +---------------+---------------+-------------------------------+
- | RR type 6 (SOA) | RR type 15 (MX) |
- +-------------------------------+---------------+---------------+
- | RR type 0 (end-of-list) | 1 hash octet | Hash 0x83 |
- +-------------------------------+---------------+---------------+
- | RR type 1 (A) | RR type 0 (end-of-list) |
- +---------------+-----------------------------------------------+
- | 1 hash octet | Hash 0x90 | RR type 1 (A) |
- +---------------+---------------+-------------------------------+
- | RR type 16 (TXT) | RR type 0 (end-of-list) |
- +---------------+---------------+-------------------------------+
- | 1 hash octet | Hash 0x1b |
- +-------------------------------+
-
- The intepretation here is that the domain that corresponds with the
- NO owner name ("1b._no.example.org.", not shown above) have a A
- record, that the domain that hash to 0x22 (truncated to one octet)
- have a NS, SOA and MX record, that the domain that hash to 0x83
- (truncated to 1 octet) have a A record etc. Note that the last hash
- value of NO RRdata does not have a RR type list in the same record.
-
-3.4 Owner Names
-
- As the previous NO RR format describe, the "next domain name" of NXT
- records is replaced by its hash value. This removes the possibility
- of chaining both backwards and forwards through a zone.
-
- But without also modifying the owner names of NO records it is still
- not difficult to chain through a zone. Consider querying a server
- for (say) "m._no.example.org", the reply could contain a NO record
- for "g._no.example.org", now an adversary can lookup records for
- "g._no.example.org", and then issue a query for a domain that would
- sort (in "the canonical order" described in RFC 2535) just before
- "g._no.example.org". Applying the technique over and over again, all
- records in the zone can still be collected.
-
- To prevent this, the owner names of NO records is replaced by its
-
-
-Josefsson Expires May 25, 2001 [Page 6]
-\f
-Internet-Draft The NO Record November 2000
-
-
- hash value. As DNS places limits on what characters can be used in
- owner names, the owner name uses a base 16 "hex" encoding [6].
-
- In order to remove the (very small) chance of generated NO record
- names colliding with existing, "real", domains, all NO records MUST
- be stored directly in the "_no" domain of the zone. I.e., a zone
- "example.org." store its NO records as, say,
- "35a4d1._no.example.org.".
-
- This change in owner names also make sure that the delegation point
- concerns of NXT records does not occur in NO records.
-
-3.5 Additional Complexity Due To Wildcards
-
- Proving that a non-existent name response is correct, or that a
- wildcard expansion response is correct, makes things a little more
- complex.
-
- In particular, when a non-existent name response is returned, an NO
- must be returned showing that the exact name did not exist and, in
- general, one or more additional NO need to be returned to also prove
- that there wasn't a wildcard whose expansion should have been
- returned. (There is no need to return multiple copies of the same
- NO.) These NOs, if any, are returned in the authority section of the
- response.
-
- Furthermore, if a wildcard expansion is returned in a response, in
- general one or more NOs needs to also be returned in the authority
- section to prove that no more specific name (including possibly more
- specific wildcards in the zone) existed on which the response should
- have been based.
-
-3.6 No Considerations at Delegation Points
-
- When NXT records are used to deny existance, there exists a special
- case at delegation points. Namely, that two distinct RRsets exist
- for the same owner name, one in the parent zone and one in the child
- zone.
-
- $ORIGIN parent.example.org.
- @ SOA
- NS
- NXT child SOA NS SIG NXT
- child NS foo
- NXT next NS SIG NXT
- next A 127.0.0.2
-
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 7]
-\f
-Internet-Draft The NO Record November 2000
-
-
- $ORIGIN child.parent.example.org.
- @ SOA
- NS
- NXT name SOA NS SIG NXT
- name A 127.0.2.1
- NXT child.parent.example.org.
-
- With NO records, the parent would deny existance of domains in
- "_no.parent.example" and the child in
- "_no.child.parent.example.org". Thus no NO RRset collision occur.
-
-3.7 Hash Truncation and Dynamic Updates
-
- Entities that create NO records MAY truncate the hash field. It
- MUST NOT truncate hash fields so they are no longer unique
- throughout a zone. Hash truncations MUST only be done to octet
- offsets. Truncation MUST be such that less significant bits are
- truncated, i.e. higher-order bits are preserved (see the examples).
-
- Zones that are dynamically updated will have to calculate and add NO
- records on-the-fly. If hash truncation is used, adding a new name
- to the zone will require updating (and signing) NO records for the
- conflicting name(s).
-
- Since truncation (and also "compression" described in the next
- section) make it impossible to predict the corresponding NO record
- given a domain name, resolvers should not ask for a hashed NO record
- (aaaa._no.example.org. IN NO) for a known domain name if they want
- to find out what types exist at the domain. Instead, a resolver
- might ask for NO records on the original name (www.example.org. IN
- NO). Such records will never exist, and the correct NO record will
- be returned by the server.
-
- To summarize, the behaviour of hash truncation should be
- configurable in the entity that creates NO records, to accomodate
- different usage-patterns. If the zone is intended to be dynamicly
- updated, hash truncation may be considered not worth the extra
- on-the-fly processing required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 8]
-\f
-Internet-Draft The NO Record November 2000
-
-
-3.8 Reducing Number of Records
-
- Entitities that create NO records MAY deny existence for several
- records per NO record. Entities that create NO records should take
- care so that each resulting NO record is not "too large". [Comments
- on this? Should there be a specific limit? It might be left as a
- DNS Operational consideration]
-
- Merging several NO records into one record also place more work on
- the resolver. Instead of parsing two hash values for each NO record
- to determine if it's applicaple, a resolver will have to parse
- several hash values and compare each.
-
- The NO RR record consist of one or more RR type list / hash values,
- described above, and a resolver need to parse the entire record to
- collect each individual field. I.e., a NO parse algorithm could
- looke like: read RRs, stop when you read a zero RR type, read hash
- length indicator, read hash size, if the entire record is read stop,
- otherwise read RRs, stop when you read a zero RR type, etc..
-
-3.9 Hash Collisions
-
- Hash value collisions are expected not to occur. For SHA-1, the
- probability that this should happen is 1 out of 2^80 on average.
-
- However, collisions are actually only a problem if the domain names
- producing the same hash value have different sets of existing types.
-
- Consider the following records
-
- ; SHA-1(one.example.org) = SHA-1(two.example.org)
-
- one.example.org. IN A 1.2.3.4
- two.example.org. IN A 5.6.7.8
-
- Given that no other RR types exist for neither domain, both
- "one.example.org" and "two.example.org" would be authenticated not
- to exist by the same NO record.
-
-3.10 Authenticating Denial of NO Records
-
- NO records (together with SIG records) authenticate denial for other
- types in a zone. Unlike NXT records that re-use the namespace in
- the zone, NO records are not intended to authenticate denial of
- other NO records.
-
-
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 9]
-\f
-Internet-Draft The NO Record November 2000
-
-
-3.11 Case Considerations
-
- Before calculating SHA-1 hash values, domain names MUST be converted
- into canonical format as described in RFC 2535. This is to make hash
- comparisons possible.
-
-3.12 Presentation Format
-
- NO RRs do not appear in original unsigned zone master files since
- they should be derived from the zone as it is being signed.
-
- If a signed file with NO records is printed or NO records are
- printed by debugging code, they appear as a list of unsigned
- integers or RR mnemonics, and the hash value in base 16 hex
- representation [6] with "0x" prepended (to distinguish it from
- integer RR codes). The zero RR that terminate the list of RR types,
- and the hash value length indicator, does not appear.
-
- See the next section for examples of printed NO RRs.
-
-3.13 Examples
-
- This section contain examples of NO records, using the reserved
- domain exmaple.org [3].
-
-3.13.1 Adding NO Records to a Zone
-
- Consider the following zone file.
-
- $ORIGIN example.org.
- @ IN SOA ...
- @ IN NS ns
- @ IN MX 0 server
- ns IN A ...
- www IN A ...
- sERVEr IN A ...
- sERVEr IN TXT "text"
-
- ; SHA1(example.org.) = 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
- ; SHA1(ns.example.org.) = 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5
- ; SHA1(www.example.org.) = 0x839ebd4386c0b26d81f147421b5b7036e61438cf
- ; SHA1(server.example.org.) = 0x906a0ad5e604b1905828499dc8672ecb8de73e2f
-
- Note that hash values are calculcated on the canonical form.
-
- The following two sections describe two valid ways of adding NO
- records to a zone.
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 10]
-\f
-Internet-Draft The NO Record November 2000
-
-
-3.13.2 Simple NO creating entity
-
- A simple NO creator entity might not implement truncation or provide
- the possibility to deny more than one records per NO record. In
- this case, the following would be added to the zone file.
-
- $ORIGIN _no.example.org.
- 1b7838c69a66eb50cc215f66ee4554d0c4c940a5
- IN NO A 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
- 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
- IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf
- 839ebd4386c0b26d81f147421b5b7036e61438cf
- IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f
- 906a0ad5e604b1905828499dc8672ecb8de73e2f
- IN NO A TXT 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5
-
-3.13.3 Advanced NO creating entity
-
- A more advanced NO creator entity might append the following
- instead, using both truncation and "compression".
-
- $ORIGIN _no.example.org
- 1b IN NO A 0x22 NS SOA MX 0x83 A 0x90 A TXT 0x1b A
-
- Note that this contain 5 hash values while the zone only contain 4
- records, the last value in the line above is in fact the first hash
- value in the zone, closing the circular NO chain.
-
-3.13.4 Resolver Query for Non-existing Domain
-
- Consider a client looking up the non-existant domain name
- "baz.example.org.", using the zone file from the previous section.
- First, we note the following calculations.
-
- SHA-1(baz.example.org.) = 0xd5d0f98783eec6e9943750f35904304bd1a4090e
- SHA-1(*.example.org.) = 0x7ab3776e3b529eb42467cc5d279c88ec951cf021
-
- A server would reply with an RCODE of NXDOMAIN and the authority
- section data including the following:
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 11]
-\f
-Internet-Draft The NO Record November 2000
-
-
- ; backwards compatibility
- example.org. IN SOA
-
- ; prove no baz.example.org
- 906a0ad5e604b1905828499dc8672ecb8de73e2f._no.example.org.
- IN NO A TXT 0x1b7838c69a66eb50cc215f66ee4554d0c4c940a5
- 906a0ad5e604b1905828499dc8672ecb8de73e2f._no.example.org. IN SIG NO
-
- ; prove no *.example.org:
- 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1._no.example.org.
- IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf
- 222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1._no.example.org. IN SIG NO
-
- In order for a client to verify the authenticity of this reply, in
- addition of verifying the SIG record, it will also need to calculate
- the one-way hash of "baz.example.org." and verify it is contained
- inside the interval of any NO record in the authority section.
- Also, to prove there are no wildcard records for baz.example.org.,
- NO records for possible wildcard expansions are returned. A client
- should similarily calculate hash values of possible wildcards and
- compare them to the authority section.
-
- Of course, if the zone was generated with the more advanced NO
- creating entity, only the NO record from the previous section would
- have to be returned.
-
-3.13.5 Resolver Query for Non-existing Type At Existing Domain
-
- Consider a client looking up TXT records for the existing domain
- "www.example.org.", again, using the same zone file as previous. A
- server would reply with an authority section like the following:
-
- 839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org.
- IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f
- 839ebd4386c0b26d81f147421b5b7036e61438cf._no.example.org. IN SIG NO
-
- The resolver verifies the signature and make sure
- SHA-1("bar.example.org.") hashes correctly.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 12]
-\f
-Internet-Draft The NO Record November 2000
-
-
-4. Comparing NO and NXT
-
- To ease comparison between NXT and NO records, this section
- summarize (mis-)features of the NXT and the NO record formats. The
- intent here is to address all operational differences between NO and
- NXT records.
-
-4.1 Denial Of Existence Of Non-Existing Names
-
- Both NXT and NO provide strong data non-existance for non-existing
- names.
-
- NXT records authenticate data non-existance up to the probability of
- finding a collision in the signature algorithm (1 in 2^64 for
- RSA/MD5). NO records authenticate data non-existance up to the
- probability of finding a collision in the signature algorithm (1 in
- 2^64 for RSA/MD5) and the NO record hash value (varies due to
- truncation). If the RSA/MD5 scheme is used, hash values in NO
- records may be truncated to 64 bits.
-
-4.2 Denial Of Types Of Existing Names
-
- Both NXT and NO provide strong data non-existance of types for
- existing names. The previous discussion also apply here.
-
-4.3 Information disclosure (chain problem)
-
- NXT records make it possible to collect all names (and records) in a
- zone. NO records prohibit this.
-
-4.4 Delegation problem
-
- NXT records require a special case where two different RRsets exist
- at the same owner name, class and type. NO records does not have
- this problem.
-
-4.5 Zone size (Bytes)
-
- The size difference is due to changing complete domain names with
- hash values (SHA1 20 bytes). Without truncation, NO records are
- probably larger than most NXT records. With truncation, NO records
- uses a few byte per hash value instead of the (possibly compressed)
- complete owner name.
-
-4.6 Zone size (Number Of Records)
-
- When NO compression is not used, NXT and NO uses the same number of
- records.
-
-
-
-Josefsson Expires May 25, 2001 [Page 13]
-\f
-Internet-Draft The NO Record November 2000
-
-
- However, NO compression can greatly reduce the number of records.
- As an example, considering a zone with records of 100.000 different
- names. NXT uses 200.000 records (NXT+SIG). Using NO compression
- with 10 hash values on each reduce this number to 20.000 records
- (NO+SIG).
-
-4.7 Zone size (Number Of Owner names)
-
- NO uses twice the amount of owner names as NXT.
-
- However, NO compression can be used to reduce this to a fraction of
- the normal amount. From the previous example with 10 hash values
- per NO record, it will uses 10.000 additional owner names in a zone
- with 100.000 names
-
-4.8 SIG Labels field and Wildcard records
-
- It is marginally faster to verify signatures for NXT records when
- wildcard records are involved -- the SIG "Label fields" hints can be
- used to determine the canonical name. With NO records this hint
- cannot be used, because it relies on knowing the full name whereas
- only the hash is available. One need to try a few SHA1 hashes to
- find the correct canonical name. The number of hashes required to
- try depend on the number of labels in the name, and scale linearly.
-
- N.B. This penalty only apply to wildcard records.
-
-4.9 Dynamic Updates
-
- Resigning dynamically updated records is required both with NXT and
- NO records.
-
- However, when NO truncation and compression is used, the additional
- penalty of re-hashing might also be required.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 14]
-\f
-Internet-Draft The NO Record November 2000
-
-
-5. Security Considerations
-
- Chaining through all NO records is still technically possible,
- altough it cannot be used to collect names and/or records in the
- zone (other than NO records themself).
-
- The security of NO record hash values is dependent on the security
- of the SHA-1 hash functions used. Truncation may affect this, but
- the birthday-paradox argument does not apply. One must find a hash
- collision given an existing hash value -- not simply find any hash
- collision. It is thus reasonably to truncate NO records to half the
- hash length used in the signature scheme (this would mean 64 bits in
- the RSA/MD5 case).
-
- It should be pointed out that given this scheme, it is easy to
- estimate the number of records within a zone, considering hash
- values are supposed to be equally distributed. This can be foiled
- by adding any number of bogus records in the zone.
-
- The authentication of NO records is provided by DNS SIG records, as
- specified in RFC 2535. The security considerations of RFC 2535 is
- not affected by this document, and should also be considered.
-
-6. IANA Considerations
-
- The NO RR type number should be selected by the IANA from the normal
- RR type space.
-
- The meaning of a zero hash length value can only be assigned by a
- standards action.
-
-Acknowledgement
-
- The idea of encrypting names, that later evolved into just hashing
- them, was originally proposed by Jonas Holmerin in private
- discussions about DNS Security. Magnus Nystr÷m proposed truncating
- the hash values.
-
- Thanks to John Linn and Magnus Nystr÷m for comments on a early
- version of this draft.
-
- Olafur Gudmundsson pointed out delegation point issues, suggested
- the use of a "_no" subdomain, and suggested replacing the type bit
- map field with a sorted list. From the namedroppers mailing list,
- I'd like to thank Alan Barrett, Andrew Draper, Andreas Gustafsson,
- Peter Koch and Brian Wellington for comments and suggestions. Ed
- Lewis noted that truncation to shortest unique prefix would not work.
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 15]
-\f
-Internet-Draft The NO Record November 2000
-
-
-References
-
- [1] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [2] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
- Domain Name System (DNS)", RFC 2538, March 1999.
-
- [3] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC
- 2606, June 1999.
-
- [4] NIST, , "Secure Hash Standard", FIPS PUB 180-1, April 1995.
-
- [5] Massey, D., Lehman, T. and E. Lewis, "DNSSEC Implementation in
- the CAIRN Testbed.", I.D. draft-ietf-dnsop-dnsseccairn-00.txt,
- October 1999.
-
- [6] Josefsson, S.A. (editor), "Base 64, 32 and 16 Encodings", I.D.
- draft-josefsson-base-encoding-00.txt, August 2000.
-
- [7] Wellington, B, "Domain Name System Security (DNSSEC) Signing
- Authority", I.D. draft-ietf-dnsext-signing-auth-01.txt, May
- 2000.
-
-
-Author's Address
-
- Simon Josefsson
- RSA Security
- Arenav\84gen 29
- Stockholm 121 29
- Sweden
-
- Phone: +46 8 7250914
- EMail: sjosefsson@rsasecurity.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 16]
-\f
-Internet-Draft The NO Record November 2000
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph
- are included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson Expires May 25, 2001 [Page 17]
-\f
-
+++ /dev/null
-DNS Extensions Working Group J. Schlyter, Ed.
-Internet-Draft March 3, 2004
-Updates: RFC 2535, RFC TCR
-Expires: September 1, 2004
-
-
- DNSSEC NSEC RDATA Format
- draft-ietf-dnsext-nsec-rdata-04.txt
-
-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.
-
- This Internet-Draft will expire on September 1, 2004.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This document redefines the wire format of the "Type Bit Map" field
- in the NSEC resource record RDATA format to cover the full RR type
- space.
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires September 1, 2004 [Page 1]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. The NSEC Resource Record . . . . . . . . . . . . . . . . . . 3
- 2.1 NSEC RDATA Wire Format . . . . . . . . . . . . . . . . . . . 4
- 2.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . . 4
- 2.1.2 The List of Type Bit Map(s) Field . . . . . . . . . . . . . 4
- 2.1.3 Inclusion of Wildcard Names in NSEC RDATA . . . . . . . . . 5
- 2.2 The NSEC RR Presentation Format . . . . . . . . . . . . . . 5
- 2.3 NSEC RR Example . . . . . . . . . . . . . . . . . . . . . . 6
- 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
- 4. Security Considerations . . . . . . . . . . . . . . . . . . 6
- Normative References . . . . . . . . . . . . . . . . . . . . 6
- Informational References . . . . . . . . . . . . . . . . . . 7
- Author's Address . . . . . . . . . . . . . . . . . . . . . . 7
- A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
- Intellectual Property and Copyright Statements . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires September 1, 2004 [Page 2]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
-1. Introduction
-
- The NSEC [5] Resource Record (RR) is used for authenticated proof of
- the non-existence of DNS owner names and types. The NSEC RR is based
- on the NXT RR as described in RFC 2535 [2], and is similar except for
- the name and typecode. The RDATA format for the NXT RR had a
- limitation in that, without using a yet undefined extension
- mechanism, the the RDATA could only carry information about the
- existence of the first 127 types.
-
- To prevent the introduction of an extension mechanism into a deployed
- base of DNSSEC aware servers and resolvers, once the first 127 type
- codes are allocated, this document redefines the wire format of the
- "Type Bit Map" field in the NSEC RDATA to cover the full RR type
- space.
-
- This document introduces a new format for the type bit map. The
- properties of the type bit map format are that it can cover the full
- possible range of typecodes, that it is relatively economic in the
- amount of space it uses for the common case of a few types with an
- owner name, that it can represent owner names with all possible types
- present in packets of approximately 8.5 kilobytes and that the
- representation is simple to implement. Efficient searching of the
- type bitmap for the presence of certain types is not a requirement.
-
- For convenience and completeness this document presents the syntax
- and semantics for the NSEC RR based on the specification in RFC 2535
- [2] and as updated by RFC TCR [5], thereby not introducing changes
- except for the syntax of the type bit map.
-
- This document updates RFC 2535 [2] and RFC TCR [5].
-
- 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 [1].
-
-2. The NSEC Resource Record
-
- The NSEC resource record lists two separate things: the owner name of
- the next RRset in the canonical ordering of the zone, and the set of
- RR types present at the NSEC RR's owner name. The complete set of
- NSEC RRs in a zone both indicate which RRsets exist in a zone and
- also form a chain of owner names in the zone. This information is
- used to provide authenticated denial of existence for DNS data, as
- described in RFC 2535 [2].
-
- The type value for the NSEC RR is 47.
-
-
-
-
-Schlyter Expires September 1, 2004 [Page 3]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
- The NSEC RR RDATA format is class independent and defined for all
- classes.
-
- The NSEC RR has no special TTL requirements.
-
-2.1 NSEC RDATA Wire Format
-
- The RDATA of the NSEC RR is as shown below:
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / Next Domain Name /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / List of Type Bit Map(s) /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-2.1.1 The Next Domain Name Field
-
- The Next Domain Name field contains the owner name of the next RR in
- the canonical ordering of the zone. The value of the Next Domain
- Name field in the last NSEC record in the zone is the name of the
- zone apex (the owner name of the zone's SOA RR).
-
- A sender MUST NOT use DNS name compression on the Next Domain Name
- field when transmitting an NSEC RR. A receiver which receives an
- NSEC RR containing a compressed Next Domain Name field SHOULD
- decompress the field value.
-
- Owner names of RRsets not authoritative for the given zone (such as
- glue records) MUST NOT be listed in the Next Domain Name unless at
- least one authoritative RRset exists at the same owner name.
-
-2.1.2 The List of Type Bit Map(s) Field
-
- The RR type space is split into 256 window blocks, each representing
- the low-order 8 bits of the 16-bit RR type space. Each block that has
- at least one active RR type is encoded using a single octet window
- number (from 0 to 255), a single octet bitmap length (from 1 to 32)
- indicating the number of octets used for the window block's bitmap,
- and up to 32 octets (256 bits) of bitmap.
-
- Blocks are present in the NSEC RR RDATA in increasing numerical
- order.
-
- "|" denotes concatenation
-
-
-
-
-Schlyter Expires September 1, 2004 [Page 4]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
- Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
-
- Each bitmap encodes the low-order 8 bits of RR types within the
- window block, in network bit order. The first bit is bit 0. For
- window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
- to RR type 2 (NS), and so forth. For window block 1, bit 1
- corresponds to RR type 257, bit 2 to RR type 258. If a bit is set to
- 1, it indicates that an RRset of that type is present for the NSEC
- RR's owner name. If a bit is set to 0, it indicates that no RRset of
- that type is present for the NSEC RR's owner name.
-
- Since bit 0 in window block 0 refers to the non-existing RR type 0,
- it MUST be set to 0. After verification, the validator MUST ignore
- the value of bit 0 in window block 0.
-
- Bits representing Meta-TYPEs or QTYPEs as specified in RFC 2929 [3]
- (section 3.1) or within the range reserved for assignment only to
- QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
- zone data. If encountered, they must be ignored upon reading.
-
- Blocks with no types present MUST NOT be included. Trailing zero
- octets in the bitmap MUST be omitted. The length of each block's
- bitmap is determined by the type code with the largest numerical
- value, within that block, among the set of RR types present at the
- NSEC RR's owner name. Trailing zero octets not specified MUST be
- interpretted as zero octets.
-
-2.1.3 Inclusion of Wildcard Names in NSEC RDATA
-
- If a wildcard owner name appears in a zone, the wildcard label ("*")
- is treated as a literal symbol and is treated the same as any other
- owner name for purposes of generating NSEC RRs. Wildcard owner names
- appear in the Next Domain Name field without any wildcard expansion.
- RFC 2535 [2] describes the impact of wildcards on authenticated
- denial of existence.
-
-2.2 The NSEC RR Presentation Format
-
- The presentation format of the RDATA portion is as follows:
-
- The Next Domain Name field is represented as a domain name.
-
- The List of Type Bit Map(s) Field is represented as a sequence of RR
- type mnemonics. When the mnemonic is not known, the TYPE
- representation as described in RFC 3597 [4] (section 5) MUST be used.
-
-
-
-
-
-
-Schlyter Expires September 1, 2004 [Page 5]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
-2.3 NSEC RR Example
-
- The following NSEC RR identifies the RRsets associated with
- alfa.example.com. and identifies the next authoritative name after
- alfa.example.com.
-
- alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC TYPE1234
-
- The first four text fields specify the name, TTL, Class, and RR type
- (NSEC). The entry host.example.com. is the next authoritative name
- after alfa.example.com. in canonical order. The A, MX, RRSIG, NSEC
- and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC and
- TYPE1234 RRsets associated with the name alfa.example.com.
-
- The RDATA section of the NSEC RR above would be encoded as:
-
- 0x04 'h' 'o' 's' 't'
- 0x07 'e' 'x' 'a' 'm' 'p' 'l' 'e'
- 0x03 'c' 'o' 'm' 0x00
- 0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
- 0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
- 0x00 0x00 0x00 0x00 0x20
-
- Assuming that the resolver can authenticate this NSEC record, it
- could be used to prove that beta.example.com does not exist, or could
- be used to prove there is no AAAA record associated with
- alfa.example.com. Authenticated denial of existence is discussed in
- RFC 2535 [2].
-
-3. IANA Considerations
-
- This document introduces no new IANA considerations, because all of
- the protocol parameters used in this document have already been
- assigned by RFC TCR [5].
-
-4. Security Considerations
-
- The update of the RDATA format and encoding does not affect the
- security of the use of NSEC RRs.
-
-Normative References
-
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [2] Eastlake, D., "Domain Name System Security Extensions", RFC
-
-
-
-Schlyter Expires September 1, 2004 [Page 6]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
- 2535, March 1999.
-
- [3] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name
- System (DNS) IANA Considerations", BCP 42, RFC 2929, September
- 2000.
-
- [4] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
- Types", RFC 3597, September 2003.
-
- [5] Weiler, S., "Legacy Resolver Compatibility for Delegation
- Signer", draft-ietf-dnsext-dnssec-2535typecode-change-05 (work
- in progress), October 2003.
-
-Informational References
-
- [6] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [7] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
-
-Author's Address
-
- Jakob Schlyter (editor)
- Karl Gustavsgatan 15
- Goteborg SE-411 25
- Sweden
-
- EMail: jakob@schlyter.se
-
-Appendix A. Acknowledgements
-
- The encoding described in this document was initially proposed by
- Mark Andrews. Other encodings where proposed by David Blacka and
- Michael Graff.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires September 1, 2004 [Page 7]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). 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 assignees.
-
- 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
-
-
-
-Schlyter Expires September 1, 2004 [Page 8]
-
-Internet-Draft DNSSEC NSEC RDATA Format March 2004
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter Expires September 1, 2004 [Page 9]
-
+++ /dev/null
-A new Request for Comments is now available in online RFC libraries.\r
-\r
-\r
- RFC 3425\r
- \r
- Title: Obsoleting IQUERY\r
- Author(s): D. Lawrence\r
- Status: Standards Track\r
- Date: November 2002\r
- Mailbox: tale@nominum.com\r
- Pages: 5\r
- Characters: 8615\r
- Updates: 1035\r
-\r
- I-D Tag: draft-ietf-dnsext-obsolete-iquery-04.txt\r
-\r
- URL: ftp://ftp.rfc-editor.org/in-notes/rfc3425.txt\r
-\r
-\r
-The IQUERY method of performing inverse DNS lookups, specified in\r
-RFC 1035, has not been generally implemented and has usually been\r
-operationally disabled where it has been implemented. Both reflect\r
-a general view in the community that the concept was unwise and\r
-that the widely-used alternate approach of using pointer (PTR) queries\r
-and reverse-mapping records is preferable. Consequently, this\r
-document deprecates the IQUERY operation, declaring it entirely\r
-obsolete. This document updates RFC 1035.\r
-\r
-This document is a product of the DNS Extensions Working Group of the\r
-IETF.\r
-\r
-This is now a Proposed Standard Protocol.\r
-\r
-This document specifies an Internet standards track protocol for\r
-the Internet community, and requests discussion and suggestions\r
-for improvements. Please refer to the current edition of the\r
-"Internet Official Protocol Standards" (STD 1) for the\r
-standardization state and status of this protocol. Distribution\r
-of this memo is unlimited.\r
-\r
-This announcement is sent to the IETF list and the RFC-DIST list.\r
-Requests to be added to or deleted from the IETF distribution list\r
-should be sent to IETF-REQUEST@IETF.ORG. Requests to be\r
-added to or deleted from the RFC-DIST distribution list should\r
-be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.\r
-\r
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending\r
-an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body \r
-help: ways_to_get_rfcs. For example:\r
-\r
- To: rfc-info@RFC-EDITOR.ORG\r
- Subject: getting rfcs\r
-\r
- help: ways_to_get_rfcs\r
-\r
-Requests for special distribution should be addressed to either the\r
-author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless\r
-specifically noted otherwise on the RFC itself, all RFCs are for\r
-unlimited distribution.echo \r
-Submissions for Requests for Comments should be sent to\r
-RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC\r
-Authors, for further information.\r
-\r
-\r
+++ /dev/null
-INTERNET-DRAFT R. Gieben
-DNSEXT Working Group NLnet Labs
-Expires September 2001 T. Lindgreen
- NLnet Labs
-
- Parent's SIG over child's KEY
-
- draft-ietf-dnsext-parent-sig-00.txt
-
-
-Status of This Document
-
- 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.
-
- Comments should be sent to the authors or the DNSEXT WG mailing
- list namedroppers@ops.ietf.org.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2001). All rights reserved.
-
-
-Abstract
-
- When dealing with large amounts of keys the procedures to update a
- zone and to sign a zone need to be clearly defined and practically
- possible. The current idea is to have the KEY RR and the parent's
- SIG to reside in the child's zone and perhaps also in the parent's
- zone. We feel that this would lead to very complicated procedures for
- large TLDs. We propose an alternative scheme in which the parent zone
- stores the parent's signature over the child's key and also a copy of
- the child's key itself.
-
- The advantage of this proposal is that all signatures signed by a
- key are in the same zone file as the producing key. This allows for a
- simple key rollover and resigning mechanism. For large TLDs this is
- extremely important.
-
-
-
-
-\fInternet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 2]
-
-
- We further discuss the impact on a secure aware resolver/forwarder
- and the impact on the authority of KEYs and the NXT record.
-
-Table of Contents
-
- Status of This Document....................................2
- Abstract...................................................2
-
- Table of Contents..........................................3
- 1 Introduction.............................................3
- 2 Proposal.................................................4
- 3 Impact on a secure aware resolver/forwarder..............4
- 3.1 Impact of key rollovers on resolver/forwarder..........4
- 4 Key rollovers............................................5
- 4.1 Scheduled key rollover.................................5
- 4.2 Unscheduled key rollover...............................5
- 5 Zone resigning...........................................6
- 6. Consequences for KEY and NXT records....................6
- 6.1. KEY bit in NXT records................................6
- 6.2. Authority of KEY records..............................6
- 7. Security Considerations.................................6
-
- Authors' Addresses.........................................7
- References.................................................7
- Full Copyright Statement...................................7
-
-
-1. Introduction
- Within a CENTR working group NLnet Labs is researching the impact
- of DNSSEC on the ccTLDs and gTLDs.
-
- In this document we are considering a secure zone, somewhere under
- a secure entry point and on-tree [1] validation between the secure
- entry point and the zone in question. The resolver we are
- considering is security aware and is preconfigured with the KEY of
- the secure entry point.
-
- RFC 2535 [3] states that a zone key must be present in the apex of
- a zone. This can be in the at the delegation point in the parent's
- zonefile (normally the case for null keys), or in the child's
- zonefile, or in both. This key is only valid if it is signed by the
- parent, so there is also the question where this signature is
- located.
-
- The original idea was to have the KEY RR and the parent's SIG to
- reside in the child's zone and perhaps also in the parent's zone.
- There is a draft proposal [4], that describes how a keyrollover can
- be handled.
-
- At NLnet Labs we found that storing the parent's signature over
- the child's key in the child's zone:
- - makes resigning a KEY by the parent difficult
-
-
-
-\fInternet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 3]
-
-
- - makes a scheduled keyrollover very complicated
- - makes an unscheduled keyrollover virtually impossible
-
- We propose an alternative scheme in which the parent's signature
- over the child's key is only stored in the parent's zone, i.e. where
- the signing key resides. This would solve the above problems.
-
- 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 [2].
-
-
-2. Proposal
- The core of the new proposal is that the parent zone stores the
- parent's signature over the child's key and also a copy of the
- child's key itself. The child zone also contains its zonekey, where
- it is selfsigned.
-
- The advantage of this proposal is that all signatures signed by a
- key are in the same zone file as the producing key. This allows for a
- simple key rollover and resigning mechanism. For large TLD's this is
- extremely important. A disadvantage would be that not all the
- information concerning one zone is stored at that zone, namely the
- (parent) SIG RR. Note that the same argument can be applied to a
- zone's NULL key, which is also stored at the parent.
-
-
-3. Impact on a secure aware resolver/forwarder
- The resolver must be aware of the fact that the parent is more
- authoritative than a child when it comes to deciding whether a zone
- is secured or not.
-
- Without caching and with on-tree validation, a resolver will
- always start its search at a secure entry point. In this way it can
- determine whether it must expect SIG records or not.
-
- Considering caching in a secure aware resolver or forwarder. If
- information of a secure zone is cached, its validated KEY should also
- be cached.
-
- If the KEY record expires, because the KEY TTL expires or because
- the SIG is no longer valid, the KEY should be discarded. The resolver
- or forwarder should then also discard other data concerning the zone
- because it is no longer validated and possible bad data should not be
- cached.
-
-3.1. Impact of key rollovers on resolver/forwarder
-
- When a zone is in the process of a key rollover, there could be a
- discrepancy between the KEY and the SIG in the apex of the zone and
- the KEY and SIG that are stored in the cache of a resolver.
-
-
-
-
-\fInternet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 4]
-
-
-
- Suppose a resolver has cached the NS, KEY and SIG records of a
- zone. Next a request comes for an A record in that zone. Also the
- zone is in the process of a keyrollover and already has new keys in
- its zone. The resolver receives an answer consisting of the A record
- and a SIG over the A record. It uses the tag field in the SIG to
- determine if it has a KEY which is suitable to validate the SIG. If
- it does not has such a KEY the resolver must ask the parent of the
- zone for a new KEY and then try it again. Now the resolver has 2
- keys for the zone, according to the tag field in the SIG it can use
- either one.
-
- If the new key also does not validate the SIG the zone is marked
- bad. If the KEY found at the parent is the NULL key the resolver
- knows that the child is considered insecure. This could for instance
- be in the case the private key of the zone is stolen.
-
-
-4. Key rollovers
- Private keys can be stolen or a key can become over used. In both
- cases a new key must be signed and distributed. This event is called
- keyrollover. We further distinguish between a scheduled and an
- unscheduled key rollover. A scheduled rollover is announced before
- hand. An unscheduled key rollover is needed when a private key is
- compromised.
-
-4.1. Scheduled key rollover
- When the signatures, produced by the key to be rolled over, are
- all in one zone file, there are two parties involved. Let us look at
- an example where a TLD rolls over its zone key. The new key needs to
- be signed with the root's key before it can be used to sign the TLD
- zone and the zone keys of the TLD's children. The steps that need to
- be taken by TLD and root are:
- - the TLD adds the new key to its keyset in its zonefile. This
- zone and keyset are signed with the old zonekey
- - then the TLD signals the parent
- - the root copies the new keyset, consisting of the both new
- and the old key, in its zonefile, resigns it and signals the
- TLD
- - the TLD removes the old key from its keyset, resigns its zone
- with the new key, and signals the the root
- - the root copies the new keyset, now consisting of the new key
- only, and resigns it
-
-4.2. Unscheduled key rollover
- Although nobody hopes that this will ever happen, we must be able
- to cope with possible key compromises. When such an event occurs, an
- immediate keyrollover is needed and must be completed in the shortest
- possible time. With two parties involved, it will still be awkward,
- but not impossible to update two zonefiles overnight. "Out-of-band"
- communication between the two parties will be necessary, since the
- compromised old key can not be trusted. We think that between two
-
-
-
-\fInternet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 5]
-
-
- parties this is doable, but this complicated procedure is beyond the
- scope of this document. [5]
-
-
-5. Zone resigning
- Resigning a TLD is necessary before the current signatures expire.
- When all SIG records, produced by the TLD's zone key are kept in the
- TLD's zonefile, and only there, such a resign session is trivial, as
- only one party (the TLD) and one zonefile is involved.
-
-
-6. Consequences for KEY and NXT records
- A key record is only present in a child zone to facilitate a key
- rollover. A resolver should therefore be aware that the zonekey of a
- child zone is actually stored in the parent's zone. This also affects
- the NXT record and the authority of KEY resource records.
-
-6.1. KEY bit in NXT records
- RFC 2535 [3], section 5.2 states:
-
- " The NXT RR type bit map format currently defined is one bit per
- RR type present for the owner name. A one bit indicates that at
- least one RR of that type is present for the owner name. A zero
- indicates that no such RR is present. [....] "
-
- With a KEY still present in a child zone we do not see a compelling
- reason to change this default behavior.
-
-6.2. Authority of KEY records
- The parent of a zone generates the signature for the key belonging
- to that zone. By making that signature available the parent publicly
- states that the child zone is trustworthy: when it comes to security
- in DNSSEC the parent is more authoritative than the child.
-
- From this we conclude that a parent zone MUST set the authority
- bit to 1 and child zones MUST set this bit to 0 when dealing with
- KEYs from that child zone.
-
- A secure entry point has a selfsigned key and thus has no parent who
- is more authoritative on that key. This is not a problem. If a
- resolver knows that a secure entry point is a secure entry point it
- must have its key preconfigured. There is no need for a parent in
- this scenario, because the resolver itself can check the security of
- that zone. A interesting consequence of this is that nobody, but the
- resolver is authoritative for a key belonging to a secure entry
- point. This authority must established via some out of band
- mechanism, like publishing keys in a newspaper.
-
-
-7. Security Considerations
- This whole document is about security.
-
-
-
-
-\fInternet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 6]
-
-
-
-
-Authors' Addresses
-
- R. Gieben
- Stichting NLnet Labs
- Kruislaan 419
- 1098 VA Amsterdam
- miek@nlnetlabs.nl
-
- T. Lindgreen
- Stichting NLnet Labs
- Kruislaan 419
- 1098 VA Amsterdam
- ted@nlnetlabs.nl
-
-
-References
-
- [1] Lewis, E. "DNS Security Extension Clarification on Zone Status",
- www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-04.txt
- [2] Bradner, S. "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119
- www.ietf.org/rfc/rfc2119.txt
- [3] Eastlake, D. "DNS Security Extensions", RFC 2535
- www.ietf.org/rfc/rfc2535.txt
- [4] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security Key Rollover"
- www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt
- [5] Gieben, R. "Chain of trust"
- secnl.nlnetlabs.nl/thesis/thesis.html
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). 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.
-
-
-
-\fInternet-Draft draft-ietf-dnsext-parent-sig-01.txt [Page 7]
-
-
-
- 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.
+++ /dev/null
-INTERNET-DRAFT R. Gieben
-DNSEXT Working Group NLnet Labs
-Expires September 2001 T. Lindgreen
- NLnet Labs
-
- Parent stores the child's zone KEYs
-
- draft-ietf-dnsext-parent-stores-zone-keys-01.txt
-
-
-Status of This Document
-
- 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.
-
- Comments should be sent to the authors or the DNSEXT WG mailing
- list namedroppers@ops.ietf.org.
-
- This document updates RFC 2535.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2001). All rights reserved.
-
-
-Abstract
-
- When dealing with large amounts of keys the procedures to update a
- zone and to sign a zone need to be clearly defined and practically
- possible. The current idea is to have the zone KEY RR and the
- parent's SIG to reside in the child's zone and perhaps also in the
- parent's zone. Operational experiences have prompted us to develop an
- alternative scheme in which the parent zone stores the parent's
- signature over the child's key and also the child's key itself.
-
- The advantage of this scheme is that all signatures signed by a key
- are in the same zone file as the producing key. This allows for a
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 2]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
- simple key rollover and resigning mechanism. For large TLDs this is
- extremely important.
-
- Besides the operational advantages, this also obsoletes the NULL key,
- as the absence of child's zone KEY, which is securely verified by the
- absence of the KEY-bit in the corresponding NXT RR, now unambiguously
- indicates that the child is not secured by this parent.
-
- We further discuss the impact on a secure aware resolver/forwarder
- and the impact on the authority of KEYs and the NXT record.
-
-
-Table of Contents
-
- Status of This Document....................................
- Abstract...................................................
-
- Table of Contents..........................................
- 1 Introduction.............................................
- 2 Proposal.................................................
- 2.1. TTL of the KEY and SIG at the parent..................
- 2.2. No NULL KEY...........................................
- 3 Impact on a secure aware resolver/forwarder..............
- 3.1 Impact of key rollovers on resolver/forwarder..........
- 4 Scheduled key rollover...................................
- 5 Unscheduled key rollover.................................
- 6 Zone resigning...........................................
- 7. Consequences for KEY and NXT records....................
- 7.1. KEY bit in NXT records................................
- 7.2. Authority of KEY records..............................
- 7.3. Selecting KEY sets....................................
- 8. The zone-KEY and local KEY records......................
- 9. Security Considerations.................................
-
- Authors' Addresses.........................................
- References.................................................
- Full Copyright Statement...................................
-
-
-1. Introduction
- Within a CENTR working group NLnet Labs is researching the impact of
- DNSSEC on the ccTLDs and gTLDs.
-
- In this document we are considering a secure zone, somewhere under a
- secure entry point and on-tree [RFC 3090] validation between the
- secure entry point and the zone in question. The resolver we are
- considering is security aware and is preconfigured with the KEY of
- the secure entry point. We also make a distinction between a
- scheduled and a unscheduled key rollover. A scheduled rollover is
- announced before hand. An unscheduled key rollover is needed when a
- private key is compromised.
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 3]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
-
- RFC 2535 states that a zone KEY must be present in the apex of a
- zone. This can be in the at the delegation point in the parent's
- zonefile, or in the child's zonefile, or in both. This key is only
- valid if it is signed by the parent, so there is also the question
- where this signature and this zone KEY are located.
-
- The original idea was to have the zone KEY RR and the parent's SIG to
- reside in the child's zone and perhaps also in the parent's zone.
- There is a draft proposal [RFC 2535], that describes how a
- keyrollover can be handled.
-
- At NLnet Labs we found that storing the parent's signature over the
- child's zone KEY in the child's zone:
- - makes resigning a KEY by the parent difficult
- - makes a scheduled keyrollover very complicated
- - makes an unscheduled keyrollover virtually impossible
-
- We propose an alternative scheme in which the parent's signature over
- the child's zone KEY and the child's zone KEY itself are only stored
- in the parent's zone, i.e. where the signing key resides. This would
- solve the above problems and also obsoletes the NULL KEY.
-
- 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. Proposal
- The core of the new proposal is that the parent zone stores the
- parent's signature over the child's zone KEY and also the child's
- zone KEY itself, and is authoritative for both KEY and SIG. The
- child zone may also contain its zone KEY, in which case is must be
- selfsigned. The child zone must not hold the parent's SIG, and must
- also not set the AA-bit on requests for its zone KEY.
-
- The main advantage of this proposal is that all signatures signed by
- a key are in the same zone file as the producing key. This allows for
- a simple key rollover and resigning mechanism. For large TLDs this is
- extremely important. A disadvantage would be that not all the
- information concerning one zone is stored at that zone, this is
- covered in section 7.2.
-
- A parent running DNSSEC SHOULD NOT refuse a request from a child to
- include and sign its key, but can ask for certain conditions to be
- met. These condition could include a fee, sufficient authentication,
- signing a non liability clause, the conditions specified in section 8
- of this document, etc.
-
-2.1. TTL of the KEY and SIG at the parent
- Each zone in DNS expresses in its SOA record the maximum and minimum
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 4]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
- TTL values that they allow in the zone. Thus it is possible that the
- parent will sign with a value that is unacceptable to the child. The
- parent MUST follow the TTL request of the child as long as that is
- within the allowed range for the parent.
-
-2.2. No NULL KEY
- This proposal obsoletes the NULL KEY. If there is no child KEY at the
- parent, which can be securely verified by inspecting the the unset
- KEY-bit in the corresponding NXT RR, the child is not secured by this
- parent (of course, the child can then still be secured off-tree).
- This updates section 3.1.2 "The zone KEY RR Flag Field" of RFC 2535,
- it says:
-
- " 11: If both bits are one, the "no key" value, there is no key
- information and the RR stops after the algorithm octet.
- By the use of this "no key" value, a signed zone KEY RR can
- authenticatably assert that, for example, a zone is not
- secured. See section 3.4 below. "
-
- As we don't have a NULL KEY anymore this is obsoleted.
- Section 3.4 "Determination of Zone Secure/Unsecured Status":
-
- " A zone KEY RR with the "no-key" type field value (both key type
- flag bits 0 and 1 on) indicates that the zone named is unsecured
- while a zone KEY RR with a key present indicates that the zone named
- is secure. The secured versus unsecured status of a zone may vary
- with different cryptographic algorithms. Even for the same
- algorithm, conflicting zone KEY RRs may be present. "
-
- This is rewritten as:
-
- " A zone is considered secured by on-tree validation [RFC 3090] when
- the there is a zone KEY from that zone present at its parent. If
- there is no zone KEY present, and the resolver is also unaware of
- alternative algorithms used and/or possible off-tree validation, the
- zone is considered unsecured. "
-
- To further clarify this. A zone is secure, when the resolver expects
- it to be, there are two possibilities:
- 1. When its parent is secure and holds a signed KEY for this child.
- 2. When zone is a secure entry point, i.e. the resolver is
- preconfigured with the KEY of this zone.
-
- RFC 3090 calls this globally secured.
-
- When a zone contains SIGs and a selfsigned KEY and this KEY is
- preconfigured in the resolvers of interest, the a zone can be
- considered locally secured (the RFC 3090 defintion). hijacked.
-
- If a zone is not globally or locally it must be considered unsecure.
-
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 5]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
-
-3. Impact on a secure aware resolver/forwarder
- The resolver must be aware of the fact that the parent is more
- authoritative than a child when it comes to deciding whether a zone
- is secured or not.
-
- Without caching and with on-tree validation, a resolver will always
- start its search at a secure entry point. In this way it can
- determine whether it must expect SIG records or not.
-
- Considering caching in a secure aware resolver or forwarder. If
- information of a secure zone is cached, its validated KEY should also
- be cached.
-
-3.1. Impact of key rollovers on resolver/forwarder
- When a zone is in the process of a key rollover, there could be a
- discrepancy between the KEY and the SIG in the apex of the zone and
- the KEY and SIG that are stored in the cache of a resolver.
-
- Suppose a resolver has cached the NS, KEY and SIG records of a zone.
- Next a request comes for an A record in that zone. Also the zone is
- in the process of a key rollover and already has new keys in its
- zone. The resolver receives an answer consisting of the A record and
- a SIG over the A record. It uses the tag field in the SIG to
- determine if it has a KEY which is suitable to validate the SIG. If
- it does not has such a KEY the resolver must ask the parent of the
- zone for a new KEY and then try it again. Now the resolver has 2
- keys for the zone, according to the tag field in the SIG it can use
- either one.
-
- If the new key also does not validate the SIG the zone is marked bad.
- If the parent indicates by having a not set KEY-bit in the NXT RR
- that there is no KEY for this zone, the child must be considered
- unsecured by this parent, despite the appearance of an (old) KEY in
- the cache. This could for instance happen after an emergency request
- from the child, who has suffered a key compromise, and has decided to
- prefer being unsecured over either dropping of the Internet or being
- exposed to have verifiable secure info added by the key-compromiser
- to their zone information.
-
-
-4. Scheduled key rollover
- When the signatures, produced by the key to be rolled over, are all
- in one zone file, there are two parties involved. Let us look at an
- possible example where a TLD rolls over its zone KEY. The new key
- needs to be signed with the root's key before it can be used to sign
- the TLD zone and the zone KEYs of the TLD's children. The steps that
- need to be taken by TLD and root are:
- - the TLD adds the new key to its KEY set in its zonefile. This
- zone and KEY set are signed with the old zone KEY
- - then the TLD signals the parent
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 6]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
- - the root copies the new KEY set, consisting of the both new and
- the old key, in its zonefile, resigns it and signals the TLD
- - the TLD removes the old key from its KEY set, resigns its zone
- with the new KEY, and signals the the root
- - the root copies the new KEY set, now consisting of the new key
- only, and resigns it
-
- Note that this procedure is immune to fake signals and spoofing
- attacks (as long as there is no key compromise):
- - on a fake signal either way the action becomes a null-action as
- the new KEY set is identical to the existing one.
- - a spoofed new KEY set will not validate with the existing KEY
- that the parent holds.
-
-
-5. Unscheduled key rollover
- Although nobody hopes that this will ever happen, we must be able to
- cope with possible key compromises. When such an event occurs, an
- immediate keyrollover is needed and must be completed in the shortest
- possible time. With two parties involved, it will still be awkward,
- but not impossible to update two zonefiles overnight. "Out-of-band"
- communication between the two parties will be necessary, since the
- compromised old key can not be trusted. We think that between two
- parties this is doable, but this complicated procedure is beyond the
- scope of this document.
-
- An alternative to an emergency key-rollover is becoming unsecured as
- an emergency measure. This has already been mentioned above in
- section 3.1. This only involves an emergency change in the parents
- zonefile (deleting the child's zone KEY), and allows the child and
- its underlying zones time to clean up before becoming secured again,
- without dropping from the Internet or being exposed to having secured
- but false zone information.
-
-
-6. Zone resigning
- Resigning a TLD is necessary before the current signatures expire.
- When all SIGs (produced by the TLD's zone KEY) and the child KEY
- records, are kept in the TLD's zonefile, such a resign session is
- trivial, as only one party (the TLD) and one zonefile are involved.
-
-
-7. Consequences for KEY and NXT records
- There are two reasons to have of the child's zone KEY not only at the
- parent but also in the child's own zonefile:
- 1. to facilitate a key-rollover
- 2. to prevent local lookups for local information to suffer
- from possible loss of access to its outside parent
-
- To cope with 1, secure aware resolvers MUST be aware that during a
- key-rollover there may be a conflict, and that in that case the
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 7]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
- parent always holds the active KEY set. To cope with 2, the local
- resolver/caching forwarder should be preconfigured with the zone-KEY
- and thus looks at its own zone as were it a secure entry-point. For
- both things to work, the zone-KEY set must be selfsigned in the child
- zonefile.
-
-7.1. KEY bit in NXT records
- RFC 2535, section 5.2 states:
-
- " The NXT RR type bit map format currently defined is one bit per RR
- type present for the owner name. A one bit indicates that at least
- one RR of that type is present for the owner name. A zero indicates
- that no such RR is present. [....] "
-
- As the zone KEY is present in a child zone, and signed by the zone
- KEY (thus selfsigned), the definition of NXT RR type bit states in
- RFC 2535, section 5.2 that the KEY bit must be set. We do not see a
- compelling reason to change this default behavior.
-
-7.2. Authority of KEY records
- The parent of a zone generates the signature for the key belonging to
- that zone. By making that signature available the parent publicly
- states that the child zone is trustworthy: when it comes to security
- in DNSSEC the parent is more authoritative than the child.
-
- From this we conclude that a parent zone MUST set the authority bit
- to 1 and child zones MUST set this bit to 0 when dealing with KEYs
- from that child zone.This also causes resolvers to pick up and cache
- the right KEY set, in case it finds conflicting KEY sets during a
- key-rollover.
-
- Some zones have no parent to make it authoritatively secure, for
- instance, the root. To be secure anyway it must be defined a secure
- entry point. If a resolver knows that a secure entry point is a
- secure entry point it must have its key preconfigured. There is no
- need for a parent in this scenario, because the resolver itself can
- check the security of that zone. A interesting consequence of this is
- that nobody is authoritative for a key belonging to a secure entry
- point. This authority must established via some out of band
- mechanism, like publishing it in a newspaper.
-
-7.3. Selecting KEY sets
- As the zone KEY set is present in two places, there is a possibility
- of two conflicting KEY sets, this will happen during a key-rollover
- and may happen at other times.
-
- With one exception, a resolver MUST always select the KEY set from
- the parent in case of a conflict, as this is the active KEY set. For
- this reason, the parent sets the AA-bit on requests, while the child
- does not.
-
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 8]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
- The one exception is when a resolver regards the child's zone as a
- secure-entry point, in which case it has the zone KEY preconfigured.
- In other words: a preconfigured KEY has even more authority then what
- a parent says. Specifying a zone as a secure entry-point makes sense
- for a local resolver in its own local zone.
-
-
-8. The zone KEY and local KEY records.
- It must be recognized that the zone KEY RR, which is signed by a
- non-local organization, is something special. The external signature
- over the public part of the key provides the local zone-administrator
- with the authority to use the corresponding private part to sign
- everything local, and thus to make his/her own zone secure. Please
- also note that the external signer, and NOT the local zone is
- authoritative for the zone KEY RRset.
-
- Part of the RRs that the zone-administrator may wish to sign are KEY
- RRs for local use, for instance for IPSEC.
-
- To make sure, that the local zone is authoritative for its own local
- KEY RRs, and that they get not exported and signed externally, these
- local KEY records SHOULD not be part of the zone KEY RRset.
- Therefore, they could be placed under a label in the zonefile, f.i.
- keys.child.parent, or for these kind of keys a new RR type could be
- defined (e.g. PUBKEY).
-
- Besides being kept clear of local KEY records, the zone KEY RRset
- SHOULD also be kept clear of any other obsolete or otherwise not
- strictly needed KEY records, because this increases the number of
- possible key compromise attacks and also increases the size of the
- parents zone file unnecessarily.
-
- In other words: the KEY RRset with the toplevel label of a zone
- SHOULD only contain its active zone KEY, unless a key-rollover is in
- progress. During a keyrollover a new KEY RR must be added to this
- RRset. Once the new KEY becomes the active zone KEY, the old KEY
- becomes obsolete and SHOULD be removed as soon as practically
- possible. Information stored in caches SHOULD NOT be an issue on when
- to remove the old zone KEY.
-
-
-9. Security Considerations
- This document addresses the operational difficulties that arise when
- DNSSEC is deployed. By putting the child's zone KEY at the parent we
- solve at lot of problems by minimizing the amount of communication
- between the two. There is one security issue: the parent must not
- ever create a valid parental SIG over a KEY RR, from which the
- private part is (also) known to someone else than the legitimate
- administrator of the child zone. This can happen in two ways:
- 1. The private KEY at the child has been compromised.
- 2. The parent has been fooled and thus insufficiently checked
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 9]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
- whether the KEY RR is really from the child.
-
- For the security it doesn't matter if the SIG and the KEY are located
- at the child or at the parent, but if they are located at the parent
- it is much easier to replace the SIG. And by keeping the parental SIG
- lifetime short, the parent helps to protect the child against
- possible key compromises. The selfsigned zone KEY stored in the
- child's zone can have a long SIG expiration lifetime, this has no
- impact on the child's security.
-
- All security considerations from RFC 2535 apply.
-
-
-Authors' Addresses
-
- R. Gieben T. Lindgreen
- Stichting NLnet Labs Stichting NLnet Labs
- Kruislaan 419 Kruislaan 419
- 1098 VA Amsterdam 1098 VA Amsterdam
- miek@nlnetlabs.nl ted@nlnetlabs.nl
-
-
-References
-
- [RFC 3090] Lewis, E. "DNS Security Extension Clarification on Zone
- Status", RFC 3090
- www.ietf.org/rfc/rfc3090.txt
- [RFC 2119] Bradner, S. "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119
- www.ietf.org/rfc/rfc2119.txt
- [RFC 2535] Eastlake, D. "DNS Security Extensions", RFC 2535
- www.ietf.org/rfc/rfc2535.txt
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). 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.
-
-
-
-\fGieben & Lindgreen Expires November 2001 [Page 10]
-
-Internet Draft Parent Stores Zone KEYS May 2001
-
-
- 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.
+++ /dev/null
-Internet Engineering Task Force S. Thomson, Cisco
-INTERNET-DRAFT C. Huitema, Microsoft
-February 28, 2003 V. Ksinant, 6WIND
-Expires August 28, 2003 M. Souissi, AFNIC
-
-
-
-
-
- DNS Extensions to support IP version 6
- <draft-ietf-dnsext-rfc1886bis-02.txt>
-
-
-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."
-
- To view the list Internet-Draft Shadow Directories, see
- http://www.ietf.org/shadow.html.
-
- This Internet Draft expires August 28, 2003.
-
-
-
-Abstract
-
- This document defines the changes that need to be made to the Domain
- Name System to support hosts running IP version 6 (IPv6). The
- changes include a resource record type to store an IPv6 address,
- a domain to support lookups based on an IPv6 address, and updated
- definitions of existing query types that return Internet addresses as
- part of additional section processing. The extensions are designed
- to be compatible with existing applications and, in particular, DNS
- implementations themselves.
-
- This Document combines RFC1886 and changes to RFC 1886 made by
- RFC 3152, obsoleting both. Changes mainly consist in replacing
- the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
-
-
-
-
-
-
-draft-ietf-dnsext-rfc1886bis-02.txt [Page 1]
-\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
-
-
-Table of Contents
-
- 1. Introduction............................................. 2
- 2. New resource record definition and domain................ 2
- 2.1. AAAA record type.................................... 3
- 2.2. AAAA data format.................................... 3
- 2.3. AAAA query.......................................... 3
- 2.4. Textual format of AAAA records...................... 3
- 2.5. IP6.ARPA domain..................................... 3
- 3. Modifications to existing query types.................... 4
- 4. Security Considerations.................................. 4
- 5. IANA Considerations...................................... 4
- APPENDIX A: Changes from RFC-1886............................ 4
- Acknowledgments.............................................. 5
- References................................................... 5
- Authors' Addresses........................................... 6
- Full Copyright Statement..................................... 7
-
-
-1. INTRODUCTION
-
- Current support for the storage of Internet addresses in the Domain
- Name System (DNS)[1,2] cannot easily be extended to support IPv6
- addresses[3] since applications assume that address queries return
- 32-bit IPv4 addresses only.
-
- To support the storage of IPv6 addresses in DNS, this document
- defines the following extensions:
-
- o A resource record type is defined to map a domain name to an
- IPv6 address.
-
- o A domain is defined to support lookups based on address.
-
- o Existing queries that perform additional section processing to
- locate IPv4 addresses are redefined to perform additional
- section processing on both IPv4 and IPv6 addresses.
-
- The changes are designed to be compatible with existing software. The
- existing support for IPv4 addresses is retained. Transition issues
- related to the co-existence of both IPv4 and IPv6 addresses in DNS
- are discussed in [4].
-
-
-2. RESOURCE RECORD DEFINITION AND DOMAIN
-
- A record type is defined to store a host's IPv6 address. A host
- that has more than one IPv6 address must have more than one such
- record.
-
-draft-ietf-dnsext-rfc1886bis-02.txt [Page 2]
-\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
-
-2.1 AAAA record type
-
- The AAAA resource record type is a record specific to the Internet
- class that stores a single IPv6 address.
-
- The IANA assigned value of the type is 28 (decimal).
-
-
-2.2 AAAA data format
-
- A 128 bit IPv6 address is encoded in the data portion of an AAAA
- resource record in network byte order (high-order byte first).
-
-
-2.3 AAAA query
-
- An AAAA query for a specified domain name in the Internet class
- returns all associated AAAA resource records in the answer section of
- a response.
-
- A type AAAA query does not perform additional section processing.
-
-
-2.4 Textual format of AAAA records
-
- The textual representation of the data portion of the AAAA resource
- record used in a master database file is the textual representation
- of a IPv6 address as defined in [3].
-
-
-2.5 IP6.ARPA Domain
-
- A special domain is defined to look up a record given an address. The
- intent of this domain is to provide a way of mapping an IPv6 address
- to a host name, although it may be used for other purposes as well.
- The domain is rooted at IP6.ARPA.
-
- An IPv6 address is represented as a name in the IP6.ARPA domain by a
- sequence of nibbles separated by dots with the suffix ".IP6.ARPA".
- The sequence of nibbles is encoded in reverse order, i.e. the
- low-order nibble is encoded first, followed by the next low-order
- nibble and so on. Each nibble is represented by a hexadecimal digit.
- For example, the inverse lookup domain name corresponding to the
- address
-
- 4321:0:1:2:3:4:567:89ab
-
- would be
-
-b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
- ARPA.
-
-draft-ietf-dnsext-rfc1886bis-02.txt [Page 3]
-\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
-
-3. MODIFICATIONS TO EXISTING QUERY TYPES
-
- All existing query types that perform type A additional section
- processing, i.e. name server (NS), location of services (SRV) and
- mail exchange (MX) query types, must be redefined to perform both
- type A and type AAAA additional section processing. These definitions
- mean that a name server must add any relevant IPv4 addresses and any
- relevant IPv6 addresses available locally to the additional section
- of a response when processing any one of the above queries.
-
-
-4. SECURITY CONSIDERATIONS
-
- Any information obtained from the DNS must be regarded as unsafe
- unless techniques specified in [7] or [8] are used. The definitions
- of the AAAA record type and of the IP6.ARPA domain do not change the
- model for use of these techniques.
-
- So, this specification is not believed to cause any new security
- problems, nor to solve any existing ones.
-
-5. IANA CONSIDERATIONS
-
- There are no IANA assignments to be performed.
-
-APPENDIX A: Changes from RFC 1886
-
- The following changes were made from RFC 1886 "DNS Extensions to
- support IP version 6":
-
- - Replaced the "IP6.INT" domain by "IP6.ARPA".
- - Mentioned SRV query types in section 3 "MODIFICATIONS TO
- EXISTING QUERY TYPES"
- - Added security considerations.
- - Updated references :
- * From RFC 1884 to RFC 2373 (IP Version 6 Addressing
- Architecture).
- * From "work in progress" to RFC 2893 (Transition Mechanisms for
- IPv6 Hosts and Routers).
- * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845.
- - Updated document abstract
- - Added table of contents
- - Added full copyright statement
- - Added IANA considerations section
-
-
-
-
-
-
-draft-ietf-dnsext-rfc1886bis-02.txt [Page 4]
-\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
-
-Acknowledgements
-
- Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien
- Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael
- Guerin (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND),
- Frederic Roudaut (IRISA) and G6 group for their help during the RFC
- 1886 Interop tests sessions.
-
- Many thanks to Alain Durand and Olafur Gudmundsson for their support.
-
-
-
-Normative References
-
- [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
- 13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [2] Mockapetris, P., "Domain Names - Implementation and Specifica-
- tion", STD 13, RFC 1035, USC/Information Sciences Institute,
- November 1987.
-
- [3] Hinden, R., and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 2373, Nokia, Cisco, July 1998.
- This RFC is being updated. The current draft is
- "draft-ietf-ipngwg-addr-arch-v3-11.txt", Hinden, R., and
- S. Deering, October 25, 2002
-
-
-
-Informative References
-
- [4] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
- Hosts and Routers", RFC 2893, FreeGate Corp., Sun Microsystems
- Inc., August 2000.
- This RFC is being updated. The current draft is
- "draft-ietf-v6ops-mech-v2-00.txt", Gilligan, R., and
- E. Nordmark, February 24, 2003
-
- [5] Thomson, S., and C. Huitema, "DNS Extensions to support IP
- version 6", RFC 1886, Bellcore, INRIA, December 1995.
-
- [6] Bush, R., "Delegation of IP6.ARPA", RFC 3152, RGnet, August
- 2001.
-
- [7] Eastlake, D., "Domain Name System Security Extensions",
- RFC 2535, IBM, March 1999
-
- [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC 2845, ISC, NAI Labs, Motorola, Nominum, May 2000.
-
-
-draft-ietf-dnsext-rfc1886bis-02.txt [Page 5]
-\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
-
-
-Authors' Addresses
-
-
- Susan Thomson
- Cisco Systems
- 499 Thornall Street, 8th floor
- Edison, NJ 08837
- Telephone: 732-635-3086
- Email: sethomso@cisco.com
-
-
- Christian Huitema
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052-6399
- Email: huitema@microsoft.com
-
-
- Vladimir Ksinant
- 6WIND S.A.
- Immeuble Central Gare - Bat.C
- 1, place Charles de Gaulle
- 78180, Montigny-Le-Bretonneux - France
- Phone: +33 1 39 30 92 36
- Email: vladimir.ksinant@6wind.com
-
-
- Mohsen Souissi
- AFNIC
- Immeuble International
- 2, rue Stephenson,
- 78181, Saint-Quentin en Yvelines Cedex - France
- Phone: +33 1 39 30 83 40
- Email: Mohsen.Souissi@nic.fr
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-dnsext-rfc1886bis-02.txt [Page 6]
-\f
-INTERNET-DRAFT DNS Extensions to support IP version 6 February 2003
-
-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 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."
-
- The IETF takes no position regarding the validity or scope of
- any intellectual property or other rights that might be claimed
- to pertain to the implementation or use of the technology
- described in this document or the extent to which any license
- under such rights might or might not be available; neither does
- it represent that it has made any effort to identify any such
- rights. Information on the IETF's procedures with respect to
- rights in standards-track and standards-related documentation
- can be found in BCP-11. Copies of claims of rights made
- available for publication and any assurances of licenses to
- be made available, or the result of an attempt made
- to obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this
- specification can be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its
- attention any copyrights, patents or patent applications, or
- other proprietary rights which may cover technology that may be
- required to practice this standard. Please address the
- information to the IETF Executive Director.
-
-
-draft-ietf-dnsext-rfc1886bis-02.txt [Page 7]
+++ /dev/null
-INTERNET-DRAFT DSA KEYs and SIGs in the DNS
-OBSOLETES: RFC 2536 Donald Eastlake 3rd
- Motorola
-Expires: January 2002 July 2001
-
-
-
-
-
- DSA KEYs and SIGs in the Domain Name System (DNS)
- --- ---- --- ---- -- --- ------ ---- ------ -----
- <draft-ietf-dnsext-rfc2536bis-dsa-00.txt>
-
- Donald E. Eastlake 3rd
-
-
-Status of This Document
-
- This draft is intended to be become a Draft Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org> or to the author.
-
- 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
-
- A standard method for storing US Government Digital Signature
- Algorithm keys and signatures in the Domain Name System is described
- which utilizes DNS KEY and SIG resource records.
-
-
-
-
-
-
-
-Donald Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT DSA in the DNS
-
-
-Table of Contents
-
- Status of This Document....................................1
- Abstract...................................................1
-
- Table of Contents..........................................2
-
- 1. Introduction............................................3
- 2. DSA KEY Resource Records................................3
- 3. DSA SIG Resource Records................................4
- 4. Performance Considerations..............................4
- 5. Security Considerations.................................5
- 6. IANA Considerations.....................................5
-
- References.................................................6
- Author's Address...........................................6
- Expiration and File Name...................................7
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT DSA in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the global hierarchical replicated
- distributed database system for Internet addressing, mail proxy, and
- other information. The DNS has been extended to include digital
- signatures and cryptographic keys as described in [RFC 2535]. Thus
- the DNS can now be secured and can be used for secure key
- distribution.
-
- This document describes how to store US Government Digital Signature
- Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
- US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
-
-
-
-2. DSA KEY Resource Records
-
- DSA public keys are stored in the DNS as KEY RRs using algorithm
- number 3 [RFC 2535]. The structure of the algorithm specific portion
- of the RDATA part of this RR is as shown below. These fields, from Q
- through Y are the "public key" part of the DSA KEY RR.
-
- The period of key validity is not in the KEY RR but is indicated by
- the SIG RR(s) which signs and authenticates the KEY RR(s) at that
- domain name.
-
- Field Size
- ----- ----
- T 1 octet
- Q 20 octets
- P 64 + T*8 octets
- G 64 + T*8 octets
- Y 64 + T*8 octets
-
- As described in [FIPS 186-2] and [Schneier]: T is a key size
- parameter chosen such that 0 <= T <= 8. (The meaning for algorithm 3
- if the T octet is greater than 8 is reserved and the remainder of the
- RDATA portion may have a different format in that case.) Q is a
- prime number selected at key generation time such that 2**159 < Q <
- 2**160 so Q is always 20 octets long and, as with all other fields,
- is stored in "big-endian" network order. P, G, and Y are calculated
- as directed by the [FIPS 186-2] key generation algorithm [Schneier].
- P is in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T
- octets long. G and Y are quantities modulo P and so can be up to the
- same length as P and are allocated fixed size fields with the same
- number of octets as P.
-
- During the key generation process, a random number X must be
- generated such that 1 <= X <= Q-1. X is the private key and is used
- in the final step of public key generation where Y is computed as
-
-
-Donald Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT DSA in the DNS
-
-
- Y = G**X mod P
-
-
-
-3. DSA SIG Resource Records
-
- The signature portion of the SIG RR RDATA area, when using the US
- Digital Signature Algorithm, is shown below with fields in the order
- they occur. See [RFC 2535] for fields in the SIG RR RDATA which
- precede the signature itself.
-
- Field Size
- ----- ----
- T 1 octet
- R 20 octets
- S 20 octets
-
- The data signed is determined as specified in [RFC 2535]. Then the
- following steps are taken, as specified in [FIPS 186-2], where Q, P,
- G, and Y are as specified in the public key [Schneier]:
-
- hash = SHA-1 ( data )
-
- Generate a random K such that 0 < K < Q.
-
- R = ( G**K mod P ) mod Q
-
- S = ( K**(-1) * (hash + X*R) ) mod Q
-
- For infromation on the SHA-1 has funcation see [FIPS 180-1] and
- [draft-sha1].
-
- Since Q is 160 bits long, R and S can not be larger than 20 octets,
- which is the space allocated.
-
- T is copied from the public key. It is not logically necessary in
- the SIG but is present so that values of T > 8 can more conveniently
- be used as an escape for extended versions of DSA or other algorithms
- as later specified.
-
-
-
-4. Performance Considerations
-
- General signature generation speeds are roughly the same for RSA [RFC
- 3110] and DSA. With sufficient pre-computation, signature generation
- with DSA is faster than RSA. Key generation is also faster for DSA.
- However, signature verification is an order of magnitude slower than
- RSA when the RSA public exponent is chosen to be small as is
- recommended for KEY RRs used in domain name system (DNS) data
-
-
-Donald Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT DSA in the DNS
-
-
- authentication.
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient, it
- is still advisable at this time to make reasonable efforts to
- minimize the size of KEY RR sets stored within the DNS consistent
- with adequate security. Keep in mind that in a secure zone, at least
- one authenticating SIG RR will also be returned.
-
-
-
-5. Security Considerations
-
- Many of the general security consideration in [RFC 2535] apply. Keys
- retrieved from the DNS should not be trusted unless (1) they have
- been securely obtained from a secure resolver or independently
- verified by the user and (2) this secure resolver and secure
- obtainment or independent verification conform to security policies
- acceptable to the user. As with all cryptographic algorithms,
- evaluating the necessary strength of the key is essential and
- dependent on local policy.
-
- The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
- current DSA standard may limit the security of DSA. For particularly
- critical applications, implementors are encouraged to consider the
- range of available algorithms and key sizes.
-
- DSA assumes the ability to frequently generate high quality random
- numbers. See [RFC 1750] for guidance. DSA is designed so that if
- manipulated rather than random numbers are used, very high bandwidth
- covert channels are possible. See [Schneier] and more recent
- research. The leakage of an entire DSA private key in only two DSA
- signatures has been demonstrated. DSA provides security only if
- trusted implementations, including trusted random number generation,
- are used.
-
-
-
-6. IANA Considerations
-
- Allocation of meaning to values of the T parameter that are not
- defined herein requires an IETF standards actions. It is intended
- that values unallocated herein be used to cover future extensions of
- the DSS standard.
-
-
-
-
-
-
-Donald Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT DSA in the DNS
-
-
-References
-
- [FIPS 180-1] - U.S. Federal Information Processing Standard: Secure
- Hash Standard, April 1995.
-
- [FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
- Signature Standard, January 2000.
-
- [RFC 1034] - P. Mockapetris, "Domain names - concepts and
- facilities", 11/01/1987.
-
- [RFC 1035] - P. Mockapetris, "Domain names - implementation and
- specification", 11/01/1987.
-
- [RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness
- Recommendations for Security", December 1994.
-
- [RFC 2535] - Domain Name System Security Extensions, D. Eastlake,
- March 1999.
-
- [RFC 2671] - Extension Mechanisms for DNS (EDNS0), P. Vixie, August
- 1999.
-
- [RFC 3110] - RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
- (DNS), D. Eastlake 3rd. May 2001.
-
- [draft-sha1] - US Secure Hash Algorithm 1 (SHA1), draft-eastlake-
- sha1-02.txt, work in progress, D. Eastlake, in IESG queue for
- approval as an Informational RFC.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography Second Edition:
- protocols, algorithms, and source code in C", 1996, John Wiley and
- Sons, ISBN 0-471-11709-9.
-
-
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-261-5434(w)
- +1-508-634-2066(h)
- FAX: +1-508-261-4447(w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-
-Donald Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT DSA in the DNS
-
-
-Expiration and File Name
-
- This draft expires in January 2002.
-
- Its file name is draft-ietf-dnsext-rfc2536bis-dsa-00.txt.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd [Page 7]
-\f
+++ /dev/null
-INTERNET-DRAFT Diffie-Hellman Keys in the DNS
-OBSOLETES: RFC 2539 Donald Eastlake 3rd
- Motorola
-Expires: January 2002 July 2001
-
-
-
-
- Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
- ------- -- -------------- ---- -- --- ------ ---- ------ -----
- <draft-ietf-dnsext-rfc2539bis-dhk-00.txt>
-
- Donald E. Eastlake 3rd
-
-
-Status of This Document
-
- This draft is intended to be become a Draft Standard RFC.
- Distribution of this document is unlimited. Comments should be sent
- to the DNS extensions working group mailing list
- <namedroppers@ops.ietf.org> or to the author.
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd [Page 1]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Keys in the DNS
-
-
-Abstract
-
- A standard method for storing Diffie-Hellman keys in the Domain Name
- System is described which utilizes DNS KEY resource records.
-
-
-
-Acknowledgements
-
- Part of the format for Diffie-Hellman keys and the description
- thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
- and Hemma Prafullchandra.
-
- In addition, the following persons provided useful comments that were
- incorporated into the predecessor of this document: Ran Atkinson,
- Thomas Narten.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd [Page 2]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Keys in the DNS
-
-
-Table of Contents
-
- Status of This Document....................................1
-
- Abstract...................................................2
- Acknowledgements...........................................2
-
- Table of Contents..........................................3
-
- 1. Introduction............................................4
- 1.1 About This Document....................................4
- 1.2 About Diffie-Hellman...................................4
- 2. Diffie-Hellman KEY Resource Records.....................5
- 3. Performance Considerations..............................6
- 4. IANA Considerations.....................................6
- 5. Security Considerations.................................6
-
- References.................................................7
- Author's Address...........................................7
- Expiration and File Name...................................7
-
- Appendix A: Well known prime/generator pairs...............8
- A.1. Well-Known Group 1: A 768 bit prime..................8
- A.2. Well-Known Group 2: A 1024 bit prime.................8
- A.3. Well-Known Group 3: A 1536 bit prime.................9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd [Page 3]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Keys in the DNS
-
-
-1. Introduction
-
- The Domain Name System (DNS) is the current global hierarchical
- replicated distributed database system for Internet addressing, mail
- proxy, and similar information. The DNS has been extended to include
- digital signatures and cryptographic keys as described in [RFC 2535].
- Thus the DNS can now be used for secure key distribution.
-
-
-
-1.1 About This Document
-
- This document describes how to store Diffie-Hellman keys in the DNS.
- Familiarity with the Diffie-Hellman key exchange algorithm is assumed
- [Schneier].
-
-
-
-1.2 About Diffie-Hellman
-
- Diffie-Hellman requires two parties to interact to derive keying
- information which can then be used for authentication. Since DNS SIG
- RRs are primarily used as stored authenticators of zone information
- for many different resolvers, no Diffie-Hellman algorithm SIG RR is
- defined. For example, assume that two parties have local secrets "i"
- and "j". Assume they each respectively calculate X and Y as follows:
-
- X = g**i ( mod p )
-
- Y = g**j ( mod p )
-
- They exchange these quantities and then each calculates a Z as
- follows:
-
- Zi = Y**i ( mod p )
-
- Zj = X**j ( mod p )
-
- Zi and Zj will both be equal to g**(ij)(mod p) and will be a shared
- secret between the two parties that an adversary who does not know i
- or j will not be able to learn from the exchanged messages (unless
- the adversary can derive i or j by performing a discrete logarithm
- mod p which is hard for strong p and g).
-
- The private key for each party is their secret i (or j). The public
- key is the pair p and g, which must be the same for the parties, and
- their individual X (or Y).
-
- For further information about Diffie-Hellman and precautions to take
- in deciding on a p and g, see [RFC 2631].
-
-
-Donald Eastlake 3rd [Page 4]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Keys in the DNS
-
-
-2. Diffie-Hellman KEY Resource Records
-
- Diffie-Hellman keys are stored in the DNS as KEY RRs using algorithm
- number 2. The structure of the RDATA portion of this RR is as shown
- below. The first 4 octets, including the flags, protocol, and
- algorithm fields are common to all KEY RRs as described in [RFC
- 2535]. The remainder, from prime length through public value is the
- "public key" part of the KEY RR. The period of key validity is not in
- the KEY RR but is indicated by the SIG RR(s) which signs and
- authenticates the KEY RR(s) at that domain name.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | KEY flags | protocol | algorithm=2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | prime length (or flag) | prime (p) (or special) /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / prime (p) (variable length) | generator length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | generator (g) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | public value length | public value (variable length)/
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- / public value (g^i mod p) (variable length) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Prime length is length of the Diffie-Hellman prime (p) in bytes if it
- is 16 or greater. Prime contains the binary representation of the
- Diffie-Hellman prime with most significant byte first (i.e., in
- network order). If "prime length" field is 1 or 2, then the "prime"
- field is actually an unsigned index into a table of 65,536
- prime/generator pairs and the generator length SHOULD be zero. See
- Appedix A for defined table entries and Section 4 for information on
- allocating additional table entries. The meaning of a zero or 3
- through 15 value for "prime length" is reserved.
-
- Generator length is the length of the generator (g) in bytes.
- Generator is the binary representation of generator with most
- significant byte first. PublicValueLen is the Length of the Public
- Value (g**i (mod p)) in bytes. PublicValue is the binary
- representation of the DH public value with most significant byte
- first.
-
- The corresponding algorithm=2 SIG resource record is not used so no
- format for it is defined.
-
-
-
-
-
-
-Donald Eastlake 3rd [Page 5]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Keys in the DNS
-
-
-3. Performance Considerations
-
- Current DNS implementations are optimized for small transfers,
- typically less than 512 bytes including DNS overhead. Larger
- transfers will perform correctly and extensions have been
- standardized [RFC 2671] to make larger transfers more efficient, it
- is still advisable at this time to make reasonable efforts to
- minimize the size of KEY RR sets stored within the DNS consistent
- with adequate security. Keep in mind that in a secure zone, at least
- one authenticating SIG RR will also be returned.
-
-
-
-4. IANA Considerations
-
- Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
- an IETF consensus as defined in [RFC 2434].
-
- Well known prime/generator pairs number 0x0000 through 0x07FF can
- only be assigned by an IETF standards action. RFC 2539, the Proposed
- Standard predecessor of this document, assigned 0x0001 through
- 0x0002. This document proposes to assign 0x0003. Pairs number 0s0800
- through 0xBFFF can be assigned based on RFC documentation. Pairs
- number 0xC000 through 0xFFFF are available for private use and are
- not centrally coordinated. Use of such private pairs outside of a
- closed environment may result in conflicts.
-
-
-
-5. Security Considerations
-
- Many of the general security consideration in [RFC 2535] apply. Keys
- retrieved from the DNS should not be trusted unless (1) they have
- been securely obtained from a secure resolver or independently
- verified by the user and (2) this secure resolver and secure
- obtainment or independent verification conform to security policies
- acceptable to the user. As with all cryptographic algorithms,
- evaluating the necessary strength of the key is important and
- dependent on local policy.
-
- In addition, the usual Diffie-Hellman key strength considerations
- apply. (p-1)/2 should also be prime, g should be primitive mod p, p
- should be "large", etc. [RFC 2631, Schneier]
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd [Page 6]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Keys in the DNS
-
-
-References
-
- [RFC 1034] - P. Mockapetris, "Domain names - concepts and
- facilities", November 1987.
-
- [RFC 1035] - P. Mockapetris, "Domain names - implementation and
- specification", November 1987.
-
- [RFC 2434] - Guidelines for Writing an IANA Considerations Section in
- RFCs, T. Narten, H. Alvestrand, October 1998.
-
- [RFC 2535] - Domain Name System Security Extensions, D. Eastlake 3rd,
- March 1999.
-
- [RFC 2539] - Storage of Diffie-Hellman Keys in the Domain Name System
- (DNS), D. Eastlake, March 1999, obsoleted by this RFC.
-
- [RFC 2631] - Diffie-Hellman Key Agreement Method, E. Rescorla, June
- 1999.
-
- [RFC 2671] - Extension Mechanisms for DNS (EDNS0), P. Vixie, August
- 1999.
-
- [Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
- Algorithms, and Source Code in C", 1996, John Wiley and Sons.
-
-
-
-
-Author's Address
-
- Donald E. Eastlake 3rd
- Motorola
- 155 Beaver Street
- Milford, MA 01757 USA
-
- Telephone: +1-508-261-5434 (w)
- +1-508-634-2066 (h)
- FAX: +1-508-261-4447 (w)
- EMail: Donald.Eastlake@motorola.com
-
-
-
-Expiration and File Name
-
- This draft expires in January 2002.
-
- Its file name is draft-ietf-dnsext-rfc2539bis-dhk-00.txt.
-
-
-
-
-Donald Eastlake 3rd [Page 7]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Keys in the DNS
-
-
-Appendix A: Well known prime/generator pairs
-
- These numbers are copied from the IPSEC effort where the derivation of
- these values is more fully explained and additional information is available.
- Richard Schroeppel performed all the mathematical and computational
- work for this appendix.
-
-
-
-A.1. Well-Known Group 1: A 768 bit prime
-
- The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
- decimal value is
- 155251809230070893513091813125848175563133404943451431320235
- 119490296623994910210725866945387659164244291000768028886422
- 915080371891804634263272761303128298374438082089019628850917
- 0691316593175367469551763119843371637221007210577919
-
- Prime modulus: Length (32 bit words): 24, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-A.2. Well-Known Group 2: A 1024 bit prime
-
- The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
- Its decimal value is
- 179769313486231590770839156793787453197860296048756011706444
- 423684197180216158519368947833795864925541502180565485980503
- 646440548199239100050792877003355816639229553136239076508735
- 759914822574862575007425302077447712589550957937778424442426
- 617334727629299387668709205606050270810842907692932019128194
- 467627007
-
- Prime modulus: Length (32 bit words): 32, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
- FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-Donald Eastlake 3rd [Page 8]
-\f
-
-INTERNET-DRAFT Diffie-Hellman Keys in the DNS
-
-
-A.3. Well-Known Group 3: A 1536 bit prime
-
- The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
- Its decimal value is
- 241031242692103258855207602219756607485695054850245994265411
- 694195810883168261222889009385826134161467322714147790401219
- 650364895705058263194273070680500922306273474534107340669624
- 601458936165977404102716924945320037872943417032584377865919
- 814376319377685986952408894019557734611984354530154704374720
- 774996976375008430892633929555996888245787241299381012913029
- 459299994792636526405928464720973038494721168143446471443848
- 8520940127459844288859336526896320919633919
-
- Prime modulus Length (32 bit words): 48, Data (hex):
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
- C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
- 83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
- 670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
-
- Generator: Length (32 bit words): 1, Data (hex): 2
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Donald Eastlake 3rd [Page 9]
-\f
+++ /dev/null
-
-
-
-
-
-Network Working Group A. Gulbrandsen
-Category: INTERNET-DRAFT Trolltech AS
-Obsoletes: 2782 P. Vixie
-draft-ietf-dnsext-rfc2782bis-01.txt Internet Software Consortium
-June 6, 2001 L. Esibov
-Expires: December 6, 2001 Microsoft Corp.
-
-
-
- A DNS RR for specifying the location of services (DNS SRV)
-
-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 Notice
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
-Abstract
-
- This document describes a DNS RR which specifies the location of the
- server(s) for a specific protocol and domain.
-
-Overview and rationale
-
- Currently, one must either know the exact address of a server to
- contact it, or broadcast a question.
-
- The SRV RR allows administrators to use several servers for a single
- domain, to move services from host to host with little fuss, and to
- designate some hosts as primary servers for a service and others as
- backups.
-
- Clients ask for a specific service/protocol for a specific domain
- (the word domain is used here in the strict RFC 1034 sense), and get
- back the names of any available servers.
-
- Note that where this document refers to "address records", it means A
- RR's, AAAA RR's, or their most modern equivalent.
-
-
-
-
-
-Expires December 2001 [Page 1]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-Definitions
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
- used in this document are to be interpreted as specified in [BCP 14].
- Other terms used in this document are defined in the DNS
- specification, RFC 1034.
-
-Applicability Statement
-
- In general, it is expected that SRV records will be used by clients
- for applications where the relevant protocol specification indicates
- that clients should use the SRV record. Such specification MUST
- define the symbolic name to be used in the Service field of the SRV
- record as described below. It also MUST include security
- considerations. Service SRV records SHOULD NOT be used in the absence
- of such specification.
-
-Introductory example
-
- If a SRV-cognizant LDAP client wants to discover a LDAP server that
- supports TCP protocol and provides LDAP service for the domain
- example.com., it does a lookup of
-
- _ldap._tcp.example.com
-
- as described in [ARM]. The example zone file near the end of this
- memo contains answering RRs for an SRV query.
-
- Note: LDAP is chosen as an example for illustrative purposes only,
- and the LDAP examples used in this document should not be considered
- a definitive statement on the recommended way for LDAP to use SRV
- records. As described in the earlier applicability section, consult
- the appropriate LDAP documents for the recommended procedures.
-
-The format of the SRV RR
-
- Here is the format of the SRV RR, whose DNS type code is 33:
-
- _Service._Proto.Domain TTL Class SRV Priority Weight Port Target
-
- (There is an example near the end of this document.)
-
- Service
- The symbolic name of the desired service, as defined in Assigned
- Numbers [STD 2] or locally. An underscore (_) is prepended to
- the service identifier to avoid collisions with DNS labels that
- occur in nature.
-
-
-
-
-
-Expires December 2001 [Page 2]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- Some widely used services, notably POP, don't have a single
- universal name. If Assigned Numbers names the service
- indicated, that name is the only name which is legal for SRV
- lookups. The Service is case insensitive.
-
- Proto
- The symbolic name of the desired protocol, with an underscore
- (_) prepended to prevent collisions with DNS labels that occur
- in nature. _TCP and _UDP are at present the most useful values
- for this field, though any name defined by Assigned Numbers or
- locally may be used (as for Service). The Proto is case
- insensitive.
-
- Domain
- The domain this RR refers to. The SRV RR is unique in that the
- name one searches for is not this Domain name; the example near
- the end shows this clearly.
-
- TTL
- Standard DNS meaning [RFC 1035].
-
- Class
- Standard DNS meaning [RFC 1035]. SRV records occur in the IN
- Class.
-
- Priority
- The priority of this target host. A client MUST attempt to
- contact the target host with the lowest-numbered priority it can
- reach; target hosts with the same priority SHOULD be tried in an
- order defined by the weight field. The range is 0-65535. This
- is a 16 bit unsigned integer in network byte order.
-
- Weight
- A server selection mechanism. The weight field specifies a
- relative weight for entries with the same priority. Larger
- weights SHOULD be given a proportionately higher probability of
- being selected. The range of this number is 0-65535. This is a
- 16 bit unsigned integer in network byte order. Domain
- administrators SHOULD use Weight 0 when there isn't any server
- selection to do, to make the RR easier to read for humans (less
- noisy). In the presence of records containing weights greater
- than 0, records with weight 0 should have a very small chance of
- being selected.
-
- In the absence of a protocol whose specification calls for the
- use of other weighting information, a client arranges the SRV
- RRs of the same Priority in the order in which target hosts,
-
-
-
-
-Expires December 2001 [Page 3]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- specified by the SRV RRs, will be contacted. The following
- algorithm SHOULD be used to order the SRV RRs of the same
- priority:
-
- To select a target to be contacted next, arrange all SRV RRs
- (that have not been ordered yet) in any order, except that all
- those with weight 0 are placed at the beginning of the list.
-
- Compute the sum of the weights of those RRs, and with each RR
- associate the running sum in the selected order. Then choose a
- uniform random real number between 0 and the sum computed
- (inclusive), and select the RR whose running sum value is the
- first in the selected order which is greater than or equal to
- the random number selected. The target host specified in the
- selected SRV RR is the next one to be contacted by the client.
- Remove this SRV RR from the set of the unordered SRV RRs and
- apply the described algorithm to the unordered SRV RRs to select
- the next target host. Continue the ordering process until there
- are no unordered SRV RRs. This process is repeated for each
- Priority.
-
- Port
- The port on this target host of this service. The range is 0-
- 65535. This is a 16 bit unsigned integer in network byte order.
- This is often as specified in Assigned Numbers but need not be.
-
- Target
- The domain name of the target host. There MUST be one or more
- address records for this name, the name MUST NOT be an alias (in
- the sense of RFC 1034 or RFC 2181). Implementors are urged, but
- not required, to return the address record(s) in the Additional
- Data section. Unless and until permitted by future standards
- action, name compression is not to be used for this field.
-
- A Target of "." means that the service is decidedly not
- available at this domain.
-
-Domain administrator advice
-
- Expecting everyone to update their client applications when the first
- server publishes a SRV RR is futile (even if desirable). Therefore
- SRV would have to coexist with address record lookups for existing
- protocols, and DNS administrators should try to provide address
- records to support old clients:
-
- - Where the services for a single domain are spread over several
- hosts, it seems advisable to have a list of address records at
- the same DNS node as the SRV RR, listing reasonable (if perhaps
-
-
-
-Expires December 2001 [Page 4]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- suboptimal) fallback hosts for Telnet, NNTP and other protocols
- likely to be used with this name. Note that some programs only
- try the first address they get back from e.g. gethostbyname(),
- and we don't know how widespread this behavior is.
-
- - Where one service is provided by several hosts, one can either
- provide address records for all the hosts (in which case the
- round-robin mechanism, where available, will share the load
- equally) or just for one (presumably the fastest).
-
- - If a host is intended to provide a service only when the main
- server(s) is/are down, it probably shouldn't be listed in
- address records.
-
- - Hosts that are referenced by backup address records must use the
- port number specified in Assigned Numbers for the service.
-
- - Designers of future protocols for which "secondary servers" is
- not useful (or meaningful) may choose to not use SRV's support
- for secondary servers. Clients for such protocols may use or
- ignore SRV RRs with Priority higher than the RR with the lowest
- Priority for a domain.
-
- Currently there's a practical limit of 512 bytes for DNS replies.
- Until all resolvers can handle larger responses, domain
- administrators are strongly advised to keep their SRV replies below
- 512 bytes.
-
- All round numbers, wrote Dr. Johnson, are false, and these numbers
- are very round: A reply packet has a 30-byte overhead plus the name
- of the service ("_ldap._tcp.example.com" for instance); each SRV RR
- adds 20 bytes plus the name of the target host; each NS RR in the NS
- section is 15 bytes plus the name of the name server host; and
- finally each A RR in the additional data section is 20 bytes or so,
- and there are A's for each SRV and NS RR mentioned in the answer.
- This size estimate is extremely crude, but shouldn't underestimate
- the actual answer size by much. If an answer may be close to the
- limit, using a DNS query tool (e.g. "dig") to look at the actual
- answer is a good idea.
-
-The "Weight" field
-
- Weight, the server selection field, is not quite satisfactory, but
- the actual load on typical servers changes much too quickly to be
- kept around in DNS caches. It seems to the authors that offering
- administrators a way to say "this machine is three times as fast as
- that one" is the best that can practically be done.
-
-
-
-
-Expires December 2001 [Page 5]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- The only way the authors can see of getting a "better" load figure is
- asking a separate server when the client selects a server and
- contacts it. For short-lived services an extra step in the
- connection establishment seems too expensive, and for long-lived
- services, the load figure may well be thrown off a minute after the
- connection is established when someone else starts or finishes a
- heavy job.
-
- Note: There are currently various experiments at providing relative
- network proximity estimation, available bandwidth estimation, and
- similar services. Use of the SRV record with such facilities, and in
- particular the interpretation of the Weight field when these
- facilities are used, is for further study. Weight is only intended
- for static, not dynamic, server selection. Using SRV weight for
- dynamic server selection would require assigning unreasonably short
- TTLs to the SRV RRs, which would limit the usefulness of the DNS
- caching mechanism, thus increasing overall network load and
- decreasing overall reliability. Server selection via SRV is only
- intended to express static information such as "this server has a
- faster CPU than that one" or "this server has a much better network
- connection than that one".
-
-The Port number
-
- Currently, the translation from service name to port number happens
- at the client, often using a file such as /etc/services.
-
- Moving this information to the DNS makes it less necessary to update
- these files on every single computer of the net every time a new
- service is added, and makes it possible to move standard services out
- of the "root-only" port range on unix.
-
-Usage rules
-
- A SRV-cognizant client SHOULD use this procedure to locate a list of
- servers and connect to the preferred one:
-
- Do a lookup for QNAME=_service._protocol.domain, QCLASS=IN,
- QTYPE=SRV.
-
- If the reply is NOERROR, ANCOUNT>0 and there is at least one
- SRV RR which specifies the requested Service and Protocol in
- the reply:
-
- If there is precisely one SRV RR, and its Target is "."
- (the root domain), abort and do not attempt lookup for
- QNAME=domain, QCLASS=IN, QTYPE=A.
-
-
-
-
-
-
-Expires December 2001 [Page 6]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- Else, for all such RR's, build a list of (Priority, Weight,
- Target) tuples
-
- Sort the list by priority (lowest number first)
-
- Create a new empty list
-
- For each distinct priority level
- While there are still elements left at this priority
- level
-
- Select an element as specified above, in the
- description of Weight in "The format of the SRV
- RR" Section, and move it to the tail of the new
- list
-
- For each element in the new list
-
- query the DNS for address records for the Target or
- use any such records found in the Additional Data
- section of the earlier SRV response.
-
- for each address record found, try to connect to the
- (protocol, address, service).
-
- else
-
- Do a lookup for QNAME=domain, QCLASS=IN, QTYPE=A
-
- for each address record found, try to connect to the
- (protocol, address, service)
-
-Notes:
-
- - Port numbers SHOULD NOT be used in place of the symbolic service
- or protocol names (for the same reason why variant names cannot
- be allowed: Applications would have to do two or more lookups).
-
- - If a truncated response comes back from an SRV query, the rules
- described in [RFC 2181] shall apply.
-
- - A client MUST parse all of the RR's in the reply.
-
- - If the Additional Data section doesn't contain address records
- for all the SRV RR's and the client may want to connect to the
- target host(s) involved, the client MUST look up the address
- record(s). (This happens quite often when the address record
- has shorter TTL than the SRV or NS RR's.)
-
-
-
-Expires December 2001 [Page 7]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- - Future protocols could be designed to use SRV RR lookups as the
- means by which clients locate their servers.
-
-Fictional example
-
- This example uses fictional service "foobar" as an aid in
- understanding SRV records. If ever service "foobar" is implemented,
- it is not intended that it will necessarily use SRV records. This is
- (part of) the zone file for example.com, a still-unused domain:
-
- $ORIGIN example.com.
- @ SOA server.example.com. root.example.com. (
- 1995032001 3600 3600 604800 86400 )
- NS server.example.com.
- NS ns1.ip-provider.net.
- NS ns2.ip-provider.net.
- ; foobar - use old-slow-box or new-fast-box if either is
- ; available, make three quarters of the logins go to
- ; new-fast-box.
- _foobar._tcp SRV 0 1 9 old-slow-box.example.com.
- SRV 0 3 9 new-fast-box.example.com.
- ; if neither old-slow-box or new-fast-box is up, switch to
- ; using the sysdmin's box and the server
- SRV 1 0 9 sysadmins-box.example.com.
- SRV 1 0 9 server.example.com.
- server A 172.30.79.10
- old-slow-box A 172.30.79.11
- sysadmins-box A 172.30.79.12
- new-fast-box A 172.30.79.13
- ; NO other services are supported
- *._tcp SRV 0 0 0 .
- *._udp SRV 0 0 0 .
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires December 2001 [Page 8]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
- In this example, a client of the "foobar" service in the
- "example.com." domain needs an SRV lookup of
- "_foobar._tcp.example.com." and possibly A lookups of "new-fast-
- box.example.com." and/or the other hosts named. The size of the SRV
- reply is approximately 365 bytes:
-
- 30 bytes general overhead
- 20 bytes for the query string, "_foobar._tcp.example.com."
- 130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
- fast-box", "old-slow-box", "server" and "sysadmins-box" -
- "example.com" in the query section is quoted here and doesn't
- need to be counted again.
- 75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
- "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is
- quoted and only needs to be counted once.
- 120 bytes for the 6 address records (assuming IPv4 only) mentioned
- by the SRV and NS RR's.
-
-IANA Considerations
-
- The IANA has assigned RR type value 33 to the SRV RR. No other IANA
- services are required by this document.
-
-Changes from RFC 2782
-
- This document obsoletes RFC 2782
- Only editorial clarifications were made to this document. Namely
-
- - it was clarified that "Weight" subsection refers to real "random
- number" rather than integer number;
-
- - it was clarified that the "Name" used in the owner name of the SRV
- record used in "The format of the SRV RR" section is a "Domain"
- name;
-
- - the "QNAME=_service._protocol.target" was replaced by
- "QNAME=_service._protocol.domain" in "Usage rules" section to
- eliminate a possibility of confusion with the Target field of the
- SRV record.
-
- - client's behavior when response to a query contains a single SRV
- RR and its Target is "." is clarified in "Usage rules" section.
-
-
-Security Considerations
-
- The authors believe this RR to not cause any new security problems.
- Some problems become more visible, though.
-
-
-
-
-
-Expires December 2001 [Page 9]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
- - The ability to specify ports on a fine-grained basis obviously
- changes how a router can filter packets. It becomes impossible
- to block internal clients from accessing specific external
- services, slightly harder to block internal users from running
- unauthorized services, and more important for the router
- operations and DNS operations personnel to cooperate.
-
- - There is no way a site can keep its hosts from being referenced
- as servers. This could lead to denial of service.
-
-
- - With SRV, DNS spoofers can supply false port numbers, as well as
- host names and addresses. Because this vulnerability exists
- already, with names and addresses, this is not a new
- vulnerability, merely a slightly extended one, with little
- practical effect.
-
-
-
-References
-
- STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
- 1700, October 1994.
-
- RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- RFC 1035: Mockapetris, P., "Domain names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
- RFC 974: Partridge, C., "Mail routing and the domain system", STD
- 14, RFC 974, January 1986.
-
- BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
- Services", BCP 17, RFC 2219, October 1997.
-
- BCP 14: Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- ARM: Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP
- Services with DNS", Work in Progress.
-
- KDC-DNS: Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
- Realm Information with DNS", Work in Progress.
-
-
-
-
-Expires December 2001 [Page 10]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
-Acknowledgements
-
- The algorithm used to select from the weighted SRV RRs of equal
- priority is adapted from one supplied by Dan Bernstein.
-
-Authors' Addresses
-
- Arnt Gulbrandsen
- Trolltech AS
- Waldemar Thranes gate 98
- N-0175 Oslo, Norway
-
- Fax: +47 21604800
- Phone: +47 21604801
- EMail: arnt@trolltech.com
-
-
- Paul Vixie
- Internet Software Consortium
- 950 Charter Street
- Redwood City, CA 94063
-
- Phone: +1 650 779 7001
-
-
- Levon Esibov
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- EMail: levone@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires December 2001 [Page 11]
-
-INTERNET-DRAFT DNS SRV RR June 2001
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires December 6, 2001 [Page 12]
\ No newline at end of file
+++ /dev/null
-
-
-
-
-
-
-DNSEXT Working Group Yuji Kamite
-INTERNET-DRAFT NTT Communications
-<draft-ietf-dnsext-tkey-renewal-mode-03.txt> Masaya Nakayama
-Expires: Sep. 3, 2003 The University of Tokyo
- Mar. 3, 2003
-
-
-
-
- TKEY Secret Key Renewal Mode
-
-
-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 defines a new mode in TKEY [RFC2930] and proposes an
- atomic method for changing secret keys used for TSIG [RFC2845]
- periodically. Originally, TKEY provides methods of setting up shared
- secrets other than manual exchange, but it cannot control timing of
- key renewal very well though it can add or delete shared keys
- separately. This proposal is a systematical key renewal procedure
- intended for preventing signing DNS messages with old and non-safe
- keys permanently.
-
-
-
-
-
-
-
-Kamite, et. al. [Page 1]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- Table of Contents
-
-
-1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 Defined Words . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.2 New Format and Assigned Numbers . . . . . . . . . . . . . . . 4
- 1.3 Overview of Secret Key Renewal Mode . . . . . . . . . . . . . 4
-2 Shared Secret Key Renewal . . . . . . . . . . . . . . . . . . . . 5
- 2.1 Key Usage Time Check . . . . . . . . . . . . . . . . . . . . 5
- 2.2 Partial Revocation . . . . . . . . . . . . . . . . . . . . . 6
- 2.3 Key Renewal Message Exchange . . . . . . . . . . . . . . . . 6
- 2.3.1 TKEY RR structure for Key Renewal . . . . . . . . . . . . 8
- 2.4 Key Adoption . . . . . . . . . . . . . . . . . . . . . . . . 9
- 2.4.1 Query for Key Adoption . . . . . . . . . . . . . . . . . 9
- 2.4.2 Response for Key Adoption . . . . . . . . . . . . . . . . 10
- 2.5 Keying Schemes . . . . . . . . . . . . . . . . . . . . . . . 11
- 2.5.1 DH Exchange for Key Renewal . . . . . . . . . . . . . . . 11
- 2.5.2 Server Assigned Keying for Key Renewal . . . . . . . . . 12
- 2.5.3 Resolver Assigned Keying for Key Renewal . . . . . . . . 13
- 2.6 Considerations about Non-compliant Hosts . . . . . . . . . . 14
-3 Secret Storage . . . . . . . . . . . . . . . . . . . . . . . . . 14
-4 Compulsory Key Revocation by Server . . . . . . . . . . . . . . . 15
- 4.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-5 Special Considerations for Two Servers' Case . . . . . . . . . . 16
- 5.1 To Cope with Collisions of Renewal Requests . . . . . . . . . 16
-6 Key Name Considerations . . . . . . . . . . . . . . . . . . . . . 17
-7 Example Usage of Secret Key Renewal Mode . . . . . . . . . . . . 17
-8 Security Considerations . . . . . . . . . . . . . . . . . . . . . 19
-9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 20
-10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
-Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 22
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al. [Page 2]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
-1. Introduction
-
- TSIG [RFC2845] provides DNS message integrity and the
- request/transaction authentication by means of message authentication
- codes (MAC). TSIG is a practical solution in view of calculation
- speed and availability. However, TSIG does not have exchanging
- mechanism of shared secret keys between server and resolver, and
- administrators might have to exchange secret keys manually. TKEY
- [RFC2930] is introduced to solve such problem and it can exchange
- secrets for TSIG via networks.
-
- In various modes of TKEY, a server and a resolver can add or delete a
- secret key be means of TKEY message exchange. However, the existing
- TKEY does not care fully about the management of keys which became
- too old, or dangerous after long time usage.
-
- It is ideal that the number of secret which a pair of hosts share
- should be limited only one, because having too many keys for the same
- purpose might not only be a burden to resolvers for managing and
- distinguishing according to servers to query, but also does not seem
- to be safe in terms of storage and protection against attackers.
- Moreover, perhaps holding old keys long time might give attackers
- chances to compromise by scrupulous calculation.
-
- Therefore, when a new shared secret is established by TKEY, the
- previous old secret should be revoked immediately. To accomplish
- this, DNS servers must support a protocol for key renewal. This
- document specifies procedure to refresh secret keys between two hosts
- which is defined within the framework of TKEY, and it is called "TKEY
- Secret Key Renewal Mode".
-
- The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and
- "OPTIONAL" in this document are to be interpreted as described in
- [RFC2119].
-
-
-1.1. Defined Words
-
- * Inception Time: Beginning of the shared secret key lifetime. This
- value is determined when the key is generated.
-
- * Expiry Limit: Time limit of the key's validity. This value is
- determined when a new key is generated. After Expiry Limit, server
- and client (resolver) must not authenticate TSIG signed with the key.
- Therefore, Renewal to the next key should be carried out before
- Expiry Limit.
-
- * Partial Revocation Time: Time when server judges the key is too old
-
-
-
-Kamite, et. al. [Page 3]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- and must be updated. It must be between Inception Time and Expiry
- Limit. This value is determined by server freely following its
- security policy. e.g., If the time from Inception to Partial
- Revocation is short, renewal will be carried out more often, which
- might be safer.
-
- * Revocation Time: Time when the key becomes invalid and can be
- removed. This value is not determined in advance because it is the
- actual time when revocation is completed.
-
- * Adoption Time: Time when the new key is adopted as the next key
- formally. After Adoption, the key is valid and server and client can
- generate or verify TSIG making use of it. Adoption Time also means
- the time when it becomes possible to remove the previous key, so
- Revocation and Adoption are usually done at the same time.
-
-
- Partial
- Inception Revocation Revocation Expiry Limit
- | | | |
- |----------------|- - - - - - >>|- (revoked) -|
- | | | |
- previous key | | |
- |- - - -|-------------------->> time
- | | new key
- Inception Adoption
-
-
-1.2. New Format and Assigned Numbers
-
- TSIG
- ERROR = (PartialRevoke), to be defined
-
- TKEY
- Mode = (server assignment for key renewal), to be defined
- Mode = (Diffie-Hellman exchange for key renewal), to be
- defined
- Mode = (resolver assignment for key renewal), to be defined
- Mode = (key adoption), to be defined
-
-
-1.3. Overview of Secret Key Renewal Mode
-
- When a server receives a query from a client signed with a TSIG key,
- It always checks if the present time is within the range of usage
- duration it considers safe. If it is judged that the key is too old,
- i.e., after Partial Revocation Time, the server comes to be in
- Partial Revocation state about the key, and this key is called
-
-
-
-Kamite, et. al. [Page 4]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- partially revoked.
-
- In this state, whenever a client sends a normal query (e.g., question
- about A RR) other than TKEY Renewal request with TSIG signed with the
- old key, the server returns an error message to notify that the time
- to renew has come. This is called "PartialRevoke" error message.
-
- The client which got this error is able to notice that it is
- necessary to refresh the secret. To make a new shared secret, it
- sends a TKEY Renewal request, in which several keying methods are
- available. It can make use of TSIG authentication signed with the
- partially revoked key mentioned above.
-
- After new secret establishment, the client sends a TKEY Adoption
- request for renewal confirmation. This can also be authenticated with
- the partially revoked key. If this is admitted by the server, the new
- key is formally adopted, and at the same time the corresponding old
- secret is invalidated. Then the client can send the first query again
- signed with the new key.
-
- Key renewal procedure is executed based on two-phase commit
- mechanism. The first phase is the TKEY Renewal request and its
- response, which means preparatory confirmation for key update. The
- second phase is Adoption request and its response. If the server gets
- request and client receives the response successfully, they can
- finish renewal process. If any error happens and renewal process
- fails during these phases, client should roll back to the beginning
- of the first phase, and send TKEY Renewal request again. This
- rollback can be done until the Expiry Limit of the key.
-
-
-
-2. Shared Secret Key Renewal
-
- Suppose a server and a client agree to change their TSIG keys
- periodically. Key renewal procedure is defined between two hosts.
-
-2.1. Key Usage Time Check
-
- Whenever a server receives a query with TSIG and can find a key that
- is used for signing it, the server checks its Inception Time, Partial
- Revocation Time and Expiry Limit (this information is usually
- memorized by the server).
-
- When the present time is before Inception Time, the server MUST NOT
- verify TSIG with the key, and server acts the same way as when no
- valid key is found, following [RFC2845].
-
-
-
-
-Kamite, et. al. [Page 5]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- When the present time is equal to Inception Time, or between
- Inception Time and Partial Revocation Time, the behavior of the
- server is the same as when a valid key is found, required in
- [RFC2845].
-
- When the present time is the same as the Partial Revocation Time, or
- between the Partial Revocation Time and Expiry Limit, the server
- comes to be in Partial Revocation state about the TSIG key and
- behaves according to the next section.
-
- When the present time is the same as the Expiry Time or after it, the
- server MUST NOT verify TSIG with the key, and returns error messages
- in the same way as when no valid key is found, following [RFC2845].
-
-
-2.2. Partial Revocation
-
- In Partial Revocation state, we say the server has partially revoked
- the key and the key has become a "partially revoked key".
-
- If server has received a query signed with the partially revoked key
- for TKEY Renewal request (See section 2.3.) or "key adoption" request
- (See section 2.4.), then server does proper process following each
- specification.
-
- If server receives other types of query signed with the partially
- revoked key and the corresponding MAC is verified, then server SHOULD
- return TSIG error message for response whose error code is
- "PartialRevoke" (See section 9.). However, if it is for TKEY key
- deletion request ([RFC2930] 4.2), server MAY process usual deletion
- operation defined therein.
-
- PartialRevoke error messages have the role to inform clients of the
- keys' partial revocation and urge them to send TKEY Renewal requests.
- These error responses MUST be signed with those partial revoked keys
- if the queries are signed with them. They are sent only when the keys
- used for queries' TSIG are found to be partially revoked. If the MAC
- of TSIG cannot be verified with the partially revoked keys, servers
- MUST NOT return PartialRevoke error with MAC, but should return
- another error such as "BADSIG" without MAC; in other words, a server
- informs its key's partial revocation only when the MAC in the
- received query is valid.
-
-
-2.3. Key Renewal Message Exchange
-
- If a client has received a PartialRevoke error and authenticated the
- response based on TSIG MAC, it sends a TKEY query for Key Renewal (in
-
-
-
-Kamite, et. al. [Page 6]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- this document, we call it Renewal request, too.) to the server. The
- request MUST be signed with TSIG or SIG(0) [RFC2931] for
- authentication. If TSIG is selected, the client can sign it with the
- partial revoked key.
-
- Key Renewal can use one of several keying methods which is indicated
- in "Mode" field of TKEY RR, and its message structure is dependent on
- that method.
-
- The server which has received Key Renewal request first tries to
- verify TSIG or SIG(0) accompanying it. If the TSIG is signed and
- verified with the partially revoked key, the request MUST be
- authenticated.
-
- After authentication, server must check existing old key's validity.
- If the partially revoked key indicated in the request TKEY's OldName
- and OldAlgorithm field (See section 2.3.1.) does not really exist at
- the server, "BADKEY" [RFC2845] is given in Error field for response.
- If any other error happens, server returns appropriate error messages
- following the specification described in section 2.5. If there are no
- errors, server returns a Key Renewal answer. This answer MUST be
- signed with TSIG or SIG(0) for authentication.
-
- When this answer is successfully returned and no error is detected by
- client, a new shared secret can be established. The details of
- concrete keying procedure are given in the section 2.5.
-
- As a result of this message exchange, client comes to know the newly
- generated key's attributes such as key's name, Inception Time and
- Expiry Limit. They are decided finally by the server, and are told to
- the client; in particular, however, once the server has decided
- Expiry Limit and returned a response, it should obey the decision as
- far as it can. In other words, they SHOULD NOT change time values for
- checking Expiry Limit in the future without any special reason, such
- as security issue like "Emergency Compulsory Revocation" described in
- section 8.
-
- On the other hand, Partial Revocation Time of this generated key is
- not decided based on the request, and not informed to the client. The
- server can determine any value as long as it is between Inception
- Time and Expiry Limit. However, it is recommended that the period
- from Inception to Partial Revocation should be fixed as the server
- side's configuration or should be set the same as the corresponding
- old key's one.
-
- Note:
- Even after the response is returned to client, possibly server
- sometimes receives another Renewal TKEY request whose OldName
-
-
-
-Kamite, et. al. [Page 7]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- indicates the same partial revoked key. Mostly such messages
- originate in client's resending or rollback because of some kinds
- of errors. In this case, the server processes keying again and
- MUST replace the associated secret with the newest produced
- secret. The secret key produced before comes to be invalid and
- should be removed from memory; this process is called secret
- overwrite. Moreover, This regenerated key's name MUST always be
- different from the one which it overwrites for secret key's
- uniqueness and distinction. See section 6, too.
-
- Even if client sends Key Renewal request though the key described
- in OldName has not been partially revoked yet, server must do
- renewal processes. But at the moment when the server accepts such
- requests with valid authentication, it MUST forcibly consider the
- key is already partially revoked, that is, the key's Partial
- Revocation Time must be changed into the present time (i.e., the
- time when the server receives the request).
-
-2.3.1. TKEY RR structure for Key Renewal
-
- TKEY RR for Key Renewal message has the structure given below. In
- principle, format and definition for each field follows [RFC2930].
- Note that each keying scheme sometimes needs different interpretation
- of RDATA field; for detail, see section 2.5.
-
-
- Field Type Comment
- ------- ------ -------
- NAME domain used for a new key, see below
- TYPE u_int16_t (defined in [RFC2930])
- CLASS u_int16_t (defined in [RFC2930])
- TTL u_int32_t (defined in [RFC2930])
- RDLEN u_int16_t (defined in [RFC2930])
- RDATA:
- Algorithm: domain algorithm for a new key
- Inception: u_int32_t about the keying material
- Expiration: u_int32_t about the keying material
- Mode: u_int16_t scheme for key agreement
- see section 9.
- Error: u_int16_t see description below
- Key Size: u_int16_t see description below
- Key Data: octet-stream
- Other Size: u_int16_t (defined in [RFC2930])
- size of other data
- Other Data: newly defined: see description below
-
-
-
-
-
-
-Kamite, et. al. [Page 8]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- For "NAME" field, both non-root and root name are allowed. It may
- be used for a new key's name in the same manner as [RFC2930] 2.1.
-
- "Algorithm" specifies which algorithm is used for agreed keying
- material, which is used for identification of the next key.
-
- "Inception" and "Expiration" are used for the valid period of
- keying material. The meanings differ somewhat according to whether
- the message is request or answer, and its keying scheme.
-
- "Key Data" has different meanings according to keying schemes.
-
- "Mode" field stores the value in accordance with the keying method,
- and see section 2.5. Servers and clients supporting TKEY Renewal
- method MUST implement "Diffie-Hellman exchange for key renewal"
- scheme. All other modes are OPTIONAL.
-
- "Error" is an extended RCODE which includes "PartialRevoke" value
- too. See section 9.
-
- "Other Data" field has the structure given below. They describe
- attributes of the key to be renewed.
-
- in Other Data filed:
-
- Field Type Comment
- ------- ------ -------
- OldNAME domain name of the old key
- OldAlgorithm domain algorithm of the old key
-
-
- "OldName" indicates the name of the previous key (usually,
- this is partially revoked key's name that client noticed by
- PartialRevoke answer from server), and "OldAlogirthm"
- indicates its algorithm.
-
-
-2.4. Key Adoption
-
-2.4.1. Query for Key Adoption
-
- After receiving a TKEY Renewal answer, the client gets the same
- secret as the server. Then, it sends a TKEY Adoption request. The
- request's question section's QNAME field is the same as the NAME
- filed of TKEY written below. In additional section, there is one TKEY
- RR that has the structure and values described below.
-
-
-
-
-
-Kamite, et. al. [Page 9]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- "NAME" field is the new key's name to be adopted which was already
- generated by Renewal message exchange. "Algorithm" is its algo-
- rithm. "Inception" means the key's Inception Time, and "Expiration"
- means Expiry Limit.
-
- "Mode" field is the value of "key adoption". See section 9.
-
- "Other Data" field in Adoption has the same structure as that of
- Renewal request message. "OldName" means the previous old key, and
- "OldAlogirthm" means its algorithm.
-
- Key Adoption request MUST be signed with TSIG or SIG(0) for
- authentication. The client can sign TSIG with the previous key. Note
- that until Adoption is finished, the new key is treated as invalid,
- thus it cannot be used for authentication immediately.
-
-
-2.4.2. Response for Key Adoption
-
- The server which has received Adoption request, it verifies TSIG or
- SIG(0) accompanying it. If the TSIG is signed with the partially
- revoked key and can be verified, the message MUST be authenticated.
-
- If the next new key indicated by the request TKEY's "NAME" is not
- really present at the server, BADNAME [RFC2845] is given in Error
- field and the error message is returned.
-
- If the next key really exists and it has not been adopted formally
- yet, the server confirms the previous key's existence indicated by
- the "OldName" and "OldAlgorithm" field. If it succeeds, the server
- executes Adoption of the next key and Revocation of the previous key.
- Response message duplicates the request's TKEY RR with NOERROR,
- including "OldName" and "OldAlgorithm" that indicate the revoked key.
-
- If the next key exists but it is already adopted, the server returns
- a response message regardless of the substance of the request TKEY's
- "OldName". In this response, Response TKEY RR has the same data as
- the request's one except as to its "Other Data" that is changed into
- null (i.e., "Other Size" is zero), which is intended for telling the
- client that the previous key name was ignored, and the new key is
- already available.
-
- Client sometimes has to retry Adoption request. Suppose the client
- sent request signed with the partially revoked key, but its response
- did not return successfully (e.g., due to the drop of UDP packet).
- Client will probably retry Adoption request; however, the request
- will be refused in the form of TSIG "BADKEY" error because the
- previous key was already revoked. In this case, client should
-
-
-
-Kamite, et. al. [Page 10]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- retransmit Adoption request signed with the next key, and expect a
- response which has null "Other Data" for confirming the completion of
- renewal.
-
-
-2.5. Keying Schemes
-
- In Renewal message exchanges, there are no limitations as to which
- keying method is actually used. The specification of keying
- algorithms is independent of the general procedure of Renewal that is
- described in section 2.3.
-
- Now this document specifies three algorithms in this section, but
- other future documents can make extensions defining other methods.
-
-
-2.5.1. DH Exchange for Key Renewal
-
- This scheme is defined as an extended method of [RFC2930] 4.1. This
- specification only describes the difference from it and special
- notice; assume that all other points, such as keying material
- computation, are the exactly same as the specification of [RFC2930]
- 4.1.
-
- Query
- In Renewal request for type TKEY with this mode, there is one TKEY
- RR and one KEY RR in the additional information section. KEY RR is
- the client's Diffie-Hellman public key [RFC2539].
-
- QNAME in question section is the same as that of "NAME" field in
- TKEY RR, i.e., it means the requested new key's name.
-
- TKEY "Mode" field stores the value of "DH exchange for key
- renewal". See section 9.
-
- TKEY "Inception" and "Expiration" are those requested for the
- keying material, that is, requested usage period of a new key.
-
- TKEY "Key Data" is used as a random, following [RFC2930] 4.1.
-
- Response
- The server which received this request first verifies the TSIG or
- SIG(0). After authentication, the old key's existence validity is
- checked, following section 2.3. If any incompatible DH key is
- found in the request, "BADKEY" [RFC2845] is given in Error field
- for response. "FORMERR" is given if the query included no DH KEY.
-
- If there are no errors, the server processes a response according
-
-
-
-Kamite, et. al. [Page 11]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- to Diffie-Hellman algorithm and returns the answer. In this
- answer, there is one TKEY RR in answer section and KEY RR(s) in
- additional section.
-
- As long as no error has occurred, all values of TKEY are equal to
- that of the request message except TKEY NAME, TKEY RDLEN, RDATA's
- Inception, Expiration, Key Size and Key Data.
-
- TKEY "NAME" field in the answer specifies the name of newly
- produced key which the client will have to use.
-
- TKEY "Inception" and "Expiration" mean the periods of the produced
- key usage. "Inception" should be set to be the time when the new
- key is actually generated or the time before it, and it will be
- regarded as Inception Time. "Expiration" is determined by the
- server, and it will be regarded as Expiry Limit.
-
- TKEY "Key Data" is used as an additional nonce, following
- [RFC2930] 4.1.
-
- The resolver supplied Diffie-Hellman KEY RR SHOULD be echoed in
- the additional section and a server Diffie-Hellman KEY RR will
- also be present in the answer section, following [RFC2930] 4.1.
-
-
-2.5.2. Server Assigned Keying for Key Renewal
-
- This scheme is defined as an extended method of [RFC2930] 4.4. This
- specification only describes the difference from it and special
- notice; assume that all other points, such as secret encrypting
- method, are the exactly same as the specification of [RFC2930] 4.4.
-
- Query
- In Renewal request for type TKEY with this mode, there is one TKEY
- RR and one KEY RR in the additional information section. KEY RR is
- used in encrypting the response.
-
- QNAME in question section is the same as that of "NAME" field in
- TKEY RR, i.e., it means the requested new key's name.
-
- TKEY "Mode" field stores the value of "server assignment for key
- renewal". See section 9.
-
- TKEY "Inception" and "Expiration" are those requested for the
- keying material, that is, requested usage period of a new key.
-
- TKEY "Key Data" is provided following the specification of
- [RFC2930] 4.4.
-
-
-
-Kamite, et. al. [Page 12]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- Response
- The server which received this request first verifies the TSIG or
- SIG(0). Resolver KEY RR is also authenticated by means of
- verifying that TSIG or SIG(0). After authentication, the old key's
- existence validity is checked, following section 2.3. "FORMERR" is
- given if the query specified no encryption key.
-
- If there are no errors, the server response contains one TKEY RR
- in the answer section, and echoes the KEY RR provided in the query
- in the additional information section.
-
- TKEY "NAME" field in the answer specifies the name of newly
- produced key which the client will have to use.
-
- TKEY "Inception" and "Expiration" mean the periods of the produced
- key usage. "Inception" should be set to be the time when the new
- key is actually generated or the time before it, and it will be
- regarded as Inception Time. "Expiration" is determined by the
- server, and it will be regarded as Expiry Limit.
-
- TKEY "Key Data" is the assigned keying data encrypted under the
- public key in the resolver provided KEY RR, which is the same as
- [RFC2930] 4.4.
-
-
-2.5.3. Resolver Assigned Keying for Key Renewal
-
- This scheme is defined as an extended method of [RFC2930] 4.5. This
- specification only describes the difference from it and special
- notice; assume that all other points, such as secret encrypting
- method, are the exactly same as the specification of [RFC2930] 4.5.
-
- Query
- In Renewal request for type TKEY with this mode, there is one TKEY
- RR and one KEY RR in the additional information section. TKEY RR
- has the encrypted keying material and KEY RR is the server public
- key used to encrypt the data.
-
- QNAME in question section is the same as that of "NAME" field in
- TKEY RR, i.e., it means the requested new key's name.
-
- TKEY "Mode" field stores the value of "resolver assignment for key
- renewal". See section 9.
-
- TKEY "Inception" and "Expiration" are those requested for the
- keying material, that is, requested usage period of a new key.
-
- TKEY "Key Data" is the encrypted keying material.
-
-
-
-Kamite, et. al. [Page 13]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- Response
- The server which received this request first verifies the TSIG or
- SIG(0). After authentication, the old key's existence validity is
- checked, following section 2.3. "FORMERR" is given if the server
- does not have the corresponding private key for the KEY RR that
- was shown in the request.
-
- If there are no errors, the server returns response. The response
- must have a TKEY RR in the answer section to tell the shared key's
- name and its usage time values.
-
- TKEY "NAME" field in the answer specifies the name of newly
- produced key which the client will have to use.
-
- TKEY "Inception" and "Expiration" mean the periods of the produced
- key usage. "Inception" should be set to be the time when the new
- key is actually generated or the time before it, and it will be
- regarded as Inception Time. "Expiration" is determined by the
- server, and it will be regarded as Expiry Limit.
-
-
-2.6. Considerations about Non-compliant Hosts
-
- Key Renewal requests and responses must be exchanged between hosts
- which can understand them and do proper processes. "PartialRevoke"
- error messages will be only ignored if they should be returned to
- non-compliant hosts.
-
- Note that server does not inform actively the necessity of renewal to
- clients, but inform it as responses invoked by client's query.
- Server needs not care whether the "PartialRevoke" errors has reached
- client or not. If client has not received yet because of any reasons
- such as packet drops, it will resend the queries, and finally will be
- able to get "PartialRevoke" information.
-
-
-3. Secret Storage
-
- Every server should keep all secrets and attached information, e.g.,
- Inception Time, Expiry Limit, etc. safely to be able to recover from
- unexpected stop. To accomplish this, formally adopted keys should be
- memorized not only on memory, but also be stored in the form of some
- files. Make sure that this should be protected strongly not to be
- read by others. If possible, they should be stored in encrypted form.
-
-
-
-
-
-
-
-Kamite, et. al. [Page 14]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
-4. Compulsory Key Revocation by Server
-
- There is a rare but possible case that although servers have already
- partially revoked keys, clients do not try to send any Renewal
- requests. If this state continues, in the future it will become the
- time of Expiry Limit. After Expiry Limit, the keys will be expired
- and completely removed, so this is called Compulsory Key Revocation
- by server.
-
- If Expiry Limit is too distant from the Partial Revocation Time, then
- even though very long time passes, clients will be able to refresh
- secrets only if they add TSIG signed with those old partially revoked
- keys into requests, which is not safe.
-
- On the other hand, if Expiry Limit is too close to Partial Revocation
- Time, perhaps clients might not be able to notice their keys' Partial
- Revocation by getting "PartialRevoke" errors.
-
- Therefore, servers should set proper Expiry Limit to their keys,
- considering both their keys' safety, and enough time for clients to
- send requests and process renewal.
-
-
-4.1. Example
-
- It might be ideal to provide both SIG(0) and TSIG as authentication
- methods. For example:
-
- A client and a server start SIG(0) authentication at first, to
- establish TSIG shared keys by means of "Query for Diffie-Hellman
- Exchanged Keying" as described in [RFC2930] 4.1. Once they get
- shared secret, they keep using TSIG for usual queries and
- responses. After a while the server returns a "ParitalRevoke" error
- and they begin a key renewal process. Both TSIG signed with
- partially revoked keys and SIG(0) are okay for authentication, but
- TSIG would be easier to use considering calculation efficiency.
-
- If any troubles should happen such as client host's long suspension
- against expectation, the server will do Compulsory Revocation.
- After recovery if the client sends a key Renewal request to refresh
- the old key, it will fail because the key is removed from the
- server. So, the client will send "Query for Diffie-Hellman
- Exchanged Keying" with SIG(0) to make a new shared key again.
-
-
-
-
-
-
-
-
-Kamite, et. al. [Page 15]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
-5. Special Considerations for Two servers' Case
-
- This section refers to the case where both two hosts are DNS servers
- which can act as full resolvers as well. If one server (called Server
- A) comes to want to refresh a shared key (called "Key A-B"), it will
- await a TKEY Renewal request from the other server (called Server B).
- But perhaps Server A will have to send queries with TSIG immediately
- to Server B to resolve some queries if it is asked by other clients.
-
- At this time, Server A is allowed to send a Renewal request to Server
- B, if Server A finds the key to use now is too old and should be
- renewed. To provide this function, both servers should be able to
- receive and process key renewal request from each other if they agree
- to refresh their shared secret keys.
-
- Note that the initiative in key renewal belongs to Server A because
- it can notice the Partial Revocation Time and decide key renewal. If
- Server B has information about Partial Revocation Time as well, it
- can also decide for itself to send Renewal request to Server A. But
- it is not essential for both two servers have information about key
- renewal timing.
-
-
-5.1. To Cope with Collisions of Renewal Requests
-
- At least one of two hosts which use Key Renewal must know their key
- renewal information such as Partial Revocation Time. It is okay that
- both hosts have it.
-
- Provided that both two servers know key renewal timing information,
- there is possibility for them to begin partial revocation and sending
- Renewal requests to each other at the same time. Such collisions will
- not happen so often because Renewal requests are usually invoked when
- hosts want to send queries, but it is possible.
-
- When one of two servers try to send Renewal requests, it must protect
- old secrets that it has partially revoked and prevent it from being
- refreshed by any requests from the other server (i.e., it must lock
- the old secret during the process of renewal). While the server is
- sending Renewal requests and waiting responses, it ignores the other
- server's Renewal requests.
-
- Therefore, servers might fail to change secrets by means of their own
- requests to others. After failure they will try to resend, but they
- should wait for random delays by the next retries. If they get any
- Renewal requests from others while they are waiting, their shared
- keys may be refreshed, then they do not need to send any Renewal
- requests now for themselves.
-
-
-
-Kamite, et. al. [Page 16]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
-6. Key Name Considerations
-
- Since both servers and clients have only to distinguish new secrets
- and old ones, keys' names do not need to be specified strictly. But
- it is recommended that some serial number or key generation time
- should be added to the name and that the names of keys between the
- same pair of hosts should have some common labels among their keys.
- For example, suppose A.example.com. and B.example.com. share the key
- "<serial number>.A.example.com.B.example.com." such as
- "10010.A.example.com.B.example.com.". After key renewal, they change
- their secret and name into "10011.A.example.com.B.example.com." If
- secret overwrite occurs as a result of client's retransmission,
- server must change the next key's name somehow; for example, server
- increases serial number forcibly, or add some random numbers to the
- name.
-
- Servers and clients must be able to use keys properly according to
- servers to query. Because TSIG secret keys themselves do not have any
- particular IDs to be distinguished and would be identified by their
- names and algorithm, it must be understood correctly what keys are
- refreshed.
-
-
-7. Example Usage of Secret Key Renewal Mode
-
- This is an example of Renewal mode usage where a Server,
- server.example.com, and a Client, client.exmple.com have an initial
- shared secret key named "00.client.example.com.server.example.com".
-
- (1) The time values about key
- "00.client.example.com.server.example.com" was set as follows:
- Inception Time is at 6:00, Expiry Limit is at 11:00.
-
- (2) At Server, a time value about renewal timing has been set too:
- Partial Revocation Time is at 8:00.
-
- (3) Suppose the present time is 7:00. If Client sends a query
- signed with key "00.client.example.com.server.example.com" to ask
- the IP address of "www.somedomain.com", finally it will get a
- proper answer from Server with valid TSIG (NOERROR).
-
- (4) At 9:00. Client sends a query signed with key
- "00.client.example.com.server.example.com" to ask the IP address of
- "www.otherdomain.com". But it will not get a proper answer from
- Server. The response does not have any IP address information about
- "www.otherdomain.com". Instead, it includes valid TSIG MAC signed
- with "00.client.example.com.server.example.com", and its Error Code
- indicates PartialRevoke.
-
-
-
-Kamite, et. al. [Page 17]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- (5) At 9:01. Client sends a Renewal request to Server. This request
- is signed with key "00.client.example.com.server.example.com". It
- includes data such as:
-
- Question Section:
- QNAME = 01.client.example.com. (Client can set this freely)
- TYPE = TKEY
-
- Additional Section:
- 01.client.example.com. TKEY
- Algorithm = hmac-md5-sig-alg.reg.int.
- Inception = (value which means 8:55)
- Expiration = (value which means 14:00)
- Mode = (DH exchange for key renewal)
- OldName = 00.client.example.com.server.example.com.
- OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
- Additional Section also contains a KEY RR for DH and a TSIG RR.
-
- (6) As soon as Server receives this request, it verifies TSIG. It
- is signed with the partially revoked key
- "00.client.example.com.server.example.com". and Server accepts the
- request. It creates a new key by Diffie-Hellman calculation and
- returns an answer which includes data such as:
-
- Answer Section:
- 01.client.example.com.server.example.com. TKEY
- Algorithm = hmac-md5-sig-alg.reg.int.
- Inception = (value meaning 8:55)
- Expiration = (value meaning 14:00)
- Mode = (DH exchange for key renewal)
- OldName = 00.client.example.com.server.example.com.
- OldAlgorithm = hmac-md5-sig-alg.reg.int.
- Answer Section also contains KEY RRs for DH.
-
- Additional Section also contains a TSIG RR.
- This response is signed with key
- "00.client.example.com.server.example.com" without error.
-
- At the same time, Server decides to set the Partial Revocation Time
- of this new key "01.client.example.com.server.example.com." as
- 11:00.
-
- (7) Client gets the response and checks TSIG MAC, and calculates
- Diffie-Hellman. It will get a new key, and it has been named
- "01.client.example.com.server.example.com" by Server.
-
-
-
-
-
-Kamite, et. al. [Page 18]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- (8) At 9:02. Client sends an Adoption request to Server. This
- request is signed with the previous key
- "00.client.example.com.server.example.com". It includes:
-
- Question Section:
- QNAME = 01.client.example.com.server.example.com.
- TYPE = TKEY
-
- Additional Section:
- 01.client.example.com.server.example.com. TKEY
- Algorithm = hmac-md5-sig-alg.reg.int.
- Inception = (value which means 8:55)
- Expiration = (value which means 14:00)
- Mode = (key adoption)
- OldName = 00.client.example.com.server.example.com.
- OldAlgorithm = hmac-md5-sig-alg.reg.int.
-
- Additional Section also contains a TSIG RR.
-
- (9) Server verifies the query's TSIG. It is signed with the
- previous key and authenticated. It returns a response whose TKEY RR
- is the same as the request's one. The response is signed with key
- "00.client.example.com.server.example.com.". As soon as the
- response is sent, Server revokes and removes the previous key. At
- the same time, key "01.client.example.com.server.example.com." is
- validated.
-
- (10) Client acknowledges the success of Adoption by receiving the
- response. Then, it will retry to send an original question about
- "www.otherdomain.com". It is signed with the adopted key
- "01.client.example.com.server.example.com", so Server authenticates
- it and returns an answer.
-
- (11) This key is used until 11:00. After that, it will be partially
- revoked again.
-
-
-8. Security Considerations
-
- This document considers about how to refresh shared secret. Secret
- changed by this method is used at servers in support of TSIG
- [RFC2845].
-
- [RFC2104] says that current attacks to HMAC do not indicate a
- specific recommended frequency for key changes but periodic key
- refreshment is a fundamental security practice that helps against
- potential weaknesses of the function and keys, and limits the damage
- of an exposed key. TKEY Secret Key Renewal provides the method of
-
-
-
-Kamite, et. al. [Page 19]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
- periodical key refreshment.
-
- TKEY Secret Key Renewal forbids clients to send queries as long as
- they do not change old keys. This means that when keys become old,
- clients must spend rather lots of time to get answers they wanted
- originally because at first they must send key Renewal requests. Thus
- the usage period of secrets should be considered carefully based on
- both TKEY processing performance and security.
-
- This document specifies the procedure of periodical key renewal, but
- actually there is possibility for servers to have no choice other
- than revoking their secret keys immediately especially when the keys
- are found to be compromised by attackers. This is called "Emergency
- Compulsory Revocation". For example, suppose the original Expiry
- Limit was set at 15:00, Partial Revocation Time at 12:00 and
- Inception Time at 10:00. if at 11:00 the key is found to be
- compromised, the server sets Expiry Limit forcibly to be 11:00 or
- before it.
-
- Consequently, once Compulsory Revocation (See section 4.) is carried
- out, normal renewal process described in this document cannot be done
- any more as far as the key is concerned. But, after such accidents
- happened, the two hosts are able to establish secret keys and begin
- renewal procedure only if they have other (non-compromised) shared
- TSIG keys or safe SIG(0) keys for the authentication of initial
- secret establishment such as Diffie-Hellman Exchanged Keying.
-
-
-9. IANA Considerations
-
- IANA needs to allocate a value for "DH exchange for key renewal",
- "server assignment for key renewal", "resolver assignment for key
- renewal" and "key adoption" in the mode filed of TKEY. It also needs
- to allocate a value for "PartialRevoke" from the extended RCODE
- space.
-
-
-10. References
-
-[RFC2104]
- H. Krawczyk, M.Bellare, R. Canetti, "Keyed-Hashing for Message
- Authentication", RFC2104, February 1997.
-
-[RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, March 1997.
-
-
-
-
-
-Kamite, et. al. [Page 20]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
-[RFC2539]
- D. Eastlake 3rd, "Storage of Diffie-Hellman Keys in the Domain Name
- System (DNS)", RFC 2539, March 1999.
-
-[RFC2845]
- Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845,
- May 2000.
-
-[RFC2930]
- D. Eastlake 3rd, ``Secret Key Establishment for DNS (TKEY RR)'',
- RFC 2930, September 2000.
-
-[RFC2931]
- D. Eastlake 3rd, "DNS Request and Transaction Signatures (SIG(0)s
- )", RFC 2931, September 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al. [Page 21]
-\f
-INTERNET-DRAFT Mar. 2003
-
-
-Authors' Addresses
-
- Yuji Kamite
- NTT Communications Corporation
- Innovative IP Architecture Center,
- Tokyo Opera City Tower 21F,
- 20-2, 3-chome, Nishi-Shinjuku, Shinjuku-ku,
- Tokyo, 163-1421, Japan.
- EMail: y.kamite@ntt.com
-
-
- Masaya Nakayama
- The University of Tokyo
- Information Technology Center,
- 2-11-16 Yayoi, Bunkyo-ku,
- Tokyo, 113-8658, Japan.
- EMail: nakayama@nc.u-tokyo.ac.jp
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kamite, et. al. [Page 22]
-\f
+++ /dev/null
-
-INTERNET-DRAFT Andreas Gustafsson
-draft-ietf-dnsext-unknown-rrs-05.txt Nominum Inc.
- March 2003
-
-Updates: RFC 1034, RFC 2163, RFC 2535
-
-
-
- Handling of Unknown DNS Resource Record Types
-
-
-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
-
- Extending the Domain Name System with new Resource Record (RR) types
- currently requires changes to name server software. This document
- specifies the changes necessary to allow future DNS implementations
- to handle new RR types transparently.
-
-1. Introduction
-
- The DNS is designed to be extensible to support new services through
- the introduction of new resource record (RR) types. In practice,
- deploying a new RR type currently requires changes to the name server
- software not only at the authoritative DNS server that is providing
- the new information and the client making use of it, but also at all
- slave servers for the zone containing it, and in some cases also at
- caching name servers and forwarders used by the client.
-
-
-
-Expires September 2003 [Page 1]
-\f
-draft-ietf-dnsext-unknown-rrs-05.txt March 2003
-
-
- Because the deployment of new server software is slow and expensive,
- the potential of the DNS in supporting new services has never been
- fully realized. This memo proposes changes to name servers and to
- procedures for defining new RR types aimed at simplifying the future
- deployment of new RR types.
-
- 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. Definition
-
- An "RR of unknown type" is an RR whose RDATA format is not known to
- the DNS implementation at hand, such that it cannot be converted to a
- type-specific text format, compressed, or otherwise handled in a
- type-specific way, and whose type is not an assigned QTYPE or Meta-
- TYPE in RFC2929 section 3.1 nor within the range reserved in that
- section for assignment only to QTYPEs and Meta-TYPEs.
-
- In the case of a type whose RDATA format is class specific, an RR is
- considered to be of unknown type when the RDATA format for that
- combination of type and class is not known.
-
-3. Transparency
-
- To enable new RR types to be deployed without server changes, name
- servers and resolvers MUST handle RRs of unknown type transparently.
- That is, they must treat the RDATA section of such RRs as
- unstructured binary data, storing and transmitting it without change
- [RFC1123].
-
- To ensure the correct operation of equality comparison (section 6)
- and of the DNSSEC canonical form (section 7) when an RR type is known
- to some but not all of the servers involved, servers MUST also
- exactly preserve the RDATA of RRs of known type, except for changes
- due to compression or decompression where allowed by section 4 of
- this memo. In particular, the character case of domain names that
- are not subject to compression MUST be preserved.
-
-4. Domain Name Compression
-
- RRs containing compression pointers in the RDATA part cannot be
- treated transparently, as the compression pointers are only
- meaningful within the context of a DNS message. Transparently
- copying the RDATA into a new DNS message would cause the compression
- pointers to point at the corresponding location in the new message,
- which now contains unrelated data. This would cause the compressed
- name to be corrupted.
-
-
-
-Expires September 2003 [Page 2]
-\f
-draft-ietf-dnsext-unknown-rrs-05.txt March 2003
-
-
- To avoid such corruption, servers MUST NOT compress domain names
- embedded in the RDATA of types that are class-specific or not well-
- known. This requirement was stated in RFC1123 without defining the
- term "well-known"; it is hereby specified that only the RR types
- defined in RFC1035 are to be considered "well-known".
-
- The specifications of a few existing RR types have explicitly allowed
- compression contrary to this specification: RFC2163 specified that
- compression applies to the PX RR, and RFC2535 allowed compression in
- SIG RRs and NXT RRs records. Since this specification disallows
- compression in these cases, it is an update to RFC2163 (section 4)
- and RFC2535 (sections 4.1.7 and 5.2).
-
- Receiving servers MUST decompress domain names in RRs of well-known
- type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
- NXT, NAPTR, and SRV (although the current specification of the SRV RR
- in RFC2782 prohibits compression, RFC2052 mandated it, and some
- servers following that earlier specification are still in use).
-
- Future specifications for new RR types that contain domain names
- within their RDATA MUST NOT allow the use of name compression for
- those names, and SHOULD explicitly state that the embedded domain
- names MUST NOT be compressed.
-
- As noted in RFC1123, the owner name of an RR is always eligible for
- compression.
-
-5. Text Representation
-
- In the "type" field of a master file line, an unknown RR type is
- represented by the word "TYPE" immediately followed by the decimal RR
- type number, with no intervening whitespace. In the "class" field,
- an unknown class is similarly represented as the word "CLASS"
- immediately followed by the decimal class number.
-
- This convention allows types and classes to be distinguished from
- each other and from TTL values, allowing the "[<TTL>] [<class>]
- <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
- RFC1035 to both be unambiguously parsed.
-
- The RDATA section of an RR of unknown type is represented as a
- sequence of white space separated words as follows:
-
- The special token \# (a backslash immediately
- followed by a hash sign), which identifies the
- RDATA as having the generic encoding defined
- herein rather than a traditional type-specific
- encoding.
-
-
-
-Expires September 2003 [Page 3]
-\f
-draft-ietf-dnsext-unknown-rrs-05.txt March 2003
-
-
- An unsigned decimal integer specifying the
- RDATA length in octets.
-
- Zero or more words of hexadecimal data encoding
- the actual RDATA field, each containing an even
- number of hexadecimal digits.
-
- If the RDATA is of zero length, the text representation contains only
- the \# token and the single zero representing the length.
-
- An implementation MAY also choose to represent some RRs of known type
- using the above generic representations for the type, class and/or
- RDATA, which carries the benefit of making the resulting master file
- portable to servers where these types are unknown. Using the generic
- representation for the RDATA of an RR of known type can also be
- useful in the case of an RR type where the text format varies
- depending on a version, protocol, or similar field (or several)
- embedded in the RDATA when such a field has a value for which no text
- format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
- 0.
-
- Even though an RR of known type represented in the \# format is
- effectively treated as an unknown type for the purpose of parsing the
- RDATA text representation, all further processing by the server MUST
- treat it as a known type and take into account any applicable type-
- specific rules regarding compression, canonicalization, etc.
-
- The following are examples of RRs represented in this manner,
- illustrating various combinations of generic and type-specific
- encodings for the different fields of the master file format:
-
- a.example. CLASS32 TYPE731 \# 6 abcd (
- ef 01 23 45 )
- b.example. HS TYPE62347 \# 0
- e.example. IN A \# 4 0A000001
- e.example. CLASS1 TYPE1 10.0.0.2
-
-6. Equality Comparison
-
- Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
- to be compared for equality. Two RRs of the same unknown type are
- considered equal when their RDATA is bitwise equal. To ensure that
- the outcome of the comparison is identical whether the RR is known to
- the server or not, specifications for new RR types MUST NOT specify
- type-specific comparison rules.
-
- This implies that embedded domain names, being included in the
- overall bitwise comparison, are compared in a case-sensitive manner.
-
-
-
-Expires September 2003 [Page 4]
-\f
-draft-ietf-dnsext-unknown-rrs-05.txt March 2003
-
-
- As a result, when a new RR type contains one or more embedded domain
- names, it is possible to have multiple RRs owned by the same name
- that differ only in the character case of the embedded domain
- name(s). This is similar to the existing possibility of multiple TXT
- records differing only in character case, and not expected to cause
- any problems in practice.
-
-7. DNSSEC Canonical Form and Ordering
-
- DNSSEC defines a canonical form and ordering for RRs [RFC2535,
- section 8.1]. In that canonical form, domain names embedded in the
- RDATA are converted to lower case.
-
- The downcasing is necessary to ensure the correctness of DNSSEC
- signatures when case distinctions in domain names are lost due to
- compression, but since it requires knowledge of the presence and
- position of embedded domain names, it cannot be applied to unknown
- types.
-
- To ensure continued consistency of the canonical form of RR types
- where compression is allowed, and for continued interoperability with
- existing implementations that already implement the RFC2535 canonical
- form and apply it to their known RR types, the canonical form remains
- unchanged for all RR types whose whose initial publication as an RFC
- was prior to the initial publication of this specification as an RFC
- (RFC TBD).
-
- As a courtesy to implementors, it is hereby noted that the complete
- set of such previously published RR types that contain embedded
- domain names, and whose DNSSEC canonical form therefore involves
- downcasing according to the DNS rules for character comparisons,
- consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
- HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
- DNAME, and A6.
-
- This document specifies that for all other RR types (whether treated
- as unknown types or treated as known types according to an RR type
- definition RFC more recent than than RFC TBD), the canonical form is
- such that no downcasing of embedded domain names takes place, and
- otherwise identical to the canonical form specified in RFC2535
- section 8.1.
-
- Note that the owner name is always set to lower case according to the
- DNS rules for character comparisons, regardless of the RR type.
-
- The DNSSEC canonical RR ordering is as specified in RFC2535 section
- 8.3, where the octet sequence is the canonical form as revised by
- this specification.
-
-
-
-Expires September 2003 [Page 5]
-\f
-draft-ietf-dnsext-unknown-rrs-05.txt March 2003
-
-
-8. Additional Section Processing
-
- Unknown RR types cause no additional section processing. Future RR
- type specifications MAY specify type-specific additional section
- processing rules, but any such processing MUST be optional as it can
- only be performed by servers for which the RR type in case is known.
-
-9. IANA Considerations
-
- The IANA is hereby requested to verify that specifications for new RR
- types requesting an RR type number comply with this specification.
- In particular, the IANA MUST NOT assign numbers to new RR types whose
- specification allows embedded domain names to be compressed.
-
-10. Security Considerations
-
- This specification is not believed to cause any new security
- problems, nor to solve any existing ones.
-
-Normative References
-
- [RFC1034] - Domain Names - Concepts and Facilities, P. Mockapetris,
- November 1987.
-
- [RFC1035] - Domain Names - Implementation and Specifications, P.
- Mockapetris, November 1987.
-
- [RFC1123] - Requirements for Internet Hosts -- Application and
- Support, R. Braden, Editor, October 1989.
-
- [RFC2119] - Key words for use in RFCs to Indicate Requirement Levels,
- S. Bradner, BCP 14, March 1997.
-
- [RFC2535] - Domain Name System Security Extensions. D. Eastlake,
- March 1999.
-
- [RFC2613] - Using the Internet DNS to Distribute MIXER Conformant
- Global Address Mapping (MCGAM), C. Allocchio, January 1998.
-
- [RFC2929] - Domain Name System (DNS) IANA Considerations, D.
- Eastlake, E. Brunner-Williams, B. Manning, September 2000.
-
-Non-normative References
-
- [RFC1876] - A Means for Expressing Location Information in the Domain
- Name System, C. Davis, P. Vixie, T. Goodwin, I. Dickinson, January
- 1996.
-
-
-
-
-Expires September 2003 [Page 6]
-\f
-draft-ietf-dnsext-unknown-rrs-05.txt March 2003
-
-
- [RFC2052] - A DNS RR for specifying the location of services (DNS
- SRV), A. Gulbrandsen, P. Vixie, October 1996. Obsoleted by RFC2782.
-
- [RFC2136] - Dynamic Updates in the Domain Name System (DNS UPDATE),
- P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997.
-
- [RFC2782] - A DNS RR for specifying the location of services (DNS
- SRV), A. Gulbrandsen, P. Vixie, L. Esibov, February 2000.
-
-Author's Address
-
- Andreas Gustafsson
- Nominum Inc.
- 2385 Bay Rd
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 381 6004
-
- Email: gson@nominum.com
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001 - 2002). 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 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
-
-
-
-Expires September 2003 [Page 7]
-\f
-draft-ietf-dnsext-unknown-rrs-05.txt March 2003
-
-
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to pertain
- to the implementation or use of the technology described in this
- document or the extent to which any license under such rights might or
- might not be available; neither does it represent that it has made any
- effort to identify any such rights. Information on the IETF's
- procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such proprietary
- rights by implementors or users of this specification can be obtained
- from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires September 2003 [Page 8]
-\f
-
+++ /dev/null
-DNSEXT WG Edward Lewis
-INTERNET DRAFT NAI Labs
-Category:I-D September 19, 2000
-
- DNS Security Extension Clarification on Zone Status
- <draft-ietf-dnsext-zone-status-03.txt>
-
-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 DNSEXT WG mailing list
-namedroppers@ops.ietf.org.
-
-This draft expires on March, 19, 2001.
-
-Copyright Notice
-
-Copyright (C) The Internet Society (1999, 2000). All rights reserved.
-
-Abstract
-
-The definition of a secured zone is presented, clarifying and updating
-sections of RFC 2535. RFC 2535 defines a zone to be secured based on a
-per algorithm basis, e.g., a zone can be secured with RSA keys, and
-not secured with DSA keys. This document changes this to define a
-zone to be secured or not secured regardless of the key algorithm used
-(or not used). To further simplify the determination of a zone's
-status, "experimentally secure" status is deprecated.
-
-1 Introduction
-
-Whether a DNS zone is "secured" or not is a question asked in at least
-four contexts. A zone administrator asks the question when
-configuring a zone to use DNSSEC. A dynamic update server asks the
-question when an update request arrives, which may require DNSSEC
-processing. A delegating zone asks the question of a child zone when
-the parent enters data indicating the status the child. A resolver
-asks the question upon receipt of data belonging to the zone.
-
-
-Expires March 19, 2001 [Page 1]
-\fInternet Draft September 19, 2000
-
-1.1 When a Zone's Status is Important
-
-A zone administrator needs to be able to determine what steps are
-needed to make the zone as secure as it can be. Realizing that due to
-the distributed nature of DNS and its administration, any single zone
-is at the mercy of other zones when it comes to the appearance of
-security. This document will define what makes a zone qualify as
-secure.
-
-A name server performing dynamic updates needs to know whether a zone
-being updated is to have signatures added to the updated data, NXT
-records applied, and other required processing. In this case, it is
-conceivable that the name server is configured with the knowledge, but
-being able to determine the status of a zone by examining the data is
-a desirable alternative to configuration parameters.
-
-A delegating zone is required to indicate whether a child zone is
-secured. The reason for this requirement lies in the way in which a
-resolver makes its own determination about a zone (next paragraph). To
-shorten a long story, a parent needs to know whether a child should be
-considered secured. This is a two part question. Under what
-circumstances does a parent consider a child zone to be secure, and
-how does a parent know if the child conforms?
-
-A resolver needs to know if a zone is secured when the resolver is
-processing data from the zone. Ultimately, a resolver needs to know
-whether or not to expect a usable signature covering the data. How
-this determination is done is out of the scope of this document,
-except that, in some cases, the resolver will need to contact the
-parent of the zone to see if the parent states that the child is
-secured.
-
-1.2 Islands of Security
-
-The goal of DNSSEC is to have each zone secured, from the root zone
-and the top-level domains down the hierarchy to the leaf zones.
-Transitioning from an unsecured DNS, as we have now, to a fully
-secured - or "as much as will be secured" - tree will take some time.
-During this time, DNSSEC will be applied in various locations in the
-tree, not necessarily "top down."
-
-For example, at a particular instant, the root zone and the "test."
-TLD might be secured, but region1.test. might not be. (For reference,
-let's assume that region2.test. is secured.) However,
-subarea1.region1.test. may have gone through the process of becoming
-secured, along with its delegations. The dilemma here is that
-subarea1 cannot get its zone keys properly signed as its parent zone,
-region1, is not secured.
-
-The colloquial phrase describing the collection of contiguous secured
-zones at or below subarea1.region1.test. is an "island of security."
-The only way in which a DNSSEC resolver will come to trust any data
-from this island is if the resolver is pre-configured with the zone
-key(s) for subarea1.region1.test., i.e., the root of the island of
-
-Expires March 19, 2001 [Page 2]
-\fInternet Draft September 19, 2000
-
-security. Other resolvers (not so configured) will recognize this
-island as unsecured.
-
-An island of security begins with one zone whose public key is
-pre-configured in resolvers. Within this island are subzones which
-are also secured. The "bottom" of the island is defined by
-delegations to unsecured zones. One island may also be on top of
-another - meaning that there is at least one unsecured zone between
-the bottom of the upper island and the root of the lower secured
-island.
-
-Although both subarea1.region1.test. and region2.test. have both been
-properly brought to a secured state by the administering staff, only
-the latter of the two is actually "globally" secured - in the sense
-that all DNSSEC resolvers can and will verify its data. The former,
-subarea1, will be seen as secured by a subset of those resolvers, just
-those appropriately configured. This document refers to such zones as
-being "locally" secured.
-
-In RFC 2535, there is a provision for "certification authorities,"
-entities that will sign public keys for zones such as subarea1. There
-is another draft, [SIGAUTH], that restricts this activity. Regardless
-of the other draft, resolvers would still need proper configuration to
-be able to use the certification authority to verify the data for the
-subarea1 island.
-
-1.2.1 Determing the closest security root
-
-Given a domain, in order to determine whether it is secure or not, the
-first step is to determine the closest security root. The closest
-security root is the top of an island of security whose name has the
-most matching (in order from the root) right-most labels to the given
-domain.
-
-For example, given a name "sub.domain.testing.signed.exp.test.", and
-given the secure roots "exp.test.", "testing.signed.exp.test." and
-"not-the-same.xy.", the middle one is the closest. The first secure
-root shares 2 labels, the middle 4, and the last 0.
-
-The reason why the closest is desired is to eliminate false senses of
-insecurity becuase of a NULL key. Continuing with the example, the
-reason both "testing..." and "exp.test." are listed as secure root is
-presumably because "signed.exp.test." is unsecured (has a NULL key).
-If we started to descend from "exp.test." to our given domain
-(sub...), we would encounter a NULL key and conclude that sub... was
-unsigned. However, if we descend from "testing..." and find keys
-"domain...." then we can conclude that "sub..." is secured.
-
-Note that this example assumes one-label deep zones, and assumes that
-we do not configure overlapping islands of security. To be clear, the
-definition given should exclude "short.xy.test." from being a closest
-security root for "short.xy." even though 2 labels match.
-
-Overlapping islands of security introduce no conceptually interesting
-
-Expires March 19, 2001 [Page 3]
-\fInternet Draft September 19, 2000
-
-ideas and do not impact the protocol in anyway. However, protocol
-implementers are advised to make sure their code is not thrown for a
-loop by overlaps. Overlaps are sure to be configuration problems as
-islands of security grow to encompass larger regions of the name
-space.
-
-1.3 Parent Statement of Child Security
-
-In 1.1 of this document, there is the comment "the parent states that
-the child is secured." This has caused quite a bit of confusion.
-
-The need to have the parent "state" the status of a child is derived
-from the following observation. If you are looking to see if an
-answer is secured, that it comes from an "island of security" and is
-properly signed, you must begin at the (appropriate) root of the
-island of security.
-
-To find the answer you are inspecting, you may have to descend through
-zones within the island of security. Beginning with the trusted root
-of the island, you descend into the next zone down. As you trust the
-upper zone, you need to get data from it about the next zone down,
-otherwise there is a vulnerable point in which a zone can be hijacked.
-When or if you reach a point of traversing from a secured zone to an
-unsecured zone, you have left the island of security and should
-conclude that the answer is unsecured.
-
-However, in RFC 2535, section 2.3.4, these words seem to conflict with
-the need to have the parent "state" something about a child:
-
- There MUST be a zone KEY RR, signed by its superzone, for every
- subzone if the superzone is secure. This will normally appear in
- the subzone and may also be included in the superzone. But, in
- the case of an unsecured subzone which can not or will not be
- modified to add any security RRs, a KEY declaring the subzone
- to be unsecured MUST appear with the superzone signature in the
- superzone, if the superzone is secure.
-
-The confusion here is that in RFC 2535, a secured parent states that a
-child is secured by SAYING NOTHING ("may also be" as opposed to "MUST
-also be"). This is counter intuitive, the fact that an absence of
-data means something is "secured." This notion, while acceptable in a
-theoretic setting has met with some discomfort in an operation
-setting. However, the use of "silence" to state something does indeed
-work in this case, so there hasn't been sufficient need demonstrated
-to change the definition.
-
-1.4 Impact on RFC 2535
-
-This document updates sections of RFC 2535. The definition of a
-secured zone is an update to section 3.4 of the RFC. Section 3.4 is
-updated to eliminate the definition of experimental keys and
-illustrate a way to still achieve the functionality they were designed
-to provide. Section 3.1.3 is updated by the specifying the value of
-the protocol octet in a zone key.
-
-Expires March 19, 2001 [Page 4]
-\fInternet Draft September 19, 2000
-
-1.5 "MUST" and other key words
-
-The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
-in this document are to be interpreted as described in [RFC 2119].
-Currently, only "MUST" is used in this document.
-
-2 Status of a Zone
-
-In this section, rules governing a zone's DNSSEC status are presented.
-There are three levels of security defined: global, local, and
-unsecured. A zone is globally secure when it complies with the
-strictest set of DNSSEC processing rules. A zone is locally secured
-when it is configured in such a way that only resolvers that are
-appropriately configured see the zone as secured. All other zones are
-unsecured.
-
-Note: there currently is no document completely defining DNSSEC
-verification rules. For the purposes of this document, the strictest
-rules are assumed to state that the verification chain of zone keys
-parallels the delegation tree up to the root zone. (See 2.b below.)
-This is not intended to disallow alternate verification paths, just to
-establish a baseline definition.
-
-To avoid repetition in the rules below, the following terms are
-defined.
-
-2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01
-for name type (indicating a zone key) and either value 00 or value 01
-for key type (indicating a key permitted to authenticate data). (See
-RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value
-of DNSSEC (3) or ALL (255).
-
-The definition updates RFC 2535's definition of a zone key. The
-requirement that the protocol field be either DNSSEC or ALL is a new
-requirement, a change to section 3.1.3.)
-
-2.b On-tree Validation - The authorization model in which only the
-parent zone is recognized to supply a DNSSEC-meaningful signature that
-is used by a resolver to build a chain of trust from the child's keys
-to a recognized root of security. The term "on-tree" refers to
-following the DNS domain hierarchy (upwards) to reach a trusted key,
-presumably the root key if no other key is available. The term
-"validation" refers to the digital signature by the parent to prove
-the integrity, authentication and authorization of the child' key to
-sign the child's zone data.
-
-2.c Off-tree Validation - Any authorization model that permits domain
-names other than the parent's to provide a signature over a child's
-zone keys that will enable a resolver to trust the keys.
-
-2.1 Globally Secured
-
-A globally secured zone, in a nutshell, is a zone that uses only
-mandatory to implement algorithms (RFC 2535, section 3.2) and relies
-
-Expires March 19, 2001 [Page 5]
-\fInternet Draft September 19, 2000
-
-on a key certification chain that parallels the delegation tree
-(on-tree validation). Globally secured zones are defined by the
-following rules.
-
-2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least
-one zone signing KEY RR (2.a) of a mandatory to implement algorithm in
-the set.
-
-2.1.b. The zone's apex KEY RR set MUST be signed by a private key
-belonging to the parent zone. The private key's public companion MUST
-be a zone signing KEY RR (2.a) of a mandatory to implement algorithm
-and owned by the parent's apex.
-
-If a zone cannot get a conforming signature from the parent zone, the
-child zone cannot be considered globally secured. The only exception
-to this is the root zone, for which there is no parent zone.
-
-2.1.c. NXT records MUST be deployed throughout the zone. (Clarifies
-RFC 2535, section 2.3.2.) Note: there is some operational discomfort
-with the current NXT record. This requirement is open to modification
-when two things happen. First, an alternate mechanism to the NXT is
-defined and second, a means by which a zone can indicate that it is
-using an alternate method.
-
-2.1.d. Each RR set that qualifies for zone membership MUST be signed
-by a key that is in the apex's KEY RR set and is a zone signing KEY RR
-(2.a) of a mandatory to implement algorithm. (Updates 2535, section
-2.3.1.)
-
-Mentioned earlier, the root zone is a special case. The root zone
-will be considered to be globally secured provided that if conforms to
-the rules for locally secured, with the exception that rule 2.1.a. be
-also met (mandatory to implement requirement).
-
-2.2 Locally Secured
-
-The term "locally" stems from the likely hood that the only resolvers
-to be configured for a particular zone will be resolvers "local" to an
-organization.
-
-A locally secured zone is a zone that complies with rules like those
-for a globally secured zone with the following exceptions. The
-signing keys may be of an algorithm that is not mandatory to implement
-and/or the verification of the zone keys in use may rely on a
-verification chain that is not parallel to the delegation tree
-(off-tree validation).
-
-2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least
-one zone signing KEY RR (2.a) in the set.
-
-2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
-one of the following two subclauses MUST hold true.
-
-
-
-Expires March 19, 2001 [Page 6]
-\fInternet Draft September 19, 2000
-
-2.2.b.1 The private key's public companion MUST be pre-configured in
-all the resolvers of interest.
-
-2.2.b.2 The private key's public component MUST be a zone signing KEY
-RR (2.a) authorized to provide validation of the zone's apex KEY RR
-set, as recognized by resolvers of interest.
-
-The previous sentence is trying to convey the notion of using a
-trusted third party to provide validation of keys. If the domain name
-owning the validating key is not the parent zone, the domain name must
-represent someone the resolver trusts to provide validation.
-
-2.2.c. NXT records MUST be deployed throughout the zone. Note: see
-the discussion following 2.1.c.
-
-2.2.d. Each RR set that qualifies for zone membership MUST be signed
-by a key that is in the apex's KEY RR set and is a zone signing KEY RR
-(2.a). (Updates 2535, section 2.3.1.)
-
-2.3 Unsecured
-
-All other zones qualify as unsecured. This includes zones that are
-designed to be experimentally secure, as defined in a later section on
-that topic.
-
-2.4 Wrap up
-
-The designation of globally secured, locally secured, and unsecured
-are merely labels to apply to zones, based on their contents.
-Resolvers, when determining whether a signature is expected or not,
-will only see a zone as secured or unsecured.
-
-Resolvers that follow the most restrictive DNSSEC verification rules
-will only see globally secured zones as secured, and all others as
-unsecured, including zones which are locally secured. Resolvers that
-are not as restrictive, such as those that implement algorithms in
-addition to the mandatory to implement algorithms, will see some
-locally secured zones as secured.
-
-The intent of the labels "global" and "local" is to identify the
-specific attributes of a zone. The words are chosen to assist in the
-writing of a document recommending the actions a zone administrator
-take in making use of the DNS security extensions. The words are
-explicitly not intended to convey a state of compliance with DNS
-security standards.
-
-3 Experimental Status
-
-The purpose of an experimentally secured zone is to facilitate the
-migration from an unsecured zone to a secured zone. This distinction
-is dropped.
-
-The objective of facilitating the migration can be achieved without a
-special designation of an experimentally secure status. Experimentally
-
-Expires March 19, 2001 [Page 7]
-\fInternet Draft September 19, 2000
-
-secured is a special case of globally secured. A zone administrator
-can achieve this by publishing a zone with signatures and configuring
-a set of test resolvers with the corresponding public keys. Even if
-the public key is published in a KEY RR, as long as there is no parent
-signature, the resolvers will need some pre-configuration to know to
-process the signatures. This allows a zone to be secured with in the
-sphere of the experiment, yet still be registered as unsecured in the
-general Internet.
-
-4 IANA/ICANN Considerations
-
-This document does not request any action from an assigned number
-authority nor recommends any actions.
-
-5 Security Considerations
-
-Without a means to enforce compliance with specified protocols or
-recommended actions, declaring a DNS zone to be "completely" secured
-is impossible. Even if, assuming an omnipotent view of DNS, one can
-declare a zone to be properly configured for security, and all of the
-zones up to the root too, a misbehaving resolver could be duped into
-believing bad data. If a zone and resolver comply, a non-compliant or
-subverted parent could interrupt operations. The best that can be
-hoped for is that all parties are prepared to be judged secure and
-that security incidents can be traced to the cause in short order.
-
-6 Acknowledgements
-
-The need to refine the definition of a secured zone has become
-apparent through the efforts of the participants at two DNSSEC
-workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a
-DARPA-funded research network), and other workshops. Further
-discussions leading to the document include Olafur Gudmundsson, Russ
-Mundy, Robert Watson, and Brian Wellington. Roy Arends, Ted Lindgreen
-and others have contributed significant input via the namedroppers
-mailing list.
-
-7 References
-
-[RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities,"
-RFC 1034, November 1987.
-
-[RFC1035] P. Mockapetris, "Domain Names - Implementation and
-Specification," RFC 1034, November 1987.
-
-[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels," RFC 2119, March 1997
-
-[RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic
-Updates in the Domain Name System," RFC 2136, April 1997.
-
-[RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC
-2535, March 1999.
-
-
-Expires March 19, 2001 [Page 8]
-\fInternet Draft September 19, 2000
-
-[draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple
-Secure Domain Name System (DNS) Dynamic Update," version 00, February
-2000.
-
-[SIGAUTH] B. Wellington, draft-ietf-dnsext-signing-auth-01.txt
-
-10 Author Information
-
-Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443
-259 2352 <lewis@tislabs.com>
-
-11 Full Copyright Statement
-
-Copyright (C) The Internet Society (1999, 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."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires March 19, 2001 [Page 9]
-
-
+++ /dev/null
-A new Request for Comments is now available in online RFC libraries.\r
-\r
-\r
- RFC 3258\r
-\r
- Title: Distributing Authoritative Name Servers via Shared\r
- Unicast Addresses\r
- Author(s): T. Hardie\r
- Status: Informational\r
- Date: April 2002\r
- Mailbox: Ted.Hardie@nominum.com\r
- Pages: 11\r
- Characters: 22195\r
- Updates/Obsoletes/SeeAlso: None\r
-\r
- I-D Tag: draft-ietf-dnsop-hardie-shared-root-server-07.txt\r
-\r
- URL: ftp://ftp.rfc-editor.org/in-notes/rfc3258.txt\r
-\r
-\r
-This memo describes a set of practices intended to enable an\r
-authoritative name server operator to provide access to a single named\r
-server in multiple locations. The primary motivation for the\r
-development and deployment of these practices is to increase the\r
-distribution of Domain Name System (DNS) servers to previously\r
-under-served areas of the network topology and to reduce the latency\r
-for DNS query responses in those areas.\r
-\r
-This document is a product of the Domain Name Server Operations\r
-Working Group of the IETF.\r
-\r
-This memo provides information for the Internet community. It does\r
-not specify an Internet standard of any kind. Distribution of this\r
-memo is unlimited.\r
-\r
-This announcement is sent to the IETF list and the RFC-DIST list.\r
-Requests to be added to or deleted from the IETF distribution list\r
-should be sent to IETF-REQUEST@IETF.ORG. Requests to be\r
-added to or deleted from the RFC-DIST distribution list should\r
-be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.\r
-\r
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending\r
-an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body \r
-help: ways_to_get_rfcs. For example:\r
-\r
- To: rfc-info@RFC-EDITOR.ORG\r
- Subject: getting rfcs\r
-\r
- help: ways_to_get_rfcs\r
-\r
-Requests for special distribution should be addressed to either the\r
-author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless\r
-specifically noted otherwise on the RFC itself, all RFCs are for\r
-unlimited distribution.echo \r
-Submissions for Requests for Comments should be sent to\r
-RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC\r
-Authors, for further information.\r
-\r
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT D. Senie
-Category: BCP Amaranth Networks Inc.
-Expires in six months July 2001
-
- Requiring DNS IN-ADDR Mapping
- draft-ietf-dnsop-inaddr-required-02.txt.
-
-
-
-Status of this Memo
-
-
- This draft, file name draft-ietf-dnsop-inaddr-required-00.txt, is
- intended to be become a Best Current Practice RFC. Distribution of
- this document is unlimited. Comments should be sent to the Domain
- Name Server Operations working group mailing list <dnsop@cafax.se> or
- to the author.
-
- 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/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000,2001). All Rights Reserved.
-
-1. Introduction
-
- The Domain Name Service has provision for providing mapping of IP
- addresses to host names. It is common practice to ensure both name to
- address, and address to name mappings are provided for networks. This
- practice, while documented, has never been documented as a
- requirement placed upon those who control address blocks. This
- document fills this gap.
-
- 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. Discussion
-
-
-
-Senie [Page 1]
-
-
-
-
-
-Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
-
-
- From the early days of the Domain Name Service [RFC 883] a special
- domain has been set aside for resolving mappings of IP addresses to
- domain names. This was refined in [RFC1035], describing the .IN-
- ADDR.ARPA in use today.
-
- The assignment of blocks of IP Address space was delegated to three
- regional registries. Guidelines for the registries are specified in
- [RFC2050], which requires regional registries to maintain IN-ADDR
- records on the large blocks of space issued to ISPs and others.
-
- ARIN's policy only requires ISPs to maintain IN-ADDR if they have a
- /16 or larger allocation [ARIN]. APNIC indicates in their policy
- document [APNIC] that those to whom they allocate blocks, and those
- further downstream SHOULD maintain IN-ADDR records. RIPE appears to
- have the strongest policy in this area [ripe-185] indicating Local
- Internet Registries are required to perform IN-ADDR services, and
- delegate those as appropriate when address blocks are delegated.
-
- As we can see, the regional registries have their own policies for
- requirements for IN-ADDR maintenance. It should be noted, however,
- that many address blocks were allocated before the creation of the
- regional registries, and thus it is unclear whether any of the
- policies of the registries are binding on those who hold blocks from
- that era.
-
- Registries allocate address blocks on CIDR [RFC1519] boundaries.
- Unfortunately the IN-ADDR zones are based on classful allocations.
- Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
- exist, but are not always implemented. Providers SHOULD follow these
- guidelines and ensure their clients set up zone files to answer the
- delegations.
-
-3. Effects of missing IN-ADDR
-
- Many applications use DNS lookups for security checks. To ensure
- validity of claimed names, some applications will look up IN-ADDR
- records to get names, and then look up the resultant name to see if
- it maps back to the address originally known. Failure to resolve
- matching names is seen as a potential security concern.
-
- Some popular FTP sites will flat-out reject users, even for anonymous
- FTP, if the IN-ADDR lookup fails or if the result of the IN-ADDR
- lookup when itself resolved, does not match. Some Telnet servers also
- implement this check.
-
- Web sites are in some cases using IN-ADDR checks to verify whether
- the client is located within a certain geopolitical entity. This is
- being employed for downloads of crypto software, for example, where
-
-
-
-Senie [Page 2]
-
-
-
-
-
-Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
-
-
- export of that software is prohibited to some locales. Credit card
- anti-fraud systems also use these methods for geographic placement
- purposes.
-
- The popular TCP Wrappers program found on most Unix and Linux systems
- has options to enforce IN-ADDR checks and to reject any client which
- does not resolve.
-
- Wider-scale implementation of IN-ADDR on dialup, CDPD and other such
- client-oriented portions of the Internet would result in lower
- latency for queries (due to lack of negative caching), and lower name
- server load and DNS traffic.
-
- Some anti-spam (anti junk email) systems use IN-ADDR to verify return
- addresses before accepting email.
-
- Many web servers look up the IN-ADDR of visitors to be used in log
- analysis. This adds to the server load, but in the case of IN-ADDR
- unavailability, it can lead to delayed responses for users.
-
- Traceroutes with descriptive IN-ADDR naming proves useful when
- debugging problems spanning large areas. When this information is
- missing, the traceroutes take longer, and it takes additional steps
- to determine who's network is the cause of problems.
-
-4. Requirements
-
- Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
- of IN-ADDR, sometimes in conjunction with a lookup of the name
- resulting from the PTR record adds no real security, can lead to
- erroneous results and generally just increases load on DNS servers.
- Further, in cases where address block holders fail to properly
- configure IN-ADDR, users of those blocks are penalized.
-
- All IP address space which is assigned and in use SHOULD be resolved
- by IN-ADDR records. All PTR records MUST use canonical names.
-
- Internet providers and other users to whom a block of addresses are
- delegated SHOULD provide for lookup of host names from IP addresses.
- This may be provided directly or by delegation to the user of the
- address block. The ISP is responsible for one or the other. In the
- event of delegation, the user is responsible for resolution.
-
- Only IP addresses not presently in use within a block, or which are
- not valid for use (zeros or ones broadcast addresses) are permitted
- to have no mapping. It should be noted that due to CIDR, many
- addresses which appear to be otherwise valid host addresses may
- actually be zeroes or ones broadcast addresses. As such, attempting
-
-
-
-Senie [Page 3]
-
-
-
-
-
-Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
-
-
- to audit a site's degree of compliance can only be done with a
- knowledge of the internal routing structure of the site. However, any
- host which originates an IP packet necessarily will have a valid host
- address, and must therefore have an IN-ADDR mapping.
-
- Regional Registries and any Local Registries to whom they delegate
- SHOULD establish and convey a policy to those to whom they delegate
- blocks that IN-ADDR mappings are required. Internet providers and end
- users with address blocks must verify their own internal networks are
- properly represented in IN-ADDR records, either by providing that
- service themselves, or delegating it to others.
-
- Those to whom blocks have been delegated SHOULD convey a policy to
- delegatees requiring that they too provide IN-ADDR records and
- require and delegations below to do the same. ISPs may wish to
- provide IN-ADDR records for their clients if the customers are unable
- to provide this for themselves.
-
-5. Security Considerations
-
- This document has no negative impact on security. While it could be
- argued that lack of PTR record capabilities provides a degree of
- anonimity, this is really not valid. Trace routes, whois lookups and
- other sources will still provide methods for discovering identity.
-
- By recommending applications avoid using IN-ADDR as a security
- mechanism this document points out that this practice, despite its
- use by many applications, is an ineffective form of security.
- Applications should use better mechanisms of authentication.
-
-6. References
-
- [RFC883] P.V. Mockapetris, "Domain names: Implementation
- specification," RFC883, November 1983.
-
- [RFC1035] P.V. Mockapetris, "Domain Names: Implementation
- Specification," RFC 1035, November 1987.
-
- [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
- an Address Assignment and Aggregation Strategy," RFC 1519, September
- 1993.
-
- [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
- RFC 2317, March 1998.
-
- [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
- Guidelines", RFC2050, BCP 12, Novebmer 1996.
-
-
-
-
-Senie [Page 4]
-
-
-
-
-
-Internet-Draft Requiring DNS IN-ADDR Mapping July 2001
-
-
- [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
- unknown, http://www.arin.net/regserv/initial-isp.html
-
- [APNIC] "Policies for address space management in the Asia Pacific
- Region," Approved October 1999, effective January 2000,
- http://www.apnic.net/drafts/add-manage-policy.html
-
- [RIPE185] "European Internet Registry Policies and Procedures,"
- ripe-185, October 26, 1998. http://www.ripe.net/docs/ripe-185.html
-
-
-7. Acknowledgements
-
- Thanks to Peter Koch and Gary Miller for their input, and to many
- people who encouraged me to write this document.
-
-8. Author's Address
-
- Daniel Senie
- Amaranth Networks Inc.
- 324 Still River Road
- Bolton, MA 01740
-
- Phone: (978) 779-6813
-
- EMail: dts@senie.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Senie [Page 5]
-
-
+++ /dev/null
-
-
-Internet Draft Johan Ihr\89n
-draft-ietf-dnsop-interim-signed-root-01.txt Autonomica
-February 2003
-Expires in six months
-
-
- An Interim Scheme for Signing the Public DNS Root
-
-
-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 memo documents a proposed mechanism for a first stage of a
- transition from an unsigned DNS root to a signed root, such that
- the data in the root zone is accompanied by DNSSEC signatures to
- allow validation.
-
- The underlying reason for signing the root zone is to be able to
- provide a more secure DNS hierarchy, where it is possible to
- distinguish false answers from correct answers.
-
- For the special case of the DNS root zone, an interim scheme is
- proposed. This scheme is mostly aimed at securing the root zone
- itself for technical and operational reasons, and to give
- operational experience of DNSSEC.
-
-
-1. Terminology
-
- The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
- and "MAY" in this document are to be interpreted as described in
- RFC 2119.
-
- The term "zone" refers to the unit of administrative control in the
- Domain Name System. "Name server" denotes a DNS name server that is
- authoritative (i.e. knows all there is to know) for a DNS zone,
- typically the root zone. A "resolver", finally, is a DNS "client",
- i.e. an entity that sends DNS queries to authoritative nameservers
- and interpret the results.
-
-
-2. Motivation for signing the DNS root
-
- In the special case of the root zone there are very strong reasons
- to take a slow and conservative approach to any changes with
- operational impact. Signing the root is such a change.
-
- DNSSEC[RFC2535, RFC3090] has been in development for a number of
- years now and still has not reached the point where the last flag
- day is behind us.
-
- However, during the years of DNSSEC development and refinement
- [RFC2930, RFC3007, RFC3008, RFC3110, RFC3225, RFC3226, AD-secure,
- Opt-in, Wild-card-optimize], the Internet has matured and more and
- more businesses and other organizations have become dependent on
- the stability and constant availability of the Internet.
-
- It is therefore prudent to do everything in our power to ensure
- that the DNS infrastructure works as well as possible and, when
- appropriate and possible, adding enhancements and functionality.
-
- The time is now right for yet another step of improvement by
- signing the root zone. By doing that any Internet user that so
- wishes will obtain the ability of verifying responses received from
- the root nameservers.
-
- Since this is new operational ground the objective is not maximum
- security but rather an "Internet-wide" controlled experiment with a
- signed root zone, where the trade off is that we utilize the fact
- that there are operators in place that can help even though they
- are not sufficiently staffed to do off-line signing in a 24x7
- mode. For this reason it is fully possible to even do automatic
- signing, since the purpose is to ensure that DNSSEC works
- operationally with a signed root zone and gain experience from the
- exercise.
-
- It should be pointed out, however, that the experimental part is
- only the added DNSSEC records. The traditional records in the root
- zone remain unchanged and the new records will only be visible to
- DNSSEC-aware resolvers that explicitly ask to see these new
- records.
-
-
-2.1. Motivation for signing the root zone now
-
- The reason DNSSEC is not yet widely deployable is that the problem
- of key management remains unsolved, especially where communication
- between the zone administrators for a parent zone and child zone is
- required.
-
- However, during the past year a solution to this problem has been
- found (in the form of a new record type, DS aka Delegation Signer)
- [DS], discussed, implemented and tested. Therefore, it is finally
- reasonable to consider DNSSEC deployment to be a real possibility
- within the next 12 months.
-
- In the case of the root zone the particular importance of managing
- the transition with zero operational mistakes is a strong reason to
- separate the signing of the zone itself, with the associated key
- management issues, from the future management of signed delegations
- (of top level domains).
-
- Although support for Delegation Signer has been implemented and
- tested it is not yet generally available except experimentally. For
- this reason signed delegations for productions zones will have to
- wait a bit longer. Furthermore, it will take some time to ensure
- that the entire RSS aka Root Server System is capable of supporting
- the protocol changes that accompany the new support for Delegation
- Signer.
-
- By signing now it will be possible to work through the operational
- issues with signing the zone itself without at the same time having
- to manage the additional complexity of signed delegations. Also, by
- explicitly not supporting any signed delegations, it is also
- possible to recover in a graceful way should new operational
- problems turn up.
-
- Because of these operational and technical issues there is a
- "window of opportunity" to sign the root zone before the status of
- implementation of "full DNSSEC", including Delegation Signer
- support, change to "generally available", thereby increasing the
- pressure for signed delegations from the root zone.
-
-
-3. Trust in DNSSEC Keys
-
- In the end the trust that a validating resolver will be able to put
- in a key that it cannot validate within DNSSEC will have to be a
- function of
-
- * trust in the key issuer
-
- * trust in the distribution method
-
- * trust in extra, out-of-band verification
-
- For any security apex, i.e. a node in the DNS hierarchy that issues
- out-of-band "trusted keys", it is of critical importance that this
- function produces a positive result (i.e. the resolver gains
- sufficient confidence in the keys to decide to trust them). The
- particular case of the root zone is no different, although possibly
- it is more crucial than many other security apexes.
-
- To ensure that the resulting trust is maximized it is necessary to
- work with all the parameters that are available. In the case of the
- key issuer there is the possibility of chosing a key issuer that
- has a large "trust base" (i.e. is already trusted by a large
- fraction of the resolver population). However, it is also possible
- to expand the aggregated trust base by using multiple simultaneous
- key issuers, as described in [Threshold-Validation].
-
- Furthermore, with multiple trusted keys it will be possible for a
- validating resolver to optimize for the "right compromise" between
-
- * maximum security (as expressed by all available signatures by all
- available keys verifying correctly
-
- * maximum redundancy (as in the DNS lookup being validated if there
- is any signature by any trusted key available)
-
- Without multiple, independent trusted keys the rollover operation
- will always be a dangerous operation where it is likely that some
- fraction of the resolver population lose their ability to verify
- lookups (and hence start to fail hard). I.e. the validating
- resolver will be forced to adopt the "maximum security" policy,
- since there is no alternative.
-
- With multiple, independent trusted keys, however, it is possible to
- design for improved redundancy by trusting lookups that are only
- validated against a subset of the available keys. This will make
- rollovers much less risky to the extent that it will be possible to
- "survive" even emergency rollovers without any immediate
- configuration chagnes in the validating resolver.
-
-
-4. Interim signing of the root zone
-
- At present all the authoritative servers for the root zone pull the
- zone from a primary master. I.e. any changes at the primary master
- will propagate via NOTIFY[RFC1996] and subsequent
- AXFR/IXFR[RFC1995, AXFR-clarify] to the slave servers.
-
- Between the primary master and the slaves transactions are signed
- with TSIG[RFC2845] signatures. This mechanism is already in place,
- and there is operational experience with periodic key rollover of
- the TSIG keys.
-
-
-4.1. Design philosophy
-
- By introducing a signing step into the distribution of the zone
- file complexity is increased. To avoid introducing new single
- points of failure it is therefore important to ensure that any
- added or changed steps are as redundant as possible.
-
- The assumption is that the operators of the root servers are
- trusted and that consistency of the zone among the root servers is
- a crucial property that MUST be preserved in emergencies.
-
- To ensure that consistency is maintained new single points of
- failure SHOULD NOT be introduced by the signing step. Therefore a
- structure where several parties have the ability to sign the zone
- is proposed. Furthermore, such a design helps avoid any individual
- party becoming a de facto single zone signing authority.
-
-
-4.2. Proposed new management structure for the root zone
-
- Taking into account the already existing infrastructure for
- management of TSIG keys and rollover of these keys the following
- structure is proposed:
-
- * Day-to-day signing of the root zone is performed by a subgroup of
- the root server operators referred to as "signing operators". For
- this task individual, per-operator, Zone Signing Keys, ZSKs, are
- used.
-
- * The set of Zone Signing Keys are signed by several Key Signing
- Keys, KSKs, at any particular time. The public part of KSKs in
- use have to be statically configured as "trusted keys" in all
- resolvers that want to be able to perform validation of
- responses.
-
- * Key rollover, the operation when an old KSK is exchanged for a
- new KSK, is managed with minimal overlap and on a frequent basis
- of no less than three times per year per KSK. The rollover
- schedule is chosen to be frequent enough to not make long-term
- trust possible while being low enough to not become operationally
- infeasible.
-
-
-4.2.1. Management and distribution of the zone file
-
- The present, unsigned zone is published by the official slaves, the
- "root nameservers", transferring the zone securely from a primary
- master and subsequently using the data to respond to queries. This
- mechanism is changed into:
-
- * The unsigned root zone is transferred securely from the primary
- master to a set of "signing primaries" managed by the operators
- participating in signing the zone. This is done via the
- traditional mechanisms NOTIFY + AXFR/IXFR + TSIG.
-
- * The root nameservers change their configuration so that they
- replace the present, single, primary master as the source of the
- zone with a set of multiple possible "signing primaries" as
- masters that provide the signed zone.
-
- * When a new, unsigned zone, is published by the primary master it
- will automatically be transferred to the pre-signing servers. The
- responsible operator will then sign the new zone and publish it
- from his signing primary. Since the serial number is higher than
- what the official root nameservers presently have the official
- root nameservers will all transfer the zone from this source
- (because of the redundant configuration with multiple possible
- masters for the signed zone).
-
- * The operators that participate in signing rotate the signing
- responsibility among themselves. Should the responsible operator
- be unable to do this for any reason then any of the others are
- able to do the signing instead. Traceability is maintained since
- the zone signing keys are individual.
-
- * To avoid having several "backup signing operators" possibly sign
- at exactly the same time backups are allocated "time windows"
- within which they are allowed to publish a signed zone.
-
- With N signers, each signer is assigned a unique number R in
- [1..N].
-
- T = 2*k*((S-R) mod N)
-
- T is time to wait in seconds, S current serial number. The length
- of the window is k, thereby separating each signing window with
- an interval where signing is not allowed.
-
- The constant k is used to create sufficient separation of the
- signers with respect to time used to sign and time needed to
- distribute the zone. A reasonable value for k would be in the
- order of 1800 seconds.
-
- * Because the digital signatures in the signed root zone MUST NOT
- expire it is necessary to ensure that the unsigned zone does
- change sufficiently often to cause new signing to occur within
- the validity period of the old signatures. This is most easily
- accomplished by a dummy update that only increments the serial
- number in the SOA record.
-
- This new requirement will not cause any operational problems,
- since in fact the root zone is maintained this way since several
- years back.
-
-
-4.2.2. Management of the Key Signing Keys
-
- Key Signing Keys, KSKs, are periodically issued by a several "Key
- Signing Key Holders", KSK holders, individually. These KSKs consist
- of a private part that should always be kept secret and a public
- part that should be published as widely as possible since it will
- be used as a "trusted key" in resolver configurations.
-
- The public part of each KSK should be included in the keyset for
- "." as described in [Threshold-Validation]. I.e. the keyset will be
- the union of the public parts of all KSKs and all ZSKs, Zone
- Signing Keys.
-
- * Each KSK holder should generate a sequence of KSKs where the
- public parts will be used to include in the keyset for "." and
- the private parts will be used for signing the keyset.
-
- * Each KSK holder should, on request from the signing operators,
- send in the public part of the KSK. The union of the public parts
- of KSKs and the corresponding public parts of ZSKs, as collected
- by the signing operators, constitute a "keyset".
-
- * Each KSK holder should, on request from the signing operators,
- sign the complete keyset with the private part of the associated
- KSK and send in the resulting signature to the signing operators
- for inclusion in the signed zone.
-
-
-4.2.3. Management of the Zone Signing Keys and the keyset signatures
-
- A subgroup of the root operators that choose to participate in
- signing the zone each hold an individual "Zone Signing Key",
- ZSK. The subgroup of operators may include all operators, but that
- is not necessary as long as a sufficient number to achieve
- redundancy in "signing ability" participates.
-
- * The complete keyset (i.e. all the public parts of KSKs and ZSKs)
- should be signed by each KSK holder individually, generating a
- new signature for the keyset which is sent back to the signing
- operators via an out-of-band mechanism.
-
- * The signing operators should verify each received signature
- against the corresponding key in the keyset and, unless invalid,
- accept the signature into the set of signatures associated with
- this keyset as described in [Threshold-Validation].
-
- * The signing operators should include one of the keysets together
- with all the KSK signatures in the zone file according to an
- agreed upon rotation schedule.
-
-
-4.2.4. Management of key rollover
-
- The Key Signing Keys should, for this interim scheme, be relatively
- short-lived and rolled over frequently. The direct intent is that
- it should not be possible to put long term trust in the keys.
- Therefore, by design, every resolver that chooses to configure
- these as "trusted keys" (to be able to validate lookups) will have
- to change the configuration periodically.
-
- This is, after all, only an interim method of root zone signing.
-
- * Key rollover is executed by changing from one signed keyset to
- another. I.e. from a keyset signed by one set of KSKs to a keyset
- signed by a partially different set of KSKs. By not rolling all
- the KSKs at the same time redundancy is improved.
-
- * Technically the signing operators are able to initiate key
- rollover, although except for the case of a suspected key
- compromise (with subsequent immediate key rollover) this ability
- should only be used according to an established schedule.
-
- * New Key Signing Keys will be published as widely as possible,
- however exactly how and where to publish the keys is by itself an
- area where it is necessary to acquire more experience. Especially
- for the case of individual hosts and other devices this will be a
- significant issue to deal with.
-
- * Since the keys expire within a few months the aim is to make it
- as difficult as possible to configure an interim key and then
- forget about it long enough to still trust an interim key when a
- long term design for signing the root zone emerges.
-
-
-4.2.5. The role of the KSK holder
-
- With multiple KSKs it is possible to have multiple individual KSK
- holders. Each will perform the role of authenticating the identity
- of the signing operators, through the act of signing the keyset
- that includes the operator Zone Signing Keys.
-
- The chain of authority that defines editorial control over the zone
- contents is entirely separate from this and is in no way affected.
-
- I.e. the KSK holder is only asserting identity of the holders of
- ZSKs and does not in any way take part in issues regarding zone
- contents. In this respect the role of a KSK holder is much like
- that of a public notary or a Certificate Authority.
-
- The primary function that the KSK holder is performing is adding
- trust to the authenticity of the Zone Signing Keys and this trust
- has to be propagated down to validating resolvers. Therefore an
- obvious key characteristic of a KSK holder is that it should
- already be trusted by as large a fraction of the "resolver
- population" as possible. In this document that fraction is referred
- to as the "trust base" of a KSK holder.
-
- The key characteristics of a KSK holder will be entities that
-
- * already are trusted by some part of the "resolver population",
- i.e. have a "trust base"
-
- * are multiple entities that complement each other (so that the
- aggregated "trust base" grows)
-
- * are willing to help work on methods for distributing their
- trusted keys to the resolvers (hard problem)
-
- The requirement on the individual KSK holders is that they must be
- able to
-
- * establish a secure out-of-band communication path in
- collaboration with the signing operators which will be used for
- authenticated exchange of the unsigned keyset and generated
- signatures
-
- * periodically generate strong keys using a good random number
- generator
-
- * manage their keys (i.e. use them for signing the operator keyset
- and keeping the private key appropriately secret)
-
-
-4.2.5.6. Suggestions for KSK holders
-
- Regional Internet Registries, RIRs, are suggested to be one
- suitable choice of KSK holders. However, since every KSK holder
- will act on its own there is no requirement that all RIRs
- participate, although more than one would be good. Other suitable
- KSK holders may exist and as long as the requirements are met more
- would be better within the packe size limitations that are
- discussed in [Threshold-Validation].
-
- The basis of the suggestion of RIRs is
-
- * their neutrality
-
- * their proven record of service to the Internet community
-
- * that they don't have the domain name system as their primary
- field of activity
-
- * their geographical diversity
-
- * the fact that they are, by definition, not a single entity, but
- rather a collective of organizations.
-
-
-5. Risk Analysis
-
- A change in the management of the root zone is always a risk. But
- that is all the more reason to do it carefully and after due
- consideration, rather than as a result of an immediate and urgent
- need. The gains of a signed root zone have to be judged against the
- added complexity of the signing step.
-
- However, added complexity, in one form or another, is basically
- unavoidable. It is possible to argue for or against implementation
- details, but in the end the benefits of a signed root will have to
- be compared against some amount of added complexity. If the cost or
- risk of this complexity is deemed to be too high, then it is not
- possible to sign the DNS root zone. If that is the conclusion; then
- it is obviously important to reach it as soon as possible.
-
- The same is true for the need for operational experience with a
- signed root zone. There is no method of acquiring this experience
- except by signing the root zone, so that is what is being proposed.
-
- Some identified scenarios:
-
-
-5.1. What will the consequences of a signed root zone be for old
- resolver software?
-
- Nameservers that are authoritative for signed zones only give out
- these signatures when explicitly asked for them. Therefore, the
- presence of signatures in the root zone will not have any impact at
- all on the majority of resolvers on the Internet that does not
- validate lookups.
-
-
-5.2. What happens if a signing operator fails to sign the zone on
- time?
-
- Literally nothing. I.e. the root zone that is published will be the
- version prior to the last change. This is not believed to be a
- major problem, since all changes to the data in the root zone are
- characterized by long overlaps in time. Furthermore every change is
- preceded by an administrative process that takes several days or
- even weeks. Because of this, a failure to install a new version of
- the root zone for even so long as a day will not noticeably change
- the turn-around time for changes in the root zone.
-
-
-5.3. What happens if several signing operators by mistake sign the
- same version?
-
- Literally nothing. One signing operator will be first, according to
- the mechanism designed to separate the different backup signing
- operators described in 3.3.1. The signed zone published by this
- operator will be the version of the signed root zone that all the
- root nameservers pick up.
-
- When the second signing operator signs the zone the serial number
- in the zone will be unchanged, and therefore the root nameservers
- will not pick this zone up but instead stay with the first version.
-
-
-5.4. What happens if the unsigned zone is compromised between the
- primary master and the signing primaries?
-
- This is basically the same threat as the zone being compromised
- between the primary master and the root servers in the traditional
- unsigned case. To guard against this possibility every zone
- transfer is already protected by a TSIG signature.
-
- Because of this the root zone file cannot get transferred to the
- signing primaries unless the transaction signature matches, thereby
- proving that the zone contents are uncompromised. The consequence
- is that if the zone transfers are somehow compromised in transit,
- they will not get signed and therefore the published root zone will
- remain the signed version of the last uncompromised transfer.
-
-
-5.5. What are the security implications for the new "signing
- primaries"? Will they not have to be as secure as the primary
- master is now?
-
- Yes. However, the entire root server system is based upon trust,
- i.e. the entire Internet is trusting the present root server system
- because there is no alternative to doing that. This proposal is not
- about changing the need for trust in the root server system. It is
- about providing a method of determining authenticity of data,
- something that is presently missing.
-
- The root operators are already trusted to provide a root server
- system based upon secure servers lacking validation mechanisms. It
- is therefore a bit difficult to argue for not trusting them to
- provide an improved system that adds exactly the lacking validation
- mechanisms on a basis of not trusting them to secure the servers
- involved. In both cases trust is involved, the difference is that
- in the latter case validation is possible.
-
- Furthermore, the proposed signing primaries will not need to have
- publicly known addresses (just as the present primary master is not
- publicly known), nor will they need to be able to communicate with
- anyone outside the well defined set of servers that are part of the
- root server system. Because of this it will be significantly easier
- to secure the signing primaries than the already present task of
- securing the DNS root nameservers.
-
-
-5.6. What happens if a Zone Signing Key is compromised?
-
- If this happens it is necessary to do an emergency rollover of the
- keyset that includes the compromised key. I.e. the old keyset (and
- its signatures) is replaced by a new keyset containing new ZSKs but
- the same, uncompromised, KSKs and its signatures. Then the root
- zone is re-signed using one of the new Zone Signing Keys.
-
- This problem is not unique to a signed root zone, it is inherent in
- any activity involving cryptographic keys.
-
- Also note that there will be no need to change any configuration in
- the resolver end. The rollover is an entirely atomic operation
- inside the management structure of the root zone.
-
-
-5.7. What happens if a Key Signing Key is compromised?
-
- Depending on the trust model used by individual validating
- resolvers one of two things will happen.
-
- Resolvers that through local policy have chosen to trust this KSK
- alone will need to change their configuration to instead trust
- other KSKs, either available from other KSK holders or a new
- trusted key made available by the same KSK holder that held the
- compromised key.
-
- Resolvers that have chosen to require multiple signatures by KSKs
- for the root zone will not have to do any emergency key rollover at
- all, since validation of lookups will still work, based upon the
- integrity of the other trusted keys that have not been compromised.
-
- In the management end it is necessary to do an emergency rollover
- of the keyset including the compromised key and the suggested
- method is by switching to a keyset that only changes the
- compromised KSK and the ZSKs and keeps all other KSKs. Such keysets
- should be prepared and signed in advance.
-
- The new signed keyset is added to the root zone and then the zone
- is re-signed using one of the new Zone Signing Keys. In this case,
- since a Key Signing Key is changed, every resolver that choose to
- trust that KSK holder will over time have to configure the new key
- to be able to validate lookups.
-
- This problem is not unique to a signed root zone, it is inherent in
- any activity involving cryptographic keys.
-
-
-5.8. Does the out-of-band communication between the signing operators
- and the RIRs holding the key-signing keys add a new failure mode?
-
- Yes. The traditional DNSSEC design assumes that (for an arbitrary
- zone, not particularly for the root zone) the key-signing key is
- managed by the same entity that manages the operator keys and hence
- no communication issue exists.
-
- In this case it is important that the signing operators do not hold
- the responsibility for the key-signing keys. The root server
- operators should only act as a "publishing service" for the root
- zone contents, not as the entity that verifies correctness of the
- published data.
-
- However, apart from established secure methods of out-of-band
- communication being available, there is also the very real
- possibility of managing these exchanges with actual eye-to-eye
- contact. Representatives for the RIRs and the root server operators
- already meet on a regular basis during IETF meetings and the
- different RIR meetings.
-
-
-6. Security Considerations
-
- Signing the DNS root zone is all about security. A signed root zone
- may aid applications and organizations all over the Internet in
- improving their security by enabling validation of DNS lookups.
-
- Signing the root zone does add a new management step and therefore
- it is important to ensure that possible failures in this management
- step does not leave the published root zone in a state that is
- actually worse than the original unsigned state.
-
- The various failure modes that have been identified all show this
- property of not being any worse than the unsigned case.
-
- There is however one scenario that changes drastically with the
- proposed distributed signing scheme and that is the consequences of
- one signing operator intentionally changing the contents of the
- root zone prior to the actual signing. In the unsigned case this
- will cause the root zone to become inconsistent (i.e. the responses
- vary depending upon which server it comes from), while in the
- signed case the root zone will remain consistent but with erroneous
- data in it.
-
- It is my belief (this is impossible to prove) that the risk of
- human error among the operators, however small, is still far
- greater than the risk of willful misconduct. Therefore, the
- proposed design that enforces consistency among the roots, is
- actually also an improvement in stability and security.
-
- Se further section 4 for a more complete risk analysis.
-
-
-7. IANA Considerations
-
- NONE.
-
-
-8. References
-
-8.1. Normative.
-
- [RFC2535] Domain Name System Security Extensions. D. Eastlake.
- March 1999.
-
- [RFC3090] DNS Security Extension Clarification on Zone Status.
- E. Lewis. March 2001.
-
- [RFC1995] Incremental Zone Transfer in DNS. M. Ohta. August 1996.
-
- [RFC1996] A Mechanism for Prompt Notification of Zone Changes
- (DNS NOTIFY). P. Vixie. August 1996.
-
- [RFC2845] Secret Key Transaction Authentication for DNS (TSIG).
- P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington.
- May 2000.
-
-8.2. Informative.
-
- [RFC2930] Secret Key Establishment for DNS (TKEY RR). D. Eastlake.
- September 2000.
-
- [RFC3007] Secure Domain Name System (DNS) Dynamic Update.
- B. Wellington. November 2000.
-
- [RFC3008] Domain Name System Security (DNSSEC) Signing Authority.
- B. Wellington. November 2000.
-
- [RFC3110] RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
- (DNS). D. Eastlake 3rd. May 2001.
-
- [RFC3225] Indicating Resolver Support of DNSSEC. D. Conrad.
- December 2001.
-
- [RFC3226] DNSSEC and IPv6 A6 aware server/resolver message size
- requirements. O. Gudmundsson. December 2001.
-
- [Delegation-Signer] Delegation Signer Resource Record.
- O. Gudmundsson. October 2002. Work In Progress.
-
- [AXFR-clarify] draft-ietf-dnsext-axfr-clarify-NN.txt DNS Zone
- Transfer Protocol Clarifications. A. Gustafsson. March
- 2002. Work In Progress.
-
- [AD-secure] draft-ietf-dnsext-ad-is-secure-NN.txt Redefinition of
- DNS AD bit. B. Wellington, O Gudmundsson. June 2002.
- Work In Progress.
-
- [Opt-In] draft-ietf-dnsext-dnssec-opt-in-NN.txt DNSSEC Opt-In
- R. Arends, M Kosters, D. Blacka. June 2002. Work In
- Progress.
-
- [Wild-card-optimize] draft-olaf-dnsext-dnssec-wildcard-
- optimization-NN.txt DNSSEC Wildcard optimization.
- O. Kolkman, J. Ihren, R. Arends. September 2002.
- Work In Progress.
-
- [Threshold-Validation]
- draft-ihren-dnsop-threshold-validation-00.txt Threshold
- validation: A Mechanism for Improved Trust and Redundancy
- for DNSSEC Keys. J. Ihren. February 2003. Work In
- Progress.
-
-9. Acknowledgments.
-
- To help me produce this document I have received lots and lots of
- comments from many people around the Internet with suggestions for
- lots and lots sorely needed improvements. Among the folks who
- helped out are, in no particular order: Paul Vixie, Bill Manning,
- Ôlafur Gu\14mundsson, Rob Austein, Patrik F\84ltstr÷m, Olaf Kolkman,
- Harald Alvestrand, Suzanne Woolf, John M. Brown, Lars-Johan Liman
- and M\85ns Nilsson.
-
-
-10. Authors' Address
-
-Johan Ihr\89n
-Autonomica AB
-Bellmansgatan 30
-SE-118 47 Stockholm, Sweden
-johani@autonomica.se
+++ /dev/null
-Internet Engineering Task Force Alain Durand
-INTERNET-DRAFT SUN Microsystems,inc.
-Feb, 27, 2003 Johan Ihren
-Expires August, 28, 2003 Autonomica
-
-
- IPv6 DNS transition issues
- <draft-ietf-dnsop-ipv6-dns-issues-02.txt>
-
-
-
-Status of this memo
-
- This memo provides information to the Internet community. It does not
- specify an Internet standard of any kind. This memo is in full
- conformance with all provisions of Section 10 of RFC2026
-
- 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/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
-
-Abstract
-
- This memo summarizes DNS related issues when transitioning a network
- to IPv6. Consensus and open issues are presented.
-
-
-
-1. Representing IPv6 addresses in DNS records
-
- In the direct zones, according to [RFC3363], IPv6 addresses are
- represented using AAAA records [RFC1886]. In the reverse zone, IPv6
- addresses are represented using PTR records in nibble format under
- the ip6.arpa. tree [RFC3152].
-
-
-
-2. IPv4/IPv6 name space
-
-2.1 Terminology
-
- The phrase "IPv4 name server" indicates a name server available over
- IPv4 transport. It does not imply anything about what DNS data is
- served. Likewise, "IPv6 name server" indicates a name server
- available over IPv6 transport.
-
-
-2.2. Introduction to the problem of name space fragmentation:
- following the referral chain
-
- The caching resolver that tries to lookup a name starts out at the
- root, and follows referrals until it is referred to a nameserver that
- is authoritative for the name. If somewhere down the chain of
- referrals it is referred to a nameserver that is only accessible over
- a type of transport that is unavailable, a traditional nameserver is
- unable to finish the task.
-
- When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
- only a matter of time until this starts to happen and the complete
- DNS hierarchy starts to fragment into a graph where authoritative
- nameservers for certain nodes are only accessible over a certain
- transport. What is feared is that a node using only a particular
- version of IP, querying information about another node using the same
- version of IP can not do it because, somewhere in the chain of
- servers accessed during the resolution process, one or more of them
- will only be accessible with the other version of IP.
-
- With all DNS data only available over IPv4 transport everything is
- simple. IPv4 resolvers can use the intended mechanism of following
- referrals from the root and down while IPv6 resolvers have to work
- through a "translator", i.e. they have to use a second name server on
- a so-called "dual stack" host as a "forwarder" since they cannot
- access the DNS data directly.
-
- With all DNS data only available over IPv6 transport everything would
- be equally simple, with the exception of old legacy IPv4 name servers
- having to switch to a forwarding configuration.
-
- However, the second situation will not arise in a foreseeable time.
- Instead, it is expected that the transition will be from IPv4 only to
- a mixture of IPv4 and IPv6, with DNS data of theoretically three
- categories depending on whether it is available only over IPv4
- transport, only over IPv6 or both.
-
- The latter is the best situation, and a major question is how to
- ensure that it as quickly as possible becomes the norm. However,
- while it is obvious that some DNS data will only be available over v4
- transport for a long time it is also obvious that it is important to
- avoid fragmenting the name space available to IPv4 only hosts. I.e.
- during transition it is not acceptable to break the name space that
- we presently have available for IPv4-only hosts.
-
-
-2.3 Policy based avoidance of name space fragmentation.
-
- Today there are only a few DNS "zones" on the public Internet that
- are available over IPv6 transport, and they can mostly be regarded
- as "experimental". However, as soon as there is a root name server
- available over IPv6 transport it is reasonable to expect that it will
- become more common to have zones served by IPv6 servers over time.
-
- Having those zones served only by IPv6-only name server would not be
- a good development, since this will fragment the previously
- unfragmented IPv4 name space and there are strong reasons to find a
- mechanism to avoid it.
-
- The RECOMMENDED approach to maintain name space continuity is to use
- administrative policies:
- - every recursive DNS server SHOULD be either IPv4-only or dual
- stack,
- - every single DNS zone SHOULD be served by at least one IPv4
- reachable DNS server.
-
- This rules out IPv6-only recursive DNS servers and DNS zones served
- only by IPv6-only DNS servers. This approach could be revisited
- if/when translation techniques between IPv4 and IPv6 were to be
- widely deployed.
-
- In order to enforce the second point, the zone validation process
- SHOULD ensure that there is at least one IPv4 address record
- available for the name servers of any child delegations within the
- zone.
-
-
-
-3. Local Scope addresses.
-
- [IPv6ADDRARCH] define three scopes of addresses, link local, site
- local and global.
-
-3.1 Link local addresses
-
- Local addresses SHOULD NOT be published in the DNS, neither in the
- forward tree nor in the reverse tree.
-
-
-3.2 Site local addresses
-
- Note: There is an ongoing discussion in the IPv6 wg on the
- usefulness of site local addresses that may end up deprecating or
- limiting the use of Site Local addresses.
-
-
- Site local addresses are an evolution of private addresses [RFC1918]
- in IPv4. The main difference is that, within a site, nodes are
- expected to have several addresses with different scopes. [ADDRSELEC]
- recommends to use the lowest possible scope possible for
- communications. That is, if both site local & global addresses are
- published in the DNS for node B, and node A is configured also with
- both site local & global addresses, the communication between node A
- and B has to use site local addresses.
-
- For reasons illustrated in [DontPublish], site local addresses SHOULD
- NOT be published in the public DNS. They MAY be published in a site
- view of the DNS if two-face DNS is deployed.
-
- For a related discussion on how to handle those "local" zones, see
- [LOCAL].
-
-
-3.3 Reverse path DNS for site local addresses.
-
- The main issue is that the view of a site may be different on a stub
- resolver and on a fully recursive resolver it points to. A simple
- scenario to illustrate the issue is a home network deploying site
- local addresses. Reverse DNS resolution for site local addresses has
- to be done within the home network and the stub resolver cannot
- simply point to the ISP DNS resolver.
-
- Site local addresses SHOULD NOT be populated in the public reverse
- tree. If two-face DNS is deployed, site local addresses MAY be
- populated in the local view of reverse tree.
-
-
-
-4. Automatic population of the Reverse path DNS
-
- Getting the reverse tree DNS populated correctly in IPv4 is not an
- easy exercise and very often the records are not really up to date or
- simply are just not there. As IPv6 addresses are much longer than
- IPv4 addresses, the situation of the reverse tree DNS will probably
- be even worse.
-
- A fairly common practice from IPv4 ISP is to generate PTR records for
- home customers automatically from the IPv4 address itself. Something
- like:
-
- 1.2.3.4.in-addr.arpa. IN PTR 4.3.2.1.local-ISP.net
-
- It is not clear today if something similar need to be done in IPv6,
- and, if yes, what is the best approach to this problem.
-
- As the number of possible PTR records would be huge (2^80) for a /48
- prefix, a possible solution would be to use wildcards entries like:
-
- *.0.1.2.3.4.5.6.7.8.9.a.b.c.ip6.arpa. IN PTR customer-42.local-
- ISP.net
-
- However, the use of wildcard is generally discouraged and this may
- not be an acceptable solution.
-
- An alternative approach is to dynamically synthetize PTR records,
- either on the server side or on the resolver side. This approach is
- discussed at length in [DYNREVERSE].
-
- Other solutions like the use of ICMP name lookups [ICMPNL] have been
- proposed but failed to reach consensus. It would work if and only the
- remote host is reachable at the time of the request and one can
- somehow trust the value that would be returned by the remote host.
- the
-
- A more radical approach would be not to pre-populate the reverse tree
- at all. This approach claims that applications that misuse reverse
- DNS for any kind of access control are fundamentally broken and
- should be fixed without introducing any kludge in the DNS. There is a
- certain capital of sympathy for this, however, ISP who who pre-
- generate statically PTR records for their IPv4 customers do it for a
- reason, and it is unlikely that this reason will disappear with the
- introduction of IPv6.
-
-
-
-5. Privacy extension addresses
-
- [RFC3041] defines privacy extensions for IPv6 stateless
- autoconfiguration where the interface ID is a random number. As those
- addresses are designed to provide privacy by making it more difficult
- to log and trace back to the user, it makes no sense to in the
- reverse tree DNS to have them pointing to a real name.
-
- [RFC3041] type addresses SHOULD NOT be published in the reverse tree
- DNS pointing to meaningful names. A generic, catch-all name MAY be
- acceptable. An interesting alternative would be to use dynamic
- synthesis as in [DYNREVERSE].
-
-
-
-6. 6to4
-
- 6to4 addresses can be published in the forward DNS, however special
- care is needed in the reverse tree. See [6to4ReverseDNS] for details.
- The delegation of 2.0.0.2.ip6.arpa. is suggested in [6to4ARPA],
- however, delegations in the reverse zone under 2.0.0.2.ip6.arpa are
- the core of the problem. Delegating the next 32 bits of the IPv4
- address used in the 6to4 domain won't scale and delegating on less
- may require cooperation from the upstream IPSs. The problem here is
- that, especially in the case of home usage of 6to4, the entity being
- delegated the x.y.z.t.2.0.0.2.ip6.arpa. zone (the ISP) may not be the
- same as the one using 6to4 (the end customer). the
-
- Another problem with reverse DNS for 6to4 addresses is that the 6to4
- prefix may be transient. One of the usage scenario of 6to4 is to have
- PCs connected via dial-up use 6to4 to connect to the IPv6 Internet.
- In such a scenario, the lifetime of the 6to4 prefix is the same as
- the DHCP lease of the IPv4 address it is derived from. It means that
- the reverse DNS delegation is only valid for the same duration.
-
- A possible approach is not to populate the reverse tree DNS for 6to4
- addresses. Another one is to use dynamic synthesis as described in
- [DYNREVERSE].
-
-
-
-
-7. Recursive DNS server discovery
-
- [DNSdiscovery] has been proposed to reserve a well known site local
- unicast address to configure the DNS resolver as a last resort
- mechanism, when no other information is available. Another approach
- is to use a DHCPv6 extensions [DHCPv6DNS].
-
-
-
-8. DNSsec
-
- There is nothing specific to IPv6 or IPv4 in DNSsec. However,
- translation tools such as NAT-PT [RFC2766] introduce a DNS-ALG that
- will break DNSsec by imposing a change in the trust model. See [DNS-
- ALG] for details.
-
-
-
-9. Security considerations
-
- Using wildcard DNS records in the reverse path tree may have some
- implication when used in conjunction with DNSsec. Security
- considerations for referenced documents are described in those memos
- and are not replicated here.
-
-
-
-10. Author addresses
-
- Alain Durand
- SUN Microsystems, Inc
- 17 Network circle UMPK17-202
- Menlo Park, CA, 94025
- USA
- Mail: Alain.Durand@sun.com
-
- Johan Ihren
- Autonomica
- Bellmansgatan 30
- SE-118 47 Stockholm, Sweden
- Mail: johani@autonomica.se
-
-
-
-11. References
-
- [RFC1918] Address Allocation for Private Internets. Y. Rekhter, B.
- Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February
- 1996.
-
- [RFC2766] Network Address Translation - Protocol Translation (NAT-
- PT).
- G. Tsirtsis, P. Srisuresh. February 2000.
-
- [RFC3041] Privacy Extensions for Stateless Address Autoconfiguration
- in IPv6,
- T. Narten, R. Draves, January 2001.
-
- [RFC3152] Delegation of ip6.arpa, R. Bush, August 2001.
-
- [RFC3363] Representing Internet Protocol version 6 (IPv6) Addresses
- in the Domain Name System (DNS), R. Bush, A. Durand, B.
- Fink, O. Gudmundsson, T. Hain. August 2002.
-
- [DYNREVERSE] Dynamic reverse DNS for IPv6, A. Durand,
- draft-durand-dnsops-dynreverse-00.txt, work in progress.
-
- [DNS-ALG] Issues with NAT-PT DNS ALG in RFC2766, A. Durand,
- draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work in
- progress.
-
- [LOCAL] Operational Guidelines for "local" zones in the DNS,
- Kato, A., Vixie, P., draft-kato-dnsop-local-zones-00.txt,
- work in progress.
-
- [ICMPNL] Use of ICMPv6 node information query for reverse DNS lookup,
- Jun-ichiro itojun Hagino, draft-itojun-ipv6-nodeinfo-
- revlookup-00.txt, work in progress.
-
- [IPv6ADDRARCH] IP Version 6 Addressing Architecture, R. Hinden,
- draft-ipngwg-addr-arch-v3-11.txt, work in progress.
-
- [6to4ARPA] Delegation of 2.0.0.2.ip6.arpa, Bush, R., Damas, J.,
- draft-ymbk-6to4-arpa-delegation-00.txt, work in progress.
-
- [6to4ReverseDNS] 6to4 and DNS, K. Moore, draft-moore-6to4-dns-03.txt,
- work in progress.
-
- [DNSdiscovery] Well known site local unicast addresses for DNS
- resolver,
- A. Durand, J. hagano, D. Thaler, draft-ietf-ipv6-dns-
- discovery-07.txt, work in progress.
-
- [DHCPv6DNS] DNS Configuration options for DHCPv6, Droms, R.
- draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt, work in
- progress.
-
-
-
-12. Full Copyright Statement
-
- "Copyright (C) The Internet Society (2001). 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+++ /dev/null
-DNSOP WG Edward Lewis
-INTERNET DRAFT NAI Labs
-Category: I-D March 2, 2001
-
- Handling of DNS Zone Signing Keys
- <draft-ietf-dnsop-keyhand-04.txt>
-
-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 DNSOP WG mailing list
-dnsop@cafax.se.
-
-This draft expires on September 2, 2001
-
-Copyright Notice
-
-Copyright (C) The Internet Society (1999-2001). All rights reserved.
-
-Abstract
-
-DNS Security Extensions require a greater interaction between zone
-administrations sharing a zone cut. The center of the interaction is
-the handling of the zone keys of the child and the signature applied
-by the parent. DNSSEC does not include a protocol for this, but the
-means of this interaction need definition to maintain the security of
-DNS.
-
-1 Introduction
-
-This document has existed for quite some time. The purpose of this
-document is to capture lessons learned regarding DNSSEC zone keys. In
-the past two years numerous workshops have been held, each adding to
-the community's lessons learned.
-
-In past editions of this document, the outline consisted of describing
-the lifecycle of a key and the steps needed to get it validated by the
-parent. In this edition, a new approach is being taken. The lessons
-learned are described without regard to fitting into an operations
-procedure. The hope is to develop a better explanation of the issues
-surrounding what will someday describe a "best current practice."
-
-2 Terminology
-
-Zone keys are explicitly defined in RFC 2535, but there have been
-certain phrases that are increasingly used that may cause confusion to
-new comers.
-
-A zone key really refers to two cryptographic values, called a public
-key and a private key. The two values always work in tandem, hence
-the singular reference. The phrase "signing with the zone key" refers
-to using the private key to generate digital signatures. The phrase
-"verifying with the zone key" refers to the use of the public key to
-verify the data and signature.
-
-3 Threats to Keys
-
-The threats to a zone key center on threats to the private key. There
-are three ways a zone key can be come useless to the owner (and
-possibly an advantage to an attacker). The private key could be come
-"exposed," "discovered," or "lost." The latter case, a lost key,
-refers to perhaps accidentally deleting the key from storage, and is a
-case that is of little concern. (Keys can be replaced easily.)
-
-An "exposed" key refers to a private key that is seen, or copied, by
-an unauthorized person. This could happen if the host holding the key
-is infiltrated or sloppy transferring of the key (such as in
-unencrypted email).
-
-A "discovered key" is one that is found through performing
-cryptographic analysis of the public key, data sets and signatures.
-Depending on various factors, such as algorithm and key size, a
-determined analyst can reverse engineer the private key.
-
-This latter loss is the most troublesome. This kind of loss is what
-creates the limited lifetime of a key. Because of this, there is a
-need to fully develop key changing (or rollover) procedures.
-
-Unfortunately, there is no current recommendation on how long it would
-take to discover a given private key. Such knowledge would be
-invaluable in the design on key handling procedures.
-
-4 "Lateral Signing"
-
-Lateral signing refers to the use of key-signing keys and data-signing
-keys to balance the need to change keys (avoiding discovery) and the
-need to configure new keys in resolvers.
-
-This approach has been developed for the use of TLDs in absence of a
-signed root zone. This approach is applicable anywhere in the DNS
-hierarchy, and will be needed by the root zone when it is signed.
-
-The thought is as follows. A zone assumes that the parent is not
-secured, hence must distribute a public key to all resolvers of
-interest. This key is a key-signing key, it will be used to sign as
-little as possible to minimize the risk of discovery. Other keys are
-used to sign the zone, with these keys changed roughly once a month.
-
-At any one time, the zone's key set will have the one key-signing key
-and some number of data-signing keys. The key-signing key will sign
-the zone key set, and the other key or keys, the zone data.
-
-A resolver would start with the key-signing key configured. When data
-arrives, it does so accompanied by a signature generated by a
-data-signing key. The resolver then retrieves the data-signing key as
-part of the zone key set, which is signed by the key-signing key.
-Hence the chain is from key-signing key to data-signing key (signed by
-key-signing key) to data (signed by data-signing key).
-
-The term "lateral" signing comes from the observation that the
-key-signing key and the data-signing key are from the same place in
-the hierarchy (same owner name).
-
-5 Getting Validation
-
-In order for DNSSEC to scale, zones will need to have their parents
-validate the zone keys. This process is the most difficult issue
-facing DNSSEC deployment.
-
-Summarizing this needed process, a child zone sends its zone key set
-to the parent, the parent signs it and returns the data to the child.
-This process is complicated by its volume (number of zones) and its
-repetitiveness due - to the key discovery problem.
-
-One important issue that has been raised regarding this process is
-what the parent does with the child's keys once they are signed. One
-school of thought is that the keys and signature are returned to the
-child and are forgotten by the parent. Another school of though is
-that the parent retains copies of the keys and signature, perhaps even
-entering them into the zone file.
-
-The former idea enables the child to "close the loop" security-wise by
-verifying that the parent signed the right keys. It might be possible
-for an attacker to intercept the submission and modify the keys.
-
-The latter idea leaves the parent better prepared for a key change in
-its zone. If the parent changes keys mid-month, or in an emergency,
-children zones (perhaps signed monthly) need to get the new
-signatures. On one workshop, this step was mishandled, resulting in
-the loss of many delegations.
-
-6 Changing Keys
-
-When the time comes to change a zone's keys, one issue is whether it
-is appropriate to retain old keys in the zone or to abruptly change
-the key set (with the exception of any key-signing key). The reason
-to retain old keys is to enable old but still valid signatures to be
-verified in caches. Arguments for abrupt change include the
-observation that this is the only way in which DNS can revoke
-signatures.
-
-8 Size and validity period
-
-An often-asked question is what is an appropriate key size. As
-mentioned earlier, a good guide is lacking. In general, per
-algorithm, a longer key compared to a shorter key is more difficult to
-discovery but takes longer to use. Longer keys can generally be used
-longer, but signing and verification are slower.
-
-The period of time in which a key should be used is an unknown
-quantity. This will likely be a decision based upon staffing, and on
-a calendar basis. Once a week is likely for zones requiring tight
-security, once a month for others.
-
-9 Random Numbers
-
-One easily overlooked issue is the source of random numbers. A good
-random number generator is needed to generate truly strong keys. In
-the worst case, a random number generator always returning the same
-number would result in the same pair of keys being generated. If a
-zone generates a pair of keys this way and an attacker gets hold of
-the same key generation software, it would be possible to discover the
-private key simply by generating a pair of keys. This, by the way,
-has already been observed in workshops.
-
-It is unfortunate that some current operating systems have poor random
-number generators. While this is improving, the machines used for key
-generation and use should be selected carefully.
-
-10 Dynamic Update
-
-Dynamic update raises an issue regarding the protection of private
-keys. As mentioned earlier, one threat is the exposure of the private
-key. This is possible of the private key is on the same machine as
-the name server, or even on any other reachable server. Therefore,
-conventional wisdom is to use non-network connected machines (perhaps
-behind a firewall) for all signing activity.
-
-Dynamic update requires the server to sign data submitted to it for a
-zone. This means the private key must be available to the name server
-(on the network).
-
-To counter this, a recommendation is offered to segregate dynamic
-update zones from static zones. This limits the risk to static data
-if a dynamic update zone key is exposed. In addition, some issues
-have been discovered with signed dynamic update zones, particularly
-the mechanism by which to refresh signatures, which also call for
-separating crucial static data from dynamic data.
-
-11 IANA Considerations
-
-This document does not place any requirements on the assigned numbers
-authority.
-
-12 Security Considerations
-
-This entire document is a note on security considerations. If the
-zone key is mishandled, in a way that compromises its security, then
-the security of its zone is compromised.
-
-13 References
-
-At some point.
-
-14 Author's Address
-
-Edward Lewis
-<lewis@tislabs.com>
-3060 Washington Rd (Rte 97)
-Glenwood, MD 21738
-+1(443)259-2352
-
-15 Acknowledgements
-
-The following individuals and groups have made significant input into
-the content of this document: the attendees of the NIC-SE work shop on
-DNSSEC, May 18 and 19, 1999, also Olafur Gudmundsson, and Brian
-Wellington.
-
-A second workshop held by the CAIRN research network September 29 and
-30th also provided input to this document. Dan Massey has provided
-input based upon this workshop and experience with DNSSEC in CAIRN.
-
-More workshops are to be acknowledged.
-
-16 Full Copyright Statement
-
-Copyright (C) The Internet Society (1999-2001). 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."
-
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-Edward Lewis NAI Labs
-Phone: +1 443-259-2352 Email: lewis@tislabs.com
-
-Dilbert is an optimist.
-
-Opinions expressed are property of my evil twin, not my employer.
-
-
+++ /dev/null
- Parent's SIG over child's KEY
- draft-ietf-dnsop-parent-sig-00.txt
-
- Miek Gieben, Ted Lindgreen
-
-
-Status of This Document
-
- 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
-
- When dealing with large amounts of keys the procedures to update a zone and
- to sign a zone need to be clearly defined and practically possible.
- The current idea is to have the KEY RR and the parent's SIG to reside in the
- child's zone and perhaps also in the parent's zone. We feel that this would
- lead to very complicated procedures for large TLD's. We propose a alternative
- scheme in which the parent zone stores the parent's signature over the child's
- key and also a copy of the child's key itself.
-
- The advantage of this proposal is that all signatures signed by a key are in
- the same zone file as the producing key. This allows for a simple key
- rollover and resigning mechanism. For large TLD's this is extremely important.
-
- We further discuss the impact on a secure aware resolver/forwarder.
-
-
-Table of Contents
-
- Status of This Document....................................
- Abstract...................................................
-
- Table of Contents..........................................
- 1 Introduction.............................................
- 2 Proposal.................................................
- 3 Impact on a secure aware resolver/forwarder..............
- 3.1 Impact of key rollovers on resolver/forwarder..........
- 4 Key rollovers............................................
- 4.1 Scheduled key rollover.................................
- 4.2 Unscheduled key rollover...............................
- 5 Zone resiging............................................
-
-
- References................................................
-
- Authors' Addresses........................................
- References................................................
-
-
-1. Introduction
- Within a CENTR working group NLnet Labs is researching the impact of
- DNSSEC on the ccTLDs and gTLDs.
-
- In this document we are considering a secure zone, somewhere under a secure
- entry point and on-tree [1] validation between the secure entry point and the
- zone in question. The resolver we are considering is security aware and is
- preconfigured with the KEY of the secure entry point.
-
- RFC 2535 [2] states that a zone key must be present in the apex of a zone.
- This can be in the at the delegation point in the parent's zonefile
- (normally the case for null keys), or in the child's zonefile, or in both.
- This key is only valid if it is signed by the parent, so there is also the
- question where this signature is located.
-
- The original idea was to have the KEY RR and the parent's SIG to reside
- in the child's zone and perhaps also in the parent's zone. There is a
- draft proposal [3], that describes how a keyrollover can be handled.
-
- At NLnet Labs we found that storing the parent's signature over the
- child's key in the child's zone:
- - makes resigning a KEY by the parent difficult
- - makes a scheduled keyrollover very complicated
- - makes an unscheduled keyrollover virtually impossible
-
- We propose an alternative scheme in which the parent's signature over the
- child's key is only stored in the parent's zone, i.e. where the signing key
- resides. This would solve the above problems.
-
-
-2. Proposal
- The core of the new proposal is that the parent zone stores the parent's
- signature over the child's key and also a copy of the child's key itself.
- The child zone also contains its zonekey, where it is selfsigned.
-
- The advantage of this proposal is that all signatures signed by a key are in
- the same zone file as the producing key. This allows for a simple key
- rollover and resigning mechanism. For large TLD's this is extremely important.
-
- A disadvantage would be that not all the information concerning one zone is
- stored at that zone, namely the (parent) SIG RR. Note that the same argument
- can be applied to a zone's NULL key, which is also stored at the parent.
-
-
-3. Impact on a secure aware resolver/forwarder
- The resolver must be aware of the fact that the parent is more authoritative
- than a child when it comes to deciding whether a zone is secured or not.
-
- Without caching and with on-tree validation, a resolver will always start
- its search at a secure entry point. In this way it can determine whether it
- must expect SIG records or not.
-
- Considering caching in a secure aware resolver or forwarder. If information
- of a secure zone is cached, its validated KEY should also be cached.
-
- If the KEY record expires, because the KEY TTL expires or because the SIG is
- no longer valid, the KEY should be discarded. The resolver or forwarder
- should then also discard other data concerning the zone because it is no
- longer validated and possible bad data should not be cached.
-
-3.1. Impact of key rollovers on resolver/forwarder
- When a zone is in the process of a key rollover, there could be a discrepancy
- between the KEY and the SIG in the apex of the zone and the KEY and SIG that
- are stored in the cache of a resolver.
-
- Suppose a resolver has cached the NS, KEY and SIG records of a zone. Next a
- request comes for an A record in that zone. Also the zone is in the process
- of a keyrollover and already has new keys in its zone. The resolver receives
- an answer consisting of the A record and a SIG over the A record. It uses
- the tag field in the SIG to determine if it has a KEY which is suitable to
- validate the SIG. If it does not has such a KEY the resolver must ask the
- parent of the zone for a new KEY and then try it again. Now the resolver
- has 2 keys for the zone, according to the tag field in the SIG it can use
- either one.
-
- If the new key also does not validate the SIG the zone is marked bad. If the
- KEY found at the parent is the NULL key the resolver knows that the child is
- considered insecure. This could for instance be in the case the private key
- of the zone is stolen.
-
-4. Key rollovers
- Private keys can be stolen or a key can become over used. In both
- cases a new a new key must be signed and distributed. This event is
- called keyrollover. We further distinguish between a scheduled and an
- unscheduled key rollover. A scheduled rollover is announced before hand.
- An unscheduled key rollover is needed when a private key is compromised.
-
-4.1. Scheduled key rollover
- When the signatures, produced by the key to be rolled over, are all
- in one zone file, there are two parties involved. Let us look at an
- example where a TLD rolls over its zone key. The new key needs to be
- signed with the root's key before it can be used to sign the TLD zone
- and the zone keys of the TLD's children. The steps that need to be taken
- by TLD and root are:
- - the TLD adds the new key to its keyset in its zonefile. This
- zone and keyset are signed with the old zonekey
- - then the TLD signals the parent
- - the root copies the new keyset, consisting of the both new
- and the old key, in its zonefile, resigns it and signals the TLD
- - the TLD removes the old key from its keyset, resigns its zone
- with the new key, and signals the the root
- - the root copies the new keyset, now consisting of the new key
- only, and resigns it
-
-4.2. Unscheduled key rollover
- Although nobody hopes that this will ever happen, we must be able to
- cope with possible key compromises. When such an event occurs, an
- immediate keyrollover is needed and must be completed in the shortest
- possible time. With two parties involved, it will still be awkward, but
- not impossible to update two zonefiles overnight. "Out-of-band"
- communication between the two parties will be necessary, since the
- compromised old key can not be trusted. We think that between two
- parties this is doable, but this complicated procedure is beyond the
- scope of this document. [4]
-
-5. Zone resigning
- Resigning a TLD is necessary before the current signatures expire.
- When all SIG records, produced by the TLD's zone key are kept in the
- TLD's zonefile, and only there, such a resign session is trivial, as
- only one party (the TLD) and one zonefile is involved.
-
-
-Authors' Addresses
-
- R. Gieben
- Stichting NLnet Labs
- Kruislaan 419
- 1098 VA Amsterdam
- miek@nlnetlabs.nl
-
- T. Lindgreen
- Stichting NLnet Labs
- Kruislaan 419
- 1098 VA Amsterdam
- ted@nlnetlabs.nl
-
-References
-
- [1] Lewis, E. "DNS Security Extension Clarification on Zone Status",
- http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-04.txt
- [2] Eastlake, D. "DNS Security Extensions", RFC 2535
- http://www.ietf.org/rfc/rfc2535.txt?number=2535
- [3] Andrews, M., Eastlake, D. "Domain Name System (DNS) Security Key Rollover"
- http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rollover-01.txt
- [4] Gieben, R. "Chain of trust"
- http://secnl.nlnetlabs.nl/thesis/thesis.html
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT David Conrad
-draft-ietf-dnsop-serverid-01.txt Nominum, Inc.
- November, 2002
-
- Identifying an Authoritative Name Server
-
-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
-
- A standardized mechanism to determine the identity of a name server
- responding to a particular query would be useful, particularly as a
- diagnostic aid. This document describes an identification convention
- used in one widely deployed implementation of the DNS protocol and
- proposes a slight modification to that convention aimed at addressing
- some implementation concerns.
-
-1. Introduction
-
- Determining the identity of the name server responding to a query has
- become more complex due primarily to the proliferation of various
- load balancing techniques. This document describes a convention used
- by one particular DNS server implementation to provide identifying
- information and proposes a slight modification to that convention to
- address concerns regarding implementation neutrality.
-
- Note that this document makes no value judgements as to whether or
- not the convention in current use is good or bad; it merely documents
-
-
-
-Expires May, 2003 [Page 1]
-\f
-draft-ietf-dnsop-serverid-01.txt May, 2002
-
-
- the covention's existence and proposes a slight redefinition of the
- convention to address non-technical implementation concerns.
-
-2. Rationale
-
- Identifying which name server is responding to queries is often
- useful, particularly in attempting to diagnose name server
- difficulties. However, relying on the IP address of the name server
- has become more problematic due the deployment of various load
- balancing solutions, including the use of shared unicast addresses as
- documented in [RFC3258].
-
- An unfortunate side effect of these load balancing solutions is that
- traditional methods of determining which server is responding can be
- unreliable. Specifically, non-DNS methods such as ICMP ping, TCP
- connections, or non-DNS UDP packets (e.g., as generated by tools such
- as "traceroute"), etc., can end up going to a different server than
- that which receives the DNS queries.
-
- This proposal makes the assumption that an identification mechanism
- that relies on the DNS protocol is more likely to be successful
- (although not guaranteed) in going to the same machine as a "normal"
- DNS query.
-
-3. Historical Conventions
-
- Recent versions of the commonly deployed Berkeley Internet Name
- Domain implementation of the DNS protocol suite from the Internet
- Software Consortium [BIND] support a way of identifying a particular
- server via the use of a standard, if somewhat unusual, DNS query.
- Specifically, a query to a late model BIND server for a TXT resource
- record in class 3 (CHAOS) for the domain name "HOSTNAME.BIND." will
- return a string that can be configured by the name server
- administrator to provide a unique identifier for the responding
- server (defaulting to the value of a gethostname() call). This
- mechanism, which is an extension of the BIND convention of using
- CHAOS class TXT RR queries to sub-domains of the "BIND." domain for
- version information, has been copied by several name server vendors.
-
- For reference, the other well-known name used by recent versions of
- BIND within the CHAOS class "BIND." domain is "VERSION.BIND." A
- query for a TXT RR for this name will return an administratively re-
- definable string which defaults to the version of the server
- responding.
-
-4. An Implementation Neutral Convention
-
- The previously described use of the CHAOS class "BIND." domain has
-
-
-
-Expires May, 2003 [Page 2]
-\f
-draft-ietf-dnsop-serverid-01.txt May, 2002
-
-
- (rightly) been viewed by many implementors as not being standardized
- nor being implementation neutral. As such, a standard mechanism to
- identify a particular machine among a shared unicast set of machines
- serving the same DNS data does not currently exist.
-
- Since a name server conforming to [RFC1034] and [RFC1035] should
- support the CHAOS class and the use of TXT resource record queries in
- the CHAOS class to derive information about a name server has been
- used in several independent name server implementations, the quickest
- way of supporting the identification of a particular name server out
- of a set of name servers all sharing the same unicast prefix would
- likely be to standardize on the BIND convention, albeit with a slight
- modification to address implementation neutrality concerns.
-
- The convention proposed here simply redefines the top level CHAOS
- domain to be "SERVER." instead of "BIND.". Since using the actual
- hostname may be considered an information leakage security risk, the
- use of the actual hostname of the server is discouraged and instead a
- unique per-server identifier should be used. As the BIND convention
- of "HOSTNAME" implies the use of a hostname, the domain name
- "ID.SERVER" is proposed. That is, a TXT RR query for "ID.SERVER." in
- the CHAOS class will return an administratively defined string that
- can be used to differentiate among multiple servers.
-
- To make this convention useful, DNS operators wishing to identify
- their servers uniquely MUST, for EACH server, put a unique string for
- the RDATA of the TXT record associated with the "ID.SERVER." domain
- in class CHAOS. For example, given two machines "a.example.com" and
- "b.example.com" that receive DNS queries at the same IP address, the
- name server administrator could include
-
- $ORIGIN SERVER.
- ID CH TXT "a"
-
- in the appropriate zone file on machine "a.example.com" and
-
- $ORIGIN SERVER.
- ID CH TXT "b"
-
- in the appropriate zone file on machine "b.example.com".
-
- Queries for TXT RRs of "id.server" in class CHAOS to the IP address
- serving both "a.example.com" and "b.example.com" should return "a" or
- "b" depending on which machine the query was routed.
-
- Implementors MUST provide a way to disable returning this identifying
- information. Implementors SHOULD provide a way to limit who can
- query for the identifying information.
-
-
-
-Expires May, 2003 [Page 3]
-\f
-draft-ietf-dnsop-serverid-01.txt May, 2002
-
-
- The use of other names in the CHAOS class "SERVER." domain are beyond
- the scope of this document.
-
-IANA Considerations
-
- The "SERVER." domain in the CHAOS class should be reserved by IANA
- and a registry should be created that reserves the "ID" name. In the
- future, requests may be submitted for other sub-domains of "SERVER.",
- e.g., "VERSION.SERVER." and the IANA should take appropriate action.
-
-Security Considerations
-
- Providing identifying information as to which server is responding
- can be seen as information leakage and thus a security risk. It may
- be appropriate to restrict who can query for the "ID.SERVER." domain.
- Filtering on source address would be one way in which restrictions
- can be applied.
-
- The identifer returned via an "ID.SERVER." query SHOULD NOT contain
- the hostname or other information that could be considered sensitive.
-
-Acknowledgements
-
- The technique for host identification documented here derive from
- practices implemented by Paul Vixie of the Internet Software
- Consortium in the Berkeley Internet Name Domain package. Useful
- comments on earlier drafts were provided by Bob Halley, Brian
- Wellington, Andreas Gustafsson, Ted Hardie, Chris Yarnell, and
- members of the ICANN Root Server System Advisory Council. Additional
- explanatory information provided due to questions received from Randy
- Bush.
-
-References
-
- [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
- RFC 1034, November 1987.
-
- [RFC1035] Mockapetris, P., "Domain Names - Implementation and
- Specifications", RFC 1035, November 1987.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3258] Hardie, T., "Distributing Authoritative Name Servers via
- Shared Unicast Addresses", RFC 3258, April, 2002.
-
-Author's Address
-
-
-
-
-Expires May, 2003 [Page 4]
-\f
-draft-ietf-dnsop-serverid-01.txt May, 2002
-
-
- David Conrad
- Nominum, Inc.
- 2385 Bay Road
- Redwood City, CA 94063
- USA
-
- Phone: +1 650 381 6003
- Fax: +1 650 381 6055
- Email: david.conrad@nominum.com
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May, 2003 [Page 5]
-\f
+++ /dev/null
-
-
- Mark Foster
-Internet Draft Tom McGarry
-Document: <draft-ietf-enum-e164-gstn-np-01.txt> James Yu
- NeuStar, Inc.
-Category: Informational February 9, 2001
-
-
- Number Portability in the GSTN: An Overview
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026 [RFC].
-
- 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), ds.internic.net (US East Coast), or
- ftp.isi.edu (US West Coast).
-
-
-1. Abstract
-
- This document provides an overview of E.164 telephone number
- portability (NP) in the Global Switched Telephone Network (GSTN).
- There are three types of number portability: service provider number
- portability (SPNP), location portability, and service portability.
- Service provider portability, the focus of the present draft, is a
- regulatory imperative in many countries seeking to liberalize local
- telephony service competition, by enabling end-users to retain pre-
- existing telephone numbers while changing service providers.
- Implementation of NP within national GSTN entails potentially
- significant changes to numbering administration, network element
- signaling, call routing and processing, billing, service management,
- and other functions. NP changes the fundamental nature of a dialed
- E.164 number from a hierarchical physical routing address to a
- virtual address, thereby requiring the transparent translation of
- the later to the former. In addition, there are various regulatory
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 [1]
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- constraints that establish relevant parameters for NP
- implementation, most of which are not network technology specific.
- Consequently, the implementation of NP behavior consistent with
- applicable regulatory constraints, as well as the need for
- interoperation with the existing GSTN NP implementations, are
- relevant topics for numerous areas of IP telephony work-in-progress
- at IETF.
-
-
-2. Introduction
-
- This document provides an overview of E.164 telephone number
- portability in the Global Switched Telephone Network (GSTN). There
- are considered to be three types of number portability (NP): service
- provider portability (SPNP), location portability (not to be
- confused with terminal mobility), and service portability.
-
- Service provider portability (SPNP), the focus of the present draft,
- is a regulatory imperative in many countries seeking to liberalize
- telephony service competition, especially local service.
- Historically, local telephony service (as compared to long distance
- or international service) has been regulated as a utility-like form
- of service. While a number of countries had begun liberalization
- (e.g. privatization, de-regulation, or re-regulation) some years
- ago, the advent of NP is relatively recent (since ~1995).
-
- E.164 numbers can be non-geographic and geographic numbers. Non-
- geographic numbers do not reveal the locations information of those
- numbers. Geographic E.164 numbers were intentionally designed as
- hierarchical routing addresses which could systematically be digit-
- analyzed to ascertain the country, serving network provider, serving
- end-office switch, and specific line of the called party. As such,
- without NP a subscriber wishing to change service providers would
- incur a number change as a consequence of being served off of a
- different end-office switch operated by the new service provider.
- The cost and convenience impact to the subscriber of changing
- numbers is seen as barrier to competition. Hence NP has become
- associated with GSTN infrastructure enhancements associated with a
- competitive environment driven by regulatory directives.
-
- Forms of SPNP have been deployed or are being deployed widely in the
- GSTN in various parts of the world, including the U.S., Canada,
- Western Europe, Australia, and the Pacific Rim (e.g. Hong Kong).
- Other regions, such as South America (e.g. Brazil) are actively
- considering it.
-
- Implementation of NP within a national telephony infrastructure
- entails potentially significant changes to numbering administration,
- network element signaling, call routing and processing, billing,
- service management, and other functions.
-
- NP changes the fundamental nature of a dialed E.164 number from a
- hierarchical physical routing address to a virtual address. NP
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 2
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- implementations attempt to encapsulate the impacts to the GSTN and
- make NP transparent to subscribers by incorporating a translation
- function to map a dialed, potentially ported E.164 address, into a
- network routing address (either a number prefix or another E.164
- address) which can be hierarchically routed.
-
- This is roughly analogous to the use of network address translation
- on IP addresses to enable IP address portability by containing the
- impact of the address change to the edge of the network and retain
- the use of CIDR blocks in the core which can be route aggregated by
- the network service provider to the rest of the internet.
-
- NP bifurcates the historical role of a subscriberÆs E.164 address
- into two or more data elements (a dialed or virtual address, and a
- network routing address) that must be made available to network
- elements through an NP translations database, carried by forward
- call signaling, and recorded on call detail records. Not only is
- call processing and routing affected, but also so is SS7/C7
- messaging. A number of TCAP-based SS7 messaging sets utilize an
- E.164 address as an application-level network element address in the
- global title address (GTA) field of the SCCP message header.
- Consequently, SS7/C7 signaling transfer points (STPs) and gateways
- need to be able to perform n-digit global title translation (GTT) to
- translate a dialed E.164 address into its network address
- counterpart via the NP database.
-
- In addition, there are various national regulatory constraints that
- establish relevant parameters for NP implementation, most of which
- are not network technology specific. Consequently, implementations
- of NP behavior in IP telephony consistent with applicable regulatory
- constraints, as well as the need for interoperation with the
- existing GSTN NP implementations, are relevant topics for numerous
- areas of IP telephony work-in-progress at IETF.
-
- This document describes three types of number portability and the
- four schemes that have been standardized to support SPNP for
- geographic E.164 numbersspecifically. Following that, specific
- information regarding the call routing and database query
- implementations are described for several regions (North American
- and Europe) and industries (wireless vs. wireline). The Number
- Portability Database (NPDB) interfaces and the call routing schemes
- that are used in the North America and Europe are described to show
- the variety of standards that may be implemented worldwide. A
- glance of the NP implementations worldwide is provided. Number
- pooling is briefly discussed to show how NP is being enhanced in the
- U.S. to conserve North American area codes. The conclusion briefly
- touches the potential impacts of NP on IP & Telecommunications
- Interoperability. Appendix A provides some specific technical and
- regulatory information on NP in North America. Appendix B describes
- the number portability administration process that manages the
- number portability database in North America.
-
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 3
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
-3. Abbreviations and Acronyms
-
- ACQ All Call Query
- AIN Advanced Intelligent Network
- AMPS Advanced Mobile Phone System
- ANSI American National Standards Institute
- CDMA Code Division Multiple Access
- CdPA Called Party Address
- CdPN Called Party Number
- CH Code Holder
- CMIP Common Management Information Protocol
- CS1 Capability Set 1
- CS2 Capability Set 2
- DN Directory Number
- DNS Domain Name System
- ETSI European Technical Standards Institute
- FCI Forward Call Indicator
- GAP Generic Address Parameter
- GMSC Gateway Mobile Services Switching Center or Gateway Mobile
- Switching Center
- GSM Global System for Mobile Communications
- GSTN Global Switched Telephone Network
- GW Gateways
- HLR Home Location Register
- IAM Initial Address Message
- IETF Internet Engineering Task Force
- ILNP Interim LNP
- IN Intelligent Network
- INAP Intelligent Network Application Part
- INP Interim NP
- IP Internet Protocol
- IS-41 Interim Standards Number 41
- ISDN Integrated Services Digital Network
- ISUP ISDN User Part
- ITN Individual Telephony Number
- ITU International Telecommunication Union
- ITU-TS ITU-Telecommunication Sector
- LDAP Lightweight Directory Access Protocol
- LEC Local Exchange Carrier
- LNP Local Number Portability
- LRN Location Routing Number
- MAP Mobile Application Part
- MNP Mobile Number Portability
- MSRN Mobile Station Roaming Number
- MTP Message Transfer Part
- NANP North American Numbering Plan
- NP Number Portability
- NPDB Number Portability Database
- NRN Network Routing Number
- OR Onward Routing
- OSS Operation Support System
- PCS Personal Communication Services
- PNTI Ported Number Translation Indicator
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 4
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- PODP Public Office Dialing Plan
- PUC Public Utility Commission
- QoR Query on Release
- RN Routing Number
- RTP Return to Pivot
- SCCP Signaling Connection Control Part
- SCP Service Control Point
- SIP Session Initiation Protocol
- SMR Special Mobile Radio
- SMS Service Management System
- SPNP Service Provider Number Portability
- SRF Signaling Relaying Function
- SRI Send Routing Information
- SS7 Signaling System Number 7
- STP Signaling Transfer Point
- TCAP Transaction Capabilities Application Part
- TDMA Time Division Multiple Access
- TN Telephone Number
- TRIP Telephony Routing Information Protocol
- URL Universal Resource Locator
- U.S. United States
-
-
-4. Types of Number Portability
-
- As there are several types of E.164 numbers (telephone numbers, or
- just TN) in the GSTN, there are correspondingly several types of
- E.164 NP in the GSTN. First there are so-call non-geographic E.164
- numbers, commonly used for service-specific applications such as
- freephone (800 or 0800). Portability of these numbers is called
- non-geographic number portability (NGNP). NGNP, for example, was
- deployed in the U.S. in 1986-92.
-
- Geographic number portability, which includes traditional fixed or
- wireline numbers as well as mobile numbers which are allocated out
- of geographic number range prefixes, is called NP or GNP or in the
- U.S. local number portability (LNP).
-
- Number portability allows the telephony subscribers in the Global
- Switched Telephone Network (GSTN) to keep their phone numbers when
- they change their service providers or subscribed services, or when
- they move to a new location.
-
- The ability to change the service provider while keeping the same
- phone number is called service provider portability (SPNP) also
- known as "operator portability."
-
- The ability to change the subscriberÆs fixed service location while
- keeping the same phone number is called location portability.
-
- The ability to change the subscribed services (e.g., from the plain
- old telephone service to Integrated Services Digital Network (ISDN)
- services) while keeping the same phone number is called service
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 5
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- portability. Another aspect of service portability is to allow the
- subscribers to enjoy the subscribed services in the same way when
- they roam outside their home networks as is supported by the
- cellular/wireless networks.
-
- In addition, mobile number portability (MNP) refers to specific NP
- implementation in mobile networks either as part of a broader NP
- implementation in the GSTN or on a stand-alone basis. Where
- interoperation of LNP and MNP is supported, service portability
- between fixed and mobile service types is possible.
-
- At present, SPNP has been the primary form of NP deployed due to its
- relevance in enabling local service competition.
-
- Also in use in the GSTN are the terms interim NP (INP) or Interim
- LNP (ILNP) and true NP. Interim NP usually refers to the use of
- remote call forwarding-like measures to forward calls to ported
- numbers through the donor network to the new service network. These
- are considered interim relative to true NP, which seeks to remove
- the donor network or old service provider from the call or signaling
- path altogether. Often the distinction between interim and true NP
- is a national regulatory matter relative to the
- technical/operational requirements imposed on NP in that country.
-
- Implementations of true NP in certain countries (e.g. U.S., Canada,
- Spain, Belgium, Denmark) may pose specific requirements for IP
- telephony implementations as a result of regulatory and industry
- requirements for providing call routing and signaling independent of
- the donor network or last previous serving network.
-
-
-5. Service Provider Number Portability Schemes
-
- Four schemes can be used to support service provider portability and
- are briefly described below. But first, some further terms are
- introduced.
-
- The donor network is the network that first assigned a telephone
- number (e.g., TN +1-202-533-1234) to a subscriber, out of a number
- range administratively (e.g., +1 202-533) assigned to it. The
- current service provider (new SP) or new serving network is the
- network that currently serves the ported number. The old serving
- network (or old SP) is the network that previously served the ported
- number before the number was ported to the new serving network.
- Since a TN can port a number of times, the old SP is not necessarily
- the same as the donor network, except for the first time the TN
- ports away, or if the TN ports back into the donor network and away
- again. While the new SP and old SP roles are transitory as a TN
- ports around, the donor network is always the same for any
- particular TN based on the service provider to whom the subtending
- number range was administratively assigned. See the discussion
- below on number pooling, as this enhancement to NP further
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 6
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- bifurcates the role of donor network into two (the number range or
- code holder network, and the block holder network).
-
- To simplify the illustration, all the transit networks are ignored,
- the originating or donor network is the one that performs the
- database queries or call redirection, and the dialed directory
- number (TN) has been ported out of the donor network before.
-
- It is assumed that the old serving network, the new serving network
- and the donor network are different networks so as to show which
- networks are involved in call handling and routing and database
- queries in each of four schemes. Please note that the port of the
- number (process of moving it from one network to another) happened
- prior to the call setup and is not included in the call steps.
- Information carried in the signaling messages to support each of the
- four schemes is not discussed to simplify the explanation.
-
-
-5.1 All Call Query (ACQ)
-
- Figure 1 shows the call steps for the ACQ scheme. Those call steps
- are as follows:
-
-
- +-------------+ +-----------+ Number +-----------+
- | Centralized | | New Serv. | ported | Old Serv. |
- | NPDB | +-------->| Network |<------------| Network |
- +-------------+ | +-----------+ +-----------+
- ^ | |
- | | |
- 1| | 3.|
- | | 2. |
- | | |
- | v |
- +----------+ | +----------+ +----------+
- | Orig. |------+ | Donor | | Internal |
- | Network | | Network | | NPDB |
- +----------+ +----------+ +----------+
-
-
- Figure 1 - All Call Query (ACQ) Scheme.
-
-
- (1) The Originating Network receives a call from the caller and
- sends a query to a centrally administered Number Portability
- Database (NPDB), a copy of which is usually resident on a
- network element within its network or through a third party
- provider.
- (2) The NPDB returns the routing number associated with the dialed
- directory number. The routing number is discussed later in
- Section 7.
- (3) The Originating Network uses the routing number to route the
- call to the new serving network.
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 7
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
-
-5.2 Query on Release (QoR)
-
- Figure 2 shows the call steps for the QoR scheme. Those call steps
- are as follows:
-
- (1) The Originating Network receives a call from the caller and
- routes the call to the donor network.
- (2) The donor network releases the call and indicates that the
- dialed directory number has been ported out of that switch.
- (3) The Originating Network sends a query to its copy of the
- centrally administered NPDB.
- (4) The NPDB returns the routing number associated with the dialed
- directory number.
- (5) The Originating Network uses the routing number to route the
- call to the new serving network.
-
-
- +-------------+ +-----------+ Number +-----------+
- | Centralized | | New Serv. | ported | Old Serv. |
- | NPDB | | Network |<------------| Network |
- +-------------+ +-----------+ +-----------+
- ^ | ^
- | | 4. |
- 3.| | 5. |
- | | +----------------------+
- | | |
- | v |
- +----------+ 2. +----------+ +----------+
- | Orig. |<---------------| Donor | | Internal |
- | Network |--------------->| Network | | NPDB |
- +----------+ 1. +----------+ +----------+
-
-
- Figure 2 - Query on Release (QoR) Scheme.
-
-
-5.3 Call Dropback
-
- Figure 3 shows the call steps for the Dropback scheme. This scheme
- is also known as "Return to Pivot (RTP)." Those call steps are as
- follows:
-
- (1) The Originating Network receives a call from the caller and
- routes the call to the donor network.
- (2) The donor network detects that the dialed directory number has
- been ported out of the donor switch and checks with an internal
- network-specific NPDB.
- (3) The internal NPDB returns the routing number associated with the
- dialed directory number.
- (4) The donor network releases the call by providing the routing
- number.
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 8
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- (5) The Originating Network uses the routing number to route the
- call to the new serving network.
-
- +-------------+ +-----------+ Number +-----------+
- | Centralized | | New Serv. | porting | Old Serv. |
- | NPDB | | Network |<------------| Network |
- +-------------+ +-----------+ +-----------+
- /\
- |
- 5. |
- +------------------------+
- |
- |
- +----------+ 4. +----------+ 3. +----------+
- | Orig. |<---------------| Donor |<----------| Internal |
- | Network |--------------->| Network |---------->| NPDB |
- +----------+ 1. +----------+ 2. +----------+
-
-
- Figure 3 - Dropback Scheme.
-
-
-5.4 Onward Routing (OR)
-
- Figure 4 shows the call steps for the OR scheme. This scheme is also
- called Remote Call Forwarding. Those call steps are as follows:
-
- (1) The Originating Network receives a call from the caller and
- routes the call to the donor network.
- (2) The donor network detects that the dialed directory number has
- been ported out of the donor switch and checks with an internal
- network-specific NPDB.
- (3) The internal NPDB returns the routing number associated with the
- dialed directory number.
- (4) The donor network uses the routing number to route the call to
- the new serving network.
-
-
- +-------------+ +-----------+ Number +-----------+
- | Centralized | | New Serv. | porting | Old Serv. |
- | NPDB | | Network |<------------| Network |
- +-------------+ +-----------+ +-----------+
- /\
- |
- 4.|
- |
- +----------+ +----------+ 3. +----------+
- | Orig. | | Donor |<----------| Internal |
- | Network |--------------->| Network |---------->| NPDB |
- +----------+ 1. +----------+ 2. +----------+
-
-
- Figure 4 - Onward Routing (OR) Scheme.
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 9
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
-
-5.5 Comparisons of the Four Schemes
-
- Only the ACQ scheme does not involve the donor network when routing
- the call to the new serving network of the dialed ported number.
- The other three schemes involve call setup to or signaling with the
- donor network.
-
- Only the OR scheme requires the setup of two physical call segments,
- one from the Originating Network to the donor network and the other
- from the donor network to the new serving network. The OR scheme is
- the least efficient in terms of using the network resources. The
- QoR and Dropback schemes set up calls to the donor network first but
- release the call back to the Originating Network that then initiates
- a new call to the Current Serving Network. For the QoR and Dropback
- schemes, circuits are still reserved one by one between the
- Originating Network and the donor network when the Originating
- Network sets up the call towards the donor network. Those circuits
- are released one by one when the call is released from the donor
- network back to the Originating Network. The ACQ scheme is the most
- efficient in terms of using the switching and transmission
- facilities for the call.
-
- Both the ACQ and QoR schemes involve Centralized NPDBs for the
- Originating Network to retrieve the routing information.
- Centralized NPDB means that the NPDB contains ported number
- information from multiple networks. This is in contrast to the
- internal network-specific NPDB that is used for the Dropback and OR
- schemes. The internal NPDB only contains information about the
- numbers that were ported out of the donor network. The internal
- NPDB can be a stand-alone database that contains information about
- all or some ported-out numbers from the donor network. It can also
- reside on the donor switch and only contains information about those
- numbers ported out of the donor switch. In that case, no query to a
- stand-alone internal NPDB is required. The donor switch for a
- particular phone number is the switch to which the number range is
- assigned from which that phone number was originally assigned.
-
- For example, number ranges in the North American Numbering Plan
- (NANP) are usually assigned in the form of central office codes (CO
- codes) comprising a six-digit prefix formatted as a NPA+NXX. Thus a
- switch serving +1-202-533 would typically serve +1-202-533-0000
- through +1-202-533-9999. In major cities, switches usually host
- several CO codes. NPA stands for Numbering Plan Area that is also
- known as the area code. It is three-digit long and has the format
- of NXX where N is any digit from 2 to 9 and X is any digit from 0 to
- 9. NXX in the NPA+NXX format is known as the office code that has
- the same format as the NPA. When the first number out of an NPA+NXX
- code is ported out to another switch, that NPA+NXX is called
- "portable NPA+NXX."
-
- Similarly, in other national E.164 numbering plans, number ranges
- cover a contiguous range of numbers within that range. Once a
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 10
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- number within that range has ported away from the donor network, all
- numbers in that range are considered potentially ported and should
- be queried in the NPDB.
-
- The ACQ scheme has two versions. One version is for the Originating
- Network to always query the NPDB when a call is received from the
- caller regardless whether the dialed directory number is ported or
- not. The other version is to check whether the dialed directory
- number belongs to any portable number range. If yes, an NPDB query
- is sent. If not, no NPDB query is sent. The former performs better
- when there are many portable number ranges. The latter performs
- better when there are not too many portable number ranges at the
- expense of checking every call to see whether NPDB query is needed.
- The latter ACQ scheme is similar to the QoR scheme except that the
- QoR scheme uses call setup and relies on the donor network to
- indicate "number ported out" before launching the NPDB query.
-
-
-6. Database Queries in the NP Environment
-
- As indicated earlier, the ACQ and QoR schemes require that a switch
- query the NPDB for routing information. Various standards have been
- defined for the switch-to-NPDB interface. Those interfaces with
- their protocol stacks are briefly described below. The term "NPDB"
- is used for a stand-alone database that may support just one or some
- or all of the interfaces mentioned below. The NPDB query contains
- the dialed directory number and the NPDB response contains the
- routing number. There are certainly other information that is sent
- in the query and response. The primary interest is to get the
- routing number from the NPDB to the switch for call routing.
-
-
-6.1 U.S. and Canada
-
- One of the following five NPDB interfaces can be used to query an
- NPDB:
-
- (a) Advanced Intelligent Network (AIN) using the American National
- Standards Institute (ANSI) version of the Intelligent Network
- Application Part (INAP) [ANSI SS] [ANSI DB]. The INAP is
- carried on top of the protocol stack that includes the (ANSI)
- Message Transfer Part (MTP) Levels 1 through 3, ANSI Signaling
- Connection Control Part (SCCP), and ANSI Transaction
- Capabilities Application Part (TCAP). This interface can be
- used by the wireline or wireless switches, is specific to the NP
- implementation in North America, and is modeled on the Public
- Office Dialing Plan (PODP) trigger defined in the Advanced
- Intelligent Network (AIN) 0.1 call model.
-
- (b) Intelligent Network (IN), which is similar to the one used for
- querying the 800 databases. The IN protocol is carried on top
- of the protocol stack that includes the ANSI MTP Levels 1
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 11
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- through 3, ANSI SCCP, and ANSI TCAP. This interface can be used
- by the wireline or wireless switches.
-
- (c) ANSI IS-41 [IS41] [ISNP], which is carried on top of the
- protocol stack that includes the ANSI MTP Levels 1 through 3,
- ANSI SCCP, and ANSI TCAP. This interface can be used by the IS-
- 41 based cellular/Personal Communication Services (PCS) wireless
- switches (e.g., AMPS, TDMA and CDMA). Cellular systems use
- spectrum at 800 MHz range and PCS systems use spectrum at 1900
- MHz range.
-
- (d) Global System for Mobile Communication Mobile Application Part
- (GSM MAP) [GSM], which is carried on top of the protocol stack
- that includes the ANSI MTP Levels 1 through 3, ANSI SCCP, and
- International Telecommunication Union - Telecommunication Sector
- (ITU-TS) TCAP. It can be used by the PCS1900 wireless switches
- that are based on the GSM technologies. GSM is a series of
- wireless standards defined by the European Telecommunications
- Standards Institute (ETSI).
-
- (e) ISUP triggerless translation. NP translations are performed
- transparently to the switching network by the signaling network
- (e.g. Signaling Transfer Points (STPs) or signaling gateways).
- ISUP IAM messages are examined to determine if the CdPN field
- has already been translated, and if not, an NPDB query is
- performed, and the appropriate parameters in the IAM message
- modified to reflect the results of the translation. The
- modified IAM message is forwarded by the signaling node on to
- the designated DPC in a transparent manner to continue call
- setup. The NPDB can be integrated with the signaling node or be
- accessed via an API locally or by a query to a remote NPDB using
- a proprietary protocol or the schemes described above.
-
-
- Wireline switches have the choice of using either (a), (b), or (e).
- IS-41 based wireless switches have the choice of using (a), (b),
- (c), or (e). PCS1900 wireless switches have the choice of using
- (a), (b), (d), or (e). In the United States, service provider
- portability will be supported by both the wireline and wireless
- systems, not only within the wireline or wireless domain but also
- across the wireline/wireless boundary. However, this is not true in
- Europe where service provider portability is usually supported only
- within the wireline or wireless domain, not across the
- wireline/wireless boundary due to explicit use of service-specific
- number range prefixes. The reason is to avoid caller confusion
- about the call charge. GSM systems in Europe are assigned
- distinctive destination network codes, and the caller pays a higher
- charge when calling a GSM directory number.
-
-
-6.2 Europe
-
- One of the following three interfaces can be used to query an NPDB:
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 12
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
-
- (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is
- carried on top of the protocol stack that includes the ITU-TS
- MTP Levels 1 through 3, ITU-TS SCCP, and ITU-TS TCAP.
-
- (b) Capability Set 2 (CS2) of the ITU-TS INAP [CS2], which is
- carried on top of the protocol stack that includes the ITU-TS
- MTP Levels 1 through ITU-TS MTP Levels 1 through 3, ITU-TS SCCP,
- and ITU-TS TCAP.
-
- (c) ISUP triggerless translation. NP translations are performed
- transparently to the switching network by the signaling network
- (e.g. STPs or signaling gateways). ISUP IAM messages are
- examined to determine if the CdPN field has already been
- translated, and if not, an NPDB query is performed, and the
- appropriate parameters in the IAM message modified to reflect
- the results of the translation. The modified IAM message is
- forwarded by the signaling node on to the designated DPC in a
- transparent manner to continue call setup.
-
-
- Wireline switches have the choice of using either (a), (b), or (c);
- however, all the implementations in Europe so far are based on CS1.
- As indicated earlier that number portability in Europe does not go
- across the wireline/wireless boundary. The wireless switches can
- also use (a) or (b) to query the NPDBs if those NPDBs contains
- ported wireless directory numbers. The term "Mobile Number
- Portability (MNP)" is used for the support of service provider
- portability by the GSM networks in Europe.
-
- In most, if not all, cases in Europe, the calls to the wireless
- directory numbers are routed to the wireless donor network first.
- Over there, an internal NPDB is queried to determine whether the
- dialed wireless directory number has been ported out or not. In
- this case, the interface to the internal NPDB is not subject to
- standardization.
-
- MNP in Europe can also be supported via MNP Signaling Relay Function
- (MNP-SRF). Again, an internal NPDB or a database integrated at the
- MNP-SRF is used to modify the SCCP Called Party Address parameter in
- the GSM MAP messages so that they can be re-directed to the wireless
- serving network. Call routing involving MNP will be explained in
- Section 7.2.
-
-
-7. Call Routing in the NP Environment
-
- This section discusses the call routing after the routing
- information has been retrieved either through an NPDB query or an
- internal database lookup at the donor switch, or from the Integrated
- Services Digital Network User Part (ISUP) signaling message (e.g.,
- for the Dropback scheme). For the ACQ, QoR and Dropback schemes, it
- is the Originating Network that has the routing information and is
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 13
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- ready to route the call. For the OR scheme, it is the donor network
- that has the routing information and is ready to route the call.
-
- A number of triggering schemes may be employed that determine where
- in the call path the NPDB query is performed. In the U.S. an ôN-1ö
- policy is used, which essentially says that for domestic calls, the
- originating local carriers performs the query, otherwise, the long
- distance carrier is expected to. To ensure independence of the
- actual trigger policy employed in any one carrier, forward call
- signaling is used to flag that an NPDB query has already been
- performed and to therefore suppress any subsequent NP triggers that
- may be encountered in downstream switches, in downstream networks.
- This allows the earliest able network in the call path to perform
- the query without introducing additional costs and call setup delays
- were redundant queries performed downstream.
-
-
-7.1 U.S. and Canada
-
- In the U.S. and Canada, a ten-digit North American Numbering Plan
- (NANP) number called Location Routing Number (LRN) is assigned to
- every switch involved in NP. In the NANP, a switch is not reachable
- unless it has a unique number range (CO code) assigned to it.
- Consequently, the LRN for a switch is always assigned out of a CO
- code that is assigned to that switch.
-
- The LRN assigned to a switch currently serving a particular ported
- telephone number is returned as the network routing address in the
- NPDB response. The service portability scheme that was adopted in
- the North America is very often referred to as the LRN scheme or
- method.
-
- LRN serves as a network address for terminating calls served off
- that switch using ported numbers. The LRN is assigned by the switch
- operator using any of the unique CO codes (NPA+NXX) assigned to that
- switch. The LRN is considered a non-dialable address, as the same
- 10-digit number value may be assigned to a line on that switch. A
- switch may have more than one LRN.
-
- During call routing/processing, a switch performs an NPDB query to
- obtain the LRN associated with the dialed directory number. NPDB
- queries are performed for all the dialed directory numbers whose
- NPA+NXX codes are marked as portable NPA+NXX at that switch. When
- formulating the ISUP Initial Address Message (IAM) to be sent to the
- next switch, the switch puts the ten-digit LRN in the ISUP Called
- Party Number (CdPN) parameter and the originally dialed directory
- number in the ISUP Generic Address parameter (GAP). A new code in
- the GAP was defined to indicate that the address information in the
- GAP is the dialed directory number. A new bit in the ISUP Forward
- Call Indicator (FCI) parameter, the Ported Number Translation
- Indicator (PNTI) bit, is set to imply that NPDB query has already
- been performed. All the switches in the downstream will not perform
- the NPDB query if the PNTI bit is set.
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 14
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
-
- When the terminating switch receives the IAM and sees the PNTI bit
- in the FCI parameter set and its own LRN in the CdPN parameter, it
- retrieves the originally dialed directory number from the GAP and
- uses the dialed directory number to terminate the call.
-
- A dialed directory number with a portable NPA+NXX does not imply
- that directory number has been ported. The NPDBs currently do not
- store records for non-ported directory numbers. In that case, the
- NPDB will return the same dialed directory number instead of the
- LRN. The switch will then set the PNTI bit but keep the dialed
- directory number in the CdPN parameter.
-
- In the real world environment, the Originating Network is not always
- the one that performs the NPDB query. For example, it is usually
- the long distance carriers that query the NPDBs for long distance
- calls. In that case, the Originating Network operated by the local
- exchange carrier (LEC) simply routes the call to the long distance
- carrier that is to handle that call. A wireless network acting as
- the Originating Network can also route the call to the
- interconnected local exchange carrier network if it does not want to
- support the NPDB interface at its mobile switches.
-
-
-7.2 Europe
-
- In Europe, a routing number is prefixed to the dialed directory
- number. The ISUP CdPN parameter in the IAM will contain the routing
- prefix and the dialed directory number. For example, United Kingdom
- uses routing prefixes with the format of 5XXXXX and Italy uses
- C600XXXXX as the routing prefix. The networks use the information
- in the ISUP CdPN parameter to route the call to the New/Current
- Serving Network.
-
- The routing prefix can identify the Current Serving Network or the
- Current Serving Switch of a ported number. For the former case,
- another query to the "internal" NPDB at the Current Serving Network
- is required to identify the Current Serving Switch before routing
- the call to that switch. This shields the Current Serving Switch
- information for a ported number from the other networks at the
- expense of an additional NPDB query. Another routing number, may be
- meaningful within the Current Serving Network, will replace the
- previously prefixed routing number in the ISUP CdPN parameter. For
- the latter case, the call is routed to the Current Serving Switch
- without an additional NPDB query.
-
- When the terminating switch receives the IAM and sees its own
- routing prefix in the CdPN parameter, it retrieves the originally
- dialed directory number after the routing prefix, and uses the
- dialed directory number to terminate the call.
-
- In addition to the addition of the routing prefix to the CdPN
- parameter, some other information may be added/modified as is listed
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 15
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- in the draft ITU-T Recommendation Q.769.1 [ISUP]. Those
- enhancements in the ISUP to support number portability are briefly
- described below.
-
- Three methods can be used to transport the Directory Number (DN) and
- the Routing Number (RN):
-
- (a) Two separate parameters with the CdPN parameter containing the
- RN and a new Called Directory Number (CdDN) parameter containing
- the DN. A new value for the Nature of Address (NOA) indicator in
- the CdPN parameter is defined to indicate that the RN is in the
- CdPN parameter. The switches use the CdPN parameter to route the
- call as is done today.
-
- (b) Two separate parameters with the CdPN parameter containing the
- DN and a new Network Routing Number (NRN) parameter containing
- the RN. This method requires that the switches use the NRN
- parameter to route the call.
-
- (c) Concatenated parameter with the CdPN parameter containing the RN
- plus the DN. A new Nature of Address (NOA) indicator in the CdPN
- parameter is defined to indicate that the RN is concatenated with
- the DN in the CdPN parameter. Some countries may not use new NOA
- value because the routing prefix does not overlap with the dialed
- directory numbers. But if the routing prefix overlaps with the
- dialed directory numbers, a new NOA value must be assigned.
- Spain uses "XXXXXX" as the routing prefix to identify the new
- serving network and uses a new NOA value of 126.
-
- There is also a network option to add a new ISUP parameter called
- Number Portability Forwarding Information parameter. This parameter
- has a four-bit Number Portability Status Indicator field that can
- provide an indication whether number portability query is done for
- the called directory number and whether the called directory number
- is ported or not if the number portability query is done.
-
- Please note that all those enhancements are for national use. This
- is because number portability is supported within a nation. Within
- each nation, the telecommunications industry or the regulatory
- bodies can decide which method or methods to use. Number
- portability related parameters and coding are never passed across
- the national boundaries.
-
- As indicated earlier, an originating wireless network can query the
- NPDB and concatenate the RN with DN in the CdPN parameter and route
- the call directly to the Current Serving Network.
-
- If NPDBs do not contain information about the wireless directory
- numbers, the call, originated from either a wireline or a wireless
- network, will be routed to the Wireless donor network. Over there,
- an internal NPDB is queried to retrieve the RN that then is
- concatenated with the DN in the CdPN parameter.
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 16
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- If MNP-SRF is supported, the Gateway Mobile Services Switching
- Center (GMSC) at the wireless donor network, when receiving a call
- from the wireline network, can send the GSM MAP Send Routing
- Information (SRI) message to the MNP-SRF. The MNP-SRF interrogates
- an internal or integrated NPDB for the RN of the MNP-SRF of the
- wireless Current Serving Network and prefixes the RN to the dialed
- wireless directory number in the global title address information in
- the SCCP Called Party Address (CdPA) parameter. This SRI message
- will be routed to the MNP-SRF of the wireless Current Serving
- Network, which then responds with an acknowledgement by providing
- the RN plus the dialed wireless directory number as the Mobile
- Station Roaming Number (MSRN). The GMSC of the wireless donor
- network formulates the ISUP IAM with the RN plus the dialed wireless
- directory number in the CdPN parameter and routes the call to the
- wireless Current Serving Network. A GMSC of the wireless Current
- Serving Network receives the call and sends an SRI message to the
- associated MNP-SRF where the global title address information of the
- SCCP CdPA parameter contains only the dialed wireless directory
- number. The MNP-SRF then replaces the global title address
- information in the SCCP CdPA parameter with the address information
- associated with a Home Location Register (HLR) that hosts the dialed
- wireless directory number and forwards the message to that HLR after
- verifying that the dialed wireless directory number is a ported-in
- number. The HLR then returns an acknowledgement by providing an
- MSRN for the GMSC to route the call to the MSC that currently serves
- the mobile station that is associated with the dialed wireless
- directory number. Please see [MNP] for details and additional
- scenarios.
-
-
-8. NP Implementations for Geographic E.164 Numbers
-
- This section shows the known SPNP implementations worldwide.
-
-
-
- +-------------+----------------------------------------------------+
- + Country + SPNP Implementation +
- +-------------+----------------------------------------------------+
- + Argentina + Analyzing operative viability now. Will determine +
- + + whether portability should be made obligatory +
- + + after a technical solution has been determined. +
- +-------------+----------------------------------------------------+
- + Australia + NP supported by wireline operators since 11/30/99. +
- + + NP among wireless operators in March/April 2000, +
- + + but may be delayed to 1Q01. The access provider +
- + + or long distance provider has the obligation to +
- + + route the call to the correct destination. The +
- + + donor network is obligated to maintain and make +
- + + available a register of numbers ported away from +
- + + its network. Telstra uses onward routing via an +
- + + on-switch solution. +
- +-------------+----------------------------------------------------+
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 17
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- + Austria + Uses onward routing at the donor network. Routing +
- + + prefix is "86xx" where "xx" identifies the +
- + + recipient switch. +
- +-------------+----------------------------------------------------+
- + Belgium + ACQ selected by the industry. Routing prefix is +
- + + "Cxxxx" where "xxxx" identifies the recipient +
- + + switch. Another routing prefix is "C00xx" with "xx"+
- + + identifying the recipient network. Plan to use NOA+
- + + to identify concatenated numbers and abandon the +
- + + hexadecimal routing prefix. +
- +-------------+----------------------------------------------------+
- + Brazil + Considering NP for wireless users. +
- +-------------+----------------------------------------------------+
- + Chile + There has been discussions lately on NP. +
- +-------------+----------------------------------------------------+
- + Colombia + There was an Article 3.1 on NP to support NP prior +
- + + to December 31, 1999 when NP becomes technically +
- + + possible. Regulator has not yet issued regulations +
- + + concerning this matter. +
- +-------------+----------------------------------------------------+
- + Denmark + Uses ACQ. Routing number not passed between +
- + + operators; however, NOA is set to "112" to +
- + + indicate "ported number." QoR can be used based +
- + + on bilateral agreements. +
- +-------------+----------------------------------------------------+
- + Finland + Uses ACQ. Routing prefix is "1Dxxy" where "xxy" +
- + + identifies the recipient network and service type. +
- +-------------+----------------------------------------------------+
- + France + Uses onward routing. Routing prefix is "Z0xxx" +
- + + where "xxx" identifies the recipient switch. +
- +-------------+----------------------------------------------------+
- + Germany + The originating network needs to do necessary +
- + + rerouting. Operators decide their own solution(s).+
- + + Deutsche Telekom uses ACQ. Routing prefix is +
- + + "Dxxx" where "xxx" identifies the recipient +
- + + network. +
- +-------------+----------------------------------------------------+
- + Hong Kong + Recipient network informs other networks about +
- + + ported-in numbers. Routing prefix is "14x" where +
- + + "14x" identifies the recipient network, or a +
- + + routing number of "4x" plus 7 or 8 digits is used +
- + + where "4x" identifies the recipient network and +
- + + the rest of digits identify the called party. +
- +-------------+----------------------------------------------------+
- + Ireland + Operators choose their own solution but use onward +
- + + routing now. Routing prefix is "1750" as the intra-+
- + + network routing code (network-specific) and +
- + + "1752xxx" to "1759xxx" for GNP where "xxx" +
- + + identifies the recipient switch. +
- +-------------+----------------------------------------------------+
- + Italy + Uses onward routing. Routing prefix is "C600xxxxx" +
- + + where "xxxxx" identifies the recipient switch. +
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 18
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- + + Telecom Italia uses IN solution and other operators+
- + + use on-switch solution. +
- +-------------+----------------------------------------------------+
- + Japan + Uses onward routing. Donor switch uses IN to get +
- + + routing number. +
- +-------------+----------------------------------------------------+
- + Mexico + NP is considered in the Telecom law; however, the +
- + + regulator (Cofetel) or the new local entrants have +
- + + started no initiatives on this process. +
- +-------------+----------------------------------------------------+
- + Netherlands + Operators decide NP scheme to use. Operators have +
- + + chosen ACQ or QoR. KPN implemented IN solution +
- + + similar to U.S. solution. Routing prefix is not +
- + + passed between operators. +
- +-------------+----------------------------------------------------+
- + Norway + OR for short-term and ACQ for long-term. QoR is +
- + + optional. Routing prefix can be "xxx" with NOA=8, +
- + + or "142xx" with NOA=3 where "xxx" or "xx" +
- + + identifies the recipient network. +
- +------------ +----------------------------------------------------+
- + Peru + Wireline NP may be supported in 2001. +
- +-------------+----------------------------------------------------+
- + Portugal + No NP today. +
- +-------------+----------------------------------------------------+
- + Spain + Uses ACQ. Telefonica uses QoR within its network. +
- + + Routing prefix is "xxyyzz" where "xxyyzz" +
- + + identifies the recipient network. NOA is set to +
- + + 126. +
- +-------------+----------------------------------------------------+
- + Sweden + Standardized the ACQ but OR for operators without +
- + + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" +
- + + with NOA=3 where "xxx" identifies the recipient +
- + + network. But operators decide NP scheme to use. +
- + + Telia uses onward routing between operators. +
- +-------------+----------------------------------------------------+
- + Switzerland + Uses OR now and QoR in 2001. Routing prefix is +
- + + "980xxx" where "xxx" identifies the recipient +
- + + network. +
- +-------------+----------------------------------------------------+
- + UK + Uses onward routing. Routing prefix is "5xxxxx" +
- + + where "xxxxx" identifies the recipient switch. NOA +
- + + is 126. BT uses the dropback scheme in some parts +
- + + of its network. +
- +-------------+----------------------------------------------------+
- + US + Uses ACQ. "Location Routing Number (LRN)" is used +
- + + in the Called Party Number parameter. Called party+
- + + number is carried in the Generic Address Parameter +
- + + Use a PNTI indicator in the Forward Call Indicator +
- + + parameter to indicate that NPDB dip has been +
- + + performed. +
- +-------------+----------------------------------------------------+
-
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 19
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
-9. Number Conservation Methods Enabled by NP
-
- In addition to porting numbers NP provides the ability for number
- administrators to assign numbering resources to operators in smaller
- increments. Today it is common for numbering resources to be
- assigned to telephone operators in a large block of consecutive
- telephone numbers (TNs). For example, in North America each of
- these blocks contains 10,000 TNs and is of the format NXX+0000 to
- NXX+9999. Operators are assigned a specific NXX, or block. That
- operator is referred to as the block holder. In that block there
- are 10,000 TNs with line numbers ranging from 0000 to 9999.
-
- Instead of assigning an entire block to the operator NP allows the
- administrator to assign a sub-block or even an individual telephone
- number. This is referred to as block pooling and individual
- telephone number (ITN) pooling, respectively.
-
-
-9.1 Block Pooling
-
- Block Pooling refers to the process whereby the number administrator
- assigns a range of numbers defined by a logical sub-block of the
- existing block. Using North America as an example, block pooling
- would allow the administrator to assign sub-blocks of 1,000 TNs to
- multiple operators. That is, NXX+0000 to NXX+0999 can be assigned
- to operator A, NXX+1000 to NXX+1999 can be assigned to operator B,
- NXX-2000 to 2999 can be assigned to operator C, etc. In this
- example block pooling divides one block of 10,000 TNs into ten
- blocks of 1,000 TNs.
-
- Porting the sub-blocks from the block holder enables block pooling.
- Using the example above operator A is the block holder, as well as,
- the holder of the first sub-block, NXX+0000 to NXX+0999. The second
- sub-block, NXX+1000 to NXX+1999, is ported from operator A to
- operator B. The third sub-block, NXX+2000 to NXX+2999, is ported
- from operator A to operator C, and so on. NP administrative
- processes and call processing will enable proper and efficient
- routing.
-
- From a number administration and NP administration perspective block
- pooling introduces a new concept, that of the sub-block holder.
- Block pooling requires coordination between the number
- administrator, the NP administrator, the block holder, and the sub-
- block holder. Block pooling must be implemented in a manner that
- allows for NP within the sub-blocks. Each TN can have a different
- serving operator, sub-block holder, and block holder.
-
-
-9.2 ITN Pooling
-
- ITN pooling refers to the process whereby the number administrator
- assigns individual telephone numbers to operators. Using the North
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 20
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- American example, one block of 10,000 TNs can be divided into 10,000
- ITNs. ITN is more commonly deployed in freephone services.
-
- In ITN the block is not assigned to an operator but to a central
- administrator. The administrator then assigns ITNs to operators.
- NP administrative processes and call processing will enable proper
- and efficient routing.
-
-
-10. Conclusion
-
- There are three general areas of impact to IP telephony work-in-
- progress at IETF:
-
- 1. Interoperation between NP in GSTN and IP telephony
- 2. NP implementation or emulation in IP telephony
- 3. Interconnection to NP administrative environment
-
- A good understanding of how number portability is supported in the
- GSTN is important when addressing the interworking issues between IP
- based networks and the GSTN. This is especially important when the
- IP based network needs to route the calls to the GSTN. As shown in
- Section 6, there are a variety of standards with various protocol
- stacks for the switch-to-NPDB interface. Not only that, the
- national variations of the protocol standards make it very
- complicate to deal with in a global environment. If an entity in
- the IP-based network needs to query those existing NPDBs for routing
- number information to terminate the calls to the destination GSTN,
- it would be impractical, if not an impossible, job for that entity
- to support all those interface standards to access the NPDBs in many
- countries.
-
- Several alternatives may address this particular problem. One
- alternative is to use certain entities in the IP-based networks for
- dealing with NP query, similar to the International Switches that
- are used in the GSTN to interwork different national ISUP
- variations. This will force signaling information associated with
- the calls to certain NP-capable networks in the terminating GSTN to
- be routed to those IP entities that support the NP functions. Those
- IP entities then query the NPDBs in the terminating country. This
- will limit the number of NPDB interfaces that certain IP entities
- need to support. Another alternative can be to define a "common"
- interface to be supported by all the NPDBs so that all the IP
- entities use that standardized protocol to query them. The
- existing NPDBs can support this additional interface, or new NPDBs
- can be deployed that contain the same information but support the
- common IP interface. The candidates for such a common interface
- include Lightweight Directory Access Protocol (LDAP) and SIP
- [SIP](e.g., using the SIP redirection capability). Certainly
- another possibility is to use interworking function to convert from
- one protocol to another.
-
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 21
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- IP-based networks can handle the domestic calls between two GSTNs.
- If the originating GSTN has performed NPDB query, SIP will need to
- transport and make use of some of the ISUP signaling information
- even if ISUP signaling may be encapsulated in SIP. Also, IP-based
- networks may perform the NPDB queries, as the N-1 carrier. In that
- case, SIP also needs to transport the NP related information while
- the call is being routed to the destination GSTN. There are three
- pieces of NP related information that SIP needs to transport. They
- are 1) the called directory number, 2) a routing number, and 3) a
- NPDB dip indicator. The NPDB dip indicator is needed so that the
- terminating GSTN will not perform another NPDB dip. The routing
- number is needed so that it is used to route the call to the
- destination network or switch in the destination GSTN. The called
- directory number is needed so that the terminating GSTN switch can
- terminate the call. When the routing number is present, the NPDB
- dip indicator may not be present because there are cases where
- routing number is added for routing the call even if NP is not
- involved. One issue is how to transport the NP related information
- via SIP. The SIP Universal Resource Locator (URL) is one mechanism.
- Another better choice may be to add an extension to the "tel" URL
- [TEL] that is also supported by SIP. If the called directory is +1-
- 202-533-1234, and its associated routing number is +1-202-544-0000,
- the "tel" URL may look like tel:+1-202-533-1234;rn=+1-202-544-
- 0000;npdi=yes where "rn" stands for "routing number" and "npdi"
- stands for "NPDB dip indicator." "rn" and "npdi" will be two new
- parameters to be added as extensions to the "tel" URL to support NP.
- Since the "fax" URL is similar to the "tel" URL where NP can impact
- the fax calls as well as the telephone calls, the same extensions to
- the "tel" URL need to be applied to the "fax" URL as well. Please
- see [TELNP] for the proposed extensions to the "tel" URL to support
- NP and freephone service. Those extensions to the "tel" and "fax"
- URLs will be automatically supported by SIP because they can be
- carried as the optional parameters in the user portion of the "sip"
- URL.
-
- For a called directory number that belongs to a country that
- supports NP, and if the IP-based network is to perform the NPDB
- query, the logical step is to perform the NPDB dip first to retrieve
- the routing number and use that routing number to select the correct
- IP telephony gateways that can reach the serving switch that serves
- the called directory number. Therefore, if the "rn" parameter is
- present in the "tel" URL in the SIP INVITE message, it instead of
- the called directory number should be used for making routing
- decisions. If "rn" is not present, then the dialed directory number
- can be used as the routing number for making routing decisions.
-
- Telephony Routing Information Protocol (TRIP) [TRIP] is a policy
- driven inter-administrative domain protocol for advertising the
- reachability of telephony destinations between location servers, and
- for advertising attributes of the routes to those destinations.
- With the NP in mind, it is very important to know that it is the
- routing number, if present, not the called directory number that
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 22
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- should be used to check against the TRIP tables for making the
- routing decisions.
-
- Overlap signaling exists in the GSTN today. For a call routing from
- the originating GSTN to the IP-based network that involves overlap
- signaling, NP will impact the call processing within the IP-based
- networks if they must deal with the overlap signaling. The entities
- in the IP-based networks that are to retrieve the NP information
- (e.g., the routing number) must collect a complete called directory
- number information before retrieving the NP information for a ported
- number. Otherwise, the information retrieval won't be successful.
- This is an issue for the IP-based networks if the originating GSTN
- does not handle the overlap signaling and collect the complete
- called directory number.
-
- The IETF enum working group is defining the use of Domain Name
- System (DNS) for identifying available services associated with a
- particular E.164 number [ENUM]. [ENUMPO] outlines the principles
- for the operation of a telephone number service that resolves
- telephone numbers into Internet domain name addresses and service-
- specific directory discovery. [ENUMPO] implements a three-level
- approach where the first level is the mapping of the telephone
- number delegation tree to the authority to which the number has been
- delegated, the second level is the provision of the requested DNS
- resource records from a service registrar, and the third level is
- the provision of service specific data from the service provider
- itself. NP certainly must be considered at the first level because
- the telephony service providers do not "own" or control the
- telephone numbers under the NP environment; therefore, they may not
- be the proper entities to have the authority for a given E.164
- number. Not only that, the donor network should not be relied on to
- reach the delegated authority during the DNS process because there
- is a regulatory requirement on NP in some countries. The delegated
- authority for a given E.164 number is likely to be an entity
- designated by the end user that owns/controls a specific telephone
- number or a third-party designated by the end-user or by the
- industry.
-
- The IP-based networks also may need to support some forms of number
- portability in the future if E.164 numbers [E164] are assigned to
- the IP-based end users. One method is to assign a GSTN routing
- number for each IP-based network domain or entity in a NP-capable
- country. This may increase the number of digits in the routing
- number to incorporate the IP entities and impact the existing
- routing in the GSTN. Another method is to associate each IP entity
- with a particular GSTN gateway. At that particular GSTN gateway,
- the called directory number then is used to locate the IP-entity
- that serves that dialed directory number. Yet, another method can
- be to assign a special routing number so that the call to an end
- user currently served by an IP entity is routed to the nearest GSTN
- gateway. The called directory number then is used to locate the IP-
- entity that serves that dialed directory number. Then a mechanism
- is developed for the IP-based network to locate the IP entity that
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 23
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- serves a particular dialed directory number. Many other types of
- networks use E.164 numbers to identify the end users or terminals in
- those networks. Number portability among GSTN, IP-based network and
- those various types of networks may also need to be supported in the
- future.
-
-11. References
-
- [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability -
- Operator Services Switching Systems," April 1999.
-
- [ANSI SS] ANSI Technical Requirements No. 2, "Number Portability -
- Switching Systems," April 1999.
-
- [ANSI DB] ANSI Technical Requirements No. 3, "Number Portability
- Database and Global Title Translation," April 1999.
-
- [CS1] ITU-T Q-series Recommendations - Supplement 4, "Number
- portability Capability set 1 requirements for service provider
- portability (All call query and onward routing)," May 1998.
-
- [CS2] ITU-T Q-series Recommendations - Supplement 5, "Number
- portability -Capability set 2 requirements for service provider
- portability (Query on release and Dropback)," March 1999.
-
- [E164] ITU-T Recommendation E.164, "The International Public
- Telecommunications Numbering Plan," 1997.
-
- [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916.
-
- [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific
- Provisioning: Principles of Operations," April 27, 2000.
-
- [GSM] GSM 09.02: "Digital cellular telecommunications system (Phase
- 2+); Mobile Application Part (MAP) specification".
-
-
- [IS41] TIA/EIA IS-756 Rev. A, "TIA/EIA-41-D Enhancements for
- Wireless Number Portability Phase II (December 1998)"Number
- Portability Network Support," April 1998.
-
- [ISUP] ITU-T COM 11-R 162-E, Draft Recommendation Q.769.1,
- "Signaling System No. 7 - ISDN User Part Enhancements for the
- Support of Number Portability," May 1999.
-
- [MNP] Draft GSM 03.66 V7.2.0 (1999-11) European Standard
- (Telecommunications series) Digital cellular telecommunications
- system (Phase 2+); Support of Mobile Number Portability (MNP);
- Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0
- Release 1998).
-
-
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 24
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- [RFC] Scott Bradner, RFC2026, "The Internet Standards Process --
- Revision 3," October 1996.
-
- [TEL] A. Vaha-Sipila, RFC2806, "URLs for Telephone Calls," April
- 2000.
-
- [TELNP] J. Yu, draft-yu-tel-url-02.txt, "Extensions to the "tel" and
- "fax" URLs to support Number Portability and Freephone
- Service," February 9, 2001.
-
- [SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, RFC
- 2543, "SIP: Session Initiation Protocl," March 1999.
-
- [TRIP] J. Rosenberg, H. Salama and M. Squire, draft-ietf-iptel-trip-
- 02.txt, "Telephony Routing Information Protocol (TRIP)," May
- 2000.
-
-
-12. Acknowledgments
-
- The authors would like to thank Monika Muench for providing
- reference information on ISUP and MNP.
-
-
-13. Author's Addresses
-
- Mark D. Foster
- NeuStar, Inc.
- 1120 Vermont Avenue, NW,
- Suite 550
- Washington, D.C. 20005
- United States
-
- Phone: +1-202-533-2800
- Fax: +1-202-533-2976
- Email: mark.foster@neustar.com
-
-
- Tom McGarry
- NeuStar, Inc.
- 1120 Vermont Avenue, NW,
- Suite 550
- Washington, D.C. 20005
- United States
-
- Phone: +1-202-533-2810
- Fax: +1-202-533-2987
-
-
- James Yu
- NeuStar, Inc.
- 1120 Vermont Avenue, NW,
- Suite 550
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 25
-\f
-Number Portability in the GSTN: An Overview February 9, 2000
-
-
- Washington, D.C. 20005
- United States
-
- Phone: +1-202-533-2814
- Fax: +1-202-533-2987
- Email: james.yu@neustar.com
-
-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 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-<Foster,McGarry,Yu> Informational - Expiration in August 9, 2001 26
-\f
+++ /dev/null
-
-
-Telephone Number Mapping A. Brown
-Internet Draft Nortel Networks
-Document: <draft-ietf-enum-operation-02.txt> Greg Vaudreuil
- Lucent Technologies
- February 23, 2001
-
-
- ENUM Service Reference Model
-
-
-
-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 document outlines the principles for the operation of a
- telephone number directory service. This service provides for the
- resolution of telephone numbers into Internet domain name addresses
- and service specific directory discovery.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Brown, Vaudreuil Expires August 2001 1
-\f ENUM Reference Model February 23, 2001
-
-
- Table of Contents
-
- 1. Abstract........................................................1
- 2. Introduction....................................................2
- 3. Scope...........................................................2
- 4. Overview........................................................4
-
- 4.1 Relationship with Dynamic Services.............................4
- 4.2 Number Portability.............................................5
- 5. The ENUM Service................................................5
- 5.1 First Tier: Determining the Service Registrar..................5
- 5.2 Second Tier: Retrieving Resource records.......................6
- 5.3 Third Tier: Service-Specific Queries...........................6
- 6. Interesting Numbering Topologies...............................8
- 6.1 Sub-addressing.................................................8
-
- 6.2 Default and Range-based Service Records........................9
- 6.3 Permissive dialing for dialing plan transitions...............9
- 7 Illustrative System Examples....................................10
- 7.1 Example: Hypothetical Reachme Service.........................10
- 7.2 Example: SIP Call Setup Service Request.......................11
- 8. Security Considerations........................................12
- 9. References.....................................................13
-
- 10. Acknowledgments...............................................13
- 11. Author's Addresses............................................13
- 12. Full Copyright Statement......................................14
- Appendix:.........................................................15
- Changes from draft-ietf-enum-operations-00.txt....................15
- Changes from draft-ietf-enum-operations-01.txt....................15
-
-
-2. Introduction
-
- This document outlines the principles for the operation of a
- telephone number directory service. This service provides for the
- resolution of telephone numbers into the address of a service
- specific directory or where applicable for a given service, directly
- into a service-specific endpoint addresses.
-
- This directory service uses the algorithms and methods described in
- RFC 2916.
-
- Please send comments on this document to the ENUM working group.
-
-3. Scope
-
- This document defines the reference architecture behind the ENUM
- protocols necessary to implement a telephone number-based Internet
- directory system. This solution enables an extensible set of
- services to be provided for a given telephone number. Example
- services may include IP telephony, store and forward or real-time
- Internet Fax, VPIM voice messaging, Internet paging, geographic
- phone location, and many others. Each service is to be separately
- defined and identified using a unique, registered service
- identifier.
-
-
-
- Brown, Vaudreuil Expires August 2001 2
-\f ENUM Reference Model February 23, 2001
-
-
- This document does not specify the particulars of any telephone
- number-based service. In particular, it does not describe how phone
- calls are placed, routed, or terminated or how voice, fax, pager, or
- email messages are routed.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Brown, Vaudreuil Expires August 2001 3
-\f ENUM Reference Model February 23, 2001
-
-
-4. Overview
-
- This telephone number-based directory system implements a three-tier
- information model; the first two constituting the ENUM service.
- This abstract model is based on analysis of pre-existing
- administrative structures, generalized service requirements, and the
- capabilities of candidate protocols. This model does not itself
- specify an administrative model, but provides a reference to guide
- implementers or conforming clients and servers.
- The mechanics of the ENUM service are specified in [ENUM].
-
- The first tier is the mapping of the telephone number delegation
- tree to the service registrar. Conceptually, this delegated
- authority knows nothing about service-specific information
- associated with the telephone number but provides a reference to
- the service registrar that does know the specific information. Where
- this services registrar is different from the delegated authority, a
- query redirection from the delegated authority to the name server of
- the service registrar for a given telephone number is necessary.
-
-
- The second tier is the set of service records themselves. The
- service records indicate which of several services may be available
- for a given telephone number. Multiple records indicating redundant
- or competitive service providers may be provided. The set of records
- may be provided or modified by any number of service providers. The
- ENUM service defines these records to be NAPTR records yielding a
- valid URL for a potentially useful service. It is up to the client
- initiating the service request to sort through the set of NAPTR
- records to determine which services are appropriate for the intended
- action.
-
- The service registrar is conceptually responsible for maintaining
- the set of service records for a given telephone number. Because
- there may be multiple service providers for a given telephone
- number, conceptually this registrar of services assumes a role of
- managing service registrations and arbitrating conflicts between
- service providers.
-
- If necessary, an additional service-specific tier of information can
- be provided by the service provider itself. This tier provides
- specific attributes including any necessary attributes to place a
- call, route a message, validate capabilities, or other data
- necessary for that service that are known only by the provider of
- that specific service.
-
-4.1 Relationship with Dynamic Services
-
- The telephone number delegation information changes infrequently.
- However, when a change to this data is made, the information must be
- rapidly propagated through the directory system. Inconsistencies
- between the authoritative data and cached data may result in loss of
- service, misrouting of communications, and/or service loops. An
- effective ENUM service requires that DNS time-to-live fields be set
- to an appropriate value consistent with the telephone number
- reassignment policies and service record update intervals.
-
- Use of the ENUM system to implement time-of-day and other highly
- dynamic services is discouraged. Where such a service is desired,
- Brown, Vaudreuil Expires August 2001 4
-\f ENUM Reference Model February 23, 2001
-
-
- it is recommended that itself be implemented as part of a service
- indicated by the service records.
-
-4.2 Number Portability
-
- The concept of number portability generally refers to the ability of
- a subscriber to change service providers, service types, or
- locations without changing their telephone number. For a full
- discussion of number portability, see [PORT]. In support of number
- portability, the ENUM service provides mechanism at the three
- conceptual tiers of the ENUM service.
-
- 1. If the telephone number has been re-delegated to another
- authority, and that authority also provides the Tier-1 ENUM
- service, the telephone number can be re-delegated in the ENUM
- service by changing the name server "NS" records to point to the
- new authority. This may be the case where numbers are re-
- delegated from the incumbent service provider to another or to a
- portability authority. The immediately higher delegated authority
- coordinates the transfer.
-
- 2. The service registrar may be reassigned. This may be the case
- where an individual or corporation changes telephony service
- providers and wishes that telephony service provider to also
- provide service registrar functions. The new service registrar
- would recreate the appropriate service specific NAPTR records and
- the delegated authority would coordinate the transfer from one
- registrar to the other.
-
- 3. If a specific service for a given telephone number was changed
- from one provider to another, such as switching telephone
- answering / voice messaging providers, the NATPR record indicating
- the specific service would change. The service registrar would
- coordinate the deletion of the record for the previous service
- provider and the insertion of a record for the new service
- provider.
-
- It is anticipated that in the early stages of an ENUM deployment,
- the delegated authority and the service registrar may be the same
- entity.
-
-5. The ENUM Service
-
-5.1 First Tier: Determining the Service Registrar
-
- The first tier is the mapping of an E.164-formatted international
- telecommunication number into the identity of the service registrar
- for that number. This may or may not involve more than one referral
- in DNS.
-
- The delegation of telephone numbers from the root authority (the
- ITU) down to individuals is a well-established system. While there
- are differing Tier-1 administrative models, to a client they each
- aim to represent in a single tree the trusted relationship between
- the delegated carriers and subsidiary registrars; a necessary
- precondition to ensure protection against various attacks. The
- delegated authority, sub-delegated authority, or individual may
- arrange to have a third-party (e.g., a service provider) list their
-
- Brown, Vaudreuil Expires August 2001 5
-\f ENUM Reference Model February 23, 2001
-
-
- information. In this case the service provider's domain would be
- returned in the ENUM query.
-
- The Internet Domain Name System provides an ideal technology for the
- first-tier directory due to its hierarchical structure, fast
- connectionless queries, and distributed administrative model.
- Earlier experimentation with the TPC.INT remote printing experiment
- has shown how the hierarchical assignment of telephone numbers can
- be mapped directly to the hierarchy of domains within the DNS. The
- ENUM directory uses that approach to map any arbitrary telephone
- number into a single domain name.
-
- ITU standard E.164 defines the structure of the public telephone
- number as follows: country code, followed by nationally significant
- part, followed by sub-address. The country code may be from one to
- three digits, and the total length may be up to 15 digits. The
- nationally significant portion may be arbitrarily divided on any
- number boundary. In many countries numbering plans, the divisions
- are not uniform, that is, the "area codes" or "city codes" may be of
- varying lengths within a single country and the total number of
- digits may be variable. Where supported by the relevant service, an
- optional sub-address of up to four digits may be utilized to
- designate an extension telephone number. Note that while sub-
- addressing is not well supported in GSTN calling, it is more widely
- supported for voice messaging. It is important to note that the
- national long-distance access or international dialing prefix
- sequence is not part of the canonical E.164 number.
-
- Within this delegation flexibility, it is always the case that the
- delegation of authority is always done left-to-right. With this
- assumption, a numbering tree can be built on a digit-by-digit basis
- that can represent any arbitrary hierarchical structure. DNS
- permits the delegation of authority on arbitrary boundaries such
- that a delegation to country code "1", "44", and "972" can all
- coexist under a single numbering plan root. The same applies for
- "service selectors", "area codes", "city codes", "line number", or
- "additional address information " within numbering plans.
-
-5.2 Second Tier: Retrieving Resource records.
-
- The second tier is the request for NAPTR RRs to discover the URL of
- the appropriate service-specific directory such as an LDAP directory
- server, H.323 gatekeeper, or specific endpoint addresses.
-
- The service registrar is responsible for ensuring that multiple
- services may be provided on behalf of a single telephone number,
- potentially by different service providers. This function includes
- an arbiter function to ensure that there is a deterministic instance
- of any given service assigned to a single telephone number. The
- service-specific directory locator function is a new service modeled
- upon existing telco service provisioning models. Long-distance
- carrier selection within the United States is one well-known example
- of a service-specific registration requiring an arbiter function
- within the current network.
-
-5.3 Third Tier: Service-Specific Queries
-
- An additional tier of query may be used to a service-specific
- directory for service-specific information. As indicated in the
- Brown, Vaudreuil Expires August 2001 6
-\f ENUM Reference Model February 23, 2001
-
-
- URI, such a query may include a SIP query to a designated gatekeeper
- or an LDAP query to a designated directory server. This tier is
- specific to the service and is to be described in service-specific
- documents. The service-specific directory is expected to be
- dynamic. It is important that as little coordination as possible be
- required between the directories of innovative and potentially
- competing service-specific providers.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Brown, Vaudreuil Expires August 2001 7
-\f ENUM Reference Model February 23, 2001
-
-
-6. Interesting Numbering Topologies
-
- The following numbering uses require special consideration in the
- provision and use of ENUM services.
-
-6.1 Sub-addressing
-
- The E.164 standard provides for sub-addressing through "additional
- information" within the 16 digits of an E.164 number. This
- information is passed through many telecommunications networks to be
- used by terminal equipment to select between alternate services or
- terminal devices. The sub-address digits are not processed by the
- switching system and are not used by intermediate processes to
- select services or route calls. In many cases, the network-
- numbering infrastructure may be unaware of the existence or use of
- sub-addressing by a given endpoint. Within ENUM, sub-addressing may
- be supported in two ways. The service registrar may explicitly
- provision NAPTR records for each sub-address, or the service
- registrar may provision default records for a range of sub-
- addresses.
-
- Using common DNS server implementations, the registrar may provision
- default records for a block of sub-addresses. A combination of
- explicit entries and default entries may be provided in common DNS
- server implementations using a longest-match algorithm. It is
- important to note that if a NAPTR or any other RR is provisioned for
- a sub-address, then all NAPTR records that are useful for that sub-
- address must also be provisioned.
-
- It is also important to note that numbers with optional sub-
- addresses may be queried without the sub-address component. For
- example, it may be useful to dial an address when placing a PSTN
- telephone call. The telephone number may terminate on an automated
- attendant application that can prompt for the appropriate internal
- extension. However, when placing a SIP call using IP telephony, the
- address plus the sub-address may be queried.
-
- The following set of records for company.com illustrate one
- configuration where a PSTN caller will be directed to the automated
- attendant application whether they dial the number or the number
- plus a sub-address, and whether the sub-address is explicitly
- provisioned or not. Calling using SIP to the explicitly provisioned
- sub-address will result in a direct call to the intended recipient.
-
- Example:
-
- 1.2.3.4.5.6.7.8.9.e164.arpa
- IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654321!" .
- IN NAPTR 10 10 "u" "sip+E2U" "!+(.*)!sip:AA@company.com!" .
-
- *.1.2.3.4.5.6.7.8.9.e164.arpa
- IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654321!" .
- IN NAPTR 10 10 "u" "sip+E2U" "!+(.*)!sip:AA@company.com!" .
-
- 1.0.1.1.2.3.4.5.6.7.8.9.e164.arpa
- IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:joe@company.com!" .
- IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654321!" .
-
-
- Brown, Vaudreuil Expires August 2001 8
-\f ENUM Reference Model February 23, 2001
-
-
-6.2 Default and Range-based Service Records
-
- It is envisioned that a corporation or service provider not subject
- to number portability may wish to maintain a set of default NAPTR
- records for all E.164 telephone numbers within a delegation block.
- Similar to sub-addressing, a service registrar may provision a set
- of NAPTR records for a set of E.164 numbers with similar service
- requirements.
-
- Example:
-
- *.3.4.5.6.7.8.9.164.arpa
- IN NAPTR 102 10 "u" "tel+E2U" "!+(.*)!Tel:+\1" .
- IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:AA@company.com!" .
- IN NAPTR 10 10 "U" "mailto+E2U" \
- "!+(.*)!mailto:+\1@company.com!" .
-
- 1.0.3.4.5.6.7.8.9.164.arpa
- IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654310!" .
- IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:AA@company.com!" .
-
- 2.2.3.4.5.6.7.8.9.164.arpa
- IN NAPTR 102 10 "u" "tel+E2U" "!^.*$!tel:+987654322!" .
- IN NAPTR 10 10 "u" "sip+E2U" "!^.*$!sip:joe@company.com!" .
- IN NAPTR 10 10 "U" "mailto+E2U" \
- "!^.*$!tel:+987654322@company.com!" .
-
- In this example, mail sent to the phone number +987654311 using
- 1.1.3.4.5.6.7.8.9.164.arpa will be sent to +987654311@company.com.
- Mail is explicitly not accepted at the automated attendant number as
- indicted by the lack of a mailto service record. Because extension
- 22 has an explicit NAPTR record for inbound calls via the tel
- record, it must also have an explicit mailto: URL in a NAPTR record.
-
-6.3 Permissive dialing for dialing plan transitions
-
- In the real-world environment, the telephone number hierarchy is
- modified as necessary to prevent number exhaustion and to facilitate
- new services. These re-numberings either insert additional digits
- at arbitrary parts of the previous telephone number or result in the
- re-assignment of a sub-tree of numbers to a new prefix. To avoid
- the operational and social disruption involved with a _flash cut_, a
- practice of _permissive dialing_ has been created. Permissive
- dialing enables and end-user to use either the previous or new
- telephone number for a period of time. During this time, there may
- be two different telephone numbers pointing to the same set of
- service records, or a duplicate set of service records for the new
- and previous number.
-
-
-
-
-
-
-
-
-
-
-
- Brown, Vaudreuil Expires August 2001 9
-\f ENUM Reference Model February 23, 2001
-
-
-7 Illustrative System Examples
-
-7.1 Example: Hypothetical Reachme Service
-
- The following hypothetical service enables an end-user to discover
- the various means by which she can reach a recipient represented by
- their corporate telephone number +1 613-555-1212 using the
- hypothetical "reachme" service. This service is hosted by directly
- by the recipient's corporation.
-
- The telephone number is transformed into a domain name form to be
- used in a DNS query.
-
- 2.1.2.1.5.5.5.3.1.6.1.e164.arpa
-
- Sample configuration file for the top tier delegations from ITU:
-
- 1.e164.arpa. IN NS ns.NANP.phone.net. ;for NANP
- 3.3.e164.arpa. IN NS ns.FR.phone.net. ; for France
- 2.7.9.e164.arpa. IN NS ns.il.phone.net. ; for Israel
-
- Sample configuration file for numbers delegated from the NANP node
- in the DNS tree:
-
- 5.5.5.3.1.6.1.e164.arpa. IN NS ns.Zcorporation.com.
- ;for +1 613 555 XXXX
- Zcorporation is the designated service registrar for the block of
- 100 numbers +1 613 555 12XX. Zcorporation provides the following
- service specific record for all telephone numbers within it's 100
- number block:
-
- *.2.1.5.5.5.3.1.6.1.e164.arpa.
- IN NAPTR 100 10 "u" "ldap+E2U"\
- "$!ldap://ldap1.Zcorporation.com/cn=\1!" .
-
- Assuming the resolver is using non-extended DNS, the query using
- telephone number +1 613 555 1212 for the_reachme service is as
- follows:
-
- QueryType: NAPTR
- QueryName: _ 2.1.2.1.5.5.5.3.1.6.1.e164.arpa.
- Response:
- IN NAPTR 10 10 "u" "Reachme+E2U" \
- "!LDAP:\\ldap1.zcorporation.com\cn=\1!" .
-
- The client can then apply the regular expression to yield an LDAP
- URI of LDAP:\\ldap1.zcorporation.com\cn=16135551212 and then use
- LDAP with the reachme schema to determine the set of communications
- technologies available for +1 613 555 1212.
-
-
-
-
-
-
-
-
-
-
- Brown, Vaudreuil Expires August 2001 10
-\f ENUM Reference Model February 23, 2001
-
-
-7.2 Example: SIP Call Setup Service Request
-
- This example provides resolution of a telephone number to the
- identifier for the SIP gatekeeper designated to support real-time
- calling (Sipphonecall) to 972 555 1313. The telephone number is
- part of a block of ported telephone numbers that have been ported
- out of the donor carriers block to another carrier.
-
- The telephone number is transformed into a domain name form to be
- used in a DNS query.
-
- Sample configuration file for the top tier delegations from ITU:
-
- 1.e164.arpa. IN NS ns.NANP.phone.net. ;for NANP
- 3.3.e164.arpa. IN NS ns.FR.phone.net. ; for France
- 2.7.9.e164.arpa. IN NS ns.il.phone.net. ; for Israel
-
- Sample DNS configuration file for the ported number block serviced
- by the 972 555 number portability authority delegated from the NANP
- node in the DNS tree:
-
- 5.5.5.2.7.9.1.e164.arpa. IN NS ns.972555Port.NANP.phone.net.
- ;for 972 555
-
- The number portability authority manages the delegation on a per-
- telephone number basis. Logically, the ns.972555Port.NANP.phone.net
- has the following record for the telephone number.
-
- 3.1.3.1.5.5.5.2.7.9.1.e164.arpa. IN NS ns.ServiceProviderB.net.
- ;for 972 555 1313
-
- ServiceProviderB provides service registrar functions directly for
- the telephone number. The following configuration entry is provided
- for +1 972 555 1313.
-
-
- 3.1.3.1.5.5.2.7.9.1.ServiceProviderB.net.
- IN NAPTR 10 10 "u" "sip+E2U"\
- "!^.*$!sip:19725551313@ServiceProviderB.net!" .
- The DNS Query and response using telephone number +1 972 555 1313:
-
- QueryType: NAPTR
- QueryName: 3.1.3.1.5.5.5.2.7.9.1.e164.arpa
- Result:
- IN NAPTR 10 10 "u" "sip+E2U" \
- "!^.*$!sip:19725551313@ServiceProviderB.net!" .
-
- The client can now use the SIP protocols to contact the SIP gateway
- to initiate a phone call.
-
-
-
-
-
-
-
-
-
-
- Brown, Vaudreuil Expires August 2001 11
-\f ENUM Reference Model February 23, 2001
-
-
-8. Security Considerations
-
- The following are known security issues taken into consideration in
- the definition of this directory service.
-
- 1. Service provider customer information is very sensitive,
- especially in this time of local phone competition. Service
- providers require the maximum flexibility to protect this data.
-
- 2. Registration of a domain name for the telephone numbers
- delegated to another carrier may result in messages being
- misdirected to the wrong carrier. As subdelegations are
- implemented, the risk that phone numbers delegated to one
- enterprise may be incorrectly pointed at another will increase.
-
- 3. Service providers operate in a regulated environment where
- certain information about subscribers must not be disclosed.
- Telephony services and Voice Messaging are subject to caller-ID
- blocking restrictions, restrictions normally enforced in the
- telephony network. No such protection is available on the
- Internet. The protection of this data is essential, but is up
- to the individual service providers to not disclose this
- information outside of their control.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Brown, Vaudreuil Expires August 2001 12
-\f ENUM Reference Model February 23, 2001
-
-
-9. References
-
- [DNS1] Mockapetris, P., "Domain names - implementation and
- specification", RFC1035, Nov 1987.
-
- [DNS2] Mockapetris, P., "Domain names - concepts and facilities",
- RFC 1034, Nov 1987.
-
- [SRV] Arnt Gulbrandsen, Paul Vixie, Levon Esibov, "A DNS RR for
- specifying the location of services (DNS SRV)", Work in Progress
-
- [E164] ITU, "CCITT Recommendation E.164 (1991), Telephone Network
- and ISDN Operation, Numbering, Routing and Mobile Service -
- Numbering Plan for the ISDN Era."
-
- [TPC1] Malamud, Carl, Rose, Marshall, "Principles of Operation for
- the TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC
- 1530, October 1993.
-
- [VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet
- Mail, Version 2", RFC 2421, September 1998.
-
- [SRV] Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the
- location of services (DNS SRV)", RFC 2052, October 1996.
-
- [REQ] Brown, Anne, "ENUM Requirements", work-in-progress, November
- 1999
-
- [ENUM] Faltstrom, Patrick, "E.164 number and DNS", RFC 2916,
- September 2000.
-
- [NAPTR] M. Mealling, R. Daniel _The Naming Authority Pointer (NAPTR)
- DNS Resource Record_, RFC 2915, September 2000.
-
- [PORT] M. Foster, T. McGarry, j. Yu, _Number Portability in the
- GSTN: An Overview_, Work-in-Progress, July 2000.
-
-10. Acknowledgments
-
-11. Author's Addresses
-
- Anne R. Brown
- Nortel Networks
- P.O. Box 3511, Station C
- Ottawa, ON K1Y 4H7
- Canada
- Phone: +1-613-765-5274
- Fax: +1-613-763-2697
- Email: ARBrown@NortelNetworks.com
-
- Gregory M. Vaudreuil
- Lucent Technologies,
- Communications Application Group
- 17080 Dallas Parkway
- Dallas, TX 75248-1905
- United States
- Phone/Fax: +1-972-733-2722
- Email: GregV@IEEE.org
-
- Brown, Vaudreuil Expires August 2001 13
-\f ENUM Reference Model February 23, 2001
-
-
-
-12. Full Copyright Statement
-
- "Copyright (C) The Internet Society (2001). 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
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Brown, Vaudreuil Expires August 2001 14
-\f ENUM Reference Model February 23, 2001
-
-
-Appendix:
-
-Changes from draft-ietf-enum-operations-00.txt
-
- o Discussion of interesting numbering topologies was added
-
- o Retrieval of NAPTR records are now described in a separate step
- from the determination of a service registrar.
-
- o A new example was created to illustrate ENUM using sub-addressing.
-
-Changes from draft-ietf-enum-operations-01.txt
-
- O Changed the title to more clearly reflect the intent of the
- document.
-
- o Collapsed Level 1 and 2 into a single tier. Aligned the document
- to use the _tier_ terminology.
-
- o Added missing text for dynamic updates.
-
- o Reworked the examples to eliminate all references to the
- controversial DNAME and CNAME redirection.
-
- o Generalized descriptions of the administrative model to avoid
- exclusion of any particular tier-1 approach.
-
- o Corrected various errors in the examples.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Brown, Vaudreuil Expires August 2001 15
-\f
\ No newline at end of file
+++ /dev/null
-
-Internet Draft Naomasa Maruyama
-draft-ietf-idn-aceid-02.txt Yoshiro Yoneya
-Jun 19, 2000 JPNIC
-Expires Dec 19, 2001
-
- Proposal for a determining process of ACE identifier
-
-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
-
- In IETF IDN WG, various kinds of ASCII Compatible Encodings,
-hereafter abbreviated as "ACE", are discussed as methods for realizing
-multilingual domain names (hereafter referred to as "MDN"). Each ACE
-uses a prefix or a suffix as an identifier in order for MDNs to fit
-within the existing ASCII domain name space. In other words,
-acceptance of an ACE proposal as an Internet standard means that the
-existing ASCII domain name space will be partitioned, in order to
-accommodate MDN space.
-
- This document describes possible trouble in the standardization
-process of ACE, and proposes a solution for it.
-
-
-1. Present situation and concern
-
- At present, some specifications relating to MDN specify their own
-ACE identifiers. In these drafts, multilingual domain names encoded
-into ASCII character strings, with the ACE identifiers in their heads
-or tails, are merely ASCII character strings. It is possible
-accidently or intentionally to register a domain name that is not an
-MDN but has the designated ACE identifier string.
-
- If this kind of registration takes place, there is no warranty
-that the domain name will be consistent with MDN semantics.
-Furthermore, there is no warranty that the name, interpreted as an
-MDN, will comply with the registration policies of the registry, when
-the ACE identifier proposal is finally accepted as an Internet
-standard. This might cause problems with name disputes and/or
-revocations.
-
- Therefore, the current situation letting independent ACE proposal
-authors arbitrarily select an ACE identifier, hence permitting domain
-name registrants registrer such names, may hinder deployment of MDN
-technology.
-
-
-2. Selecting ACE identifiers
-
- In order to maintain a smooth standardization process for ACE,
-this document proposes a strategy for selecting and reserving of ACE
-identifiers and a method for assigning them.
-
-
-2.1 The ACE identifier candidates and tentative suspension of
- registering relevant domain names
-
- All strings starting with a combination of two alpha-numericals,
-followed by two hyphens, are defined to be ACE prefix identifier
-candidates. All strings starting with two hyphens followed by two
-alpha-numericals are defined as ACE suffix identifier candidates. ACE
-prefix identifier candidates and ACE suffix identifier candidates are
-collectively called ACE identifier candidates.
-
- All the domain name registries recognized by ICANN SHOULD
-tentatively suspend registration of domain names which have an ACE
-prefix identifier candidate at the head of at least one label of the
-domain name and those which have an ACE suffix identifier candidate at
-the tail of at least one label of the name. These domain names are
-collectively called "relevant domain names".
-
- This suspension should be continued until September 1, 2001
-00:00:00 UTC.
-
-
-2.2 Survey of relevant domain name registration
-
- All registries recognized by ICANN SHOULD conduct a survey about
-relevant domain names registered in their zone, and report, no later
-than August 11, 2001 00:00:00 UTC, all of the ACE identifier
-candidates which are used by relevant domain names.
-
-
-2.3 Selection of ACE identifiers and permanent blocking of
- relevant domain names
-
- The IDN WG or other organ of IETF or ICANN MUST summarize the
-reports and list ACE identifier candidates that are not reported to be
-used in registered domain names by August 18, 2001 00:00:00 UTC, and
-select ten to twenty ACE prefix identifier candidates and ten to
-twenty ACE suffix identifier candidates for ACE identifiers. Among
-these twenty to forty ACE identifiers, one prefix identifier and one
-suffix identifier will be used for experiments. Others will be used,
-one by one as ACE standard evolves.
-
- The list of ACE identifiers will be sent to IANA, and will be
-maintained by IANA from August 25, 2001 00:00:00 UTC. Domain names
-relevant to these identifiers SHOULD NOT be registered in any DNS
-zone, except for registration of multilingual domain names compliant
-to one of future IDN standards. This new restriction about the domain
-name space will be notified to all ICANN recognized registries by IANA
-immediately after it receives the list.
-
-
-2.4 Blocking of registration for relevant domain names
-
- Domain names relevant to ACE identifiers selected by the procedure
-described in section 2.3 SHOULD NOT be registered in any zone of ICANN
-recognized registries except for registration of multilingual domain
-names compliant to one of future IDN standards. All ICANN recognized
-registries SHOULD implement this restriction no later than September 1,
-2001 00:00:00 UTC.
-
- Registration for domain names relevant to ACE identifier
-candidates, tentatively suspended by 2.1, but not relevant to ACE
-identifiers selected by section 2.3 MAY be reopened from September 1,
-2001 00:00:00 UTC.
-
-
-3. Use of an ACE identifier in writing an ACE proposal
-
- When writing an ACE proposal using an ACE identifier, the author
-SHOULD either describe the ACE identifier as "to be decided" and left
-to discretion of the IDN WG or other organ of IETF or ICANN, or use
-either of the ACE identifiers for experiment defined in section 2.3,
-with a unique version number added after or before the prefix or
-suffix.
-
- If a proposal is validated and published as an Internet Draft, the
-IDN WG or other organ of IETF or ICANN MUST replace the "to be
-decided" part with an experimental identifier with a unique version
-number added after or before the prefix or the suffix.
-
-
-4. Determination of ACE identifier
-
- When an Internet Draft relating to ACE is accepted as an Internet
-standard and becomes an RFC, IDN WG or other organ of IETF or ICANN
-MUST replace the experimental ACE identifier, augmented by the version
-number, with one of the ACE identifiers.
-
-
-5. Security considerations
-
- None in particular.
-
-
-6. Changes from the previous version
-
- We excluded suffixes of one hyphen followed by three alpha-
-numericals from the candidates. This is because we found that, as of
-Nov. 29, 2000, there were 23,921 domain names registered in the .JP
-space relevant to these suffixes. This was more than 10% of 227,852
-total registrations in the JPNIC database at the moment, and hence we
-felt these suffixes are not good candidates.
-
- In addition to this and some minor linguistic corrections, we
-changed "The IDN WG" in section 2.3 to "The IDN WG or other organ of
-IETF or ICANN".
-
-
-7. References
-
-[IDNREQ] Z Wenzel, J Seng, "Requirements of Internationalized Domain
- Names", draft-ietf-idn-requirements-03.txt, Jun 2000.
-
-[RACE] P Hoffman, "RACE: Row-based ASCII Compatible Encoding for
- IDN", draft-ietf-idn-race-02.txt, Oct 2000.
-
-[BRACE] A Costello, "BRACE: Bi-mode Row-based ASCII-Compatible
- Encoding for IDN", draft-ietf-idn-brace-00.txt, Sep 2000.
-
-[LACE] P Hoffman, "LACE: Length-based ASCII Compatible Encoding for
- IDN", draft-ietf-idn-lace-00.txt, Nov 2000.
-
-[VERSION] M Blanchet, "Handling versions of internationalized domain
- names protocols", draft-ietf-idn-version-00.txt, Nov 2000.
-
-
-8. Acknowledgements
-
- We would like to express our hearty thanks to members of JPNIC IDN
-Task Force for valuable discussions about this issue. We also would
-like to express our appreciation to Mr. Dave Crocker for checking and
-correcting the preliminary version of this draft.
-
-
-9. Author's Address
-
-Naomasa Maruyama
-Japan Network Information Center
-Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
-Chiyoda-ku Tokyo 101-0052, Japan
-maruyama@nic.ad.jp
-
-Yoshiro Yoneya
-Japan Network Information Center
-Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
-Chiyoda-ku Tokyo 101-0052, Japan
-yone@nic.ad.jp
+++ /dev/null
-INTERNET-DRAFT Adam M. Costello
-draft-ietf-idn-amc-ace-m-00.txt 2001-Feb-12
-Expires 2001-Aug-14
-
- AMC-ACE-M version 0.1.0
-
-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
-
- Distribution of this document is unlimited. Please send comments
- to the author at amc@cs.berkeley.edu, or to the idn working
- group at idn@ops.ietf.org. A non-paginated (and possibly
- newer) version of this specification may be available at
- http://www.cs.berkeley.edu/~amc/charset/amc-ace-m
-
-Abstract
-
- AMC-ACE-M is a reversible map from a sequence of Unicode [UNICODE]
- characters to a sequence of letters (A-Z, a-z), digits (0-9), and
- hyphen-minus (-), henceforth called LDH characters. Such a map
- (called an "ASCII-Compatible Encoding", or ACE) might be useful for
- internationalized domain names [IDN], because host name labels are
- currently restricted to LDH characters by [RFC952] and [RFC1123].
-
- AMC-ACE-M is a cross between BRACE [BRACE00] (which is efficient
- but complex) and DUDE [DUDE00] (which is simple and provides case
- preservation). AMC-ACE-M is much simpler than BRACE but similarly
- efficient, and provides case preservation like DUDE.
-
- Besides domain names, there might also be other contexts where it is
- useful to transform Unicode characters into "safe" (delimiter-free)
- ASCII characters. (If other contexts consider hyphen-minus to be
- unsafe, a different character could be used to play its role, like
- underscore.)
-\f
-Contents
-
- Features
- Name
- Overview
- Base-32 characters
- Encoding procedure
- Decoding procedure
- Signature
- Case sensitivity models
- Comparison with RACE, BRACE, LACE, and DUDE
- Example strings
- Security considerations
- References
- Author
- Example implementation
-
-Features
-
- Uniqueness: Every Unicode string maps to at most one LDH string.
-
- Completeness: Every Unicode string maps to an LDH string.
- Restrictions on which Unicode strings are allowed, and on length,
- may be imposed by higher layers.
-
- Efficient encoding: The ratio of encoded size to original size is
- small for all Unicode strings. This is important in the context
- of domain names because [RFC1034] restricts the length of a domain
- label to 63 characters.
-
- Simplicity: The encoding and decoding algorithms are reasonably
- simple to implement. The goals of efficiency and simplicity are at
- odds; AMC-ACE-M aims at a good balance between them.
-
- Case-preservation: If the Unicode string has been case-folded prior
- to encoding, it is possible to record the case information in the
- case of the letters in the encoding, allowing a mixed-case Unicode
- string to be recovered if desired, but a case-insensitive comparison
- of two encoded strings is equivalent to a case-insensitive
- comparison of the Unicode strings. This feature is optional; see
- section "Case sensitivity models".
-
- Readability: The letters A-Z and a-z and the digits 0-9 appearing
- in the Unicode string are represented as themselves in the label.
- This comes for free because it usually the most efficient encoding
- anyway.
-
-Name
-
- AMC-ACE-M is a working name that should be changed if it is adopted.
- (The M merely indicates that it is the thirteenth ACE devised by
- this author. BRACE was the third. D through L did not deliver
- enough efficiency to justify their complexity.) Rather than waste
- good names on experimental proposals, let's wait until one proposal
- is chosen, then assign it a good name. Suggestions (assuming the
- primary use is in domain names):
-\f
- UniHost
- UTF-A ("A" for "ASCII" or "alphanumeric",
- but unfortunately UTF-A sounds like UTF-8)
- UTF-H ("H" for "host names",
- but unfortunately UTF-H sounds like UTF-8)
- UTF-D ("D" for "domain names")
- NUDE (Normal Unicode Domain Encoding)
-
-Overview
-
- AMC-ACE-M maps characters to characters--it does not consume or
- produce code points, code units, or bytes, although the algorithm
- makes use of code points, and implementations will of course need to
- represent the input and output characters somehow, usually as bytes
- or other code units.
-
- Each character in the Unicode string is represented by an
- integral number of characters in the encoded string. There is no
- intermediate bit string or octet string.
-
- The encoded string alternates between two modes: literal mode and
- base-32 mode. LDH characters in the Unicode string are encoded
- literally, except that hyphen-minus is doubled. Non-LDH characters
- in the Unicode string are encoded using base-32, in which each
- character of the encoded string represents five bits (a "quintet").
- A non-paired hyphen-minus in the encoded string indicates a mode
- change.
-
- In base-32 mode a group of one to five quintets are used to
- represent a number, which is added to an offset to yield a
- Unicode code point, which in turn represents a Unicode character.
- (Surrogates, which are code units used by UTF-16 in pairs to
- refer to code points, are not used and not allowed in AMC-ACE-M.)
- Similarities between the code points are exploited to make the
- encoding more compact.
-
-Base-32 characters
-
- "a" = 0 = 0x00 = 00000 "s" = 16 = 0x10 = 10000
- "b" = 1 = 0x01 = 00001 "t" = 17 = 0x11 = 10001
- "c" = 2 = 0x02 = 00010 "u" = 18 = 0x12 = 10010
- "d" = 3 = 0x03 = 00011 "v" = 19 = 0x13 = 10011
- "e" = 4 = 0x04 = 00100 "w" = 20 = 0x14 = 10100
- "f" = 5 = 0x05 = 00101 "x" = 21 = 0x15 = 10101
- "g" = 6 = 0x06 = 00110 "y" = 22 = 0x16 = 10110
- "h" = 7 = 0x07 = 00111 "z" = 23 = 0x17 = 10111
- "i" = 8 = 0x08 = 01000 "2" = 24 = 0x18 = 11000
- "j" = 9 = 0x09 = 01001 "3" = 25 = 0x19 = 11001
- "k" = 10 = 0x0A = 01010 "4" = 26 = 0x1A = 11010
- "m" = 11 = 0x0B = 01011 "5" = 27 = 0x1B = 11011
- "n" = 12 = 0x0C = 01100 "6" = 28 = 0x1C = 11100
- "p" = 13 = 0x0D = 01101 "7" = 29 = 0x1D = 11101
- "q" = 14 = 0x0E = 01110 "8" = 30 = 0x1E = 11110
- "r" = 15 = 0x0F = 01111 "9" = 31 = 0x1F = 11111
-
- The digits "0" and "1" and the letters "o" and "l" are not used, to
- avoid transcription errors.
-\f
- All decoders must recognize both the uppercase and lowercase
- forms of the base-32 characters. The case may or may not convey
- information, as described in section "Case sensitivity models".
-
-Encoding procedure
-
- The encoder first examines the Unicode string and chooses some
- parameters. It writes these parameters into the output string, then
- proceeds to encode each Unicode character, one at a time. The exact
- sequence of steps is given below. All ordering of bits and quintets
- is big-endian (most significant first). The >> and << operators
- used below mean bit shift, as in C. For >> there is no question of
- logical versus arithmetic shift because AMC-ACE-M makes no use of
- negative numbers.
-
- 0) Determine the Unicode code point for each non-LDH character in
- the Unicode string. Since LDH characters are encoded literally,
- their code points are not needed. Depending on how the Unicode
- string is presented to the encoder, this step may be a no-op.
-
- 1) Verify that there are are no invalid code points in the input;
- that is, none exceed 0x10FFFF (the highest code point in the
- Unicode code space) and none are in the range D800..DFFF
- (surrogates).
-
- 2) Determine the most populous row: Row n is defined as the 256
- code points starting with n << 8, except that this definition
- would makes rows D8..DF useless, because they would contain only
- surrogates. Therefore AMC-ACE-M defines rows D8..DF to be the
- following non-aligned blocks of 256 code points:
-
- row D8 = 0020..001F
- row D9 = 005B..015A
- row DA = 007B..017A
- row DB = 00A0..019F
- row DC = 00C0..01BF
- row DD = 00DF..01DE
- row DE = 0134..0233
- row DF = 0270..036F
-
- (Rationale: Whereas almost every small script is confined to
- a single row, the Latin script is split across a few rows,
- and the row boundaries are not especially convenient for many
- languages.)
-
- Determine the row containing the most non-LDH input code points,
- breaking ties in favor of smaller-numbered rows. (If a code
- point appears multiple times in the input, it counts multiple
- times. This applies to steps 3 and 4 also.) Call it row B.
- Let offsetB be the first code point of row B.
-
- 3) Determine the most populous 16-window: For each n in 0..31 let
- offset = ((offsetB >> 3) + n) << 3 and count the number of code
- points in the range offset through offset + 0xF. Let A be the
- value of n that maximizes this count, breaking ties in favor
- of smaller values of n, and let offsetA be the corresponding
- offset.
-\f
- 4) Determine the most populous 20k-window: If the input is empty,
- then let C = 0. Otherwise, for each input code point, let n =
- code_point >> 11, and count the number of non-LDH input code
- points that are not in row B and are in the range (n << 11)
- through (n << 11) + 0x4FFF. Determine the value of n that
- maximizes the count, breaking ties in favor of smaller values of
- n, and let C be that value.
-
- 5) Choose a style: One of the base-32 codes used in step 7.3 has
- two variants, and so base-32 mode is subdivided into two styles,
- narrow and wide, depending on which variant is used. Compute
- the total number of base-32 characters that would be produced
- if narrow style were used, and the number if wide style were
- used. The easiest way to do this is to mimic the logic of steps
- 6 and 7.3. Use whichever style would produce fewer base-32
- characters. In case of a tie, use narrow style.
-
- 6) Encode the parameters. If narrow style is used, then let
- offsetC = (offsetB >> 12) << 12, and encode B and A as three or
- four base-32 characters:
-
- 00bbb bbbbb aaaaa if B <= 0xFF
- 01bbb bbbbb bbbbb aaaaa otherwise
-
- If wide style is used, then let offsetC = C << 11, and encode B
- and C as three or five base-32 characters:
-
- 10bbb bbbbb ccccc if B <= 0xFF and C <= 0x1F
- 11bbb bbbbb bbbbb ccccc ccccc otherwise
-
- 7) Encode each input character in turn, using the first of the
- following cases that applies. The mode is initially base-32.
-
- 7.1) The character is a hyphen-minus (U+002D). Encode it as
- two hyphen-minuses.
-
- 7.2) The character is an LDH character. If in base-32 mode
- then output a hyphen-minus and switch to literal mode.
- Copy the character to the output.
-
- 7.3) The character is a non-LDH character. If in literal
- mode then output a hyphen-minus and switch to base-32
- mode. Encode the character's code point using the
- first of the following cases that applies. Square
- brackets enclose quintets that can be used to record
- the upper/lowercase attribute of the Unicode character
- (because the corresponding base-32 characters are
- guaranteed to be letters rather than digits) (see section
- "Case sensitivity models").
-
- 7.3.1) Narrow style was chosen and the code point is in
- the range offsetA through offsetA + 0xF. Subtract
- offsetA and encode the difference as a single
- base-32 character:
-\f
- [0xxxx]
-
- 7.3.2) The code point is in the range offsetB through
- offsetB + 0xFF. Subtract offsetB and encode the
- difference as two base-32 characters:
-
- 1xxxx [0xxxx]
-
- 7.3.3) The code point is in the range offsetC through
- offsetC + 0xFFF. Subtract offsetC and encode the
- difference as three base-32 characters:
-
- 1xxxx 1xxxx [0xxxx]
-
- 7.3.4) Wide style was chosen and the code point is in
- the range offsetC + 0x1000 through offsetC +
- 0x4FFF. Subtract offsetC + 0x1000 and encode the
- difference as three base-32 characters:
-
- [0xxxx] xxxxx xxxxx
-
- 7.3.5) The code point is in the range 0 through 0xFFFF.
- Encode it as four base-32 characters:
-
- 1xxxx 1xxxx 1xxxx [0xxxx]
-
- 7.3.6) If we've come this far, the code point must be
- in the range 0x10000 through 0x10FFFF. Subtract
- 0x10000 and encode the difference as five base-32
- characters:
-
- 1xxxx 1xxxx 1xxxx 1xxxx [0xxxx]
-
-Decoding procedure
-
- The details of the decoding procedure are implied by the encoding
- procedure. The overall sequence of steps is as follows.
-
- 1) Undo the encoder's step 6: From the first few base-32
- characters, determine whether narrow or wide style is used, and
- determine the offsets.
-
- 2) Set the mode to base-32. For each remaining input character, use
- the first of the following cases that applies:
-
- 2.1) The character is a hyphen-minus, and the following
- character is also a hyphen-minus. Consume them both and
- output a hyphen-minus.
-
- 2.2) The character is a hyphen-minus. Consume it and toggle
- the mode flag.
-
- 2.3) The current mode is literal. Consume the input character
- and output it.
-\f
- 2.4) Interpret the input character and up to four of its
- successors as base-32. Consume characters until one is
- found whose value has the form 0xxxx. That is the one
- that carries the upper/lowercase information. Remember
- the length of the code. If the length is one and wide
- style is being used, consume two more characters.
- Decode the base-32 characters into an integer, add the
- appropriate offset (which depends on the remembered code
- length), and output the Unicode character corresponding to
- the resulting code point.
-
- If the case-flexible or case-preserving model is being
- used (see section "Case sensitivity models"), the decoder
- must either perform the case conversion as it is decoding,
- or construct a separate record of the case information to
- accompany the output string.
-
- 3) Before returning the output (be it a string or a string plus
- case information), the decoder must invoke the encoder on it,
- and compare the result to the input string. The comparison
- must be case-sensitive if the case-sensitive or case-flexible
- model is being used, case-insensitive if the case-insensitive
- or case-preserving model is being used. If the two strings do
- not match, it is an error. This check is necessary to guarantee
- the uniqueness property (there cannot be two distinct encoded
- strings representing the same Unicode string).
-
- If the decoder at any time encounters an unexpected character, or
- unexpected end of input, then the input is invalid.
-
-Signature
-
- The issue of how to distinguish ACE strings from unencoded strings
- is largely orthogonal to the encoding scheme itself, and is
- therefore not specified here. In the context of domain name labels,
- a standard prefix and/or suffix (chosen to be unlikely to occur
- naturally) would presumably be attached to ACE labels. (In that
- case, it would probably be good to forbid the encoding of Unicode
- strings that appear to match the signature, to avoid confusing
- humans about whether they are looking at a Unicode string or an ACE
- string.)
-
- In order to use AMC-ACE-M in domain names, the choice of signature
- must be mindful of the requirement in [RFC952] that labels never
- begin or end with hyphen-minus. The raw encoded string will never
- begin with a hyphen-minus, and will end with a hyphen-minus iff the
- Unicode string ends with a hyphen-minus. The easiest solution is
- to use a suffix as the signature. Alternatively, if the Unicode
- strings were forbidden from ending with a hyphen-minus, a prefix
- could be used.
-
- It appears that "---" is extremely rare in domain names; among the
- four-character prefixes of all the second-level domains under .com,
- .net, and .org, "---" never appears at all. Therefore, perhaps the
- signature should be of the form ?--- (prefix) or ---? (suffix),
- where ? could be "u" for Unicode, or "i" for internationalized, or
- "a" for ACE, or maybe "q" or "z" because they are rare.
-\f
-Case sensitivity models
-
- The higher layer must choose one of the following four models.
-
- Models suitable for domain names:
-
- * Case-insensitive: Before a string is encoded, all its non-LDH
- characters must be case-folded so that any strings differing
- only in case become the same string (for example, strings could
- be forced to lowercase). Folding LDH characters is optional.
- The case of base-32 characters and literal-mode characters is
- arbitrary and not significant. Comparisons between encoded
- strings must be case-insensitive. The original case of non-LDH
- characters cannot be recovered from the encoded string.
-
- * Case-preserving: The case of the Unicode characters is not
- considered significant, but it can be preserved and recovered,
- just like in non-internationalized host names. Before a string
- is encoded, all its non-LDH characters must be case-folded
- as in the previous model. LDH characters are naturally able
- to retain their case attributes because they are encoded
- literally. The case attribute of a non-LDH character is
- recorded in one of the base-32 characters that represent
- it (section "Encoding procedure" tells which one). If the
- base-32 character is uppercase, it means the Unicode character
- is caseless or should be forced to uppercase after being
- decoded (which is a no-op if the case folding already forces
- to uppercase). If the base-32 character is lowercase, it
- means the Unicode character is caseless or should be forced to
- lowercase after being decoded (which is a no-op if the case
- folding already forces to lowercase). The case of the other
- base-32 characters in a multi-quintet encoding is arbitrary
- and not significant. Only uppercase and lowercase attributes
- can be recorded, not titlecase. Comparisons between encoded
- strings must be case-insensitive, and are equivalent to
- case-insensitive comparisons between the Unicode strings. The
- intended mixed-case Unicode string can be recovered as long as
- the encoded characters are unaltered, but altering the case of
- the encoded characters is not harmful--it merely alters the case
- of the Unicode characters, and such a change is not considered
- significant.
-
- In this model, the input to the encoder and the output of the
- decoder can be the unfolded Unicode string (in which case the
- encoder and decoder are responsible for performing the case
- folding and recovery), or can be the folded Unicode string
- accompanied by separate case information (in which case the
- higher layer is responsible for performing the case folding and
- recovery). Whichever layer performs the case recovery must
- first verify that the Unicode string is properly folded, to
- guarantee the uniqueness of the encoding.
-
- It is easy to extend the nameprep algorithm [NAMEPREP02] to
- remember case information. It merely requires an additional
- bit to be associated with each output code point in the mapping
- table.
-\f
- The case-insensitive and case-preserving models are interoperable.
- If a domain name passes from a case-preserving entity to a
- case-insensitive entity, the case information will be lost, but
- the domain name will still be equivalent. This phenomenon already
- occurs with non-internationalized domain names.
-
- Models unsuitable for domain names, but possibly useful in other
- contexts:
-
- * Case-sensitive: Unicode strings may contain both uppercase and
- lowercase characters, which are not folded. Base-32 characters
- must be lowercase. Comparisons between encoded strings must be
- case-sensitive.
-
- * Case-flexible: Like case-preserving, except that the choice
- of whether the case of the Unicode characters is considered
- significant is deferred. Therefore, base-32 characters must
- be lowercase, except for those used to indicate uppercase
- Unicode characters. Comparisons between encoded strings may be
- case-sensitive or case-insensitive, and such comparisons are
- equivalent to the corresponding comparisons between the Unicode
- strings.
-
-Comparison with RACE, BRACE, LACE, and DUDE
-
- In this section we compare AMC-ACE-M and four other ACEs: RACE
- [RACE03], BRACE [BRACE00], LACE [LACE01], and Extended DUDE
- [DUDE00]. We do not include SACE [SACE], UTF-5 [UTF5], or UTF-6
- [UTF6] in the comparison, because SACE appears obviously too
- complex, UTF-5 appears obviously too inefficient, and UTF-6 can
- never be more efficient than its similarly simple successor, DUDE.
-
- Case preservation support:
-
- DUDE, AMC-ACE-M: all characters
- BRACE: only the letters A-Z, a-z
- RACE, LACE: none
-
- RACE, BRACE, and LACE transform the Unicode string to an
- intermediate bit string, then into a base-32 string, so there is no
- particular alignment between the base-32 characters and the Unicode
- characters. DUDE and AMC-ACE-M do not have this intermediate stage,
- and enforce alignment between the base-32 characters and the Unicode
- characters, which facilitates the case preservation.
-
- Complexity is hard to measure. This author would subjectively
- describe the complexity of the algorithms as:
-
- RACE, LACE, DUDE: fairly simple but not trivial
- AMC-ACE-M: moderate
- BRACE: complex
-
- The complexity of AMC-ACE-M is in the number of rules, but the
- individual rules are not very complex, and they are generally
- non-interacting.
-\f
- The relative efficiency of the various algorithms is suggested
- by the sizes of the encodings in section "Example strings". For
- each ACE there is a graph below showing a horizontal bar for
- each example string, representing the ACE length divided by the
- minimum length among all the ACEs for that example string (so the
- ratio is at least 1). Example R is excluded because it violates
- nameprep [NAMEPREP02]. The other example strings all use different
- languages, except that there are several Japanese examples. To
- avoid skewing the results, each graph collapses all the Japanese
- ratios into a single bar representing the median ratio. A ratio r
- is represented by a bar of length r/0.04 characters. Since the bar
- will always be at least 1/0.04 = 25 characters long, we show the
- first 25 characters as "O" and the rest as "@". The bars are sorted
- so that the graph looks like a cummulative distribution. Each bar
- is labeled with the language of the corresponding example string.
- (The difference between the Chinese and Taiwanese strings is that
- the former uses simplified characters.)
-
- RACE:
- Hindi OOOOOOOOOOOOOOOOOOOOOOOOO@@@
- Korean OOOOOOOOOOOOOOOOOOOOOOOOO@@@
- Arabic OOOOOOOOOOOOOOOOOOOOOOOOO@@@@
- Taiwanese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@
- Hebrew OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@
- Russian OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@
- Japanese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@
- Spanish OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@
- Chinese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@@
- Vietnamese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@@@@@@@@
- Czech OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@@@@@@@@@@@@@@@@@
-
- LACE:
- Korean OOOOOOOOOOOOOOOOOOOOOOOOO@@@
- Hindi OOOOOOOOOOOOOOOOOOOOOOOOO@@@@
- Taiwanese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@
- Arabic OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@
- Hebrew OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@
- Chinese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@
- Japanese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@
- Russian OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@
- Spanish OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@@
- Vietnamese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@@@@@@
- Czech OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@@@@@@@@@@@
-
- DUDE:
- Russian OOOOOOOOOOOOOOOOOOOOOOOOO
- Arabic OOOOOOOOOOOOOOOOOOOOOOOOO
- Hebrew OOOOOOOOOOOOOOOOOOOOOOOOO@@
- Vietnamese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@
- Chinese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@
- Japanese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@
- Korean OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@
- Spanish OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@
- Czech OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@
- Hindi OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@
- Taiwanese OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@@@@
-\f
- AMC-ACE-M:
- Czech OOOOOOOOOOOOOOOOOOOOOOOOO
- Hebrew OOOOOOOOOOOOOOOOOOOOOOOOO
- Japanese OOOOOOOOOOOOOOOOOOOOOOOOO
- Korean OOOOOOOOOOOOOOOOOOOOOOOOO
- Russian OOOOOOOOOOOOOOOOOOOOOOOOO
- Spanish OOOOOOOOOOOOOOOOOOOOOOOOO
- Taiwanese OOOOOOOOOOOOOOOOOOOOOOOOO
- Vietnamese OOOOOOOOOOOOOOOOOOOOOOOOO
- Chinese OOOOOOOOOOOOOOOOOOOOOOOOO@
- Arabic OOOOOOOOOOOOOOOOOOOOOOOOO@@@
- Hindi OOOOOOOOOOOOOOOOOOOOOOOOO@@@@@
-
- BRACE:
- Chinese OOOOOOOOOOOOOOOOOOOOOOOOO
- Hindi OOOOOOOOOOOOOOOOOOOOOOOOO
- Japanese OOOOOOOOOOOOOOOOOOOOOOOOO
- Spanish OOOOOOOOOOOOOOOOOOOOOOOOO
- Taiwanese OOOOOOOOOOOOOOOOOOOOOOOOO
- Arabic OOOOOOOOOOOOOOOOOOOOOOOOO@
- Czech OOOOOOOOOOOOOOOOOOOOOOOOO@
- Vietnamese OOOOOOOOOOOOOOOOOOOOOOOOO@
- Hebrew OOOOOOOOOOOOOOOOOOOOOOOOO@@
- Korean OOOOOOOOOOOOOOOOOOOOOOOOO@@
- Russian OOOOOOOOOOOOOOOOOOOOOOOOO@@@
-
- These results suggest that DUDE is preferrable to RACE and LACE,
- because it has similar simplicity, better support for case
- preservation, and is somewhat more efficient.
-
- The results also suggest that AMC-ACE-M is preferrable to BRACE,
- because it has similar efficiency, better support for case
- preservation, and is simpler.
-
- DUDE and AMC-ACE-M have equal support for case preservation, but
- AMC-ACE-M offers significantly better efficiency, at the cost of
- significantly greater complexity, so choosing between them entails a
- value judgement.
-
-Example strings
-
- In the ACE encodings below, signatures (like "bq--" for RACE) are
- not shown. Non-LDH characters in the Unicode string are forced to
- lowercase before being encoded using BRACE, RACE, and LACE. For
- RACE and LACE, the letters A-Z are likewise forced to lowercase.
- UTF-8 and UTF-16 are included for length comparisons, with non-ASCII
- bytes shown as "?". AMC-ACE-M is abbreviated AMC-M. Backslashes
- show where line breaks have been inserted in ACE strings too long
- for one line. The RACE and LACE encodings are courtesy of Mark
- Davis's online UTF converter [UTFCONV] (slightly modified to remove
- the length restrictions).
-
- The first several examples are all names of Japanese music artists,
- song titles, and TV programs, just because the author happens to
- have them handy (but Japanese is useful for providing examples
- of single-row text, two-row text, ideographic text, and various
- mixtures thereof).
-\f
- (A) 3<nen>B<gumi><kinpachi><sensei> (Japanese TV program title)
-
- <nen> = U+5E74 (kanji)
- <gumi> = U+7D44 (kanji)
- <kinpachi><sensei> = U+91D1 U+516B U+5148 U+751F (kanji)
-
- UTF-16: ????????????????
- UTF-8: 3???B???????????????
- AMC-M: utk-3-8ze-B-hkenqtymwifi9
- BRACE: u-3-ygj-b-ynb6gjc7pp4k5p5w
- DUDE: j3le74G062nd44p1d1l16bk8n51f
- RACE: 3aadgxtuabrh2rer2fiwwukioupq
- LACE: 74adgxtuabrh2rer2fiwwukioupq
-
- (B) <amuro><namie>-with-SUPER-MONKEYS (Japanese music group name)
-
- <amuro><namie> = U+5B89 U+5BA4 U+5948 U+7F8E U+6075 (kanji)
-
- UTF-8: ??????????????????-with-SUPER-MONKEYS
- AMC-M: u5m2j4etwif6q2zf---with--SUPER--MONKEYS
- BRACE: uvj7fuaqcahy982xa---with--SUPER--MONKEYS
- DUDE: lb89q4p48nf8em075-g077m9n4m8-N3LGM5N2-MdVURLN9J
- UTF-16: ????????????????????????????????????????????????
- LACE: ajnytjablfeac74oafqhkeyafv3qm5difvzxk4dfoiww233onnsxs4y
- RACE: 3bnysw5elfeh7dtaouac2adxabuqa5aanaac2adtab2qa4aamuaheab\
- nabwqa3yanyagwadfab4qa4y
-
- (C) Hello-Another-Way-<sorezore><no><basho> (Japanese song title)
-
- <sorezore><no> = U+305D U+308C U+305E U+308C U+306E (hiragana)
- <basho> = U+5834 U+6240 (kanji)
-
- UTF-8: Hello-Another-Way-?????????????????????
- BRACE: ji7-Hello--Another--Way---v3jhaefvd2ufj62
- AMC-M: bsk-Hello--Another--Way---p2nq2nyqx2veyuwa
- DUDE: M8lssv-Huvn4m8ln2-Nm1n9-j05docleocmel834m240
- UTF-16: ??????????????????????????????????????????????????
- LACE: ciagqzlmnrxs2ylon52gqzlsfv3wc6jnauyf3dc6rrxacwbuafrea
- RACE: 3aagqadfabwaa3aan4ac2adbabxaa3yaoqagqadfabzaaliao4agcad\
- zaawtaxjqrqyf4memgbxfqndcia
-
- (D) <hitotsu><yane><no><shita>2 (Japanese TV program title)
-
- <hitotsu> = U+3072 U+3068 U+3064 (hiragana)
- <yane> = U+5C4B U+6839 (kanji)
- <no> = U+306E (hiragana)
- <shita> = U+4E0B (kanji)
-
- UTF-16: ????????????????
- UTF-8: ?????????????????????2
- AMC-M: bsnzciex6wmy2vjqw8sm-2
- BRACE: ji96u56uwbhf2wqxnw4s-2
- DUDE: j072m8klc4bm839j06eke0bg032
- RACE: 3ayhemdigbsfys3iheyg4tqlaaza
- LACE: 74yhemdigbsfys3iheyg4tqlaaza
-\f
- (E) Maji<de>Koi<suru>5<byou><mae> (Japanese song title)
-
- <de> = U+3067 (hiragana)
- <suru> = U+3059 U+308B (hiragana)
- <byou><mae> = U+79D2 U+524D (kanji)
-
- UTF-8: Maji???Koi??????5??????
- UTF-16: ??????????????????????????
- AMC-M: bsm-Maji-r-Koi-b2m-5-z37cxuwp
- BRACE: ji8-Maji-g-Koi-qe7x-5-wx7p6ma
- DUDE: Mdhqpj067G06bvpj059obg035n9d2l24d
- RACE: 3aag2adbabvaa2jqm4agwadpabutawjqrmadk6oskjgq
- LACE: 74ag2adbabvaa2jqm4agwadpabutawjqrmadk6oskjgq
-
- (F) <pafii>de<runba> (Japanese song title)
-
- <pafii> = U+30D1 U+30D5 U+30A3 U+30FC (katakana)
- <runba> = U+30EB U+30F3 U+30D0 (katakana)
-
- UTF-16: ??????????????
- BRACE: 3iu8pazt-de-pygi
- AMC-M: bs3jp4d9n-de-8m9di
- RACE: gdi5li7475sp6zpl6pia
- DUDE: j0d1lq3vcg064lj0ebv3t0
- UTF-8: ????????????de?????????
- LACE: aqyndvnd7qbaazdfamyox46q
-
- (G) <sono><supiido><de> (Japanese song title)
-
- <sono> = U+305D U+306E (hiragana)
- <supiido> = U+30B9 U+30D4 U+30FC U+30C9 (katakana)
- <de> = U+3067 (hiragana)
-
- RACE: gbow5oou7tewo
- UTF-16: ??????????????
- BRACE: bidprdmp9wt7mi
- LACE: a4yf23vz2t6mszy
- AMC-M: bsmfyq5j7e9n6jr
- DUDE: j05dmer9t4vcs9m7
- UTF-8: ?????????????????????
-
- The next several examples are all translations of the sentence "Why
- can't they just speak in <language>?" (courtesy of Michael Kaplan's
- "provincial" page [PROVINCIAL]). Word breaks and punctuation have
- been removed, as is often done in domain names.
-
- (H) Arabic (Egyptian):
- U+0644 U+064A U+0647 U+0645 U+0627 U+0628 U+062A U+0643 U+0644
- U+0645 U+0648 U+0634 U+0639 U+0631 U+0628 U+064A U+061F
-
- DUDE: m44qnli7oqk3kloj4phi8kahf
- BRACE: 28akcjwcmp3ciwb4t3ngd4nbaz
- AMC-M: agiekhfuhuiukdefivevjvbuiktr
- RACE: azceur2fe4ucuq2eivediojrfbfb6
- LACE: cedeisshiutsqksdircuqnbzgeueuhy
- UTF-16: ??????????????????????????????????
- UTF-8: ??????????????????????????????????
-\f
- (I) Chinese (simplified):
- U+4ED6 U+4EEC U+4E3A U+4EC0 U+4E48 U+4E0D U+8BF4 U+4E2D U+6587
-
- UTF-16: ??????????????????
- BRACE: kgcqqsgp26i5h4zn7req5i
- AMC-M: uqj7g8nvk6awispn9wupdnh
- DUDE: ked6ucjas0k8gdobf4ke2dm587
- UTF-8: ???????????????????????????
- LACE: azhnn3b2ybea2aml6qau4libmwdq
- RACE: 3bhnmtxmjy5e5qcojbha3c7ujywwlby
-
- (J) Czech: Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky
-
- <ccaron> = U+010D
- <ecaron> = U+011B
- <iacute> = U+00ED
-
- UTF-8: Pro??prost??nemluv????esky
- AMC-M: g26-Pro-p-prost-9m-nemluv-6pp-esky
- BRACE: i32-Pro-u-prost-8y-nemluv-29f3n-esky
- DUDE: N0imfh0dg70imfn3kh1bg6eltsn5mudh0dg65n3mbn9
- UTF-16: ????????????????????????????????????????????
- LACE: amaha4tpaeaq2biaobzg643uaearwbyanzsw23dvo3wqcainaqagk43\
- lpe
- RACE: ah7xb73s75xq373q75zp6377op7xig77n37wl73n75wp65p7o3762dp\
- 7mx7xh73l754q
-
- (K) Hebrew:
- U+05DC U+05DE U+05D4 U+05D4 U+05DD U+05E4 U+05E9 U+05D5 U+05D8
- U+05DC U+05D0 U+05DE U+05D3 U+05D1 U+05E8 U+05D9 U+05DD U+05E2
- U+05D1 U+05E8 U+05D9 U+05EA
-
- AMC-M: af4nqeep8e8jfinaqdb8ijp8cb8ij8k
- DUDE: ldcukktu4pt5osgujhu8t9tu2t1u8t9ua
- BRACE: 27vkyp7bgwmbpfjgc4ynx5nd8xsp5nd9c
- RACE: axon5vgu3xsotvoy3tin5u6r5dm53ywr5dm6u
- LACE: cyc5zxwu2to6j2ov3donbxwt2huntxpc2hunt2q
- UTF-8: ????????????????????????????????????????????
- UTF-16: ????????????????????????????????????????????
-
- (L) Hindi:
- U+092F U+0939 U+0932 U+094B U+0917 U+0939 U+093F U+0928 U+094D
- U+0926 U+0940 U+0915 U+094D U+092F U+094B U+0902 U+0928 U+0939
- U+0940 U+0902 U+092C U+094B U+0932 U+0938 U+0915 U+0924 U+0947
- U+0939 U+0948 U+0902 (Devanagari)
-
- BRACE: 2b7xtenqdr7zc6uma2pmcz7ibage237kdemicnk9gei32
- RACE: bextsmslc44t6kcnezabktjpjmbcqokaaiwewmrycuseookiai
- LACE: dyes6ojsjmltspzijuteafknf5fqekbziabcyszshaksirzzjaba
- AMC-M: ajhurbvcwmthbhuiwpugitfwpurwmscuibiscunwmvcatfuerbwisc
- DUDE: p2fj9ikbh7j9vi8kdi6k0h5kdifkbg2i8j9k0g2ickbj2oh5i4k7j9k\
- 8g2
- UTF-16: ???????????????????????????????????????????????????????\
- ?????
- UTF-8: ???????????????????????????????????????????????????????\
- ???????????????????????????????????
-\f
- (M) Korean:
- U+C138 U+ACC4 U+C758 U+BAA8 U+B4E0 U+C0AC U+B78C U+B4E4 U+C774
- U+D55C U+AD6D U+C5B4 U+B97C U+C774 U+D574 U+D55C U+B2E4 U+BA74
- U+C5BC U+B9C8 U+B098 U+C88B U+C744 U+AE4C (Hangul syllables)
-
- UTF-16: ????????????????????????????????????????????????
- UTF-8: ???????????????????????????????????????????????????????\
- ?????????????????
- AMC-M: yhxcj2w6exiaxi68acfn92n68ezehk6xypdpwam6zehmwhk648eavwd\
- p6aqi23ieemweywn
- BRACE: y394qebjusrcndbs82pkvstf96sxufcr7ffr4vbgdwsxufcx8pdktgb\
- gmnsqydmk7im56arju6pt82
- LACE: 77atrlgey5mlvkfu4dakzn4mwtsmo5gvlsww3rnuxf6mo5gvotkvzmx\
- exj2mlpfzzcyjrsely5ck4ta
- RACE: 3datrlgey5mlvkfu4dakzn4mwtsmo5gvlsww3rnuxf6mo5gvotkvzmx\
- exj2mlpfzzcyjrsely5ck4ta
- DUDE: s138qcc4s758raa8ke0s0acr78cke4s774t55cqd6ds5b4r97cs774t\
- 574lcr2e4q74s5bcr9c8g98s88bn44qe4c
-
- (N) Russian:
- U+041F U+043E U+0447 U+0435 U+043C U+0443 U+0436 U+0435 U+043E
- U+043D U+0438 U+043D U+0435 U+0433 U+043E U+0432 U+043E U+0440
- U+044F U+0442 U+043F U+043E U+0440 U+0443 U+0441 U+0441 U+043A
- U+0438 (Cyrillic)
-
- DUDE: K3fuk7j5sk3j6lutotljuiuk0vijfuk0jhhjao
- AMC-M: aehHgrvfemvgvfgfafvfvdgvcgiwrkhgimjjca
- BRACE: 269xyjvcyafqfdwyr3xfd8z8byi6z39xyi692s7ug2
- RACE: aq7t4rzvhrbtmnj6hu4d2njthyzd4qcpii7t4qcdifatuoa
- LACE: dqcd6pshgu6egnrvhy6tqpjvgm7depsaj5bd6psainaucory
- UTF-16: ???????????????????????????????????????????????????????\
- ???
- UTF-8: ???????????????????????????????????????????????????????
- ???
-
- (O) Spanish: Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol
-
- <eacute> = U+00E9
- <ntilde> = U+00F1
-
- UTF-8: Porqu??nopuedensimplementehablarenEspa??ol
- AMC-M: aa7-Porqu-b-nopuedensimplementehablarenEspa-j-ol
- BRACE: 22x-Porqu-9-nopuedensimplementehablarenEspa-j-ol
- DUDE: N0mfn2hlu9mevn0lm5klun3m9tn0mcltlun4m5ohishn2m5uLn3gm1v\
- 1mfs
- RACE: abyg64troxuw433qovswizloonuw24dmmvwwk3tumvugcytmmfzgk3t\
- fonygd4lpnq
- LACE: faaha33sof26s3tpob2wkzdfnzzws3lqnrsw2zloorswqylcnrqxezl\
- omvzxayprn5wa
- UTF-16: ???????????????????????????????????????????????????????\
- ?????????????????????????
-
- (P) Taiwanese:
- U+4ED6 U+5011 U+7232 U+4EC0 U+9EBD U+4E0D U+8AAA U+4E2D U+6587
-\f
- UTF-16: ??????????????????
- UTF-8: ???????????????????????????
- AMC-M: uqj7g2tbgtu6a385pspnxkupdnh
- BRACE: kgcqui49gatc2wyrn8y7cndgte9
- RACE: 3bhnmuaroize5qe6xvha3cvkjywwlby
- LACE: 75hnmuaroize5qe6xvha3cvkjywwlby
- DUDE: ked6l011n232kec0pebdke0doaaake2dm587
-
- (Q) Vietnamese:
- Ta<dotbelow>isaoho<dotbelow>kh<ocirc>ngth<ecirc><hookabove>chi\
- <hookabove>no<acute>iti<ecirc><acute>ngVi<ecirc><dotbelow>t
-
- <dotbelow> = U+0323
- <ocirc> = U+00F4
- <ecirc> = U+00EA
- <hookabove> = U+0309
- <acute> = U+0301
-
- UTF-8: Ta??isaoho??kh??ngth????chi??no??iti????ngVi????t
- AMC-M: ada-Ta-ud-isaoho-ud-kh-s9e-ngth-s8kj-chi-j-no-b-iti-s8k\
- b-ngVi-s8kud-t
- BRACE: i54-Ta-8-isaoho-ay-kh-29n-ngth-s2xa6i-chi-k-no-2g-iti-2\
- 9c29-ngVi-25p48-t
- UTF-16: ???????????????????????????????????????????????????????\
- ?????????????????????
- DUDE: N4m1j23g69n3m1vovj23g6bov4menn4m8uaj09g63opj09g6evj01g6\
- 9n4m9uaj01g6enN6m9uaj23g74
- LACE: aiahiyibamrqmadjonqw62dpaebsgcaannupi3thoruouaidbebqay3\
- ineaqgcicabxg6aidaecaa2lunhvacaybauag4z3wnhvacazdaeahi
- RACE: ap7xj73bep7wt73t75q76377nd7w6i77np7wr77u75xp6z77ot7wr77\
- kbh7wh73i75uqt73o75xqd73j752p62p75ia763x7m77xn73j77vch7\
- 3u
-
- The last example is an ASCII string that breaks not only the
- existing rules for host name labels but also the rules proposed in
- [NAMEPREP02] for internationalized domain names.
-
- (R) -> $1.00 <-
-
- UTF-8: -> $1.00 <-
- DUDE: -jei0kj1iej0gi0jc-
- RACE: aawt4ibegexdambahqwq
- LACE: bmac2praeqys4mbqea6c2
- UTF-16: ??????????????????????
- AMC-M: aae--vqae-1-q-00-avn--
- BRACE: 229--t2b4-1-w-00-i9i--
-
-Security considerations
-
- Users expect each domain name in DNS to be controlled by a single
- authority. If a Unicode string intended for use as a domain label
- could map to multiple ACE labels, then an internationalized domain
- name could map to multiple ACE domain names, each controlled by
- a different authority, some of which could be spoofs that hijack
- service requests intended for another. Therefore AMC-ACE-M is
- designed so that each Unicode string has a unique encoding.
-\f
- However, there can still be multiple Unicode representations of the
- "same" text, for various definitions of "same". This problem is
- addressed to some extent by the Unicode standard under the topic
- of canonicalization, but some text strings may be misleading or
- ambiguous to humans when used as domain names, such as strings
- containing dots, slashes, at-signs, etc. These issues are being
- further studied under the topic of "nameprep" [NAMEPREP02].
-
-References
-
- [ACEID01] Yoshiro Yoneya, Naomasa Maruyama, "Proposal for
- a determining process of ACE identifier", 2000-Dec-19,
- draft-ietf-idn-aceid-01.
-
- [BRACE00] Adam Costello, "BRACE: Bi-mode Row-based
- ASCII-Compatible Encoding for IDN version 0.1.2", 2000-Sep-19,
- draft-ietf-idn-brace-00.
-
- [DUDE00] Brian Spolarich, Mark Welter, "DUDE: Differential Unicode
- Domain Encoding", 2000-Nov-21, draft-ietf-idn-dude-00.
-
- [IDN] Internationalized Domain Names (IETF working group),
- http://www.i-d-n.net/, idn@ops.ietf.org.
-
- [LACE01] Paul Hoffman, Mark Davis, "LACE: Length-based ASCII
- Compatible Encoding for IDN", 2001-Jan-05, draft-ietf-idn-lace-01.
-
- [NAMEPREP02] Paul Hoffman, Marc Blanchet, "Preparation
- of Internationalized Host Names", 2001-Jan-17,
- draft-ietf-idn-nameprep-02.
-
- [PROVINCIAL] Michael Kaplan, "The 'anyone can be provincial!' page",
- http://www.trigeminal.com/samples/provincial.html.
-
- [RACE03] Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding
- for IDN", 2000-Nov-28, draft-ietf-idn-race-03.
-
- [RFC952] K. Harrenstien, M. Stahl, E. Feinler, "DOD Internet Host
- Table Specification", 1985-Oct, RFC 952.
-
- [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
- 1987-Nov, RFC 1034.
-
- [RFC1123] Internet Engineering Task Force, R. Braden (editor),
- "Requirements for Internet Hosts -- Application and Support",
- 1989-Oct, RFC 1123.
-
- [SACE] Dan Oscarsson, "Simple ASCII Compatible Encoding (SACE)",
- draft-ietf-idn-sace-*.
-
- [UNICODE] The Unicode Consortium, "The Unicode Standard",
- http://www.unicode.org/unicode/standard/standard.html.
-
- [UTF5] James Seng, Martin Duerst, Tin Wee Tan, "UTF-5, a
- Transformation Format of Unicode and ISO 10646", draft-jseng-utf5-*.
-
- [UTF6] Mark Welter, Brian W. Spolarich, "UTF-6 - Yet Another
- ASCII-Compatible Encoding for IDN", draft-ietf-idn-utf6-*.
-\f
- [UTFCONV] Mark Davis, "UTF Converter",
- http://www.macchiato.com/unicode/convert.html.
-
-Author
-
- Adam M. Costello <amc@cs.berkeley.edu>
- http://www.cs.berkeley.edu/~amc/
-
-
-Example implementation
-
-
-/******************************************/
-/* amc-ace-m.c 0.1.0 (2001-Feb-12-Mon) */
-/* Adam M. Costello <amc@cs.berkeley.edu> */
-/******************************************/
-
-/* This is ANSI C code implementing AMC-ACE-M version 0.1.*. */
-
-
-/************************************************************/
-/* Public interface (would normally go in its own .h file): */
-
-#include <limits.h>
-
-enum amc_ace_status {
- amc_ace_success,
- amc_ace_invalid_input,
- amc_ace_output_too_big
-};
-
-enum case_sensitivity { case_sensitive, case_insensitive };
-
-#if UINT_MAX >= 0x10FFFF
-typedef unsigned int u_code_point;
-#else
-typedef unsigned long u_code_point;
-#endif
-
-int amc_ace_m_encode(
- unsigned int input_length,
- const u_code_point *input,
- const unsigned char *uppercase_flags,
- unsigned int *output_size,
- unsigned char *output );
-\f
- /* amc_ace_m_encode() converts Unicode to AMC-ACE-M. The input */
- /* must be represented as an array of Unicode code points */
- /* (not code units; surrogate pairs are not allowed), and the */
- /* output will be represented as null-terminated ASCII. The */
- /* input_length is the number of code points in the input. The */
- /* output_size is an in/out argument: the caller must pass */
- /* in the maximum number of characters that may be output */
- /* (including the terminating null), and on successful return */
- /* it will contain the number of characters actually output */
- /* (including the terminating null, so it will be one more than */
- /* strlen() would return, which is why it is called output_size */
- /* rather than output_length). The uppercase_flags array must */
- /* hold input_length boolean values, where nonzero means the */
- /* corresponding Unicode character should be forced to uppercase */
- /* after being decoded, and zero means it is caseless or should */
- /* be forced to lowercase. Alternatively, uppercase_flags may */
- /* be a null pointer, which is equivalent to all zeros. The */
- /* letters a-z and A-Z are always encoded literally, regardless */
- /* of the corresponding flags. The encoder always outputs */
- /* lowercase base-32 characters except when nonzero values */
- /* of uppercase_flags require otherwise, so the encoder is */
- /* compatible with any of the case models. The return value */
- /* may be any of the amc_ace_status values defined above; if */
- /* not amc_ace_success, then output_size and output may contain */
- /* garbage. On success, the encoder will never need to write an */
- /* output_size greater than input_length*5+6, because of how the */
- /* encoding is defined. */
-
-int amc_ace_m_decode(
- enum case_sensitivity case_sensitivity,
- unsigned char *scratch_space,
- const unsigned char *input,
- unsigned int *output_length,
- u_code_point *output,
- unsigned char *uppercase_flags );
-\f
- /* amc_ace_m_decode() converts AMC-ACE-M to Unicode. The input */
- /* must be represented as null-terminated ASCII, and the output */
- /* will be represented as an array of Unicode code points. */
- /* The case_sensitivity argument influences the check on the */
- /* well-formedness of the input string; it must be case_sensitive */
- /* if case-sensitive comparisons are allowed on encoded strings, */
- /* case_insensitive otherwise (see also section "Case sensitivity */
- /* models" of the AMC-ACE-M specification). The scratch_space */
- /* must point to space at least as large as the input, which will */
- /* get overwritten (this allows the decoder to avoid calling */
- /* malloc()). The output_length is an in/out argument: the */
- /* caller must pass in the maximum number of code points that */
- /* may be output, and on successful return it will contain the */
- /* actual number of code points output. The uppercase_flags */
- /* array must have room for at least output_length values, or it */
- /* may be a null pointer if the case information is not needed. */
- /* A nonzero flag indicates that the corresponding Unicode */
- /* character should be forced to uppercase by the caller, while */
- /* zero means it is caseless or should be forced to lowercase. */
- /* The letters a-z and A-Z are output already in the proper case, */
- /* but their flags will be set appropriately so that applying the */
- /* flags would be harmless. The return value may be any of the */
- /* amc_ace_status values defined above; if not amc_ace_success, */
- /* then output_length, output, and uppercase_flags may contain */
- /* garbage. On success, the decoder will never need to write */
- /* an output_length greater than the length of the input (not */
- /* counting the null terminator), because of how the encoding is */
- /* defined. */
-
-
-/**********************************************************/
-/* Implementation (would normally go in its own .c file): */
-
-#include <string.h>
-
-/* Character utilities: */
-
-/* is_ldh(codept) returns 1 if the code point represents an LDH */
-/* character (ASCII letter, digit, or hyphen-minus), 0 otherwise. */
-
-static int is_ldh(u_code_point codept)
-{
- if (codept == 45) return 1;
- if (codept < 48) return 0;
- if (codept <= 57) return 1;
- if (codept < 65) return 0;
- if (codept <= 90) return 1;
- if (codept < 97) return 0;
- if (codept <= 122) return 1;
- return 0;
-}
-
-/* is_AtoZ(c) returns 1 if c is an */
-/* uppercase ASCII letter, zero otherwise. */
-\f
-static unsigned char is_AtoZ(unsigned char c)
-{
- return c >= 65 && c <= 90;
-}
-
-/* special_row_offset[n] holds the offset of the */
-/* bottom of special row 0xD8 + n, where n is in 0..7. */
-
-static u_code_point special_row_offset[] =
- { 0x0020, 0x005B, 0x007B, 0x00A0, 0x00C0, 0x00DF, 0x0134, 0x0270 };
-
-/* base32[n] is the lowercase base-32 character representing */
-/* the number n from the range 0 to 31. Note that we cannot */
-/* use string literals for ASCII characters because an ANSI C */
-/* compiler does not necessarily use ASCII. */
-
-static const unsigned char base32[] = {
- 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, /* a-k */
- 109, 110, /* m-n */
- 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, /* p-z */
- 50, 51, 52, 53, 54, 55, 56, 57 /* 2-9 */
-};
-
-/* base32_decode(c) returns the value of a base-32 character, in the */
-/* range 0 to 31, or the constant base32_invalid if c is not a valid */
-/* base-32 character. */
-
-enum { base32_invalid = 32 };
-
-static unsigned int base32_decode(unsigned char c)
-{
- if (c < 50) return base32_invalid;
- if (c <= 57) return c - 26;
- if (c < 97) c += 32;
- if (c < 97 || c == 108 || c == 111 || c > 122) return base32_invalid;
- return c - 97 - (c > 108) - (c > 111);
-}
-
-/* unequal(case_sensitivity,a1,a2,n) returns 0 if the arrays */
-/* a1 and a2 are equal in the first n positions, 1 otherwise. */
-/* If case_sensitivity is case_insensitive, then ASCII A-Z are */
-/* considered equal to a-z respectively. */
-
-static int unequal(
- enum case_sensitivity case_sensitivity,
- const unsigned char *a1,
- const unsigned char *a2,
- unsigned int n )
-{
- const unsigned char *end;
- unsigned char c1, c2;
-\f
- if (case_sensitivity != case_insensitive) return memcmp(a1,a2,n);
-
- for (end = a1 + n; a1 < end; ++a1, ++a2) {
- c1 = *a1;
- c2 = *a2;
- if (c1 >= 65 && c1 <= 90) c1 += 32;
- if (c2 >= 65 && c2 <= 90) c2 += 32;
- if (c1 != c2) return 1;
- }
-
- return 0;
-}
-
-
-/* Encoder: */
-
-int amc_ace_m_encode(
- unsigned int input_length,
- const u_code_point *input,
- const unsigned char *uppercase_flags,
- unsigned int *output_size,
- unsigned char *output )
-{
- unsigned int literal, wide; /* boolean */
- u_code_point codept, n, diff, morebits;
- u_code_point A, B, C, offsetA, offsetB, offsetC, offset;
- const u_code_point *input_end, *p, *pp;
- unsigned int count, max, next_in, next_out, max_out, codelen, i;
- unsigned char c;
-
- input_end = input + input_length;
-
- /* 1) Verify that only valid code points appear: */
-
- for (p = input; p < input_end; ++p) {
- if (*p >> 11 == 0x1B || *p > 0x10FFFF) return amc_ace_invalid_input;
- }
-
- /* 2) Determine the most populous row: B and offsetB */
-
- /* first check the special rows: */
-
- B = 0xD8;
- offsetB = special_row_offset[0];
- max = 0;
-
- for (n = 0; n < 8; ++n) {
- offset = special_row_offset[n];
- count = 0;
-
- for (p = input; p < input_end; ++p) {
- if (*p - offset <= 0xFF && !is_ldh(*p)) ++count;
- }
-\f
- if (count > max) {
- B = 0xD8 + n;
- offsetB = offset;
- max = count;
- }
- }
-
- /* now check the regular rows: */
-
- for (pp = input; pp < input_end; ++pp) {
- n = *pp >> 8;
- count = 0;
-
- for (p = input; p < input_end; ++p) {
- if (*p >> 8 == n && !is_ldh(*p)) ++count;
- }
-
- if (count > max || (count == max && n < B)) {
- B = n;
- offsetB = n << 8;
- max = count;
- }
- }
-
- /* 3) Determine the most populous 16-window: A and offsetA */
-
- A = 0;
- max = 0;
-
- for (n = 0; n <= 0x1F; ++n) {
- offset = ((offsetB >> 3) + n) << 3;
- count = 0;
-
- for (p = input; p < input_end; ++p) {
- if (*p - offset <= 0xF && !is_ldh(*p)) ++count;
- }
-
- if (count > max) {
- A = n;
- offsetA = offset;
- max = count;
- }
- }
-
- /* 4) Determine the most populous 20k-window: C */
-
- C = 0;
- max = 0;
-
- for (pp = input; pp < input_end; ++pp) {
- count = 0;
- n = *pp >> 11;
- offset = n << 11;
-
- for (p = input; p < input_end; ++p) {
- if (*p - offset <= 0x4FFF && !is_ldh(*p)) ++count;
-\f
- if (count > max || (count == max && n < C)) {
- C = n;
- max = count;
- }
- }
- }
-
- /* 5) Determine the style to use: wide or narrow */
-
- /* if narrow style were used: */
-
- offsetC = (offsetB >> 12) << 12;
- count = 3 + (B > 0xFF);
-
- for (p = input; p < input_end; ++p) {
- if (is_ldh(*p)) { }
- else if (*p - offsetA <= 0xF) count += 1;
- else if (*p - offsetB <= 0xFF) count += 2;
- else if (*p - offsetC <= 0xFFF) count += 3;
- else if (*p <= 0xFFFF) count += 4;
- else count += 5;
- }
-
- max = count;
-
- /* if wide style were used: */
-
- offsetC = C << 11;
- count = B <= 0xFF && C <= 0x1F ? 3 : 5;
-
- for (p = input; p < input_end; ++p) {
- if (is_ldh(*p)) { }
- else if (*p - offsetB <= 0xFF) count += 2;
- else if (*p - offsetC <= 0x4FFF) count += 3;
- else if (*p <= 0xFFFF) count += 4;
- else count += 5;
- }
-
- wide = (count < max);
-
- /* 6) Initialize offsetC, and encode the style and offsets: */
-
- max_out = *output_size;
- next_out = 0;
-
- if (wide) {
- offsetC = C << 11;
-\f
- if (B <= 0xFF && C <= 0x1F) {
- if (max_out - next_out < 3) return amc_ace_output_too_big;
- output[next_out++] = base32[0x10 | (B >> 5)];
- output[next_out++] = base32[B & 0x1F];
- output[next_out++] = base32[C];
- }
- else {
- if (max_out - next_out < 5) return amc_ace_output_too_big;
- output[next_out++] = base32[0x18 | (B >> 10)];
- output[next_out++] = base32[(B >> 5) & 0x1F];
- output[next_out++] = base32[B & 0x1F];
- output[next_out++] = base32[C >> 5];
- output[next_out++] = base32[C & 0x1F];
- }
- }
- else {
- offsetC = (offsetB >> 12) << 12;
-
- if (B <= 0xFF) {
- if (max_out - next_out < 3) return amc_ace_output_too_big;
- output[next_out++] = base32[B >> 5];
- output[next_out++] = base32[B & 0x1F];
- }
- else {
- if (max_out - next_out < 4) return amc_ace_output_too_big;
- output[next_out++] = base32[8 | (B >> 10)];
- output[next_out++] = base32[(B >> 5) & 0x1F];
- output[next_out++] = base32[B & 0x1F];
- }
-
- output[next_out++] = base32[A];
- }
-
- /* 7) Main encoding loop: */
-
- literal = 0;
-
- for (next_in = 0; next_in < input_length; ++next_in) {
- codept = input[next_in];
-
- if (codept == 45 /* hyphen-minus */) {
- /* case 7.1 */
- if (max_out - next_out < 2) return amc_ace_output_too_big;
- output[next_out++] = 45;
- output[next_out++] = 45;
- continue;
- }
-
- if (is_ldh(codept)) {
- /* case 7.2 */
- if (!literal) {
- if (max_out - next_out < 1) return amc_ace_output_too_big;
- output[next_out++] = 45;
- literal = 1;
- }
-\f
- if (max_out - next_out < 1) return amc_ace_output_too_big;
- output[next_out++] = codept;
- continue;
- }
-
- /* case 7.3 */
-
- if (literal) {
- if (max_out - next_out < 1) return amc_ace_output_too_big;
- output[next_out++] = 45;
- literal = 0;
- }
-
- if (!wide) {
- diff = codept - offsetA;
-
- if (diff <= 0xF) {
- /* case 7.3.1 */
- codelen = 1;
- goto encoder_base32_bottom;
- }
- }
-
- diff = codept - offsetB;
-
- if (diff <= 0xFF) {
- /* case 7.3.2 */
- codelen = 2;
- goto encoder_base32_bottom;
- }
-
- diff = codept - offsetC;
-
- if (diff <= 0xFFF) {
- /* case 7.3.3 */
- codelen = 3;
- goto encoder_base32_bottom;
- }
-
- if (wide) {
- diff = codept - offsetC - 0x1000;
-
- if (diff <= 0x3FFF) {
- /* case 7.3.4 */
- codelen = 1;
- morebits = diff & 0x3FF;
- diff >>= 10;
- goto encoder_base32_bottom;
- }
- }
-
- if (codept <= 0xFFFF) {
- /* case 7.3.5 */
- diff = codept;
- codelen = 4;
- goto encoder_base32_bottom;
- }
-\f
- /* case 7.3.6 */
- diff = codept - 0x10000;
- codelen = 5;
-
- encoder_base32_bottom: /* output diff as n base-32 digits: */
- if (max_out - next_out < codelen) return amc_ace_output_too_big;
- i = codelen - 1;
- c = base32[diff & 0xF];
- if (uppercase_flags && uppercase_flags[next_in]) c -= 32;
- output[next_out + i] = c;
-
- while (i > 0) {
- diff >>= 4;
- output[next_out + --i] = base32[0x10 | (diff & 0xF)];
- }
-
- next_out += codelen;
-
- if (wide && codelen == 1) {
- /* case 7.3.4 */
- if (max_out - next_out < 2) return amc_ace_output_too_big;
- output[next_out++] = base32[morebits >> 5];
- output[next_out++] = base32[morebits & 0x1F];
- }
- }
-
- /* null terminator: */
- if (max_out - next_out < 1) return amc_ace_output_too_big;
- output[next_out++] = 0;
- *output_size = next_out;
- return amc_ace_success;
-}
-
-
-/* Decoder: */
-
-int amc_ace_m_decode(
- enum case_sensitivity case_sensitivity,
- unsigned char *scratch_space,
- const unsigned char *input,
- unsigned int *output_length,
- u_code_point *output,
- unsigned char *uppercase_flags )
-{
- unsigned int literal, wide, large; /* boolean */
- const unsigned char *next_in;
- unsigned char c;
- unsigned int next_out, max_out, codelen, input_size, scratch_size;
- u_code_point q, B, offsets[6], diff, offset;
- enum amc_ace_status status;
-\f
- /* 1) Decode the style and offsets: */
-
- next_in = input;
- q = base32_decode(*next_in++);
- if (q == base32_invalid) return amc_ace_invalid_input;
- wide = q >> 4;
- large = (q >> 3) & 1;
- B = q & 7;
- q = base32_decode(*next_in++);
- if (q == base32_invalid) return amc_ace_invalid_input;
- B = (B << 5) | q;
-
- if (large) {
- q = base32_decode(*next_in++);
- if (q == base32_invalid) return amc_ace_invalid_input;
- B = (B << 5) | q;
- }
-
- /* offsets[codelen] is for base-32 codes with codelen characters */
- /* (not counting the extra two in wide-style 0xxxx xxxxx xxxxx) */
-
- offsets[2] = B >> 3 == 0x1B ? special_row_offset[B & 7] : B << 8;
- q = base32_decode(*next_in++);
- if (q == base32_invalid) return amc_ace_invalid_input;
-
- if (!wide) {
- offsets[1] = ((offsets[2] >> 3) + q) << 3;
- offsets[3] = (offsets[2] >> 12) << 12;
- }
- else {
- offset = q << 11;
-
- if (large) {
- q = base32_decode(*next_in++);
- if (q == base32_invalid) return amc_ace_invalid_input;
- offset = (offset << 5) | q;
- }
-
- offsets[3] = offset;
- offsets[1] = offset + 0x1000;
- }
-
- offsets[4] = 0;
- offsets[5] = 0x10000;
-
- /* 2) Main decoding loop: */
-
- max_out = *output_length;
- next_out = 0;
- literal = 0;
-
- for (;;) {
- c = *next_in++;
- if (!c) break;
-\f
- if (c == 45 /* hyphen-minus */) {
- if (*next_in == 45) {
- /* case 2.1: "--" decodes to "-" */
- ++next_in;
- if (max_out - next_out < 1) return amc_ace_output_too_big;
- if (uppercase_flags) uppercase_flags[next_out] = 0;
- output[next_out++] = 45;
- continue;
- }
-
- /* case 2.2: unpaired hyphen-minus toggles mode */
- literal = !literal;
- continue;
- }
-
- if (!is_ldh(c)) return amc_ace_invalid_input;
- if (max_out - next_out < 1) return amc_ace_output_too_big;
-
- if (literal) {
- /* case 2.3: literal letter/digit */
- if (uppercase_flags) uppercase_flags[next_out] = is_AtoZ(c);
- output[next_out++] = c;
- continue;
- }
-
- /* case 2.4: base-32 sequence */
-
- diff = 0;
- codelen = 1;
-
- for (;;) {
- q = base32_decode(c);
- if (q == base32_invalid) return amc_ace_invalid_input;
- diff = (diff << 4) | (q & 0xF);
- if ((q & 0x10) == 0) break;
- if (++codelen > 5) return amc_ace_invalid_input;
- c = *next_in++;
- }
-
- /* Now codelen is the number of input characters read, */
- /* and c is the character holding the uppercase flag. */
-
- if (wide && codelen == 1) {
- q = base32_decode(*next_in++);
- if (q == base32_invalid) return amc_ace_invalid_input;
- diff = (diff << 5) | q;
- q = base32_decode(*next_in++);
- if (q == base32_invalid) return amc_ace_invalid_input;
- diff = (diff << 5) | q;
- }
-
- offset = offsets[codelen];
- if (uppercase_flags) uppercase_flags[next_out] = is_AtoZ(c);
- output[next_out++] = offset + diff;
- }
-\f
- /* 3) Re-encode the output and compare to the input: */
-
- input_size = next_in - input;
- scratch_size = input_size;
- status = amc_ace_m_encode(next_out, output, uppercase_flags,
- &scratch_size, scratch_space);
- if (status != amc_ace_success ||
- scratch_size != input_size ||
- unequal(case_sensitivity, scratch_space, input, input_size)
- ) return amc_ace_invalid_input;
- *output_length = next_out;
- return amc_ace_success;
-}
-
-
-/******************************************************************/
-/* Wrapper for testing (would normally go in a separate .c file): */
-
-#include <assert.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-/* For testing, we'll just set some compile-time limits rather than */
-/* use malloc(), and set a compile-time option rather than using a */
-/* command-line option. */
-
-enum {
- unicode_max_length = 256,
- ace_max_size = 256,
- test_case_sensitivity = case_insensitive
-};
-
-
-static void usage(char **argv)
-{
- fprintf(stderr,
- "%s -e reads big-endian UTF-32 and writes AMC-ACE-M ASCII.\n"
- "%s -d reads AMC-ACE-M ASCII and writes big-endian UTF-32.\n"
- "UTF-32 is extended: bit 31 is used as force-to-uppercase flag.\n"
- , argv[0], argv[0]);
- exit(EXIT_FAILURE);
-}
-
-
-static void fail(const char *msg)
-{
- fputs(msg,stderr);
- exit(EXIT_FAILURE);
-}
-
-static const char too_large[] =
- "input or output is too large, recompile with larger limits\n";
-
-static const char invalid_input[] = "invalid input\n";
-\f
-int main(int argc, char **argv)
-{
- enum amc_ace_status status;
-
- if (argc != 2) usage(argv);
- if (argv[1][0] != '-') usage(argv);
- if (argv[1][2] != '\0') usage(argv);
-
- if (argv[1][1] == 'e') {
- u_code_point input[unicode_max_length];
- unsigned char uppercase_flags[unicode_max_length];
- unsigned char output[ace_max_size];
- unsigned int input_length, output_size;
- int c0, c1, c2, c3;
-
- /* Read the UTF-32 input string: */
-
- input_length = 0;
-
- for (;;) {
- c0 = getchar();
- c1 = getchar();
- c2 = getchar();
- c3 = getchar();
-
- if (c1 == EOF || c2 == EOF || c3 == EOF) {
- if (c0 != EOF) fail("input not a multiple of 4 bytes\n");
- break;
- }
-
- if (input_length == unicode_max_length) fail(too_large);
-
- if ((c0 != 0 && c0 != 0x80)
- || c1 < 0 || c1 > 0x10
- || c2 < 0 || c2 > 0xFF
- || c3 < 0 || c3 > 0xFF ) {
- fail(invalid_input);
- }
-
- input[input_length] = ((u_code_point) c1 << 16) |
- ((u_code_point) c2 << 8) | (u_code_point) c3;
- uppercase_flags[input_length] = (c0 >> 7);
- ++input_length;
- }
-
- /* Encode, and output the result: */
-
- output_size = ace_max_size;
- status = amc_ace_m_encode(input_length, input, uppercase_flags,
- &output_size, output);
- if (status == amc_ace_invalid_input) fail(invalid_input);
- if (status == amc_ace_output_too_big) fail(too_large);
- assert(status == amc_ace_success);
- fputs((char *) output, stdout);
- return EXIT_SUCCESS;
- }
-\f
- if (argv[1][1] == 'd') {
- unsigned char input[ace_max_size], scratch[ace_max_size];
- u_code_point output[unicode_max_length], codept;
- unsigned char uppercase_flags[unicode_max_length];
- unsigned int output_length, i;
- size_t n;
-
- /* Read the AMC-ACE-M ASCII input string: */
-
- n = fread(input, 1, ace_max_size, stdin);
- if (n == ace_max_size) fail(too_large);
- input[n] = 0;
-
- /* Decode, and output the result: */
-
- output_length = unicode_max_length;
- status = amc_ace_m_decode(test_case_sensitivity, scratch, input,
- &output_length, output, uppercase_flags);
- if (status == amc_ace_invalid_input) fail(invalid_input);
- if (status == amc_ace_output_too_big) fail(too_large);
- assert(status == 0);
-
- for (i = 0; i < output_length; ++i) {
- putchar(uppercase_flags[i] ? 0x80 : 0);
- codept = output[i];
- putchar(codept >> 16);
- putchar((codept >> 8) & 0xFF);
- putchar(codept & 0xFF);
- }
-
- return EXIT_SUCCESS;
- }
-
- usage(argv);
- return EXIT_SUCCESS; /* not reached, but quiets a compiler warning */
-}
-
-
-
- INTERNET-DRAFT expires 2001-Aug-12
+++ /dev/null
-INTERNET-DRAFT Adam M. Costello
-draft-ietf-idn-brace-00.txt 2000-Sep-14
-Expires 2001-Mar-14
-
- BRACE: Bi-mode Row-based ASCII-Compatible Encoding for IDN
- version 0.1.2
-
-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
-
- Distribution of this document is unlimited. Please send comments
- to the author at amc@cs.berkeley.edu, or to the idn working group
- at idn@ops.ietf.org. A newer version of this specification may be
- available at http://www.cs.berkeley.edu/~amc/charset/brace
-
-Abstract
-
- BRACE is a reversible function from Unicode (UTF-16) [UNICODE]
- text strings to host name labels. Host name labels are defined by
- [RFC952] and [RFC1123] as case-insensitive strings of ASCII letters,
- digits, and hyphens, neither beginning nor ending with a hyphen.
- [RFC1034] restricts the length of labels to 63 characters.
-
-Contents
-
- Primary goals
- Secondary goals
- Overview
- Encoding procedure
- Base-32 characters
- Encoding styles
- Decoding procedure
- Comparison with RACE
- Example strings
- Security considerations
- References
- Author
- Example implementation
-\f
-Primary goals
-
- Efficient encoding: Small ratio of encoded size to original size,
- for all UTF-16 strings.
-
- Uniqueness: Every UTF-16 string maps to at most one label.
-
- Completeness: Every UTF-16 string maps to a label, provided it is
- not too long. Restrictions on which UTF-16 strings are allowed is
- purely a matter of policy.
-
- Degeneration: All valid host name labels that do not end with the
- BRACE signature "-8Q9" (or "-8q9") are the BRACE encodings of their
- own UTF-16 representations.
-
-Secondary goals
-
- Conceptual simplicity: This has been somewhat compromised for the
- sake of efficient encoding.
-
- Readability: ASCII letters and digits in the original string are
- represented literally in the encoded string. This comes for free
- because it is the most efficient encoding anyway.
-
-Overview
-
- The encoded string alternates between two modes. ASCII letters,
- digits, and hyphens in the Unicode string (which will henceforth be
- called LDH characters) are encoded literally, except that hyphens
- are doubled. Non-LDH codes in the Unicode string are encoded
- using base-32 mode, in which each character of the encoded string
- represents five bits. Single hyphens in the encoded string indicate
- mode changes.
-
- The base-32 mode uses exactly one of four styles. Half-row style is
- used for Unicode strings in which all the non-LDH codes belong to
- a single half-row (have the same upper 9 bits). Full-row style is
- used for Unicode strings in which all the non-LDH codes belong to a
- single row (have the same upper 8 bits) but not all the same half.
- Mixed style is used when when many of the non-LDH characters (but
- not all of them) belong to the same row. No-row style is used for
- all other strings.
-
-Encoding procedure
-
- If the UTF-16 string contains more than 63 16-bit codes, it's too
- long, so abort.
-
- If the upper bytes are all zero, and the string formed by the lower
- bytes is a valid host name label and does not end with "-8Q9" or
- "-8q9", output the low bytes and stop.
-\f
- The encoder needs a bit queue capable of holding up to 22 bits, a
- buffer of LDH characters capable of holding up to 124 characters,
- and a 4-value encoding style indicator. The LDH buffer is initially
- empty. The initial contents of the bit queue, and the value of the
- style indicator, depend on which encoding style is chosen (which
- is explained below). Bit strings are enqueued and dequeued in
- big-endian order (most significant bit first).
-
- After choosing the style and initializing the bit queue, perform the
- following actions:
-
- while the bit queue contains at least 5 bits
- dequeue 5 bits
- output the corresponding base-32 character
- endwhile
-
- for each 16-bit code of the UTF-16 string (in order) do
- if the code is 0x002D ("-", ASCII hyphen) then
- append two hyphens to the ASCII buffer
- else if the code is an LDH character then
- if the LDH buffer contains no non-hyphens then
- append one hyphen to the LDH buffer
- endif
-
- append the code to the LDH buffer
- else (the code is not an LDH character)
- if the LDH buffer contains any non-hyphens then
- append one hyphen to the LDH buffer
- endif
-
- if the bit queue is empty then
- output the LDH buffer and reset it to empty
- endif
-
- enqueue the bit string corresponding to the code
- (the bit string depends on the encoding style)
- dequeue 5 bits
- output the corresponding base-32 character
- output the LDH buffer and reset it to empty
-
- while the bit queue contains at least 5 bits
- dequeue 5 bits
- output the corresponding base-32 character
- endwhile
- endif
- endfor
-
- if the bit queue is not empty
- enqueue zero bits until it contains 5 bits
- dequeue 5 bits
- output the corresponding base-32 character
- endif
-
- output the LDH buffer
- output the LDH characters "-8Q9"
-
- If the total number of characters output was greater than 63, the
- string is too long for a host name label.
-\f
- Notice that a group of LDH characters appears in the output as soon
- as all the bits of the preceeding non-LDH codes have appeared. The
- base-32 character that appears just before the switch to literal
- mode may contain at most four bits of information from the first
- non-LDH character that comes after the LDH group.
-
-Base-32 characters
-
- "2" = 0 = 00000
- "3" = 1 = 00001
- "4" = 2 = 00010
- "5" = 3 = 00011
- "6" = 4 = 00100
- "7" = 5 = 00101
- "8" = 6 = 00110
- "9" = 7 = 00111
- "A" = 8 = 01000
- "B" = 9 = 01001
- "C" = 10 = 01010
- "D" = 11 = 01011
- "E" = 12 = 01100
- "F" = 13 = 01101
- "G" = 14 = 01110
- "H" = 15 = 01111
- "I" = 16 = 10000
- "J" = 17 = 10001
- "K" = 18 = 10010
- "M" = 19 = 10011
- "N" = 20 = 10100
- "P" = 21 = 10101
- "Q" = 22 = 10110
- "R" = 23 = 10111
- "S" = 24 = 11000
- "T" = 25 = 11001
- "U" = 26 = 11010
- "V" = 27 = 11011
- "W" = 28 = 11100
- "X" = 29 = 11101
- "Y" = 30 = 11110
- "Z" = 31 = 11111
-
- The digits "0" and "1" and the letters "O" and "L" ("l") are not
- used, to avoid transcription errors.
-
- The base-32 characters, like all characters in host name labels, are
- case-insensitive, so they must be recognized in both upper and lower
- case. However, since existing LDH labels are usually stored in
- lower case, it is recommended that the base-32 portions of encoded
- names be stored in upper case, to help humans easily pick out the
- literal portions.
-
-Encoding styles
-
- The choice of encoding style depends only on the codes in the UTF-16
- string that are not LDH characters. It in no way depends on any LDH
- codes that may be present.
-\f
- Each code belongs to a particular half-row, which is given by its
- upper 9 bits. If all of the non-LDH codes belong to the same
- half-row, use half-row style: Initialize the bit queue by enqueuing
- two 0 bits followed by the designated half-row number (the 9-bit
- half-row number shared by all the codes). During the encoding
- procedure the bit string corresponding to each code is its lower 7
- bits.
-
- If not all the non-LDH codes belong to the same half-row, but they
- all belong to the same row (same upper 8 bits), use full-row style:
- Initialize the bit queue by enqueuing a 0 bit, then a 1 bit, then
- the designated row number (the 8-bit row number shared by all the
- codes). During the encoding procedure the bit string corresponding
- to each code is its lower 8 bits.
-
- If not all non-LDH codes belong to the same row, then consider
- using mixed style, which chooses a priviledged half-row. For each
- half-row used by the non-LDH codes, count the number of codes that
- belong to that half-row. Then, for each half-row, calculate M, the
- number of base-32 characters that would be required if that half row
- were chosen:
-
- N = total number of non-LDH codes
- H = number of non-LDH codes in the candidate half-row
- C = number of non-LDH codes in the complementary half-row (the
- one with the opposite lowest bit)
- M = (2 + 9 + 18*(N - H - C) + 8*H + 9*C + 4) / 5
- = 3 + (18*N - 10*H - 9*C) / 5
-
- (The division is integer division, which discards any remainder.)
-
- Choose the half-row with the smallest M, breaking ties in favor of
- lower-numbered half-rows. Compare this M with M', the number of
- base-32 characters that would be required if no-row style were used:
-
- M' = (2 + 16*N + 4) / 5 = (6 + 16*N) / 5
-
- If M' <= M, use no-row style: Initialize the bit queue by
- enqueueing two 1 bits. There is no designated row number. During
- the encoding procedure the bit string corresponding to each code is
- the full 16-bit code itself.
-
- If M < M', use mixed style: Initialize the bit queue by enqueueing
- a 1 bit, then a 0 bit, then the designated 9-bit half-row number
- (the one chosen above). During the encoding procedure the bit
- string corresponding to each code is:
-
- 0 followed by the lower 7 bits if the code belongs to the chosen
- half-row;
-
- 10 followed by the lower 7 bits if the code belongs to the
- complementary half-row;
-\f
- 11 followed by the whole 16-bit code otherwise.
-
-Decoding procedure
-
- The following description assumes that UTF-16 output is desired.
-
- If the input string does not end with "-8Q9" or "-8q9", output the
- input string (converted from ASCII to UTF-16) and stop.
-
- The decoder needs a bit queue capable of holding up to 22 bits. It
- is initially empty. It also needs a literal-mode flag, which is
- initially unset, and a 4-value style indicator.
-
- Perform the following actions:
-
- read the first character and enqueue its base-32 quintet
- dequeue two bits and use them to set the style indicator
-
- if the style uses a designated full/half row number then
- while the queue does not contain enough bits to represent it
- read the next character and enqueue its base-32
- endwhile
-
- dequeue enough bits to set the designated row (or half-row)
- endif
-
- for each remaining input character except the last four do
- if the character is an ASCII hyphen then
- if the next character is also an ASCII hyphen then
- skip it
- output an ASCII hyphen (converted to UTF-16)
- else
- toggle the literal-mode flag
- endif
- else if the literal-mode flag is set then
- output the character (converted to UTF-16)
- else (the literal-mode flag is clear)
- enqueue the character's base-32 quintet
-
- if the bit queue contains enough bits to represent a
- UTF-16 code (which depends on the style indicator)
- then
- dequeue just enough bits to represent one code
- output the code
- endif
- endif
- endfor
-
- At the end the bit queue may contain up to four 0 bits. If it
- contains anything else, the input was invalid.
-\f
-Comparison with RACE
-
- BRACE is an extension of RACE [RACE01]. For Unicode strings
- that contain no LDH characters and use the full-row or no-row
- encoding styles, BRACE is virtually identical to RACE. For other
- strings, BRACE produces a smaller encoding than RACE. For example,
- the encoding is substantially more compact for Unicode strings
- containing a substantial number of LDH characters, or containing
- many Japanese kana with some kanji.
-
- Unlike RACE, any LDH characters present in the Unicode string are
- represented literally in the BRACE-encoded string. This may or may
- not be useful, but it happens to be the most compact way to encode
- LDH characters.
-
- Whereas RACE uses a signature prefix, BRACE uses a signature suffix.
- This makes it easy to guarantee that the encoded label never ends
- with a hyphen, even if the original UTF-16 string does. (Whether
- such a UTF-16 string should be allowed is a matter of policy, not
- technical capability).
-
- The main drawback of BRACE is its greater complexity.
-
-Example strings
-
- All of these examples use Japanese text, merely because that is the
- only kind of non-English text that the author has lying around.
-
- Example of no-row style:
-
- An actual music group name coerced into the usual format for
- host name labels:
-
- AMURONAMIE-with-super-monkeys
-
- AMURONAMIE stands for five kanji whose Unicode values are (in
- order):
-
- U+5B89 U+5BA4 U+5948 U+7F8E U+6075
-
- The BRACE encoding is:
-
- UVJ7FUAQCAHY982XA---with--super--monkeys-8Q9
-
- (Note that the RACE encoding would have been 79 characters long,
- and hence unusable.)
-
- Example of mixed style:
-
- An actual song title coerced into the usual format for host name
- labels:
-
- hello-another-way-SOREZORENOBASHO
-
- SOREZORENOBASHO stands for five hiragana followed by two kanji,
- whose Unicode values are (in order):
-\f
- U+305D U+308C U+305E U+308C U+306E U+5834 U+6240
-
- The BRACE encoding is:
-
- JI7-hello--another--way---V3JHAEFVD2UFJ62-8Q9
-
- Example of full-row style:
-
- An actual song title, SONOSUPIIDODE, which stands for two
- hiragana followed by four katakana followed by one hiragana,
- whose Unicode values are:
-
- U+305D U+306E U+30B9 U+30D4 U+30FC U+30C9 U+3067
-
- The BRACE encoding is:
-
- BIDPRDMP9WT7MI-8Q9
-
- Example of half-row style:
-
- An actual song title:
-
- PAFIIdeRUNBA
-
- PAFII stands for four katakana whose Unicode values are:
-
- U+30D1 U+30D5 U+30A3 U+30FC
-
- RUNBA stands for three katakana whose Unicode values are:
-
- U+30EB U+30F3 U+30D0
-
- The BRACE encoding is:
-
- 3IU8PAZT-de-PYGI-8Q9
-
- Example of an ASCII string that breaks all the rules of host name
- labels:
-
- -> $1.00 <-
-
- The BRACE encoding is:
-
- 229--T2B4-1-W-00-I9I---8Q9
-
-Security considerations
-
- Users expect each host name in DNS to be controlled by a single
- authority. If a UTF-16 string could map to multiple labels, then
- a UTF-16 host name could map to multiple real host names, each
- controlled by a different authority, some of which could be spoofs
- that hijack service requests intended for another. Therefore BRACE
- is designed so that each UTF-16 string maps to a unique label.
-\f
- However, there can still be multiple UTF-16 representations
- of the "same" text, for various definitions of "same". This
- problem is addressed by the Unicode standard under the topic of
- canonicalization, but the issue needs to be studied further in the
- context of host names.
-
- Also, some text strings may be misleading or ambiguous to humans,
- such as strings containing dots, slashes, at-signs, etc. Policies
- for allowable Unicode strings need to be developed.
-
-References
-
- [IDN] Internationalized Domain Names (IETF working group),
- http://www.i-d-n.net/, idn@ops.ietf.org.
-
- [RACE01] Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding
- for IDN", 2000-Aug-31, draft-ietf-idn-race-01.
-
- [RFC952] K. Harrenstien, M. Stahl, E. Feinler, "DOD Internet Host
- Table Specification", 1985-Oct, RFC 952.
-
- [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
- 1987-Nov, RFC 1034.
-
- [RFC1123] Internet Engineering Task Force, R. Braden (editor),
- "Requirements for Internet Hosts -- Application and Support",
- 1989-Oct, RFC 1123.
-
- [SACE] Dan Oscarsson, "Simple ASCII Compatible Encoding (SACE)",
- draft-ietf-idn-sace.
-
- [UNICODE] The Unicode Consortium, "The Unicode Standard",
- http://www.unicode.org/unicode/standard/standard.html.
-
- [UTF5] James Seng, Martin Duerst, Tin Wee Tan, "UTF-5, a
- Transformation Format of Unicode and ISO 10646", draft-jseng-utf5.
-
-Author
-
- Adam M. Costello <amc@cs.berkeley.edu>
- http://www.cs.berkeley.edu/~amc/
-
-
-Example implementation
-
-
-/* brace.c 0.1.1 (2000-Sep-09-Sat) */
-/* Adam M. Costello <amc@cs.berkeley.edu> */
-
-/* This is ANSI C code implementing BRACE version 0.1.*. */
-\f
-/* Public interface (would normally go in its own .h file): */
-
-enum {
- brace_encoder_in_max = 63,
- brace_encoder_out_max = 4 + (6 + 16 * brace_encoder_in_max) / 5 + 1,
- brace_decoder_in_max = 63 + 1,
- brace_decoder_out_max = brace_decoder_in_max - 1
-};
-
- /* The above constants are the maximum array sizes */
- /* that the encoder/decoder will accept/produce */
- /* (including null terminators for ASCII strings). */
-
-void brace_encode(
- unsigned int input_length,
- unsigned short *input,
- char output[brace_encoder_out_max] );
-
- /* brace_encode() converts UTF-16 input to null-terminated */
- /* BRACE-encoded ASCII output. The input_length must not */
- /* exceed brace_encoder_in_max, and the output array must */
- /* have at least the size indicated below. Under those */
- /* constraints, this function never fails. */
-
-int brace_decode(
- char *input,
- unsigned int *output_length,
- unsigned short output[brace_decoder_out_max] );
-
- /* brace_decode() converts null-terminated BRACE-encoded ASCII */
- /* input to UTF-16 output. The input length (including the null */
- /* terminator) must not exceed brace_encoder_in_max, and output */
- /* array must have at least the size indicated below. Returns 1 */
- /* on success, 0 if the input was malformed. If 0 is returned */
- /* the output array may contain garbage, but *output_length will */
- /* not have been affected. */
-
-
-/* Implementation (would normally go in its own .c file): */
-
-#include <assert.h>
-
-static const char base32[] = {
- 50, 51, 52, 53, 54, 55, 56, 57, 65, 66, 67, 68, 69, 70, 71, 72,
- 73, 74, 75, 77, 78, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90
-};
-
-/* We can't use string literals for ASCII characters because */
-/* an ANSI C compiler does not necessarily use ASCII. */
-
-enum encoding_style {
- half_row_style = 0,
- full_row_style = 1,
- mixed_style = 2,
- no_row_style = 3
-};
-\f
-/* is_ldh(code) returns 1 if the UTF-16 code represents an LDH */
-/* character (ASCII letter, digit, or hyphen), 0 otherwise. */
-
-static int is_ldh(unsigned short code)
-{
- if (code == 45) return 1;
- if (code < 48) return 0;
- if (code <= 57) return 1;
- if (code < 65) return 0;
- if (code <= 90) return 1;
- if (code < 97) return 0;
- if (code <= 122) return 1;
- return 0;
-}
-
-void brace_encode(
- unsigned int input_length,
- unsigned short *input,
- char output[brace_encoder_out_max] )
-{
- unsigned long queue;
- enum encoding_style style;
- unsigned short half_rows[brace_encoder_in_max],
- half_row_counts[brace_encoder_in_max];
- unsigned int num_nonldh, num_half_rows, i, half_row, j, queue_length,
- best_half_row, next_literal_position, non_hyphen_flag,
- next_base32_position, code;
-
- assert(input_length <= brace_encoder_in_max);
-
- /* Count the non-LDH codes and half-rows: */
-
- num_nonldh = 0;
- num_half_rows = 0;
-
- for (i = 0; i < input_length; ++i) {
- if (is_ldh(input[i])) continue;
- ++num_nonldh;
- half_row = input[i] >> 7;
-
- for (j = 0; j < num_half_rows; ++j) {
- if (half_rows[j] == half_row) {
- ++half_row_counts[j];
- break;
- }
- }
-
- if (j == num_half_rows) {
- half_rows[num_half_rows] = half_row;
- half_row_counts[num_half_rows] = 1;
- ++num_half_rows;
- }
- }
-
- /* If the input is already a valid label and does not end */
- /* with the BRACE signature, output it and we're done: */
-\f
- if (num_nonldh == 0 && /* all codes are LDH and */
- input[0] != 45 && /* first not hyphen and */
- input[input_length - 1] != 45 && /* last not hyphen and */
- !( input[input_length - 1] == 57 && /* last four not -8Q9 */
- ( input[input_length - 2] == 81 ||
- input[input_length - 2] == 113 ) && /* (or -8q9) */
- input[input_length - 3] == 56 &&
- input[input_length - 4] == 45 ) ) {
- for (i = 0; i < input_length; ++i) output[i] = input[i];
- output[input_length] = 0; /* null terminator */
- return;
- }
-
- /* Choose an encoding style and initialize the bit queue: */
-
- if (num_half_rows == 1) {
- style = half_row_style;
- queue_length = 11;
- queue = half_rows[0];
- }
- else if ( num_half_rows == 2 &&
- (half_rows[0] >> 1) == (half_rows[1] >> 1) ) {
- style = full_row_style;
- queue_length = 10;
- queue = (1 << 8) | (half_rows[0] >> 1);
- }
- else {
- unsigned int M, H, C, Mprime, best_M = 230; /* M is always < 230 */
-
- /* Find the best half-row for mixed style: */
-
- best_half_row = 512; /* half_row is always < 512 */
-
- for (i = 0; i < num_half_rows; ++i) {
- half_row = half_rows[i];
- H = half_row_counts[i];
- C = 0;
-
- for (j = 0; j < num_half_rows; ++j) {
- if (j != i && (half_rows[j] >> 1) == (half_row >> 1)) {
- C = half_row_counts[j];
- break;
- }
- }
-
- M = 3 + (18 * num_nonldh - 10*H - 9*C) / 5;
-
- if (M < best_M || (M == best_M && half_row < best_half_row)) {
- best_M = M;
- best_half_row = half_row;
- }
- }
-\f
- /* Compare mixed style to no-row style: */
-
- Mprime = (6 + 16 * num_nonldh) / 5;
-
- if (Mprime <= best_M) {
- style = no_row_style;
- queue_length = 2;
- queue = 3;
- }
- else {
- style = mixed_style;
- queue_length = 11;
- queue = (1 << 10) | best_half_row;
- }
- }
-
- /* Flush the bit queue: */
-
- next_base32_position = 0;
-
- while (queue_length >= 5) {
- queue_length -= 5;
- output[next_base32_position++] =
- base32[(queue >> queue_length) & 0x1f];
- }
-
- /* To avoid unnecessary copies, we use the output */
- /* array itself for the LDH buffer. The following */
- /* equalities should hold whenever the buffer is empty: */
-
- next_literal_position = next_base32_position + (queue_length > 0);
- non_hyphen_flag = 0; /* set whenever buffer contains a non-hyphen */
-
- /* Main encoding loop: */
-
- for (i = 0; i < input_length; ++i) {
- code = input[i];
-
- if (code == 45) {
- /* Encode a hyphen as two hyphens into the buffer: */
- output[next_literal_position++] = 45;
- output[next_literal_position++] = 45;
- }
- else if (is_ldh(code)) {
- if (!non_hyphen_flag) {
- /* Indicate a change to literal mode: */
- output[next_literal_position++] = 45;
- non_hyphen_flag = 1;
- }
-\f
- /* Encode the LDH character literally: */
- output[next_literal_position++] = code;
- }
- else { /* non-LDH code */
- if (non_hyphen_flag) {
- /* Indicate a change to base-32 mode: */
- output[next_literal_position++] = 45;
- non_hyphen_flag = 0; /* we will empty the buffer */
- }
-
- /* If the bit queue is empty, flush the LDH buffer: */
-
- if (queue_length == 0) {
- next_base32_position = next_literal_position;
- }
-
- /* Enqueue the bit string corresponding to the code: */
-
- if (style == half_row_style) {
- queue = (queue << 7) | (code & 0x7f);
- queue_length += 7;
- }
- else if (style == full_row_style) {
- queue = (queue << 8) | (code & 0xff);
- queue_length += 8;
- }
- else if (style == no_row_style) {
- queue = (queue << 16) | code;
- queue_length += 16;
- }
- else /* style == mixed_style */ {
- if ((code >> 7) == best_half_row) {
- queue = (queue << 8) | (code & 0x7f);
- queue_length += 8;
- }
- else if ((code >> 8) == (best_half_row >> 1)) {
- queue = (queue << 9) | (1 << 8) | (code & 0x7f);
- queue_length += 9;
- }
- else {
- queue = (queue << 18) | (3ul << 16) | code;
- queue_length += 18;
- }
- }
-
- /* Output one base-32 character: */
- queue_length -= 5;
- output[next_base32_position] =
- base32[(queue >> queue_length) & 0x1f];
-
- if (next_base32_position == next_literal_position) {
- /* LDH buffer is already empty. */
- ++next_base32_position;
- }
- else {
- /* Flush the LDH buffer: */
- next_base32_position = next_literal_position;
- }
-\f
- /* next_literal_position is momentarily invalid, */
- /* but we know the LDH buffer is empty. */
-
- /* Flush the bit queue: */
-
- while (queue_length >= 5) {
- queue_length -= 5;
- output[next_base32_position++] =
- base32[(queue >> queue_length) & 0x1f];
- }
-
- /* Fix next_literal_position: */
- next_literal_position = next_base32_position + (queue_length > 0);
- }
-
- assert(next_literal_position < brace_encoder_out_max);
- }
-
- /* Flush the bit queue: */
-
- if (queue_length > 0) {
- assert(queue_length < 5);
- output[next_base32_position] =
- base32[(queue << (5 - queue_length)) & 0x1f];
- }
-
- /* Flushing the LDH buffer at this point is a no-op. */
-
- /* Output "-8Q9" and the null terminator: */
-
- assert(next_literal_position + 4 < brace_encoder_out_max);
- output[next_literal_position++] = 45;
- output[next_literal_position++] = 56;
- output[next_literal_position++] = 81;
- output[next_literal_position++] = 57;
- output[next_literal_position] = 0;
-}
-
-/* base32_decode() converts a base-32 character to a value from */
-/* 0 to 31. If the character is valid, its value is written to */
-/* *quintet and 1 is returned. Otherwise, *value is not changed */
-/* and 0 is returned. */
-
-static int base32_decode(char c, unsigned int *quintet)
-{
- if (c < 50) return 0;
- if (c <= 57) { *quintet = c - 50; return 1; }
- if (c < 65) return 0;
- if (c >= 97) c -= 32;
- if (c <= 75) { *quintet = c - 57; return 1; }
- if (c == 76) return 0;
- if (c <= 78) { *quintet = c - 58; return 1; }
- if (c == 79) return 0;
- if (c <= 90) { *quintet = c - 59; return 1; }
- return 0;
-}
-\f
-int brace_decode(
- char *input,
- unsigned int *output_length,
- unsigned short output[brace_decoder_out_max] )
-{
- unsigned long queue;
- unsigned int i, input_length, queue_length, literal_mode_flag,
- quintet, n, next_code_position;
- enum encoding_style style;
- unsigned short common_prefix;
- char c;
-
- /* Check whether input ends with "-8Q9": */
-
- for (i = 0; input[i]; ++i) assert(i < brace_decoder_in_max);
-
- if (!(input[i-1] == 57 && input[i-3] == 56 &&
- input[i-4] == 45 && (input[i-2] == 81 || input[i-2] == 113))) {
-
- /* Copy input to output and we're done: */
-
- for (i = 0; input[i]; ++i) output[i] = input[i];
- assert(i <= brace_decoder_out_max);
- *output_length = i;
- return 1;
- }
-
- /* Initialize using the first base-32 character: */
-
- input_length = i;
- i = 0;
- if (!base32_decode(input[i], &quintet)) return 0;
- queue = quintet;
- queue_length = 3;
- literal_mode_flag = 0;
- style = quintet >> 3;
-
- /* Determine common_prefix: */
-
- if (style == no_row_style) n = 0;
- else if (style == full_row_style) n = 8;
- else n = 9;
-
- while (queue_length < n) {
- if (!base32_decode(input[++i], &quintet)) return 0;
- queue = (queue << 5) | quintet;
- queue_length += 5;
- }
-
- common_prefix = (queue >> (queue_length - n)) << (16 - n);
- queue_length -= n;
-
- /* Main decoding loop: */
-
- next_code_position = 0;
-
- while (++i < input_length - 4) {
- c = input[i];
-\f
- if (c == 45) {
- if (input[i+1] == 45) {
- ++i;
- output[next_code_position++] = 45; /* "--" means "-" */
- }
- else literal_mode_flag ^= 1; /* "-" toggles literal mode */
- }
- else if (literal_mode_flag) { /* literal non-hyphen */
- output[next_code_position++] = c;
- }
- else { /* base-32 character */
- /* Enqueue the corresponding quintet: */
- if (!base32_decode(c, &quintet)) return 0;
- queue = (queue << 5) | quintet;
- queue_length += 5;
-
- /* If the queue contains enough bits for a UTF-16 code, */
- /* dequeue them, decode them, and output the code: */
-
- if (style == no_row_style && queue_length >= 16) {
- output[next_code_position++] =
- (queue >> (queue_length - 16)) & 0xffff;
- queue_length -= 16;
- }
- else if (style == full_row_style && queue_length >= 8) {
- output[next_code_position++] =
- common_prefix | ((queue >> (queue_length - 8)) & 0xff);
- queue_length -= 8;
- }
- else if (style == half_row_style && queue_length >= 7) {
- output[next_code_position++] =
- common_prefix | ((queue >> (queue_length - 7)) & 0x7f);
- queue_length -= 7;
- }
- else if (style == mixed_style) {
- n = (queue >> (queue_length - 2)) & 3; /* top 2 bits */
-
- if (n <= 1 && queue_length >= 8) {
- output[next_code_position++] =
- common_prefix | ((queue >> (queue_length - 8)) & 0x7f);
- queue_length -= 8;
- }
- else if (n == 2 && queue_length >= 9) {
- output[next_code_position++] = (common_prefix ^ 0x80) |
- ((queue >> (queue_length - 9)) & 0x7f);
- queue_length -= 9;
- }
- else if (n == 3 && queue_length >= 18) {
- output[next_code_position++] =
- (queue >> (queue_length - 18)) & 0xffff;
- queue_length -= 18;
- }
- }
- }
- }
-\f
- assert(next_code_position <= brace_decoder_out_max);
-
- /* Check that the bit queue contains only zeros, at most four: */
-
- if (queue_length > 4) return 0;
- if ((queue & ((1 << queue_length) - 1)) != 0) return 0;
-
- /* Set the output length and we're done: */
-
- *output_length = next_code_position;
- return 1;
-}
-
-
-/* Wrapper for testing (would normally go in a separate .c file): */
-
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-static void usage(char **argv)
-{
- fprintf(stderr,
- "%s -e reads big-endian UTF-16 and writes BRACE-format ASCII.\n"
- "%s -d reads BRACE-format ASCII and writes big-endian UTF-16.\n"
- , argv[0], argv[0]);
- exit(EXIT_FAILURE);
-}
-
-static void fail(const char *msg)
-{
- fputs(msg,stderr);
- exit(EXIT_FAILURE);
-}
-
-static const char input_too_large[] = "input is too large\n";
-
-int main(int argc, char **argv)
-{
- unsigned int input_length;
-
- if (argc != 2) usage(argv);
- if (argv[1][0] != '-') usage(argv);
- if (argv[1][2] != '\0') usage(argv);
-
- if (argv[1][1] == 'e') {
- unsigned short input[brace_encoder_in_max];
- char output[brace_encoder_out_max];
- int hi, lo;
-
- /* Read the UTF-16 input string: */
-
- input_length = 0;
-
- for (;;) {
- hi = getchar();
- lo = getchar();
-\f
- if (lo == EOF) {
- if (hi != EOF) fail("input contained an odd number of bytes\n");
- break;
- }
-
- if (input_length == brace_encoder_in_max) fail(input_too_large);
-
- if (hi > 0xff || lo > 0xff) {
- fail("input bytes do not fit in 8 bits\n");
- }
-
- input[input_length++] =
- (unsigned short) hi << 8 | (unsigned short) lo;
- }
-
- /* Encode, and output the result: */
-
- brace_encode(input_length, input, output);
- if (strlen(output) > brace_decoder_in_max) fail(input_too_large);
- fputs(output,stdout);
- return EXIT_SUCCESS;
- }
-
- if (argv[1][1] == 'd') {
- char input[brace_decoder_in_max];
- unsigned short output[brace_decoder_out_max];
- unsigned int output_length, i;
- size_t n;
-
- /* Read the BRACE-encoded ASCII input string: */
-
- n = fread(input, 1, brace_decoder_in_max, stdin);
- if (n == brace_decoder_in_max) fail(input_too_large);
- input[n] = 0;
-
- /* Decode, and output the result: */
-
- if (!brace_decode(input, &output_length, output)) {
- fail("input was malformed\n");
- }
-
- for (i = 0; i < output_length; ++i) {
- putchar(output[i] >> 8);
- putchar(output[i] & 0xff);
- }
-
- return EXIT_SUCCESS;
- }
-
- usage(argv);
- return EXIT_SUCCESS; /* not reached, but quiets compiler warning */
-}
-
-
-
- INTERNET-DRAFT expires 2001-Mar-14
+++ /dev/null
-\8f©À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
-
-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
-
-During the development of Internationalized Domain Name (IDN), it is
-discovered that there is a substantial lack of information and
-misunderstanding on Han ideographs and its folding mechanism.
-
-This document attempts to address some of the issues on doing han
-folding with respect to IDN. Hopefully, this will dispel some of the
-common misunderstanding of this problem and to discuss some of the
-issues with han ideograph and its folding mechanism.
-
-This document addresses very specific problem to IDN and thus is not
-meant as a reference for generic Han folding. Generic Han folding are
-much more complicated and certainly beyond this document. However, the
-use of this document may be applicable to other areas that are related
-with names, e.g. Common Name Resolution Protocol [CNRP].
-
-1. Definition and convention
-
-Characters mentioned in this document are identified by their position
-or code point in the Unicode character set [UCS]. The notation U+12AB,
-for example, indicates the character at the position 12AB (hexadecimal)
-in the [UCS]. It is strongly recommended that a [UCS] table is available
-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
-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
-in plane 0) in the future.
-
-Conversion between ideographs can be done using four different
-approaches: Code-base substitution, character-based substitution,
-lexicon-based substitution and context-based substitution. Han folding
-refers only to code-base substitution, similar to case mapping of
-alphabetic characters.
-
-2. Introduction
-
-Traditionally, domain names have been case insensitive (as defined in
-[RFC1035] Section 2.3.3). While this is not a problem when domain names
-are restricted to English alphanumeric letters and digits, it becomes a
-serious problem for IDN. An important criterion for having a robust IDN
-is to have good normalization and canonicalization forms. This is to
-ensure domain name duplications are kept to the minimal.
-
-Fortunately, Unicode Consortium is developing technical reports on
-canonicalization [UTR21] and normalization [UTR15]. Hence, it becomes
-simple for IDN to ride upon the work of Unicode and use these
-references.
-
-Unfortunately, both [UTR15] and [UTR21] are limited in scope and do not
-address many other scripts. In particular, Han ideographs are not
-discussed in detail in these documents and most experts are quick to
-point out that this problem is technically impossible.
-
-2.1 Han ideographs
-
-While there are many forms or writing style for Chinese characters, the
-most common used 'zhengti' {U+6B63 U+4F53/U+6B63 U+9AD4} represent
-Chinese ideographs by radicals (U+2E80-U+2FDF) that is composed of
-simple strokes.
-
-When the Unicode Consortium started work on Universal Character Set, it
-was suggested that Hanzi, Kanji and Hanja ideographs should be unified
-into a single code space. This resulted in the CJK Unification, whereby
-27,786 Han ideographs are allocated in U+3400-U+9FFF and U+F900-U+FAFF
-range. Another 41,000 Han ideographs will be added to Plane 2.
-
-Ideographs are common in China, Korea and Japan but as ideographs spread
-and evolve, the form of the ideographs sometimes differs slightly from
-country to country. For example, the word 'villa' {U+838A} 'zhuang' in
-Chinese, in Japanese is 'sou' {U+8358}. These are given different code
-points in Unicode.
-
-3. Chinese (Hanzi)
-
-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"
-{U+5C71} still bears some resembles to 3 peaks of a hill.
-
-Not all ideographs are pictograph. There are other classifications such
-as compound ideographs, phonetic ideographs etc. For example,
-'endurance' {U+5FCD} is a pierced 'knife' {U+5200} above the 'heart'
-{U+5FC3}, or as a Chinese saying goes, 'endurance is like having a
-pierced knife in your heart'.
-
-Hence, almost all Han ideographs are associated with some meaning by
-itself which is very different from most other scripts. This causes some
-confusion that Han folding is a form of lexicon-substitution.
-
-Chinese ideographs underwent a major change in the 1950s after the
-establishment of People's Republic of China. A committee on Language
-Reform was established in China whose activities include simplification
-of Chinese ideographs. The Simplified Chinese (SC) are used in China
-and Singapore and Traditional Chinese (TC) in Taiwan, Hong Kong PRC,
-Macau PRC, and most other oversea Chinese.
-
-The process is to take complex ideographs and simplify them. The main
-purposes is to make it easier to remember and write and thus to raise
-the literacy of the population.
-
-For example, 'lightning' TC {U+96FB} becomes SC {U+6535} (They drop the
-'rain' {U+96E8} part from the TC). In many cases, they bear no
-resemblance to any of the original traditional forms e.g. 'dragon' TC
-{U+9F8D} SC {U+9F99}. Two different TC may also have the same SC since
-it means fewer ideographs to learn, e.g. SC {U+53D1} can be {U+667C} or
-{U+9AEE} depending on semantics. The official 'Comprehensive List of
-Simplified Characters' latest published in 1986 listed 2244 SC
-[ZONGBIAO].
-
-Therefore, the process of SC-to-TC is very complicated. It is not
-possible to do it accurately without considering the semantics of the
-phrase.
-
-On the other hand, TC-to-SC is much simple although different TCs may
-map to one single SC. While Unicode does not handle TC & SC, in the
-informal [UNIHAN] document, it listed 2145 TC and its equivalent mapping
-of SC. However, because that document is informal and not part of the
-Unicode standard, it is incomplete and has mistakes in the code points.
-Hence, precise tables for TC-to-SC conversion have not been fully laid
-out.
-
-In domain names, we are particularly interested in is to equivalences
-comparison of the names, and not converting SC-to-TC. Therefore, for
-this purpose, it is possible that equivalency matching be done in the
-TC-to-SC folding prior to comparison, similar to lower-case English
-strings before comparing them, e.g. 'taiwan' SC {U+53F0 U+6E7E} will
-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 \85ñ³\85Åæ {U+5934 U+53D1} will match TC
-(U+982D U+9AEE). It will also match TC {U+982D U+9AEE} that does not
-have any meaning in Chinese.
-
-It should also be noted that SC are not used together with TC. Hence,
-'hair' is either written as SC {U+5934 U+53D1} or TC {U+982D U+9AEE}
-but (almost) never {U+5934 U+9AEE} or {U+982D U+53D1}. So the problem
-of SC and TC may not too serious for IDN.
-
-Unfortunately, when it comes to names in Chinese, places where SC are
-used (i.e. Singapore and China), traditional and simplified ideographs
-are sometimes mixed within a single name for artistic reasons. Some of
-them even 'create' ideographs for their names.
-
-[Need to add a section on Bopomofo U+3118 to U+312A in future draft]
-
-4. Korean (Hanja and Hangeul)
-
-Korean is one of the first cultures to imported Chinese ideographs into
-Korean language as a written form. These Korean ideographs are known as
-'hanja' {U+6F22 U+5B57/U+D55C U+C790} and they are widely used until
-recently where 'hangeul' {U+D55C U+AE00} become more popular.
-
-Hangeul {U+D55C U+AE00} is a systemic script designed by a 15th century
-ruler and linguistic expert, King Sejong {U+4E16 U+5B97}. It is based
-on the pronunciation of the Korean language, hanmal. A Korean syllable
-is composed of 'jamo' {U+5B57 U+6BCD/U+C790 U+BAA8} elements that
-represent different sound. Hence, unlike Han ideographs, each hangeul
-syllable does not have any meaning.
-
-Each hanja ideographs can be represented by hangeul syllable. For
-example, 'samsung' hanja {U+4E09 U+661F} hangeul {U+C0BC U+C131}. Note
-that {U+4E09} is pronounced as 'sa-ah-am' or in jamo {U+3145} {U+314F}
-{U+3141}, which gives hangeul {U+C0BC}. While Jamo decompositions are
-described in [UTR15] in Form D decomposition, this document also
-suggested another hanguel canonical decomposition in Appendix A to
-accommodates both modern and old hangeul.
-[Need to fill up Appendix A when information is more complete]
-
-Most hanja characters have only one pronunciation. However, some hanja
-pronunciation differs as according to orthography (same for Chinese &
-Japanese) or the position in a word, which make this more complex. And
-of course, conversation of Hangeul back to hanja is impossible by code
-substitution without consideration for semantics.
-
-Korean also invented their own ideographs that are called 'gugja'
-{U+56FD U+5B57/U+AD6D U+C790}.
-
-5. Japanese (Kanji, Hiragana, Katakana)
-
-Japanese adopted Chinese ideograph from the Korean and the Chinese since
-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
-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,
-kanji all remain very integrated within the Japanese language.
-
-Japanese also invented ideographs known as 'kokuji' {U+56FD U+5B57}. For
-example, 'iwashi' {U+9C2F} is a Japanese kokuji ideograph. Kokuji are
-invented according to Han ligature rules. For example, 'touge' "mountain
-pass" {U+5CE0} is a conjunction of meaning with 'yama' "mountain"
-{U+5C71} + 'ue' "up" {U+4E0A} + 'shita' "down" {U+4E0B}.
-
-Japanese is also a vocal language, i.e. the script itself is based on
-pronunciation. Each hiragana corresponding to one pronunciation and 48
-hiragana forms the basic of the Japanese language, including the less
-commonly used 'we' {U+3091}. Furthermore, hiragana has more 35 forms to
-represent voiced sound, P-sound, double consonant. For example, 'ga'
-{U+304C} is a voiced sound of 'ka' {U+304B}. Katakana is a mirror of
-hiragana with few more forms and they are used to integrate foreign
-words or phrases into Japanese, or to emphasize words or phrases even
-in Japanese, or to represent onomatopoeia. For example, 'hamburger'
-pronounced as 'han-baa-gaa' in Japanese is written as {U+30CF U+30F3
-U+30D0 U+30FC U+30AC U+30FC} instead of {U+306F U+3093 U+3070 U+3041
-U+304C U+3041} because it is a foreign word.
-
-If Japanese uses hiragana and katakana only, then it is fairly obvious
-that written Japanese is going to be very long. Hence, kanji are used
-when referring to nouns or verbs. Each kanji corresponds to one or more
-hiragana characters. For example, 'japan' pronounced as 'nippon'
-{U+306B U+3063 U+307D U+3093} are written as {U+65E5 U+672C} instead.
-
-Hiragana, like Korean jamo, has no meaning itself. And also, Kanji can
-take on different pronunciation (which means different hiragana)
-depending where and how it is use in the sentence. For example, 'sky'
-{U+7A7A} can be pronounced as {U+305D U+3089} or {U+30BD U+30E9}.
-
-Hence, a code substitution between hiragana and kanji is impractical.
-
-On the other hand, there are Kanji that has the same meaning with the
-same pronunciation and equivalent. For example, 'river' "kawa" can be
-either {U+5DDD} or {U+6CB3}. The only differential between the two
-ideographs is that it signifies the 'size of the river' (the latter is
-bigger river).
-
-Japanese also reduce complex Chinese ideographs to a simplified form.
-For example, 'both' {U+5169} was simplified {U+4E21}. Note that Chinese
-simplified it to {U+4E24} instead. However, traditional Japanese kanji
-are seldom used nowadays beyond documenting old historical text that
-they are treated different from the more commonly used simplified form,
-or used to express proper noun such as person's name or trademarks.
-Hence, Han folding here is not recommended.
-
-4. Vietnamese
-
-While Vietnamese also adopted Chinese ideographs ('chu han') and created
-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'.
-
-
-5. zVariant
-
-Unicode has a three dimension conceptual model to Ideograph
-Unification. The three dimensions are semantic (X axis - meaning,
-function), abstract shape (Y-axis - general form) and actual shape
-(Z-axis \82Çô instantiated, type-faced).
-
-When two ideographs have similar etymology but are given two different
-code points in Unicode, they are known as zVariant ideograph i.e. they
-belong to the same 'Z' axis. For example, 'villa' {U+838A} and {U+8358}.
-
-
-6. Ideographic Description
-
-In Unicode v3.0, an ideographic description (U+2FF0-U+2FFB) was
-introduced allowing Han ideograph to be constructed using radical
-(U+2E80-U+2FD5) and Han ideograph (U+3400-U+9FFF).
-
-The intention of this description method is to allow ideograph that is
-not defined by Unicode to be described. Hence, it is not necessary that
-these ideograph can be display properly. In addition, this method are
-not deterministic and allowing same ideograph to be represented in
-different sequence.
-
-For example, 'zong' {U+9B03} (for discussion sake, we are going to use
-an ideograph which is already in Unicode) can be decomposed to U+2FF1
-U+9ADF U+5B97 using descriptive code points and Unified Ideograph.
-U+9ADF can also be decomposed as U+2FF0 U+2ED2 U+2F3A and U+5B97 as
-U+2FF5 U+2F28 U+2F70. In addition, U+9ADF is equivalent to U+2FBD.
-Hence, if we were to use only descriptive code points and radicals only,
-we can get U+2FF1 U+2FBD U+2FF5 U+2F28 U+2F70 or U+2FF1 U+2FF0 U+2ED2
-U+2F3A U+2FF5 U+2F28 U+2F70.
-
-In addition, certain radical has been simplified and thus, in some
-context, equivalent. For example, the radical for 'bird' can be either
-U+2EE6 or U+2FC3.
-
-Hence, until there is a deterministic well-defined rule for
-ideographic description, ideographs formed by this method are not
-recommended for domain names use.
-
-It should be noted that the Unicode Consortium never intended the
-ideographic description to be used in protocols like IDN where exact
-comparison must be done. But it is certainly desirable to this feature
-as it is commons for Chinese to invent ideographs for names by adding
-or removing radical from standard ideographs.
-
-7. Mechanism
-
-The implicit proposal in this document is that CJKV ideographs may or
-may not be "folded" for the purposes of comparison of domain names.
-
-But if folding is required, there are four different ways that this
-folding could be done.
-
-a) Folding by DNS clients, or by user agents
-b) Folding by DNS servers
-c) Folding by Domain Name registration services for the purposes of
- preventing confusing allocations CJKV Domain Names which would,
- if transcoded, be the same
-
-Before we can give much more reaction, we need to know which use is
-planned.
-
-The third use is important. It should be put in place. This problem can
-be reduced alternately by representing non-ASCII characters that are
-domain names or other URL characters using hex-escaped character
-references in HTML pages.
-
-To characterize Han characters as ideographs or pictograms is
-inadequate, because most of the Han ideograph have both a phonetic and
-a semantic element. Indeed, this is enough to characterize Chinese
-writing as phonetic, though it is other things as well. Thus, it's
-difficult to comment on whether folding is useful for Chinese or not.
-
-The first use has the problem that lightweight devices do not have
-enough room to fit a Unicode X-axis mapping table.
-
-The second use has the problem that introducing mapping will limit the
-performance of DNS servers. Alphabetic case mapping can be performed
-using a single logical AND instruction; CJKV character folding requires
-a lookup table.
-
-In alphabetic scripts, there is also requirement to fold Latin, Greek,
-Hebrew, Cyrillic, Hebrew and Arabic together. There may be a stronger
-requirement for CJKV characters.
-
-Note also that because modern OS are Unicode based and have network-
-downloadable IMEs, "interoperability" is becoming less equivalent to
-"use BIG5 characters only" or "use GB2312 character only" or "use
-Shift-JIS characters only".
-
-If conservative safety is really required, then
-1) find the x-axis characters which are available in all major CJK
- character sets used on the internet;
-2) only allow variants of those in domain names;
-3) when one variant is used, no other can be allocated. So comparisons
- are made on x-axis characters, but the license of that domain name
- can pick which y or z variants they wish to use..
-
-Acknowledgement
-
-The editor gratefully acknowledge the contributions of:
-
-Paul Hoffman <phoffman@imc.org>
-Jiang Mingliang <jiang@i-DNS.net>
-Dongman Lee <dlee@icu.ac.kr>
-Karlsson Kent <keka@im.se>
-
-Author(s)
-
-James SENG \88Äè\86î¯\85«Å
-i-DNS.net International Pte Ltd.
-8 Temasek Boulevard
-Suntec Tower 3 #24-02
-Singapore 038988
-Email: James@Seng.cc
-Tel: +65 2468208
-
-Yoshiro YONEYA
-NTT Software Corporation
-Shinagawa IntercityBldg., B-13F
-2-15-2 Kohnan, Minato-ku Tokyo 108-6113 Japan
-Email: yone@po.ntts.co.jp
-Tel: +81-3-5782-7291
-
-Kenny HUANG \89©â\85ï¥\89¢ä
-Geotempo International Ltd; TWNIC
-3F, No 16 Kang Hwa Street, Nei Hu
-Taipei 114, Taiwan
-Email: huangk@alum.sinica.edu
-Tel: +886-2-2658-6510
-
-KIM Kyongsok/GIM Gyeongseog
-
-References
-
-[UNISTD3] The Unicode Standard v3.0. Unicode Consortium.
-[UCS] ISBN 0-201-61633-5
-
-[IDN] "IETF Internationalized Domain Names Working Group",
- idn@ops.ietf.org, James Seng, Marc Blanchet
-
-[CNRP] "Common Name Resolution Protocol",
- cnrp-ietf@lists.netsol.com, Leslie Daigle
-
-[CJKV] CJKV Information Processing ISBN 1-56592-224-7
-
-[C2C] The pitfalls and Complexities of Chinese to Chinese
- Conversion. http://www.basistech.com/articles/C2C.html,
- Jack Halpern, Jouni Kerman
-
-[KANJIDIC] Sanseido\82ÇÖs Unicode Kanji Information Dictionary
- ISBN 4-385-13690-4
-
-[UNICHART] Unicode chart http://charts.unicode.org/
-
-[ZONGBIAO] Simplified Characters Standard Chart 2nd Edition, 1986
-
-[UNIHAN] Unicode Han Database, Unicode Consortium
- ftp://ftp.unicode.org/Public/UNIDATA/Unihan.txt
-
-[ISO11941] ISO TS 11941: Information and documentation \82Çô
- Transliteration of Korean script into Latin characters.
- Technical Specification 11941. First edition. 1996-12-31.
- ISO (International Organization for Standardization).
-
-[KimK 1990] "A New Proposal for a Standard Hangeul (or Korean Script)
- Code", KIM Kyongsok. Computer Standards & Interfaces,
- Vol. 9, No. 3, pp. 187-202, 1990.
-
-[KimK 1992] "A common Approach to Designing the Hangeul Code and
- Keyboard", KIM Kyongsok. Computer Standards & Interfaces,
- 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]
\ No newline at end of file
+++ /dev/null
-
-IDN Working Group Edmon Chung & David Leung
-Internet Draft Neteka Inc.
-<draft-ietf-idn-dnsii-mdnp-02.txt> February 2001
-
-
- The DNSII Multilingual Domain Name Protocol
-
-
-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 reader is cautioned not to depend on the values that appear in
- examples to be current or complete, since their purpose is primarily
- educational. Distribution of this memo is unlimited.
-
- 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.
-
- A copy of this particular draft is also archived at
- http://www.dnsii.org.
-
-
-Abstract
-
- The core thinking for DNSII is that multilingual DNS requests SHOULD
- be signaled within a DNS label whether by way of a binary tag or an
- alphanumeric prefix, and that compatibility to legacy client
- applications SHOULD be taken into concern alongside legacy server
- implementations.
-
- Besides the original specifications, four alternatives including the
- use of EDNS are included for discussion purposes in this document.
-
- Historically, the DNS is capable of handling only names within the
- basic English alphanumeric character set (plus the hyphen), yet the
- standards were so elegantly and openly designed that the extension of
- the DNS into a multilingual and symbols based system proves to be
- possible with simple adjustments.
-
- These adjustments will be made on both the client side and the server
- side. However, DNSII works on the principal that it is preferable to
- make the transition to multilingual domain names seamless and
-
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
- transparent to the end-user. Which means initially the server SHOULD
- take the primary responsibility for the technical implementation of
- the changes required for a multilingual Internet.
-
- The DNSII protocol is designed to allow the preservation of
- interoperability, consistency and simplicity of the original DNS,
- while being expandable and flexible for the handling of any character
- or symbol used for the naming of an Internet domain. DNSII intends
- to provide a platform for the implementation of multilingual domain
- names.
-
-Table Of Contents
-
- 1. Introduction....................................................2
- 1.1 Terminology....................................................2
- 1.2 DNSII..........................................................3
- 2. DNSII Protocol..................................................3
- 2.1 InPacket DNSII Identifier......................................3
- 2.2 InPacket Label Encoding Type (ILET)............................4
- 2.3 The Rationale for using ILET...................................5
- 2.4 Considerations for Specific Requests...........................6
- 2.4.1 PTR Records..................................................6
- 3. Alternate Implementations.......................................7
- 3.1 Restricted ILET Values.........................................7
- 3.2 Reduced ILET Bit Allocation....................................8
- 3.3 DNSII over EDNS................................................9
- 3.3.1 DNSII Identifier using EDNS..................................9
- 3.3.2 ILET using EDNS OPT RRs.....................................10
- 4. Implementation & Deployment Strategies.........................11
- 5. IDN Requirements Considerations................................12
- 6. DNSSEC, EDNS and IPv6 Considerations...........................12
- 7. Intellectual Property Considerations...........................13
- 8. References.....................................................13
-
-
-1. Introduction
-
- This Internet-draft describes details of the DNSII Multilingual
- Domain Name protocol. The Internet-Draft assumes that the reader is
- familiar with the concepts discussed in the widely distributed RFCs
- "Domain Names Concepts and Facilities" [RFC 1034] and "Domain Names
- Implementation and Specification" [RFC 1035].
-
-
-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].
-
- A number of multilingual characters are used in this document for
- examples. Please select your view encoding type to UTF-8 for it to
- be displayed properly.
-
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
-
-1.2 DNSII
-
- The DNSII specifications takes a radically different approach: it
- successfully identifies the difference between original DNS and DNSII
- packets within the labels and at the same time allows the use of
- multiple charsets to be easily incorporated in a standardized manner.
- It causes no harm to the current DNS because it embraces the original
- format for DNS laid out in RFC1035, complemented with the ideas
- incorporated in EDNS [RFC2671].
-
-
-2. DNSII Protocol
-
- The DNSII Protocol consists mainly of two parts: the InPacket DNSII
- Identifier and the InPacket Label Encoding Type. In addition, there
- are several special considerations for specific record types.
-
-
-2.1 InPacket DNSII Identifier
-
- In the DNSII specifications, an InPacket DNSII Identifier MUST be
- inserted before a label to signify that it contains extended
- characters that are not supported by the current DNS.
-
- This DNSII flag, which is the first two bits of a label, effectively
- distinguishes a DNSII compliant request from the existing format,
- without having to conduct a guess from a name check whether the
- incoming packet is multilingual aware. This is a substantial
- improvement over character encoding schemes and multilingual
- implementations in which it is almost impossible to determine the
- language of an incoming request. The DNSII flag makes the process
- clear and simple.
-
- Currently:
- "00" regular label [RFC1035]
- "11" a redirection for DNS compression [RFC1035]
- "01" indicates the use of EDNS for multiple UDP packets [RFC2671]
-
- DNSII calls for the use of the bit sequence "10" to identify that the
- querying node is DNSII aware. This will mean that all the possible
- variations at top two label bits will be used. Therefore, in
- consideration, following two bits MUST be reserved for future
- flagging use. The 2 bits SHOULD be arbitrarily set to "00". This
- effectively opens up 3 more possible implementations for future
- enhancements.
-
- The motivation for this approach is the belief there should be no
- ambiguity in name resolution. Any name that the client wishes to
- resolve, should resolve, regardless of the client side-encoding
- scheme.
-
-
-
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
-2.2 InPacket Label Encoding Type (ILET)
-
- Immediately following the 2 assigned DNSII flag and the 2 reserved
- bits are 12 bits assigned to determine the InPacket Label Encoding
- Type (ILET).
-
- The ILET is a 12-bit number that is used to determine the encoding
- scheme used by the characters of the label. The MIBenum numbers
- [RFC1700] SHOULD be used in this field. The allocation of 12 bits
- aligns perfectly with the MIBenum specification, of which the value
- goes up to over 2200. With 12 bits, the total possible values would
- be 4096 (with 11 bits, the largest value that can be represented is
- only 2047, slightly short of the specification). The reason for the
- adoption of MIBenum is to make use of the existing list of encoding
- numbering schemes rather than re-inventing the wheel.
-
- The value in the ILET field SHOULD only be allowed for the valid
- encoding schemes defined in the MIBenum list. After identifying the
- encoding type, the regular count-label scheme of the DNS resumes.
- The resulting label should look like this:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +---+---+-------+---------------+
- |1 0| z | ILET |
- +---------------+---------------+
- | COUNT | characters... |
- +---------------+---------------+
-
- To minimize the size of a DNS packet, if the entire label is
- constituted in characters only from the ANSI table, the DNS label
- will appear identical to current implementations. The first two bits
- will remain "00".
- For example, using the DNSII format the label for "dns" MAY be
- represented as:
-
- 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | 1 0| 0 0| 0 0 0 0 0 0 0 0 0 0 1 1| MIBenum 3 = ANSI
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | 3 | 6 4 | "d"=64
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | 6 E | 7 3 | "n"=6E "s"=73
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- Or, the same domain label "dns" MAY also be represented as:
-
- 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | 3 | d |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | n | s |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Chung & Leung [Page 4]
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
- With a multilingual domain name ns.\85\96\96\85Éì\87þ©\87´\98.tld as an example:
-
- 1 1 1 1 1 1 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +---------------------------------------------------------------+
- |1 0| z | ANSI=3 | 2 | n |
- +---------------------------------------------------------------+
- | s |1 0|0 0| UCS-2=1000 | 4 |
- +---------------------------------------------------------------+
- | \85\96\96 (U+57DF) | \85Éì (U+540D) |
- +---------------------------------------------------------------+
- | \87þ© (U+7CFB) | \87´\98 (U+7D71) |
- +---------------------------------------------------------------+
- |0 0| 3 | t | l | d |
- +---------------------------------------------------------------+
- | 0 |
- +---------------+
- From the above example, we can see that the DNSII format is used for
- the first label "ns", as well as for the second label, which is in
- Chinese (the MIBenum for UCS-2 or ISO 10646 [Unicode] is 1000). The
- third label "tld" however uses the current format.
-
- In any case, the count-label-count-label mechanism is largely
- preserved. Especially in the case of extended characters where in
- other proposals, the "count" no longer represents the character
- count. In the above example, the domain is still represented as 2ns4
- \85\96\96\85Éì\87þ©\87´\983t ld0, exactly in line with the original specifications.
-
- Note that the first label in any query could be represented in DNSII
- format to alert the destination server that it is DNSII aware. This
- is not required but is specifically configured for the considerations
- with CNAME, A6, DNAME and PTR records.
-
- This approach is used to ensure that there is no confusion about the
- encoding format of the label. ILET allows the capability of
- employing all existing encoding schemes (UTF-7, UTF-8, ISO 10646
- [UCS-2], ISO 10646 [UCS-4]). ILET also allows the flexibility of
- employing future encoding schemes.
-
-
-2.3 The Rationale for using ILET
-
- Besides being able to preserve the count-label-count-label structure,
- which in itself is actually a very important part because of the
- problematic non-uniform byte encoding schemes, the use of ILET aligns
- perfectly with previous IETF specifications as well as beneficial for
- tricky case folding and canonicalization issues.
-
- We know that all protocols MUST identify, for all character data,
- which charset is in use [RFC2277], therefore it is necessary to
- specify whatever encoding scheme, whether it be UTF-8, UTF-7, 16-bit
- UCS-2 or ISO 8859 that is being used. In essence, we understand that
-
-
-Chung & Leung [Page 5]
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
- it is paramount that a charset be clearly identified, especially in
- situation like the DNS where no direct communication is established.
-
- At times and in specific cases, language information may be required
- to achieve a particular level of quality for the purpose of
- displaying a text stream. For example, UTF-8 encoded Han may require
- transmission of a language tag to select the specific glyphs to be
- displayed at a particular level of quality.
-
- Note that information other than language may be used to achieve the
- required level of quality in a display process. In particular, a
- font tag is sufficient to produce identical results. However, the
- association of a language with a specific block of text has
- usefulness far beyond its use in display. In particular, as the
- amount of information available in multiple languages on the World
- Wide Web grows, it becomes critical to specify which language is in
- use in particular documents, to assist automatic indexing and
- retrieval of relevant documents._ [RFC2130]
- In effect, this means for different languages, it is beneficial to be
- able to identify the language in order to perform specific functions
- to the characters, including case folding. With ILET, the local
- encoding scheme could be used and with them there are well defined
- folding methods. Therefore, the use of ILET enables an optimized
- folding mechanism brought about by the preservation of local encoding
- schemes, which is otherwise very difficult or virtually impossible to
- do if only UTF-8 is used.
-
- For the DNS however, a language tag is less feasible because if a
- name is consisted of multiple languages, it would be very difficult
- for tagging to be performed. The possibility of having multiple
- languages is very sound, and is used frequently as trademarks around
- the world. For example the famous Toys"ϯ"Us name, uses a character
- from the Cyrillic language set.
-
-
-2.4 Considerations for Specific Requests
-
- For certain requests, an ANSI only name could result in a
- multilingual domain as an answer. These include PTR, CNAME, A6 and
- DNAME requests. Special considerations are made within the DNSII
- protocol to make sure that non-DNSII aware servers will not be fed
- with a DNSII format packet.
-
-
-2.4.1 PTR Records
-
- For all PTR requests, the first label of the query MUST use DNSII
- format to alert the destination server. Upon which, a DNSII packet
- will be replied should the name contain extended characters.
-
- If the DNSII format is not used, and the PTR record stumbles upon a
- multilingual domain name, one of the following responses SHOULD be
- given:
-
-Chung & Leung [Page 6]
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
- a. The implementer of DNSII MAY chose to reject the request;
-
- or
-
- b. An ACE format domain with a "for.ref.only" suffix MAY be returned;
-
- or
-
- c. A DNSII compliant server MAY return an 8-bit format of the
- requested domain.
-
- Since the PTR record is usually used for display purposes only, the
- rejection (the IP address will then be used) or ACE format is
- acceptable. If the response is however used for further resolution,
- an ACE format MUST not be used.
-
-
-2.4.2 CNAME, A6 & DNAME
-
- For queries concerning the record types CNAME, A6 or DNAME, a DNSII
- aware server should first check to see if the incoming request is
- DNSII compliant (flagged by the "10" bits in the first label):
-
- If so, and the domain to be returned includes extended characters,
- the response SHOULD be in DNSII format.
-
- If not, any multilingual domains returned should be in an 8 bit form.
-
- For the above record types it is strongly RECOMMENDED not to
- associate an alphanumeric label to a multilingual label as the
- RDATA. However, it is permissible to associate a multilingual label
- with an alphanumeric label as the RDATA.
-
-
-3. Alternate Implementations
-
- The DNSII-MDNP is intended to be a framework for the implementation
- of multilingual domain names. While the core concepts and the design
- principles remain consistent, it is possible to contemplate
- alternative implementations. The four alternatives introduced here
- include the arbitrary restriction of ILET values, the reduction of
- ILET bit allocation for reflecting ISO 10646 transformations only,
- and finally two implementations using DNSII over EDNS.
-
-
-3.1 Restricted ILET Values
-
- One possible implementation guideline is for the ILET to be
- restricted to values only representing ISO 10646 transformations
- including UCS-2, UCS-4, UTF-7, UTF-8, UTF-16 and other as they become
- available and included as a standard MIBenum.
-
-
-
-Chung & Leung [Page 7]
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
- Although this takes away some of the benefits of keeping the local
- encoding scheme which includes the issues of case folding,
- canonicalization and other related concerns, it creates a system that
- on one hand contains only encoding schemes from ISO 10646, but on the
- other hand still provides the flexibility of deploying new encoding
- schemes that stem from ISO 10646, such as the 32-bit format that is
- due to be used soon.
-
- We understand it is specified that in protocols, which up to now have
- used US-ASCII only, UTF-8 forms a simple upgrade path; however, its
- use should be negotiated either by negotiating a protocol version or
- by negotiating charset usage, and a fallback to UTF-7 MUST be
- available. [RFC2130] With DNSII, the required fallback to UTF-7
- could easily be done by setting the ILET value to reflect UTF-7.
-
-
-3.2 Reduced ILET Bit Allocation
-
- Furthering the restriction of the ILET to ISO 10646 transformations
- only, the ILET bit allocations could also be reduced from 12 bit to 5
- bit. This successfully creates a total of 32 possible values. The
- reserved bits are also reduced to one.
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +---+-+---------+---------------+
- |1 0|z| ILET | COUNT |
- +---------------+---------------+
- | characters... |
- +---------------+
-
- For example, the label "\85\96\96\85Éì\87þ©\87´\98" will now be reflected in DNS packets
- in the following form:
-
- 1 1 1 1 1 1 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +---------------------------------------------------------------+
- |1 0|z| ILET=1 | 4 | \85\96\96 (U+57DF) |
- +---------------------------------------------------------------+
- | \85Éì (U+540D) | \87þ© (U+7CFB) |
- +---------------------------------------------------------------+
- | \87´\98 (U+7D71) |
- +--------------------------------+
-
- To start off with, the ILET values MAY be determined as follows:
-
- 0 = reserved for ANSI 1 = UTF-7
- 2 = UCS-2 3 = UTF-8
- 4 = UCS-4 5 = UTF-16
- 6 = 6 octets per character 7 = 7 octets per character
- 8 = UCS-8 (8 octets per character) 9 = UTF-31
- etc.
-
-
-Chung & Leung [Page 8]
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
- The ILET number will be the number of octets that should be read each
- time, with exceptions at 0,3,5,9 or any number that is just after a
- full UCS. ILET=3 corresponds to UTF8 because ILET=2 = UCS2 and UTF-8
- is a compatibility transformation for UCS-2 (in 16bit) in 8bit. A
- possible future expansion to UCS-8 is also included to make the
- schema truly future prove.
-
- This arrangement opens up opportunity and versatility of the use of
- private schemes that make use of odd byte length characters or
- symbols such as 6, 7 or even 18octet representations without the need
- for the DNS to update or adjust to, while maintaining the integrity
- and unique nature of domain names.
-
-
-3.3 DNSII over EDNS
-
- While DNSII and EDNS could coexist, it is possible to implement the
- DNSII concept onto an EDNS based platform. It is however preferable
- to use both EDNS and the DNSII scheme together as described in
- Section 6, because EDNS(0) compliant servers may have trouble when
- the label count exceeds the value of 63 (and smaller than 127)
- because then, the EDNS mechanism MAY be reiterated.
-
- Nevertheless, it is possible to utilize EDNS to act as a DNSII
- Identifier. The short-comings and pit-falls are however further laid
- in another draft DNSII-EDNS.
-
-
-3.3.1 DNSII Identifier using EDNS
-
- EDNS could simply be used in place of the DNSII Identifier. Assuming
- that the reduced ILET values introduced in Section 3.2 is used, the
- ILET will fit nicely into one octet immediately following the ELT
- portion. The resulting representation for the domain "host.\85\96\96\85Éì\87þ©\87´\98
- .tld" would be as follows:
-
- 1 1 1 1 1 1 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +---------------------------------------------------------------+
- 20|0 0| 4 | h | o | s |
- +---------------------------------------------------------------+
- | t |0 1|0 0 0 0 1 0| ILET=UCS-2=2 | 4 |
- +---------------------------------------------------------------+
- | \85\96\96 (U+57DF) | \85Éì (U+540D) |
- +---------------------------------------------------------------+
- | \87þ© (U+7CFB) | \87´\98 (U+7D71) |
- +---------------------------------------------------------------+
- |0 0| 3 | t | l | d |
- +---------------------------------------------------------------+
- | 0 |
- +---------------+
-
-
-
-Chung & Leung [Page 9]
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
- The OPT RR could be used not only for version control but also as a
- notification for the destination server on the level of conformance
- of the inquirer. This is especially beneficial when considering the
- issues raised in Section 2.4 where ANSI only requests my result in a
- multilingual response.
-
- Proposed identifications within the OPT RR (used in this document for
- discussion purposes):
- ELT = 0b000010
- EDNS-VERSION = 2 (DNSII)
- OPTION-CODE = 1 (IDN)
- OPTION-DATA = conformance level (defined in DNSII-MDNR Section 4)
- Plus other information if required
-
- The conformance level SHOULD be included in the first octet of the
- OPTION-DATA field and reflect the value corresponding to:
-
- BASIC conformance = 1
- INTERMEDIATE conformance = 2
- FULL conformance = 3
-
- A resulting DNSII OPT RR from a fully compliant inquirer SHOULD be in
- the form:
-
- 1 1 1 1 1 1 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +---------------------------------------------------------------+
- | NAME=0 | TYPE = OPT = 41 | Sender's UDP |
- +---------------------------------------------------------------+
- | Payload Size |EXTENDED-RCODE=0|EDNS-VERSION=2| z |
- +---------------------------------------------------------------+
- | z | RDLENGTH = 5 | OPTION-CODE = |
- +---------------------------------------------------------------+
- | IDN = 1 | OPTION-LENGTH = 1 | Conformance=3 |
- +---------------------------------------------------------------+
-
-
-3.3.2 ILET using EDNS OPT RRs
-
- Instead of using the OPT RR only as a notification of DNSII
- awareness, it utilized to indicate the type of encoding that is being
- used in the labels. In other words, the ILET value could be included
- in the OPT RR instead of within the label.
-
- The ILET value will be included right after the conformance level
- octet in the OPTION-DATA field within the OPT RR RDATA.
-
-
-
-
-
-
-
-
-Chung & Leung [Page 10]
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
- The resulting QNAME labels and OPT RR for the domain "www.\85\96\96\85Éì\87þ©\87´\98
- .tld" from a fully compliant inquirer sending the name in UCS-2
- would become:
-
- 1 1 1 1 1 1 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +---------------------------------------------------------------+
- |0 0| 3 | w | w | w |
- +---------------------------------------------------------------+
- |0 1|0 0 0 0 1 0| 4 | \85\96\96 (U+57DF) |
- +---------------------------------------------------------------+
- | \85Éì (U+540D) | \87þ© (U+7CFB) |
- +---------------------------------------------------------------+
- | \87´\98 (U+7D71) |0 0| 3 | t |
- +---------------------------------------------------------------+
- | l | d | 0 |
- +-----------------------------------------------+
-
- (OPT RR containing ILET information)
- : :
- / /
- +---------------------------------------------------------------+
- | NAME=0 | TYPE = OPT = 41 | Sender's UDP |
- +---------------------------------------------------------------+
- | Payload Size |EXTENDED RCODE=0|EDNS-VERSION=2| z |
- +---------------------------------------------------------------+
- | z | RDLENGTH = 9 | OPTION-CODE = |
- +---------------------------------------------------------------+
- | IDN = 1 | OPTION-LENGTH = 4 | Conformance=3 |
- +---------------------------------------------------------------+
- | 1 | 0 | 0 | 0 |
- +---------------------------------------------------------------+
-
-
- Note that instead of allocating only 12 bits for the ILET, the
- MIBenum value is expressed over 4 octets with each octet carrying a
- numeric value. Since UCS-2 is used and the MIBenum value for UCS-2 =
- 1000, the 4 octets corresponds to the values 1, 0, 0, 0 respectively.
-
- If the reduced ILET values are used, only 1 octet is required to
- reflect the encoding scheme being used.
-
-
-4. Implementation & Deployment Strategies
-
- The first step in any multilingual domain name implementation should
- be to encourage an 8-bit clean approach to DNS. However, even when
- the system is 8-bit clean the problem with conflicting characters
- still exists. This is where the DNSII protocol becomes most
- valuable.
-
- Although the DNSII protocol could be implemented at any level of the
- DNS, the following phased rollout is contemplated.
-
-Chung & Leung [Page 11]
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
-
- (1) Registry Level - The most meaningful starting point for
- deployment would be at the registry level since this creates the
- demand from the end users to use multilingual and extended character
- domain names for Second Level Domains.
-
- (2) Host Level - At the same time, registrants of the new extended
- domain names could start to implement DNSII to host these special
- kinds of domain names. All other hosts that do not wish to use
- extended characters do not have to migrate to the DNSII.
-
- (3) Client Level - Once the multilingual aspect and the DNSII
- specifications become mainstream, the user level resolvers will begin
- to migrate. This will include both the client resolver as well as
- the ISP's DNS.
-
- (4) Root Level - Eventually, as the DNSII is proven to be stable and
- beneficial for the Internet at large, it could be used in the Root
- Level so that new multilingual TLDs could be created.
-
-
-5. IDN Requirements Considerations
-
- The DNSII protocol specification is in line with most if not all of
- the requirements identified by the IDN work group.
-
-
-6. DNSSEC, EDNS and IPv6 Considerations
-
- The use of DNSII should not require any adjustments with the
- implementation of DNSSEC, EDNS or IPv6. EDNS as well as compression
- in fact will be done exactly the same as the existing system.
- For example, the domain host.dns.\85\96\96\85Éì\87þ©\87´\98.tld running with EDNS as
- well as compression after host will look as follows:
-
-
- 1 1 1 1 1 1 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +---------------------------------------------------------------+
- 20|0 1| ELT |0 0| 3 | d | n |
- +---------------------------------------------------------------+
- | s |1 0|0 0| UCS-2=1000 | 4 |
- +---------------------------------------------------------------+
- | \85\96\96 (U+57DF) | \85Éì (U+540D) |
- +---------------------------------------------------------------+
- | \87þ© (U+7CFB) | \87´\98 (U+7D71) |
- +---------------------------------------------------------------+
- |0 0| 3 | t | l | d |
- +---------------------------------------------------------------+
- | 0 |
- +---------------+
-
-
-Chung & Leung [Page 12]
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
- : :
- / /
- +---------------------------------------------------------------+
- |0 0| 4 | h | o | s |
- +---------------------------------------------------------------+
- | t |1 1| 21 |
- +-----------------------------------------------+
-
-
-7. Intellectual Property Considerations
-
- It is the intention of Neteka to submit the DNSII protocol and other
- elements of the multilingual domain name server software to IETF for
- review, comment or standardization.
-
- Neteka Inc. has applied for one or more patents on the technology
- related to multilingual domain name server software and multilingual
- email server software suite. If a standard is adopted by IETF and
- any patents are issued to Neteka with claims that are necessary for
- practicing the standard, any party will be able to obtain the right
- to implement, use and distribute the technology or works when
- implementing, using or distributing technology based upon the
- specific specifications under fair, reasonable and non-discriminatory
- terms.
-
- Other DNSII related documents and discussions could be found at
- http://www.dnsii.org.
-
-8. References
-
- [DNSII-MDNR] E. Chung, D. Leung, _DNSII Multilingual Domain Name
- Resolution_, August 2000
-
- [RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700,
- October 1994.
-
- [ISO10646] ISO/IEC 10646-1:2000. International Standard -
- Information technology -- Universal Multiple-Octet Coded
- Character Set (UCS)
-
- [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,
- April 1997
-
-
-Chung & Leung [Page 13]
-\fDNSII-MDNP Multilingual Domain Name Protocol August 2000
-
- [RFC2277] H. Alvestrand, _IETF Policy on Character Sets and
- Languages_ RFC 2277, January 1998
-
- [RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)",
- August 1999, RFC 2671.
-
-
-
- Authors:
-
- Edmon Chung
- Neteka Inc.
- 2462 Yonge St. Toronto,
- Ontario, Canada M4P 2H5
- edmon@neteka.com
-
- David Leung
- Neteka Inc.
- 2462 Yonge St. Toronto,
- Ontario, Canada M4P 2H5
- david@neteka.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Chung & Leung [Page 14]
+++ /dev/null
-
-IDN Working Group Edmon Chung & David Leung
-Internet Draft Neteka Inc.
-<draft-ietf-idn-dnsii-mdnr-01.txt> February 2001
-
-
-
- DNSII Multilingual Domain Name Resolution
-
-
-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 reader is cautioned not to depend on the values that appear in
- examples to be current or complete, since their purpose is primarily
- educational. Distribution of this memo is unlimited.
-
- 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.
-
- A copy of this particular draft is also archived at
- http://www.dnsii.org.
-
-
-Abstract
-
- This document outlines a resolution process that forms a framework
- for the resolution of multilingual domain names. Additionally, a
- tunneling mechanism utilizing additional RRs is introduced for the
- transition to a fully multilingual capable name space.
-
- The Internet-Draft for DNSII-MDNP was focused purely on discussing
- the ultimate packet protocol that is being sent around the Internet
- for multilingual domain names. This paper complements the previous
- paper by outlining the contemplated resolution process with the DNSII
- protocol throughout the DNS name resolution process.
-
- Whether the DNSII protocol is implemented exactly as specified in
- DNSII-MDNP is less relevant, rather it is the idea of having a
- multilingual packet identifier and the fall back process that
- matters. The DNSII-MDNR successfully addresses the transitional
- issues at each node of the DNS resolution process providing a clear
- migration path and strategy for the deployment of a multilingual
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
- enabled DNS system. It also outlines the conformance levels required
- for basic or complete implementations for applications, resolvers and
- name servers.
-
-
-Table of Contents
-
- 1. Introduction....................................................2
- 1.1 Terminology....................................................2
- 1.2 Multilingual Domain Name Resolution............................3
- 1.2 DNSII-MDNR.....................................................3
- 2. DNSII Proposal with respect to the DNS Layers...................3
- 3. The Resolution Process..........................................5
- 3.1 Steady State Resolution........................................5
- 3.2 Client-End or Inquirer Transitional Fall-Back Strategy.........6
- 3.2.1 Tunneling MDNP through DNSII RR..............................6
- 3.2.2 Tunneling ILET RRs...........................................8
- 3.3 Resolvers & Server-End Transitional Fallback Strategy..........9
- 3.3.1 Tunneling MDNP Responses through DNSII ANS RR................9
- 3.3.2 Reinsertion of ILET and DNSII Identifier....................10
- 4. DNSII Conformance Levels.......................................10
- 4.1 Application Conformance Levels................................11
- 4.2 Resolver Conformance Levels...................................11
- 4.3 Authoritative Server Conformance Levels.......................11
- 5. Transition Schedule & Strategy.................................12
- 6. Summary of Discussion..........................................12
- 6.1 Client/Application Resolution Strategy........................13
- 6.2 Resolver Resolution Strategy..................................13
- 6.3 Authoritative Name Server Resolution Strategy.................13
- 7. Security Considerations........................................14
- 8. Intellectual Property Considerations...........................14
- 9. References.....................................................14
-
-
-1. Introduction
-
- This Internet-Draft describes details of the contemplated resolution
- process after the deployment of DNSII-MDNP, or other multilingual
- domain name efforts containing a bit flag multilingual packet
- identifier or otherwise InPacket identifications for that matter.
-
- The reader is assumed to be familiar with the concepts discussed in
- the DNSII-MDNP Internet-Draft <draft-ietf-idn-dnsii-mdnp.txt>.
-
-
-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].
-
-
-
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
- A number of multilingual characters are used in this document for
- examples. Please select your view encoding type to Big-5
- (Traditional Chinese) for them to be displayed properly.
-
-
-
-
-1.2 Multilingual Domain Name Resolution
-
- The original specifications for the DNS were designed to be open
- enough for simple implementation of a multilingual naming system with
- slight adjustments as laid out in DNSII-MDNP. The transition and
- especially its resolution process during migration is however a
- tricky problem. Several things that MUST be kept in mind is that
- there is a initial phase, an intermediate phase and an ultimate
- steady state phase. DNSII-MDNP only described the ideal protocol at
- steady state, with incorporated flexibility for transition from the
- present to multilingual as well as again towards future unknown
- grounds.
-
- It is important to remember that the ultimate form SHOULD be
- determined and then the transition scheme laid out. While an ASCII
- translation system might seem favorable in the short-run, it
- effectively creates an alternative universe which is counter to the
- spirit of the DNS. However an ASCII translation is implemented, it
- immediately creates a "human-multilingual" universe and a "machine-
- ASCII" universe. This document introduces a tunneling mechanism to
- transition the DNS from today's monolingual system, through an 8-bit
- or 7-bit migration scheme towards a truly sustainable multilingual
- name space, arriving at a DNSII type system.
-
-
-1.2 DNSII-MDNR
-
- While DNSII-MDNP describes the framework for the ultimate protocol
- format of a multilingual DNS, DNSII-MDNR will discuss how the packet
- SHOULD be transported and interpreted throughout the DNS. The
- document will describe both the intended resolution process as well
- as part of the transition strategy from the existing DNS to a DNSII
- enabled system.
-
-
-2. DNSII Proposal with respect to the DNS Layers
-
- The following diagram illustrates the use of DNSII-MDNP at a steady
- state. Section 3 will discuss the fallback strategies while Section
- 4 will talk about issues on conformance levels.
-
-
-
-
-
-
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
- +---------------+
- | | NamePrep:
- | Application | Canonicalize in Form C/KC
- | | Insert DNSII Identifier +---------------------+
- | | Insert appropriate ILET | (Base data) |
- +---------------+ +---------------------+
- | |
- | DNS Packet with DNSII | (no standard)
- | Identifier & ILET | RECOMMENDS
- | | UCS-2/4
- +---------------+ |
- | Resolver | Canonicalize, Case Fold +---------------------+
- | | (for cache lookup) or | Auth DNS server |
- +---------------+ leave as is & Resolve | (Canonicalize, |
- | | Case Fold & Lookup) |
- | Pass Along without +---------------------+
- | Altering Case or Canonicalization |
- | |
- | <----- DNS service interface -----> |
- +------------------------------------------------------------------+
- | DNS service |
- | +-----------------------+ +--------------------+ |
- | | Forwarding DNS server | | Caching DNS server | |
- | +-----------------------+ +--------------------+ |
- | |
- | +-------------------------+ |
- | | Parent-zone DNS servers | |
- | +-------------------------+ |
- | |
- | +-------------------------+ |
- | | Root DNS servers | |
- | +-------------------------+ |
- | |
- +------------------------------------------------------------------+
-
- Please note that at each level, the domain name is being
- canonicalized. This is to ensure that at the end, characters that
- can be represented by a single code point will not be otherwise
- compared resulting in inconsistent reply to a humanly identical name.
- It is RECOMMENDED that applications SHOULD conduct canonicalization
- while servers MUST. Duplicating the process is fine because if a
- character is already composed, it will not compose again with another
- character.
-
- This arrangement is very similar to the ASCII case folding
- experienced in the DNS today. In the original specifications, it was
- RECOMMENDED that query sent be left as they are and case folding done
- only at the server end. Some application implementations however do
- perform the case folding at the user end. As the query arrives at
- the server, it is still case folded.
-
-
-
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
- Case folding for multilingual domain names should follow the existing
- implementations for ASCII names, where the application SHOULD and the
- server MUST.
-
-
-3. The Resolution Process
-
- It is inevitable that at the end of the day, the entire DNS chain
- SHOULD be updated in order for multilingual domain names to be as
- efficiently resolved as names under the current DNS. DNSII strives
- to provide a schema that ultimately brings the system to a desirable
- steady state while carefully giving considerations to all the
- transition issues. These include the considerations that at the
- application end, there is already a preference and an installed base
- of character encoding that may or may not conform to the desires of
- the server end operations. The use of ILET is therefore highly
- desirable and essential.
-
-
-3.1 Steady State Resolution
-
- At steady state, the resolution process of multilingual domain names
- SHOULD be identical to the existing system. Additional steps of
- going through alphanumeric translation are unnecessary and
- undesirable.
-
- With DNSII, the contemplated steady state process resembles the well-
- known DNS model laid out in RFC1035.
-
-
- Local Host | Foreign
- |
- +---------+ +----------+ | +---------+
- | | user queries | |queries | | |
- | |(DNSII identifier | | | | |
- | | ILET=UCS without | | | | |
- | User | Transformation) | | | | Foreign |
- | Program |------------------>| Resolver |---------|->| Name |
- | | | | | | Server |
- | |<------------------| |<--------|--| |
- | | user responses | |responses| | |
- | | | | | | |
- +---------+ +----------+ | +---------+
- | ^ |
- cache additions | | references |
- v | |
- +----------+ |
- | cache | |
- +----------+ |
-
-
- Eventually, an ISO 10646 UCS without transformation is desired as the
- common format. The benefits of having a uniform byte length encoding
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
- far exceeds the seemingly easier transformation solution. Especially
- considering that the DNS requires a label count that should reflect
- the number of characters in a label. Of course there exists
- combination characters in the ISO 10646 specifications as well, but
- after canonicalization, only the ones that must use combinations
- remain and they are usually meaningful depictions.
-
- The importance of this count value is further demonstrated by
- scrambling efforts to extend the size of this field or to compress
- character encoding to accommodate multilingual characters. With
- DNSII, this no longer constitutes an issue because any language will
- be able to share the same number of characters thanks to the use of
- ISO 10646. As a matter of fact, the desire to use uniform byte
- length characters formed part of the original intent of the ISO 10646
- initiative anyway.
-
-3.2 Client-End or Inquirer Transitional Fall-Back Strategy
-
- For a DNSII aware Client, it will be able to create DNSII packets
- which provides precise character data of the domain name in question.
- However, if it encounters a non-compliant resolver, it MUST be able
- to fallback to a format acceptable by current resolvers.
-
-
- +---------+ +----------+
- | | (1) user queries | | (2) if Resolver is
- | | (DNSII identifier | | DNSII compliant,
- | | ILET=UCS without | | Packet is resolved
- | User | Transformation) | | accordingly. If
- | Program |----------------------->| Resolver | not fallback to (3)
- | | | |
- | |<-----------------------| |
- | | (3) Upon the detection | |
- | | of the DNSII Flag | |
- | | resolver will reply | |
- | | with _Format Error_ | |
- | | | |
- | |----------------------->| | (5) Current resolu-
- | | (4) Send QNAME using | | tion process begins
- | | local encoding or | | with the DNSII RR
- | | UTF-8 with or without | | passed along as an
- | | Additional DNSII RR | | Additional RR
- +---------+ +----------+
-
-
-3.2.1 Tunneling MDNP through DNSII RR
-
- An additional DNSII RR would be tunneled through using the format of
- a TXT RR with the RDATA part containing the multilingual labels in a
- DNSII compliant format. The TTL of the RR MUST be set to zero to
- avoid caching.
-
-
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
- It is not feasible to have a new RR type just for DNSII because the
- resolver might reject RRs with unknown types. For the name used in
- the QNAME as well as the NAME field of the DNSII RR UTF-8 MAY be used
- as the default fallback encoding. However, an arbitrary ASCII name
- MAY also be used just for the purpose of tunneling. The TTL for
- responses to tunneled requests MUST be set to zero to avoid caching
- at any level in the DNS. More detailed description in Section 3.4.
-
- For older DNS servers, requests with a non-empty additional
- information section MAY produce error returns, however since the
- deployment of DNSSEC, especially for TSIG considerations, this no-
- longer constitutes a problem. Basic security prepared servers such
- as BIND 4 or 8 is already capable of bearing the tunneled DNSII RR.
-
- It is possible to use ACE/RACE type translations at this level,
- however it is more advisable to use a truly arbitrary label such as
- _-for-tunneling-only-_. So doing requires only reserving one
- arbitrary name while ACE/RACE creates one more arbitrary name for
- each new multilingual name registered, which will eventually
- contribute to the fracturing of the DNS.
-
- As an example, a tunneling packet for the domain name: host. \97\8cªW¿t\99ð
- .tld. (4host4\97\8cªW¿t\99ð3 tld0) will be represented as:
-
- (in the QNAME field)
-
- 1 1 1 1 1 1 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +---------------------------------------------------------------+
- 12|0 0| 4 | h | o | s |
- +---------------------------------------------------------------+
- 16| t | 20 | - | f |
- +---------------------------------------------------------------+
- 20| 0 | r | - | t |
- +---------------------------------------------------------------+
- 24| u | n | n | e |
- +---------------------------------------------------------------+
- 28| l | i | n | g |
- +---------------------------------------------------------------+
- 32| - | o | n | l |
- +---------------------------------------------------------------+
- 36| y | - | 3 | t |
- +---------------------------------------------------------------+
- 40| l | d | 0 |...
- +-----------------------------------------------+
-
-
-
-
-
-
-
-
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
- (The Additional DNSII RR Tunneled in TXT RR form)
-
- : :
- / /
- +---------------------------------------------------------------+
- 80|1 1| 12 | TYPE = TXT = 16 |
- +---------------------------------------------------------------+
- 84| CLASS = IN = 1 | TTL |
- +---------------------------------------------------------------+
- 88| = 0 | RDLENGTH = 22 |
- +---------------------------------------------------------------+
- 92|0 0| 4 | h | o | s |
- +---------------------------------------------------------------+
- 96| t |1 0|0 0| UCS-2=1000 | 4 |
- +---------------------------------------------------------------+
- 100|1 1| 13 |1 0|z| ILET=2 | 4 |
- +---------------------------------------------------------------+
- 104| \97\8c (U+57DF) | ªW (U+540D) |
- +---------------------------------------------------------------+
- 108| ¿t (U+7CFB) | \99ð (U+7D71) |
- +---------------------------------------------------------------+
- 112|1 1| 38 |
- +-------------------------------+
-
-
- The reason a DNSII RR is attached is to alert the authoritative DNS
- server that the query is DNSII compliant while being able to tunnel
- the request through non-compliant resolvers without any loss of
- information.
-
-3.2.2 Tunneling ILET RRs
-
- Another fallback strategy is to tunnel just the ILET instead of the
- entire DNSII label. If UTF-8 or a local encoding is used as the
- QNAME, then the arbitrary ASCII label is no longer necessary. The
- tunneled RR therefore need only consist of an ILET indicating the
- encoding format used.
-
- Within the RDATA of an ILET RR masked as a TXT RR the first 4 bytes
- will be used to indicate that it is an ILET and the following 4 bytes
- to reflect the MIBenum of the encoding used.
-
-
-
-
-
-
-
-
-
-
-
-
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
- Following the example given in 3.2.1, the QNAME would be in UTF-8
- (MIBenum = 106), while the additional ILET RR would be in the form:
-
- : :
- / /
- +---------------------------------------------------------------+
- 80|1 1| 12 | TYPE = TXT = 16 |
- +---------------------------------------------------------------+
- 84| CLASS = IN = 1 | TTL |
- +---------------------------------------------------------------+
- 88| = 0 | RDLENGTH = 22 |
- +---------------------------------------------------------------+
- 92| I | L | E | T |
- +---------------------------------------------------------------+
- 96| 0 | 1 | 0 | 6 |
- +---------------------------------------------------------------+
-
-
-3.3 Resolvers & Server-End Transitional Fallback Strategy
-
- The tunneling scheme described in Section 3.2 assumes that the
- authoritative server is fully DNSII compliant. This assertion is
- laid out in Section 4.3 where it is discussed that only fully
- compliant servers SHOULD serve multilingual names directly under
- their authoritative zone. In any other case, the arbitrary domain
- "-for-tunneling-only-" should result in an NXDomain response.
-
- For security aware servers, an NXT RR of the last name wrapped by its
- first name in the zone records will be returned because of the
- leading "-" for the tunneling label.
-
- If the application end is not DNSII compliant, the fallback
- resolution strategy for resolvers would simply be to pass along the
- labels in their 8-bit format and determine the existence of the
- requested name as usual. If a tunneled DNSII RR is detected, by way
- of a label constituting entirely of _-for-tunneling-only-_ and the
- existence of a valid DNSII RR, the resolver should attempt to resolve
- the name according to the DNSII specification and tunnel the answer
- back to the inquirer.
-
-
-3.3.1 Tunneling MDNP Responses through DNSII ANS RR
-
- To tunnel a DNSII compliant answer through a non-compliant resolver,
- another DNSII ANS RR is tunneled. Also using the TXT RR format as a
- mask. TXT RRs are best used because it is a valid RR and its RDATA
- is an unrestricted byte stream determined only by the RDLENGTH. The
- RDATA for a DNSII ANS RR would be the entire content of a regular
- response RR attached to a DNSII format name.
-
- Continuing on the example given in Section 3.2, suppose an A record
- is requested and the IP address returned for the domain host.\97\8cªW¿t\99ð
-
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
- .tld. is 123.4.5.6, then an additional DNSII ANS RR (TXT) in the
- following form will be included:
-
- : :
- / /
- +---------------------------------------------------------------+
- 114|1 1| 12 | TYPE = TXT = 16 |
- +---------------------------------------------------------------+
- 118| CLASS = IN = 1 | TTL |
- +---------------------------------------------------------------+
- 122| = 0 | RDLENGTH = 16 |
- +---------------------------------------------------------------+
- 126|1 1| 92 | TYPE = A = 1 |
- +---------------------------------------------------------------+
- 130| CLASS = IN = 1 | TTL |
- +---------------------------------------------------------------+
- 134| = 3600 | RDLENGTH = 4 |
- +---------------------------------------------------------------+
- 138| 123 | 4 | 5 | 6 |
- +---------------------------------------------------------------+
-
- Note that compression is available in the DNSII RRs. While the
- tunneling TXT mask uses the ASCII tunneling name and therefore points
- back to the QNAME at offset 12, the tunneled A Record response uses
- the offset corresponding to the DNSII compliant labels at 92. While
- the TTL of the TXT mask MUST be zero, the tunneled A Record RR
- contains a regular TTL, in this case 3600.
-
-
-3.3.2 Reinsertion of ILET and DNSII Identifier
-
- When a resolver receives an incoming query with a tunneled DNSII/ILET
- RR, it SHOULD reconfigure the query into a fully compliant format
- before engaging in further resolution. If a "00" query is received,
- the resolver should convert the label into UTF-8, set the DNSII
- identifier "10" on and set the ILET to UTF-8.
-
- In the scenario where the client end is not DNSII compliant, either a
- local encoding 8-bit stream or a UTF-8 encoded stream without the
- DNSII flag nor ILET will be transported. During the transition
- period, should this occur, the above forced UTF-8 conversion and ILET
- insertion would take place and it would be up to the authoritative
- server to determine the existence of the requested domain. InZone
- DNSII handling mechanism will serve to take care of these
- transitional exceptions.
-
-
-4. DNSII Conformance Levels
-
- DNSII is designed for a smooth transition from the existing ASCII
- based DNS to a multilingual capable DNS. Therefore, it is not
- necessary for all servers and applications to be switched to
- multilingual capable before starting the deployment.
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
-
-
-4.1 Application Conformance Levels
-
- The BASIC compliancy for applications would be to remove validity
- checks for domain names. The resolution process will determine a
- non-existing domain name, so there really is no need to prevent a DNS
- packet with multilingual labels to be sent through the wires.
-
- The INTERMEDIATE compliancy for applications involves the insertion
- of the DNSII identifier as well as the ILET according to the local
- inputting and screen scheme. If a user is using a JIS format scheme,
- it should set the ILET to reflect it being used. At the same time,
- the tunneling mechanism discussed in Section 3.2 MUST also be in
- place.
-
- FULLY compliant applications will send all DNS packets with the DNSII
- identifier and the ILET set to UCS-2/4. The fallback scheme discussed
- in Section 3.2 MUST also be in place. InZone DNSII mechanisms SHOULD
- also be available to deal with local encoding exceptions.
-
-
-4.2 Resolver Conformance Levels
-
- The BASIC compliancy for resolvers would be to allow an 8-bit clean
- approach to name resolution. Also, it should be made sure that the
- additional DNSII RR (TXT) will not be truncated during resolution.
-
- The INTERMEDIATE compliant resolvers MUST understand how to process
- the DNSII identifier as well as not reject the ILET. Interpretation
- of the name is not required so it is NOT necessary for the resolvers
- to be able to map all or any of the ILET values (with the alternative
- approach in DNSII-MDNP, the ILET value corresponds to the byte length
- of the characters contained in the label, which makes the count
- workable even if the ILET value is not known by the resolver). In
- this scenario caching will be for exact comparison only (label to
- label with ILET intact). The important criteria is for the resolver
- to be able to pass along the DNS query to the corresponding
- authoritative server and obtain a correct response.
-
- FULLY compliant resolvers will be able to process the DNSII identifer
- and know all the ILET values for full function name mapping. Cache
- name lookup will be fully enabled and inquiry fallback mechanism
- discussed in Section 3.2.2 SHOULD be performed in the event of
- encountering a non-compliant server.
-
-
-4.3 Authoritative Server Conformance Levels
-
- Authoritative servers MUST be fully compliant before attempting to
- serve multilingual sub-domains under its authoritative zone. They
- should however prepare for the transition towards a multilingual name
- space even if they do not intend to deploy it right away.
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
-
- The BASIC compliancy for authoritative name servers is to allow an 8-
- bit clean approach towards sub-domains that are not directly under
- its authority (i.e. sub-sub-domains).
-
- The INTERMEDIATE compliant name server will be able to process the
- DNSII identifier and ILET without rejecting the query. The
- authoritative zone as well as its direct sub-domains however SHOULD
- not include the use of the DNSII flags because ILET values are not
- understood at this compliancy level.
-
- FULLY compliant name servers will be able to handle DNSII compliant
- label formats at its sub-domain levels. That is, fully compliant
- root servers will be able to serve multilingual TLDs, fully compliant
- TLD servers will be able to serve multilingual SLDs, etc.
-
-
-5. Transition Schedule & Strategy
-
- DNSII is designed to allow a gradual adoption of multilingual domain
- names on the Internet. The transition strategy is therefore geared
- to be demand-pull instead of a technology-push incentive. However,
- to provide a platform for a demand-pull approach, it is required for
- operators to first safeguard their system. The simple approach as
- laid out in Section 4 is to propose that servers take a 8-bit clean
- approach on name resolution.
-
- As discussed in DNSII-MDNP, it is reasonable for the deployment of
- DNSII-MDNP at the registry level first to draw demand for the service
- and let the host level DNSs with multilingual names to begin
- migration first. DNS operators around the world should however
- prepare for the transition and begin the deployment of DNSII
- depending on their interest in serving multilingual domain names,
- according to the conformance levels laid out in Section 4, beginning
- from BASIC compliancy for operators that are least interested to a
- FULLY compliant server for operators who wishes to provide
- multilingual capabilities for their users.
-
- The root servers could easily be adjusted to be a BASIC compliant
- authoritative name server. Once the demand is proven and the
- stability of the system tested, they too could transition to fully
- compliant authoritative servers so that multilingual TLDs could be
- rolled out.
-
-
-6. Summary of Discussion
-
- This document introduces the contemplated transition and steady state
- resolution process for multilingual domain names with a DNSII
- compliant format. Two tunneling mechanisms using the TXT RR was
- introduced for the preservation of information during transitional
- resolution.
-
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
-6.1 Client/Application Resolution Strategy
-
- Send Query in DNSII format
- IF RCODE = Format Error
- THEN send query in UTF-8/Local Encoding AND append DNSII RR
- IF RCODE = Format Error
- THEN send Query in ASCII with _-for-tunneling-only-_ label
- AND append DNSII RR
- AND check for DNSII ANS RR in response
- ELSE proceed and check for DNSII ANS RR in response
- ELSE proceed as usual
-
-
-6.2 Resolver Resolution Strategy
-
- (*)IF incoming request is in pure DNSII format
- THEN resolve according to ILET in cache and by recursive lookup
- IF encounter RCODE = Format Error
- THEN send query in UTF-8 AND append DNSII RR
- IF RCODE = Format Error
- THEN send query in ASCII with _-for-tunneling-only-_
- label
- AND append DNSII RR
- AND check for DNSII ANS RR in response
- ELSE proceed and check for DNSII ANS RR in response
- ELSE proceed as usual with pure DNSII Format (*)
- AND respond in pure DNSII format
- ELSE IF incoming request has tunneled MDNP information
- THEN resolve using the information in the appended DNSII RR
- Reset Query using DNSII Format and go through (*)
- AND convert back to tunneling format before responding to query
- With DNSII ANS RR appended to response
- AND set TTL for regular RRs in the Answer field to be = 0
- ElSE IF incoming request is in the original "00" label format
- AND no tunneled information is included
- AND the label contains characters beyond A-z, 0-9 or "-"
- THEN force convert all labels to UTF-8
- AND query using DNSII Format and go through (*)
- ELSE proceed as usual (existing ASCII based names)
-
-
-6.3 Authoritative Name Server Resolution Strategy
-
- IF incoming request is in pure DNSII format
- THEN resolve according to ILET
- AND respond in pure DNSII format
- ELSE IF incoming request has tunneled MDNP information
- THEN resolve using the information in the appended DNSII RR
- AND convert back to tunneling format before responding to query
- With DNSII ANS RR appended to response
- AND set TTL for regular RRs in the Answer field to be = 0
- ELSE use InZone DNSII mechanisms AND use 8-bit clean approach
-
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
-7. Security Considerations
-
- DNSII RRs will be secured through transaction authentication, while
- DNSII ANS RRs could have their own SIG RRs. In general, the DNSII-
- MDNR should not constitute any extra burden on DNS security.
-
-
-8. Intellectual Property Considerations
-
- It is the intention of Neteka to submit the DNSII protocol and other
- elements of the multilingual domain name server software to IETF for
- review, comment or standardization.
-
- Neteka Inc. has applied for one or more patents on the technology
- related to multilingual domain name server software and multilingual
- email server software suite. If a standard is adopted by IETF and
- any patents are issued to Neteka with claims that are necessary for
- practicing the standard, any party will be able to obtain the right
- to implement, use and distribute the technology or works when
- implementing, using or distributing technology based upon the
- specific specifications under fair, reasonable and non-discriminatory
- terms.
-
- Other DNSII related documents and discussions could be found at
- http://www.dnsii.org.
-
-9. References
-
- [DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name
- Protocol", August 2000
-
- [RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC
- 1700, October 1994.
-
- [ISO10646] ISO/IEC 10646-1:2000. International Standard --
- Information technology -- Universal Multiple-Octet Coded
- Character Set (UCS)
-
- [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
-
-
-
-
-
-
-
-\fDNSII-MDNR Multilingual Domain Name Resolution August 2000
-
- Authors:
-
- Edmon Chung
- Neteka Inc.
- 2462 Yonge St. Toronto,
- Ontario, Canada M4P 2H5
- edmon@neteka.com
-
- David Leung
- Neteka Inc.
- 2462 Yonge St. Toronto,
- Ontario, Canada M4P 2H5
- david@neteka.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-\f
\ No newline at end of file
+++ /dev/null
-Working Group Edmon Chung & David Leung
-Internet Draft Neteka Inc.
-<draft-ietf-idn-dnsii-trace-00.txt> September 2000
-
-
- DNSII Transitional Reflexive ASCII Compatible Encoding (TRACE)
-
-
-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 reader is cautioned not to depend on the values that appear in
- examples to be current or complete, since their purpose is primarily
- educational. Distribution of this memo is unlimited.
-
- 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
-
- ASCII Compatible Encoding (ACE) schemes should only be used as a
- transitional strategy with a well-defined way forward to the eventual
- enabling of a truly multilingual name space for the DNS.
-
- The previous DNSII documents surrounding multilingual domain names
- have focused on the ultimate form with the DNSII-MDNR suggesting
- possible tunneling techniques where ACE may be used. This document
- furthers the discussion on an ACE system, which not only provides a
- pathway towards the ultimate DNSII scheme but also an interim
- solution taking care of the immediate needs.
-
- A reflexive CNAME process RENAME is introduced where non-ASCII
- incoming queries will be automatically CNAMEd to its ASCII
- counterpart without requiring an actual lookup. The resolver will
- then be responsible for recursively looking up the corresponding
- translated alphanumeric name.
-
- This document does not attempt to create another ACE scheme, instead
- it discusses the way an ACE scheme could be used as a transition
- towards the ultimate goal of a true multilingual name on the wire.
-
-
-Chung & Leung [Page 1]
-
-\fDNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
-
-Table of Contents
-
- 1. Introduction....................................................2
- 1.1 Terminology....................................................2
- 2. TRACE - Introduced with Due Obsolescence........................3
- 2.1 Problems & Benefits of ACE.....................................3
- 2.2 TRACE Format...................................................3
- 2.3 TRACE Identifier...............................................3
- 2.4 TRACE Zone Handling............................................4
- 3. REflexive CNAME (RENAME)........................................4
- 3.1 Non-Recursive Name Servers with RENAME-ON......................5
- 3.1 Recursive Name Servers (Resolvers) with RENAME-ON..............6
- 3.2 Benefits of RENAME.............................................6
- 3.3 Problems with RENAME...........................................7
- 4. Use of RENAME with Respect to DNS Hierarchy.....................7
- 4.1 General Rules for using RENAME.................................8
- 4.2 Transitioning towards Identification Based DNSII...............8
- 5. Security Considerations.........................................9
- 6. Conclusion......................................................9
- 7. Intellectual Property Considerations...........................10
- 8. References.....................................................10
-
-
-1. Introduction
-
- ACE usage should be limited to machine read only and steps should be
- taken to avoid the user being able to easily input the names through
- an application onto the wire. This is a well-understood concept
- because without this requirement, the creation of an ACE system
- effectively creates an alternate universe model that is counter to
- the spirit of the DNS. In essence, if an ACE scheme could easily be
- typed in, people who are typing that sequence of characters may be
- unexpectedly be brought to another site which happens to have the
- same "code".
-
- TRACE outlines a scheme that uses an ACE scheme but is identified in
- a 7-bit format that could not easily be typed in by a user. Thereby
- preventing an inconsistent expectation of a domain name. Beyond the
- specification of an identifier a RENAME function for an ACE
- resolution process is also introduced.
-
-
-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].
-
- A number of characters used in this document are in a Big-5 encoding,
- you could select your view encoding type to traditional Chinese or
- Big-5 for it to be displayed properly.
-
-
-
-Chung & Leung [Page 2]
-
-\fDNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
-
-2. TRACE - Introduced with Due Obsolescence
-
- TRACE is designed to be a transitional scheme with due obsolescence
- once a full-fledged DNSII mode is attained.
-
-
-2.1 Problems & Benefits of ACE
-
- One of the major problems with ACE is the evident result of creating
- an extra layer on top of the DNS. DNS was designed to be the human
- friendly machine identifier with its names human readable. With ACE,
- it is certain that an added layer is required to decode a domain
- name. This also effectively results in a quasi-alternate universe
- mode whereby the actual characters represent a translation into the
- existing domain name space.
-
- However, ACE has its benefits as well and the most prominent one is
- that host servers need not migrate to new name servers. Also it will
- ensure that there is a lengthy enough migration period for other
- applications to start adapting to the new DNS specifications.
-
-
-2.2 TRACE Format
-
- TRACE does not intend to introduce a new type of encoding. Rather,
- it is concerned with using a 7-bit compatible identifier and a
- reflexive mechanism for switching from regular DNS packets to TRACE.
-
-
-2.3 TRACE Identifier
-
- In other ACE proposals, identifiers are often created from
- alphanumeric characters, which end users can easily type in. The
- problem with this approach is easy to understand, for each
- multilingual name, one alphanumeric name must be reserved simply for
- the use of the multilingual conversion and will not be available for
- normal usage.
-
- For example from Paul Hoffman's draft [RACE-01], the sample
- conversion for a value 0x3a27 would result in a string "bq--hitq".
- The name "bq--hitq" which is a perfectly usable name on its own must
- now be reserved for a multilingual name. Also, 4 character spaces
- will be wasted just for the identifier.
-
- Instead of using an alphanumeric identifier, a single 7-bit compliant
- control character is used. The proposed character is the control
- character with the value 0x7F. With this character, a multilingual
- name part could be effectively identified while it would be very
- difficult for the average user to enter the character into an
- application, thereby avoiding the issue discussed above.
-
- In any case, an ACE form name is not intended for an end user to type
- in. The only reason for ACE is that the current name servers could
-
-Chung & Leung [Page 3]
-
-\fDNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
-
- easily handle them. TRACE provides a simple and effective way which
- is 7-bit compliant and a string that is could not be easily imitated.
-
-
-2.4 TRACE Zone Handling
-
- A zone administrator could also easily enter the TRACE Identifier
- into the zone file. To insert the TRACE Identifier in a BIND server,
- the administrator could simply append the string "\127" before the
- ACE label. Current BIND servers will understand that "\127" calls
- for the character with the value 127 and therefore load it into
- memory accordingly. The BIND should also be reconfigured to set the
- options for "check-names" to "ignore".
-
- In the following examples, the ACE format used is simply the hex
- value of the corresponding character encoding. RACE or other ACE
- formats or hex of other encoding schemes may be used.
-
- To set up an NS record to ns1.trace.tld and an A record to 123.4.5.6
- for the name "ñññ\85" <U+4e2d><U+6587> in a BIND server, using UTF-8
- (E4B8AD E69687) the following lines are included into the zone file:
-
- \127e4b8ade69687 IN NS ns1.trace.tld.
- \127e4b8ade69687 IN A 123.4.5.6
-
- Section 4.3 will discuss a method to prepare the zone file for the
- transition into a fully DNSII compliant mode.
-
-
-3. REflexive CNAME (RENAME)
-
- To complement an ACE transition, a reflexive mechanism is introduced.
- REflexive CNAME (RENAME) successfully creates a scheme whereby child
- DNS nodes could keep using their BIND name servers while be capable
- of hosting multilingual domain names.
-
- RENAME is simply a mechanism that attaches an incoming multilingual
- name to its ACE counterpart as it enters a RENAME-ON name server.
- When to use RENAME is discussed in Section 4.
-
- As an example, if an incoming query contains a the domain name "ññ
- ñ\85.tld" <U+4e2d><U+6587>.tld in UTF-8 encoding reaches a RENAME-ON
- name server, the following automatic response will be created:
-
- ñññ\85.tld IN CNAME \127e4b8ade69687.tld
-
- If the server is in non-recursive mode, the RENAMEd name will now be
- used for a lookup within the zone and the corresponding response
- returned to the inquirer, including the CNAME process. If the server
- is in recursive mode, the RENAMEd name will be used for lookup within
- cache and passed on through the DNS hierarchy when not found.
-
-
-
-Chung & Leung [Page 4]
-
-\fDNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
-
-3.1 Non-Recursive Name Servers with RENAME-ON
-
- The two basic modes for a name server includes a non-recursive mode,
- which are usually used by registries, root or authoritative host
- servers; and a recursive mode, which are usually resolvers installed
- in ISPs.
-
- A non-recursive mode server with RENAME-ON would upon receiving a
- multilingual name label, automatically CNAME the name to an ACE
- format. If a complete match is found, the response will be passed
- back to the inquirer including the CNAME record. If no direct match
- is found, it will pass along either an authoritative NXDomain or the
- nearest NS Record in ACE format so that the inquirer may continue its
- recursive request.
-
- The following diagram and descriptions details the resolution process
- for the domain "www.ñññ\85.ñññ\85.tld" or <U+4e2d><U+6587>.<U+4e2d>
- <U+6587>.tld, with a DNSII TRACE RENAME-ON server installed at the
- Parent domain "ñññ\85.tld" and a BIND server installed at the Child DNS
- domain "ñññ\85.ñññ\85.tld":
-
- (3)
- +--------+ +------------+ +---------------+
- | | (1) | | (2) | |
- | Client |-------->| Resolver |-------->| Parent Domain | ñññ\85.tld
- | |<--------| |<--------| (RENAME-ON) |
- | | (8) | | (4) | |
- +--------+ +------------+ +---------------+
- ^ |
- | | (6)
- | | (5) +--------------+
- | +-------->| |
- +-----------| Child Domain | ñññ\85.ñññ\85.tld
- (7) | (using BIND) |
- | |
- +--------------+
-
-
- (1) A user enters a query for the A record of "www.ñññ\85.ñññ\85.tld" or
- <U+4e2d><U+6587>.<U+4e2d><U+6587>.tld using an ISO10646 encoding
- input.
-
- (2) The DNS recursive resolver arrives at the parent domain "ññ
- ñ\85.tld" <U+4e2d><U+6587>.tld
-
- (3) With RENAME-ON and detection that the incoming query is non-ASCII,
- the server reflexively assigns the CNAME to the domain:
-
- www.ñññ\85.ñññ\85.tld. IN CNAME www.\127e4b8ade69687.
- \127e4b8ade69687.tld.
-
-
-
-
-Chung & Leung [Page 5]
-
-\fDNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
-
- (4) Since a direct match is not found in the Parent DNS, the closest
- NS record is returned to the Resolver, with the CNAME part
- included:
-
- www.ñññ\85.ñññ\85.tld. IN CNAME www.\127e4b8ade69687.
- \127e4b8ade69687.tld.
-
- \127e4b8ade69687.\127e4b8ade69687.tld. IN NS
- ns1.\127e4b8ade69687.\127e4b8ade69687.tld.
-
- ns1.\127e4b8ade69687.\127e4b8ade69687.tld. IN A 123.5.6.7
-
- (5) The recursive resolver passes on the request using the CNAME
- record to the Child DNS as:
-
- www.\127e4b8ade69687.\127e4b8ade69687.tld.
-
- Asking for an A record for the corresponding domain.
-
- (6) The Child DNS simply does a regular look up for the domain with
- the corresponding response.
-
- (7) Assuming that the correct IP address for www.ñññ\85.ñññ\85.tld is
- 123.6.7.8, the response would be:
-
- www.\127e4b8ade69687.\127e4b8ade69687.tld. IN A 123.6.7.8
-
- (8) The resolver will then respond to the client request accordingly,
- including the CNAME record.
-
-
-3.1 Recursive Name Servers (Resolvers) with RENAME-ON
-
- If the recursive resolver is DNSII compatible and have switched the
- RENAME-ON, then both the parent and child DNSs could still run BIND
- and be able to serve multilingual names. As the request goes through
- the resolver, it is automatically CNAMEd to the corresponding ACE
- format name and passed along for further resolution.
-
- When the corresponding response is obtained, the definite answer
- including the CNAME record will both be passed to the client.
-
-
-3.2 Benefits of RENAME
-
- The immediate benefit for using RENAME is that once it is deployed at
- a particular DNS level, all its child, or sub-level DNSs could
- continue to run a BIND-based or current name server while still be
- capable of serving multilingual domain names.
-
- Most ACE implementations expect the client application to begin
- migration first. This is unfortunately would take a long time
- because we understand that client end migration may take years to
-
-Chung & Leung [Page 6]
-
-\fDNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
-
- complete. With RENAME however, the migration could be dynamic.
- Section 4 explains further how and when RENAME should be used to
- complement and facilitate the resolution of multilingual names even
- when some of the components are not fully multilingual aware.
-
-
-3.3 Problems with RENAME
-
- RENAME effectively creates an ACE based name space which is
- ultimately undesired. Also, wherever the RENAME function is located,
- it will intensify the processing requirements for the machine to
- handle the conversion of the incoming multilingual label into an ACE
- format and package the CNAME record accordingly.
-
-
-4. Use of RENAME with Respect to DNS Hierarchy
-
- For the discussion within this document, the DNS hierarchy is
- summarized into four nodes, beginning with the client end
- application, through the resolver, to the root or NIC servers then
- finally at the authoritative host for a second-level domain. This
- more or less summarizes the DNS process from the initiation of a
- request to the authoritative host.
-
- All together, there are 16 combinations with the basic DNS
- environments. The following chart outlines the different
- combinations with the denotations as:
-
-
- B = B-DNS = Current Bind-based DNS
- D = DNSII = DNSII Compliant Name Servers
- RENAME(X-X-X-X) = RENAME(Client/application-Resolver-Root/NIC-Host)
- with X = ON = RENAME-ON
- FF = RENAME-OFF
- OP = Optional ON/OFF
- NA = Not Applicable
-
- Scenario | Client |Resolver|Root/NIC| Host | RENAME(ON/OFF)
- ---------+--------+--------+--------+--------+---------------------
- 1) BBBB | B-DNS | B-DNS | B-DNS | B-DNS | existing system
- +--------+--------+--------+--------+
- 2) BBBD | B-DNS | B DNS | B-DNS | DNSII | RENAME(NA-NA-NA-FF)
- +--------+--------+--------+--------+
- 3) BBDB | B-DNS | B DNS | DNSII | B-DNS | RENAME(NA-NA-ON-NA)
- +--------+--------+--------+--------+
- 4) BDBB | B-DNS | DNSII | B DNS | B-DNS | RENAME(NA-ON-NA-NA)
- +--------+--------+--------+--------+
- 5) DBBB | DNSII | B-DNS | B-DNS | B-DNS | RENAME(ON-NA-NA-NA)
- +--------+--------+--------+--------+
- 6) BBDD | B-DNS | B-DNS | DNSII | DNSII | RENAME(NA-NA-FF-FF)
- +--------+--------+--------+--------+
- 7) DNND | B-DNS | DNSII | DNSII | B-DNS | RENAME(NA-OP-ON-NA)
- +--------+--------+--------+--------+
-
-Chung & Leung [Page 7]
-
-\fDNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
-
- Scenario | Client |Resolver|Root/NIC| Host | RENAME(ON/OFF)
- ---------+--------+--------+--------+--------+---------------------
- 8) DDBB | DNSII | DNSII | B-DNS | B-DNS | RENAME(OP-ON-NA-NA)
- +--------+--------+--------+--------+
- 9) DBBD | DNSII | B-DNS | B-DNS | DNSII | RENAME(ON-NA-NA-FF)
- +--------+--------+--------+--------+
- 10) BDBD | B-DNS | DNSII | B-DNS | DNSII | RENAME(NA-ON-NA-FF)
- +--------+--------+--------+--------+
- 11) DBDB | DNSII | B-DNS | DNSII | B-DNS | RENAME(ON-NA-OP-NA)
- +--------+--------+--------+--------+
- 12) BDDD | B-DNS | DNSII | DNSII | DNSII | RENAME(NA-FF-FF-FF)
- +--------+--------+--------+--------+
- 13) DDDB | DNSII | DNSII | DNSII | B-DNS | RENAME(OP-OP-ON-NA)
- +--------+--------+--------+--------+
- 14) DDBD | DNSII | DNSII | B-DNS | DNSII | RENAME(OP-ON-NA-FF)
- +--------+--------+--------+--------+
- 15) DBDD | DNSII | B-DNS | DNSII | DNSII | RENAME(ON-NA-FF-FF)
- +--------+--------+--------+--------+
- 16) DDDD | DNSII | DNSII | DNSII | DNSII | Full DNSII mode
- +--------+--------+--------+--------+
-
-
-4.1 General Rules for using RENAME
-
- As a general rule, RENAME should be turned on whenever there is an
- anticipation that further down the DNS hierarchy or resolution
- process, a host has not been migrated and is still using existing
- name server software. For example, Scenario(3),(4) or (5) and their
- equivalents.
-
- If it is known that the entire set of child hosts is DNSII compliant,
- then RENAME is optional even if there exists child sub-sub-domain
- host beneath the sub-domain level that uses existing name servers.
- For example, Scenario(7) and the sample given in Section 3.
-
- The end host without any more child sub-domains SHOULD never turn on
- RENAME. This consideration is given to reduce the amount of
- transition traffic created due to the reflexive answer where no
- further resolution is required.
-
-
-4.2 Transitioning towards Identification Based DNSII
-
- Following the DNSII-MDNP recommendations, TRACE could smooth the
- transition into a multilingual name space by starting at the registry
- level and without requiring the host DNSs to migrate.
-
- As the user-end applications or recursive ISP resolvers began the
- migration, new multilingual TLDs could also be introduced even before
- the root servers begin any migration.
-
- Eventually, when the root servers migrate, they should be enabled
- with both the full DNSII capability with the InPacket Identifier,
-
-Chung & Leung [Page 8]
-
-\fDNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
-
- ILET as well as TRACE as a fallback should there be any host DNS
- still using existing servers.
-
- From the general rules, we understand that if the entire child DNSs
- are DNSII enabled, then the RENAME function of the parent DNS could
- be turned off. This therefore makes way for a very sensible
- migration strategy owing to the hierarchical structure of the DNS.
- Since a parent DNS must know a glue record for its immediate
- children, it is easy for the zone administrator to determine whether
- it could turn off the RENAME function for its zone.
-
- While it is understood that gradually, all name servers should
- migrate to be DNSII capable and that multilingual names, TRACE
- creates a very effective way of monitoring the migration by
- encouraging child DNSs to begin transition first followed by upper
- and more important levels, up to the root.
-
- A fully DNSII aware server should also be prepared for DNSII queries.
- That is, it should be able to process requests containing the DNSII
- Identifier and ILET. As a working example, a Neteka Enhanced BIND
- (for a demo copy please mailto:netekare@neteka.com) has been
- developed as a demonstration. To enter a full DNSII label, in the
- product, simply duplicate the TRACE identifier and insert a
- corresponding ILET. As an example, for "ñññ\85.tld" <U+4e2d>
- <U+6587>.tld with ILET = 1000 = Unicode, an A record for the IP
- address 123.4.5.6 could be added to the zone file as:
-
- \127\12710004e2d6587.tld. IN A 123.4.5.6
-
- In such an environment, DNSII aware queries will be answered
- accordingly utilizing the "\127\127" record.
-
-
-5. Security Considerations
-
- The implementation of TRACE constitutes no further security burden on
- the DNS. DNSSEC could be used in parallel with TRACE resolution and
- records. RENAME records will be secured through transaction
- authentication, while authoritative records will have their own SIG
- RRs.
-
- Moreover, the TRACE identifier actually increases the security for
- multilingual names over other ACE implementations by using the 0x7F
- character, which is difficult for an end user to key in, thereby
- reducing the possible confusions.
-
-
-6. Conclusion
-
- With any implementation, the first step towards universal deployment
- of a multilingual aware name space should be an 8-bit clean approach.
- For current BIND servers it is a simple configuration matter, which
- could be set as an option for checknames to be ignored.
-
-Chung & Leung [Page 9]
-
-\fDNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
-
-
- With TRACE, the migration from the current system could be dynamic.
- While it is encouraged that the registries begin the migration first
- because it is most sensible, client end or recursive resolvers could
- also begin the migration.
-
- The use of the control character 0x7F also solves two problems at
- once: 1) a 7-bit identifier to avoid disruption of other applications
- using DNS; and, 2) an identifier that is not easily input by a client
- end user to prevent confusion between a multilingual name and an
- English alphanumeric only name.
-
- RENAME successfully creates an environment where host level DNSs
- could hold on to their existing BIND based name servers while being
- able to host multilingual domains, thereby relieving the migration
- stress for hosting facilities and ISPs.
-
-
-7. Intellectual Property Considerations
-
- It is the intention of Neteka to submit the DNSII protocol and other
- elements of the multilingual domain name server software to IETF for
- review, comment or standardization.
-
- Neteka Inc. has applied for one or more patents on the technology
- related to multilingual domain name server software and multilingual
- email server software suite. If a standard is adopted by IETF and
- any patents are issued to Neteka with claims that are necessary for
- practicing the standard, any party will be able to obtain the right
- to implement, use and distribute the technology or works when
- implementing, using or distributing technology based upon the
- specific specifications under fair, reasonable and non-discriminatory
- terms.
-
-
-8. References
-
- [DNSII-MDNP] E. Chung & D. Leung "DNSII Multilingual Domain Name
- Protocol", August 2000
-
- [RACE] P. Hoffman "RACE: Row-based ASCII Compatible Encoding for
- IDN", August 31, 2000
-
- [RFC1700] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC
- 1700, October 1994.
-
- [ISO10646] ISO/IEC 10646-1:2000. International Standard --
- Information technology -- Universal Multiple-Octet Coded
- Character Set (UCS)
-
- [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels," RFC 2119, March 1997
-
-
-Chung & Leung [Page 10]
-
-\fDNSII-TRACE DNSII Transitional Reflexive ACE (TRACE) August 2000
-
-
- Authors:
-
- Edmon Chung
- Neteka Inc.
- 2462 Yonge St. Toronto,
- Ontario, Canada M4P 2H5
- edmon@neteka.com
-
- David Leung
- Neteka Inc.
- 2462 Yonge St. Toronto,
- Ontario, Canada M4P 2H5
- david@neteka.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Chung & Leung [Page 11]
+++ /dev/null
-INTERNET-DRAFT Mark Welter
-draft-ietf-idn-dude-02.txt Brian W. Spolarich
-Expires 2001-Dec-07 Adam M. Costello
- 2001-Jun-07
-
- Differential Unicode Domain Encoding (DUDE)
-
-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
-
- Distribution of this document is unlimited. Please send comments to
- the authors or to the idn working group at idn@ops.ietf.org.
-
-Abstract
-
- DUDE is a reversible transformation from a sequence of nonnegative
- integer values to a sequence of letters, digits, and hyphens (LDH
- characters). DUDE provides a simple and efficient ASCII-Compatible
- Encoding (ACE) of Unicode strings [UNICODE] for use with
- Internationalized Domain Names [IDN] [IDNA].
-
-Contents
-
- 1. Introduction
- 2. Terminology
- 3. Overview
- 4. Base-32 characters
- 5. Encoding procedure
- 6. Decoding procedure
- 7. Example strings
- 8. Security considerations
- 9. References
- A. Acknowledgements
- B. Author contact information
- C. Mixed-case annotation
- D. Differences from draft-ietf-idn-dude-01
- E. Example implementation
-\f
-1. Introduction
-
- The IDNA draft [IDNA] describes an architecture for supporting
- internationalized domain names. Each label of a domain name may
- begin with a special prefix, in which case the remainder of the
- label is an ASCII-Compatible Encoding (ACE) of a Unicode string
- satisfying certain constraints. For the details of the constraints,
- see [IDNA] and [NAMEPREP]. The prefix has not yet been specified,
- but see http://www.i-d-n.net/ for prefixes to be used for testing
- and experimentation.
-
- DUDE is intended to be used as an ACE within IDNA, and has been
- designed to have the following features:
-
- * Completeness: Every sequence of nonnegative integers maps to an
- LDH string. Restrictions on which integers are allowed, and on
- sequence length, may be imposed by higher layers.
-
- * Uniqueness: Every sequence of nonnegative integers maps to at
- most one LDH string.
-
- * Reversibility: Any Unicode string mapped to an LDH string can
- be recovered from that LDH string.
-
- * Efficient encoding: The ratio of encoded size to original size
- is small. This is important in the context of domain names
- because [RFC1034] restricts the length of a domain label to 63
- characters.
-
- * Simplicity: The encoding and decoding algorithms are reasonably
- simple to implement. The goals of efficiency and simplicity are
- at odds; DUDE places greater emphasis on simplicity.
-
- An optional feature is described in appendix C "Mixed-case
- annotation".
-
-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].
-
- LDH characters are the letters A-Z and a-z, the digits 0-9, and
- hyphen-minus.
-
- A quartet is a sequence of four bits (also known as a nibble or
- nybble).
-
- A quintet is a sequence of five bits.
-
- Hexadecimal values are shown preceeded by "0x". For example, 0x60
- is decimal 96.
-
- As in the Unicode Standard [UNICODE], Unicode code points are
- denoted by "U+" followed by four to six hexadecimal digits, while a
- range of code points is denoted by two hexadecimal numbers separated
- by "..", with no prefixes.
-\f
- XOR means bitwise exclusive or. Given two nonnegative integer
- values A and B, A XOR B is the nonnegative integer value whose
- binary representation is 1 in whichever places the binary
- representations of A and B disagree, and 0 wherever they agree.
- For the purpose of applying this rule, recall that an integer's
- representation begins with an infinite number of unwritten zeros.
- In some programming languages, care may need to be taken that A and
- B are stored in variables of the same type and size.
-
-3. Overview
-
- DUDE encodes a sequence of nonnegative integral values as a sequence
- of LDH characters, although implementations will of course need to
- represent the output characters somehow, typically as ASCII octets.
- When DUDE is used to encode Unicode characters, the input values are
- Unicode code points (integral values in the range 0..10FFFF, but not
- D800..DFFF, which are reserved for use by UTF-16).
-
- Each value in the input sequence is represented by one or more LDH
- characters in the encoded string. The value 0x2D is represented
- by hyphen-minus (U+002D). Each non-hyphen-minus character in
- the encoded string represents a quintet. A sequence of quintets
- represents the bitwise XOR between each non-0x2D integer and the
- previous one.
-
-4. Base-32 characters
-
- "a" = 0 = 0x00 = 00000 "s" = 16 = 0x10 = 10000
- "b" = 1 = 0x01 = 00001 "t" = 17 = 0x11 = 10001
- "c" = 2 = 0x02 = 00010 "u" = 18 = 0x12 = 10010
- "d" = 3 = 0x03 = 00011 "v" = 19 = 0x13 = 10011
- "e" = 4 = 0x04 = 00100 "w" = 20 = 0x14 = 10100
- "f" = 5 = 0x05 = 00101 "x" = 21 = 0x15 = 10101
- "g" = 6 = 0x06 = 00110 "y" = 22 = 0x16 = 10110
- "h" = 7 = 0x07 = 00111 "z" = 23 = 0x17 = 10111
- "i" = 8 = 0x08 = 01000 "2" = 24 = 0x18 = 11000
- "j" = 9 = 0x09 = 01001 "3" = 25 = 0x19 = 11001
- "k" = 10 = 0x0A = 01010 "4" = 26 = 0x1A = 11010
- "m" = 11 = 0x0B = 01011 "5" = 27 = 0x1B = 11011
- "n" = 12 = 0x0C = 01100 "6" = 28 = 0x1C = 11100
- "p" = 13 = 0x0D = 01101 "7" = 29 = 0x1D = 11101
- "q" = 14 = 0x0E = 01110 "8" = 30 = 0x1E = 11110
- "r" = 15 = 0x0F = 01111 "9" = 31 = 0x1F = 11111
-
- The digits "0" and "1" and the letters "o" and "l" are not used, to
- avoid transcription errors.
-
- A decoder must accept both the uppercase and lowercase forms of
- the base-32 characters (including mixtures of both forms). An
- encoder should output only lowercase forms or only uppercase forms
- (unless it uses the feature described in the appendix C "Mixed-case
- annotation").
-
-5. Encoding procedure
-
- All ordering of bits, quartets, and quintets is big-endian (most
- significant first).
-\f
- let prev = 0x60
- for each input integer n (in order) do begin
- if n == 0x2D then output hyphen-minus
- else begin
- let diff = prev XOR n
- represent diff in base 16 as a sequence of quartets,
- as few as are sufficient (but at least one)
- prepend 0 to the last quartet and 1 to each of the others
- output a base-32 character corresponding to each quintet
- let prev = n
- end
- end
-
- If an encoder encounters an input value larger than expected (for
- example, the largest Unicode code point is U+10FFFF, and nameprep
- [NAMEPREP03] can never output a code point larger than U+EFFFD),
- the encoder may either encode the value correctly, or may fail, but
- it must not produce incorrect output. The encoder must fail if it
- encounters a negative input value.
-
-6. Decoding procedure
-
- let prev = 0x60
- while the input string is not exhausted do begin
- if the next character is hyphen-minus
- then consume it and output 0x2D
- else begin
- consume characters and convert them to quintets until
- encountering a quintet whose first bit is 0
- fail upon encountering a non-base-32 character or end-of-input
- strip the first bit of each quintet
- concatenate the resulting quartets to form diff
- let prev = prev XOR diff
- output prev
- end
- end
- encode the output sequence and compare it to the input string
- fail if they do not match (case-insensitively)
-
- The comparison at the end is necessary to guarantee the uniqueness
- property (there cannot be two distinct encoded strings representing
- the same sequence of integers). This check also frees the decoder
- from having to check for overflow while decoding the base-32
- characters. (If the decoder is one step of a larger decoding
- process, it may be possible to defer the re-encoding and comparison
- to the end of that larger decoding process.)
-
-7. Example strings
-
- The first several examples are nonsense strings of mostly unassigned
- code points intended to exercise the corner cases of the algorithm.
-
- (A) u+0061
- DUDE: b
-
- (B) u+2C7EF u+2C7EF
- DUDE: u6z2ra
-\f
- (C) u+1752B u+1752A
- DUDE: tzxwmb
-
- (D) u+63AB1 u+63ABA
- DUDE: yv47bm
-
- (E) u+261AF u+261BF
- DUDE: uyt6rta
-
- (F) u+C3A31 u+C3A8C
- DUDE: 6v4xb5p
-
- (G) u+09F44 u+0954C
- DUDE: 39ue4si
-
- (H) u+8D1A3 u+8C8A3
- DUDE: 27t6dt3sa
-
- (I) u+6C2B6 u+CC266
- DUDE: y6u7g4ss7a
-
- (J) u+002D u+002D u+002D u+E848F
- DUDE: ---82w8r
-
- (K) u+BD08E u+002D u+002D u+002D
- DUDE: 57s8q---
-
- (L) u+A9A24 u+002D u+002D u+002D u+C05B7
- DUDE: 434we---y393d
-
- (M) u+7FFFFFFF
- DUDE: z999993r or explicit failure
-
- The next several examples are realistic Unicode strings that could
- be used in domain names. They exhibit single-row text, two-row
- text, ideographic text, and mixtures thereof. These examples are
- names of Japanese television programs, music artists, and songs,
- merely because one of the authors happened to have them handy.
-
- (N) 3<nen>b<gumi><kinpachi><sensei> (Latin, kanji)
- u+0033 u+5E74 u+0062 u+7D44 u+91D1 u+516B u+5148 u+751F
- DUDE: xdx8whx8tgz7ug863f6s5kuduwxh
-
- (O) <amuro><namie>-with-super-monkeys (Latin, kanji, hyphens)
- u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074
- u+0068 u+002D u+0073 u+0075 u+0070 u+0065 u+0072 u+002D u+006D
- u+006F u+006E u+006B u+0065 u+0079 u+0073
- DUDE: x58jupu8nuy6gt99m-yssctqtptn-tmgftfth-trcbfqtnk
-
- (P) maji<de>koi<suru>5<byou><mae> (Latin, hiragana, kanji)
- u+006D u+0061 u+006A u+0069 u+3067 u+006B u+006F u+0069 u+3059
- u+308B u+0035 u+79D2 u+524D
- DUDE: pnmdvssqvssnegvsva7cvs5qz38hu53r
-
- (Q) <pafii>de<runba> (Latin, katakana)
- u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0
- DUDE: vs5bezgxrvs3ibvs2qtiud
-\f
- (R) <sono><supiido><de> (hiragana, katakana)
- u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067
- DUDE: vsvpvd7hypuivf4q
-
-8. Security considerations
-
- Users expect each domain name in DNS to be controlled by a single
- authority. If a Unicode string intended for use as a domain label
- could map to multiple ACE labels, then an internationalized domain
- name could map to multiple ACE domain names, each controlled by
- a different authority, some of which could be spoofs that hijack
- service requests intended for another. Therefore DUDE is designed
- so that each Unicode string has a unique encoding.
-
- However, there can still be multiple Unicode representations of the
- "same" text, for various definitions of "same". This problem is
- addressed to some extent by the Unicode standard under the topic of
- canonicalization, and this work is leveraged for domain names by
- "nameprep" [NAMEPREP03].
-
-9. References
-
- [IDN] Internationalized Domain Names (IETF working group),
- http://www.i-d-n.net/, idn@ops.ietf.org.
-
- [IDNA] Patrik Faltstrom, Paul Hoffman, "Internationalizing Host
- Names In Applications (IDNA)", draft-ietf-idn-idna-01.
-
- [NAMEPREP03] Paul Hoffman, Marc Blanchet, "Preparation
- of Internationalized Host Names", 2001-Feb-24,
- draft-ietf-idn-nameprep-03.
-
- [RFC952] K. Harrenstien, M. Stahl, E. Feinler, "DOD Internet Host
- Table Specification", 1985-Oct, RFC 952.
-
- [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
- 1987-Nov, RFC 1034.
-
- [RFC1123] Internet Engineering Task Force, R. Braden (editor),
- "Requirements for Internet Hosts -- Application and Support",
- 1989-Oct, RFC 1123.
-
- [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", 1997-Mar, RFC 2119.
-
- [SFS] David Mazieres et al, "Self-certifying File System",
- http://www.fs.net/.
-
- [UNICODE] The Unicode Consortium, "The Unicode Standard",
- http://www.unicode.org/unicode/standard/standard.html.
-
-A. Acknowledgements
-
- The basic encoding of integers to quartets to quintets to base-32
- comes from earlier IETF work by Martin Duerst. DUDE uses a slight
- variation on the idea.
-\f
- Paul Hoffman provided helpful comments on this document.
-
- The idea of avoiding 0, 1, o, and l in base-32 strings was taken
- from SFS [SFS].
-
-B. Author contact information
-
- Mark Welter <mwelter@walid.com>
- Brian W. Spolarich <briansp@walid.com>
- WALID, Inc.
- State Technology Park
- 2245 S. State St.
- Ann Arbor, MI 48104
- +1 734 822 2020
-
- Adam M. Costello <amc@cs.berkeley.edu>
- University of California, Berkeley
- http://www.cs.berkeley.edu/~amc/
-
-C. Mixed-case annotation
-
- In order to use DUDE to represent case-insensitive Unicode strings,
- higher layers need to case-fold the Unicode strings prior to DUDE
- encoding. The encoded string can, however, use mixed-case base-32
- (rather than all-lowercase or all-uppercase as recommended in
- section 4 "Base-32 characters") as an annotation telling how to
- convert the folded Unicode string into a mixed-case Unicode string
- for display purposes.
-
- Each Unicode code point (unless it is U+002D hyphen-minus) is
- represented by a sequence of base-32 characters, the last of which
- is always a letter (as opposed to a digit). If that letter is
- uppercase, it is a suggestion that the Unicode character be mapped
- to uppercase (if possible); if the letter is lowercase, it is a
- suggestion that the Unicode character be mapped to lowercase (if
- possible).
-
- DUDE encoders and decoders are not required to support these
- annotations, and higher layers need not use them.
-
- Example: In order to suggest that example O in section 7 "Example
- strings" be displayed as:
-
- <amuro><namie>-with-SUPER-MONKEYS
-
- one could capitalize the DUDE encoding as:
-
- x58jupu8nuy6gt99m-yssctqtptn-tMGFtFtH-tRCBFQtNK
-
-D. Differences from draft-ietf-idn-dude-01
-
- Four changes have been made since draft-ietf-idn-dude-01 (DUDE-01):
-
- 1) DUDE-01 computed the XOR of each integer with the previous one
- in order to decide how many bits of each integer to encode, but
- now the XOR itself is encoded, so there is no need for a mask.
-\f
- 2) DUDE-01 made the first quintet of each sequence different from
- the rest, while now it is the last quintet that differs, so it's
- easier for the decoder to detect the end of the sequence.
-
- 3) The base-32 map has changed to avoid 0, 1, o, and l, to help
- humans avoid transcription errors.
-
- 4) The initial value of the previous code point has changed from 0
- to 0x60, making the encodings of a few domain names shorter and
- none longer.
-
-
-E. Example implementation
-
-
-
-/******************************************/
-/* dude.c 0.2.3 (2001-May-31-Thu) */
-/* Adam M. Costello <amc@cs.berkeley.edu> */
-/******************************************/
-
-/* This is ANSI C code (C89) implementing */
-/* DUDE (draft-ietf-idn-dude-02). */
-
-
-/************************************************************/
-/* Public interface (would normally go in its own .h file): */
-
-#include <limits.h>
-
-enum dude_status {
- dude_success,
- dude_bad_input,
- dude_big_output /* Output would exceed the space provided. */
-};
-
-enum case_sensitivity { case_sensitive, case_insensitive };
-
-#if UINT_MAX >= 0x1FFFFF
-typedef unsigned int u_code_point;
-#else
-typedef unsigned long u_code_point;
-#endif
-
-enum dude_status dude_encode(
- unsigned int input_length,
- const u_code_point input[],
- const unsigned char uppercase_flags[],
- unsigned int *output_size,
- char output[] );
-\f
- /* dude_encode() converts Unicode to DUDE (without any */
- /* signature). The input must be represented as an array */
- /* of Unicode code points (not code units; surrogate pairs */
- /* are not allowed), and the output will be represented as */
- /* null-terminated ASCII. The input_length is the number of code */
- /* points in the input. The output_size is an in/out argument: */
- /* the caller must pass in the maximum number of characters */
- /* that may be output (including the terminating null), and on */
- /* successful return it will contain the number of characters */
- /* actually output (including the terminating null, so it will be */
- /* one more than strlen() would return, which is why it is called */
- /* output_size rather than output_length). The uppercase_flags */
- /* array must hold input_length boolean values, where nonzero */
- /* means the corresponding Unicode character should be forced */
- /* to uppercase after being decoded, and zero means it is */
- /* caseless or should be forced to lowercase. Alternatively, */
- /* uppercase_flags may be a null pointer, which is equivalent */
- /* to all zeros. The encoder always outputs lowercase base-32 */
- /* characters except when nonzero values of uppercase_flags */
- /* require otherwise. The return value may be any of the */
- /* dude_status values defined above; if not dude_success, then */
- /* output_size and output may contain garbage. On success, the */
- /* encoder will never need to write an output_size greater than */
- /* input_length*k+1 if all the input code points are less than 1 */
- /* << (4*k), because of how the encoding is defined. */
-
-enum dude_status dude_decode(
- enum case_sensitivity case_sensitivity,
- char scratch_space[],
- const char input[],
- unsigned int *output_length,
- u_code_point output[],
- unsigned char uppercase_flags[] );
-\f
- /* dude_decode() converts DUDE (without any signature) to */
- /* Unicode. The input must be represented as null-terminated */
- /* ASCII, and the output will be represented as an array of */
- /* Unicode code points. The case_sensitivity argument influences */
- /* the check on the well-formedness of the input string; it */
- /* must be case_sensitive if case-sensitive comparisons are */
- /* allowed on encoded strings, case_insensitive otherwise. */
- /* The scratch_space must point to space at least as large */
- /* as the input, which will get overwritten (this allows the */
- /* decoder to avoid calling malloc()). The output_length is */
- /* an in/out argument: the caller must pass in the maximum */
- /* number of code points that may be output, and on successful */
- /* return it will contain the actual number of code points */
- /* output. The uppercase_flags array must have room for at */
- /* least output_length values, or it may be a null pointer if */
- /* the case information is not needed. A nonzero flag indicates */
- /* that the corresponding Unicode character should be forced to */
- /* uppercase by the caller, while zero means it is caseless or */
- /* should be forced to lowercase. The return value may be any */
- /* of the dude_status values defined above; if not dude_success, */
- /* then output_length, output, and uppercase_flags may contain */
- /* garbage. On success, the decoder will never need to write */
- /* an output_length greater than the length of the input (not */
- /* counting the null terminator), because of how the encoding is */
- /* defined. */
-
-
-/**********************************************************/
-/* Implementation (would normally go in its own .c file): */
-
-#include <string.h>
-
-/* Character utilities: */
-
-/* base32[q] is the lowercase base-32 character representing */
-/* the number q from the range 0 to 31. Note that we cannot */
-/* use string literals for ASCII characters because an ANSI C */
-/* compiler does not necessarily use ASCII. */
-
-static const char base32[] = {
- 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, /* a-k */
- 109, 110, /* m-n */
- 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, /* p-z */
- 50, 51, 52, 53, 54, 55, 56, 57 /* 2-9 */
-};
-
-/* base32_decode(c) returns the value of a base-32 character, in the */
-/* range 0 to 31, or the constant base32_invalid if c is not a valid */
-/* base-32 character. */
-\f
-enum { base32_invalid = 32 };
-
-static unsigned int base32_decode(char c)
-{
- if (c < 50) return base32_invalid;
- if (c <= 57) return c - 26;
- if (c < 97) c += 32;
- if (c < 97 || c == 108 || c == 111 || c > 122) return base32_invalid;
- return c - 97 - (c > 108) - (c > 111);
-}
-
-/* unequal(case_sensitivity,s1,s2) returns 0 if the strings s1 and s2 */
-/* are equal, 1 otherwise. If case_sensitivity is case_insensitive, */
-/* then ASCII A-Z are considered equal to a-z respectively. */
-
-static int unequal( enum case_sensitivity case_sensitivity,
- const char s1[], const char s2[] )
-{
- char c1, c2;
-
- if (case_sensitivity != case_insensitive) return strcmp(s1,s2) != 0;
-
- for (;;) {
- c1 = *s1;
- c2 = *s2;
- if (c1 >= 65 && c1 <= 90) c1 += 32;
- if (c2 >= 65 && c2 <= 90) c2 += 32;
- if (c1 != c2) return 1;
- if (c1 == 0) return 0;
- ++s1, ++s2;
- }
-}
-
-
-/* Encoder: */
-
-enum dude_status dude_encode(
- unsigned int input_length,
- const u_code_point input[],
- const unsigned char uppercase_flags[],
- unsigned int *output_size,
- char output[] )
-{
- unsigned int max_out, in, out, k, j;
- u_code_point prev, codept, diff, tmp;
- char shift;
-
- prev = 0x60;
- max_out = *output_size;
-
- for (in = out = 0; in < input_length; ++in) {
-
- /* At the start of each iteration, in and out are the number of */
- /* items already input/output, or equivalently, the indices of */
- /* the next items to be input/output. */
-\f
- codept = input[in];
-
- if (codept == 0x2D) {
- /* Hyphen-minus stands for itself. */
- if (max_out - out < 1) return dude_big_output;
- output[out++] = 0x2D;
- continue;
- }
-
- diff = prev ^ codept;
-
- /* Compute the number of base-32 characters (k): */
- for (tmp = diff >> 4, k = 1; tmp != 0; ++k, tmp >>= 4);
-
- if (max_out - out < k) return dude_big_output;
- shift = uppercase_flags && uppercase_flags[in] ? 32 : 0;
- /* shift controls the case of the last base-32 digit. */
-
- /* Each quintet has the form 1xxxx except the last is 0xxxx. */
- /* Computing the base-32 digits in reverse order is easiest. */
-
- out += k;
- output[out - 1] = base32[diff & 0xF] - shift;
-
- for (j = 2; j <= k; ++j) {
- diff >>= 4;
- output[out - j] = base32[0x10 | (diff & 0xF)];
- }
-
- prev = codept;
- }
-
- /* Append the null terminator: */
- if (max_out - out < 1) return dude_big_output;
- output[out++] = 0;
-
- *output_size = out;
- return dude_success;
-}
-
-
-/* Decoder: */
-
-enum dude_status dude_decode(
- enum case_sensitivity case_sensitivity,
- char scratch_space[],
- const char input[],
- unsigned int *output_length,
- u_code_point output[],
- unsigned char uppercase_flags[] )
-{
- u_code_point prev, q, diff;
- char c;
- unsigned int max_out, in, out, scratch_size;
- enum dude_status status;
-
- prev = 0x60;
- max_out = *output_length;
-\f
- for (c = input[in = 0], out = 0; c != 0; c = input[++in], ++out) {
-
- /* At the start of each iteration, in and out are the number of */
- /* items already input/output, or equivalently, the indices of */
- /* the next items to be input/output. */
-
- if (max_out - out < 1) return dude_big_output;
-
- if (c == 0x2D) output[out] = c; /* hyphen-minus is literal */
- else {
- /* Base-32 sequence. Decode quintets until 0xxxx is found: */
-
- for (diff = 0; ; c = input[++in]) {
- q = base32_decode(c);
- if (q == base32_invalid) return dude_bad_input;
- diff = (diff << 4) | (q & 0xF);
- if (q >> 4 == 0) break;
- }
-
- prev = output[out] = prev ^ diff;
- }
-
- /* Case of last character determines uppercase flag: */
- if (uppercase_flags) uppercase_flags[out] = c >= 65 && c <= 90;
- }
-
- /* Enforce the uniqueness of the encoding by re-encoding */
- /* the output and comparing the result to the input: */
-
- scratch_size = ++in;
- status = dude_encode(out, output, uppercase_flags,
- &scratch_size, scratch_space);
- if (status != dude_success || scratch_size != in ||
- unequal(case_sensitivity, scratch_space, input)
- ) return dude_bad_input;
-
- *output_length = out;
- return dude_success;
-}
-
-
-/******************************************************************/
-/* Wrapper for testing (would normally go in a separate .c file): */
-
-#include <assert.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-/* For testing, we'll just set some compile-time limits rather than */
-/* use malloc(), and set a compile-time option rather than using a */
-/* command-line option. */
-\f
-enum {
- unicode_max_length = 256,
- ace_max_size = 256,
- test_case_sensitivity = case_insensitive
- /* suitable for host names */
-};
-
-
-static void usage(char **argv)
-{
- fprintf(stderr,
- "%s -e reads code points and writes a DUDE string.\n"
- "%s -d reads a DUDE string and writes code points.\n"
- "Input and output are plain text in the native character set.\n"
- "Code points are in the form u+hex separated by whitespace.\n"
- "A DUDE string is a newline-terminated sequence of LDH characters\n"
- "(without any signature).\n"
- "The case of the u in u+hex is the force-to-uppercase flag.\n"
- , argv[0], argv[0]);
- exit(EXIT_FAILURE);
-}
-
-
-static void fail(const char *msg)
-{
- fputs(msg,stderr);
- exit(EXIT_FAILURE);
-}
-
-static const char too_big[] =
- "input or output is too large, recompile with larger limits\n";
-static const char invalid_input[] = "invalid input\n";
-static const char io_error[] = "I/O error\n";
-
-
-/* The following string is used to convert LDH */
-/* characters between ASCII and the native charset: */
-
-static const char ldh_ascii[] =
- "................"
- "................"
- ".............-.."
- "0123456789......"
- ".ABCDEFGHIJKLMNO"
- "PQRSTUVWXYZ....."
- ".abcdefghijklmno"
- "pqrstuvwxyz";
-
-
-int main(int argc, char **argv)
-{
- enum dude_status status;
- int r;
- char *p;
-
- if (argc != 2) usage(argv);
- if (argv[1][0] != '-') usage(argv);
- if (argv[1][2] != 0) usage(argv);
-\f
- if (argv[1][1] == 'e') {
- u_code_point input[unicode_max_length];
- unsigned long codept;
- unsigned char uppercase_flags[unicode_max_length];
- char output[ace_max_size], uplus[3];
- unsigned int input_length, output_size, i;
-
- /* Read the input code points: */
-
- input_length = 0;
-
- for (;;) {
- r = scanf("%2s%lx", uplus, &codept);
- if (ferror(stdin)) fail(io_error);
- if (r == EOF || r == 0) break;
-
- if (r != 2 || uplus[1] != '+' || codept > (u_code_point)-1) {
- fail(invalid_input);
- }
-
- if (input_length == unicode_max_length) fail(too_big);
-
- if (uplus[0] == 'u') uppercase_flags[input_length] = 0;
- else if (uplus[0] == 'U') uppercase_flags[input_length] = 1;
- else fail(invalid_input);
-
- input[input_length++] = codept;
- }
-
- /* Encode: */
-
- output_size = ace_max_size;
- status = dude_encode(input_length, input, uppercase_flags,
- &output_size, output);
- if (status == dude_bad_input) fail(invalid_input);
- if (status == dude_big_output) fail(too_big);
- assert(status == dude_success);
-
- /* Convert to native charset and output: */
-
- for (p = output; *p != 0; ++p) {
- i = *p;
- assert(i <= 122 && ldh_ascii[i] != '.');
- *p = ldh_ascii[i];
- }
-
- r = puts(output);
- if (r == EOF) fail(io_error);
- return EXIT_SUCCESS;
- }
-
- if (argv[1][1] == 'd') {
- char input[ace_max_size], scratch[ace_max_size], *pp;
- u_code_point output[unicode_max_length];
- unsigned char uppercase_flags[unicode_max_length];
- unsigned int input_length, output_length, i;
-\f
- /* Read the DUDE input string and convert to ASCII: */
-
- fgets(input, ace_max_size, stdin);
- if (ferror(stdin)) fail(io_error);
- if (feof(stdin)) fail(invalid_input);
- input_length = strlen(input);
- if (input[input_length - 1] != '\n') fail(too_big);
- input[--input_length] = 0;
-
- for (p = input; *p != 0; ++p) {
- pp = strchr(ldh_ascii, *p);
- if (pp == 0) fail(invalid_input);
- *p = pp - ldh_ascii;
- }
-
- /* Decode: */
-
- output_length = unicode_max_length;
- status = dude_decode(test_case_sensitivity, scratch, input,
- &output_length, output, uppercase_flags);
- if (status == dude_bad_input) fail(invalid_input);
- if (status == dude_big_output) fail(too_big);
- assert(status == dude_success);
-
- /* Output the result: */
-
- for (i = 0; i < output_length; ++i) {
- r = printf("%s+%04lX\n",
- uppercase_flags[i] ? "U" : "u",
- (unsigned long) output[i] );
- if (r < 0) fail(io_error);
- }
-
- return EXIT_SUCCESS;
- }
-
- usage(argv);
- return EXIT_SUCCESS; /* not reached, but quiets compiler warning */
-}
-
-
-
- INTERNET-DRAFT expires 2001-Dec-07
+++ /dev/null
-Internet Draft Patrik Faltstrom
-draft-ietf-idn-idna-03.txt Cisco
-July 20, 2001 Paul Hoffman
-Expires in six months IMC & VPNC
-
- Internationalizing Host Names In Applications (IDNA)
-
-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 or resolver that will allow
-internationalized host names to be used by end users with changes only
-to applications. It allows flexibility for user input and display, and
-assures that host names that have non-ASCII characters are not sent to
-DNS servers or resolvers.
-
-
-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 be updated; no changes are
-needed to the DNS protocol or any DNS servers or the resolvers on user's
-computers.
-
-This document is being discussed on the ietf-idna@mail.apps.ietf.org
-mailing list. To subscribe, send a message to
-ietf-idna-request@mail.apps.ietf.org with the single word "subscribe" in
-the body of the message.
-
-1.1 Design philosophy
-
-Many 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.
-
-These proposals would require that the application protocols that use
-host names as protocol elements to change. This is due to the
-assumptions and requirements made in those protocols about the
-characters that have always been used for host names, and the encoding
-of those characters. Other proposals for IDN protocols do not require
-changes to DNS servers but still require changes to most application
-protocols to handle the new names.
-
-Updating all (or even a significant percentage) of the existing servers
-in the world will be difficult, to say the least. Updating applications,
-application gateways, and clients to handle changes to the application
-protocols is also daunting. Because of this, we have designed a protocol
-that requires no updating of any name servers. IDNA still requires the
-updating of applications, but only for input and display of names, not
-for changes to the protocols. Once a user has updated these, she or he
-could immediately start using internationalized host names. The cost of
-implementing IDN may thus be much lower, and the speed of implementation
-could be much higher.
-
-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].
-
-
-2. Structural Overview
-
-In IDNA, users' applications 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 IDNA
-
-The interfaces in IDNA can be represented pictorially as:
-
- +------+
- | User |
- +------+
- ^
- |Input and display: local interface methods
- |(pen, keyboard, glowing phosphorus, ...)
- +-----------------|------------------------------+
- | v |
- | +--------------------------+ |
- | | Application | |
- | +--------------------------+ |
- | ^ ^ |
- | Call to resolver:| |Application-specific |
- | nameprepped ACE| |protocol: |
- | v |predefined by the | End system
- | +----------+ |protocol or defaults |
- | | Resolver | |to nameprepped ACE |
- | +----------+ | |
- | ^ | |
- +---------------|----------|---------------------+
- DNS protocol:| |
- nameprepped ACE| |
- v v
- +-------------+ +---------------------+
- | DNS servers | | Application servers |
- +-------------+ +---------------------+
-
-This document uses the generic term "ACE" for an ASCII-compatible
-encoding. After the IDN Working Group has chosen a specific ACE, this
-document will be updated to refer to just that single ACE. Until that
-time, an implementor creating experimental software must choose an ACE
-to use, such as RACE or LACE or DUDE.
-
-2.1.1 Entry and display in 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 IDNA-aware application can accept and display internationalized host
-names in two formats: the internationalized character set(s) supported
-by the application, and in an ACE. Applications MAY allow ACE input and
-output, but are not encouraged to do so except as an interface for
-special purposes, possibly for debugging. ACE 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 ACE
-encodings in the user interface is described in section 3. Because name
-parts encoded with ACE can be rendered either as the encoded ASCII
-characters or the proper decoded characters, the application MAY have an
-option for the user to select the preferred method of display; if it
-does, rendering the ACE SHOULD NOT be the default.
-
-Host names are often stored and transported in many places. For example,
-they are part of documents such as mail messages and web pages. They are
-transported in the many parts of many protocols, such as both the
-control commands and the RFC 2822 body parts of SMTP, and the headers
-and the body content in HTTP.
-
-In protocols and document formats that define how to handle
-specification or negotiation of charsets, IDN host name parts can be
-encoded in any charset allowed by the protocol or document format. If a
-protocol or document format only allows one charset, IDN host name parts
-must be given in that charset. In any place where a protocol or document
-format allows transmition of the characters in IDN host name parts, IDN
-host name parts SHOULD be transmitted using whatever character encoding
-and escape mechanism that the protocol or document format uses at that
-place.
-
-All protocols that have host names as protocol elements already have the
-capacity for handling host names in the ASCII charset. Thus, IDN host
-name parts can be specified in those protocols in the ACE charset, which
-is a superset of the ASCII charset that uses the same set of octets.
-
-2.1.2 Applications and resolvers
-
-Applications communicate with resolver libraries through a programming
-interface (API). Typically, the IETF does not standardize APIs, although
-there are non-standard APIs specified 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.
-
-Before converting the name parts into ACE, the application MUST prepare
-each name part as specified in [NAMEPREP]. The application MUST use ACE
-for the name parts that are sent to the resolver, and will always get
-name parts encoded in ACE from the resolver.
-
-IDNA-aware applications MUST be able to work with both
-non-internationalized host name parts (those that conform to [STD13] and
-[STD3]) and internationalized host name parts. An IDNA-aware application
-that is resolving a non-internationalized host name part MUST NOT do
-any preparation or conversion to ACE on any non-internationalized name
-part.
-
-2.1.3 Resolvers and DNS servers
-
-An operating system might have a set of libraries for converting host
-names to nameprepped ACE. The input to such a library might be in one or
-more charsets that are used in applications (UTF-8 and UTF-16 are likely
-candidates for almost any operating system, and script-specific charsets
-are likely for localized operating systems). The output would be either
-the unchanged name part (if the input already conforms to [STD13] and
-[STD3]), or the nameprepped, ACE-encoded name part.
-
-DNS servers MUST use the ACE 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 ACE 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.
-
-2.1.4 Avoiding exposing users to the raw ACE encoding
-
-All applications that might show the user a host name that was received
-from a gethostbyaddr or other such lookup SHOULD update as soon as
-possible in order to prevent users from seeing the ACE. However, this is
-not considered a big problem because so few applications show this type
-of resolution to users.
-
-If an application decodes an ACE name but cannot show all of the
-characters in the decoded name, such as if the name contains characters
-that the output system cannot display, the application SHOULD show the
-name in ACE format instead of displaying the name with the replacement
-character (U+FFFD). This is to make it easier for the user to transfer
-the name correctly to other programs. Programs that by default show the
-ACE form when they cannot show all the characters in a name part SHOULD
-also have a mechanism to show the name with as many characters as
-possible and replacement characters in the positions where characters
-cannot be displayed. In many cases, the application doesn't know exactly
-what the underlying rendering engine can or cannot display.
-
-In addition to the condition above, if an application decodes an ACE
-name but finds that the decoded name was not properly prepared according
-to [NAMEPREP] (for example, if it has illegal characters in it), the
-application SHOULD show the name in ACE format and SHOULD NOT display
-the name in its decoded form. This is to avoid security issues described
-in [NAMEPREP].
-
-2.1.5 Automatic detection of ACE
-
-An application which receives a host name SHOULD verify whether or not
-the host name is in ACE. This is possible by verifying the prefix in
-each of the labels, and seeing whether or not the label is in ACE. This
-MUST be done regardless of whether or not the communication channel used
-(such as keyboard input, cut and paste, application protocol,
-application payload, and so on) is encoding with ACE.
-
-The reason for this requirement is that many applications are not
-ACE-aware. Applications that are not ACE-aware will send host names in
-ACE but mark the charset as being US-ASCII or some other charset which
-has the characters that are valid in [STD13] as a subset.
-
-2.1.6 Bidirectional text
-
-In IDNA, text storage and display follows the rules in the Unicode standard
-[Unicode3.1]. In particular, all Unicode text is stored in logical order;
-the Unicode standard has an extensive discussion of how to deal with reorder
-glyphs for display when dealing with bidirectional text such as Arabic or
-Hebrew. See [UAX9] for more information.
-
-
-3. Name Server Considerations
-
-It is imperative that there be only one encoding for a particular host
-name. ACE is an encoding for host name parts that use characters outside
-those allowed for host names [STD13]. Thus, a primary master name server
-MUST NOT contain an ACE-encoded name that decodes to a host name that is
-allowed in [STD13] and [STD3].
-
-Name servers MUST NOT have any records with host names that contain
-internationalized name parts unless those name parts have be prepared
-according to [NAMEPREP]. If names that are not legal in [NAMEPREP] are
-passed to an application, it will result in an error being passed to the
-application with no error being reported to the name server. Further, no
-application will ever ask for a name that is not legal in [NAMEPREP]
-because requests always go through [NAMEPREP] before getting to the DNS.
-Note that [NAMEPREP] describes how to handle versioning of unallocated
-codepoints.
-
-The host name data in zone files (as specified by section 5 of RFC 1035)
-MUST be both nameprepped and ACE encoded.
-
-
-4. Root Server Considerations
-
-Because there are no changes to the DNS protocols, adopting this
-protocol has no effect on the DNS 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.
-
-This memo describes an algorithm which encodes characters that are not
-valid according to STD3 and STD13 into octet values that are valid. No
-security issues such as string length increases or new allowed values
-are introduced by the encoding process or the use of these encoded
-values, apart from those introduced by the ACE encoding itself.
-
-When detecting an ACE-encoded host name, and decoding the ACE, care must
-be taken that the resulting value(s) are valid characters which can be
-handled by the application. This is described in more detail in section
-2.1.4.
-
-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
-
-[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
-Internationalized Host Names", draft-ietf-idn-nameprep.
-
-[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels", March 1997, RFC 2119.
-
-[STD3] Bob Braden, "Requirements for Internet Hosts -- Communication
-Layers" (RFC 1122) and "Requirements for Internet Hosts -- Application
-and Support" (RFC 1123), STD 3, October 1989.
-
-[STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
-1034) and "Domain names - implementation and specification" (RFC 1035,
-STD 13, November 1987.
-
-[UAX9] Unicode Standard Annex #9, The Bidirectional Algorithm.
-http://www.unicode.org/unicode/reports/tr9/
-
-[Unicode3.1] The Unicode Standard, Version 3.1.0: The Unicode
-Consortium. The Unicode Standard, Version 3.0. Reading, MA,
-Addison-Wesley Developers Press, 2000. ISBN 0-201-61633-5, as amended
-by: Unicode Standard Annex #27: Unicode 3.1
-<http://www.unicode.org/unicode/reports/tr27/tr27-4.html>.
-
-
-
-B. Changes from the -02 draft
-
-Editorial changes throughout
-
-2.1.1: Major changes to the second paragraph. Added major text to fourth
-paragraph.
-
-2.1.4: Added to the end of the second paragraph. Added the third
-paragraph.
-
-2.1.6: Complete change.
-
-6: Added [Unicode3.1] and [UAX9].
-
-
-C. Authors' Addresses
-
-Patrik Faltstrom
-Cisco Systems
-Arstaangsvagen 31 J
-S-117 43 Stockholm Sweden
-paf@cisco.com
-
-Paul Hoffman
-Internet Mail Consortium and VPN Consortium
-127 Segre Place
-Santa Cruz, CA 95060 USA
-phoffman@imc.org
\ No newline at end of file
+++ /dev/null
-Internet Draft Marc Blanchet
-draft-ietf-idn-idne-02.txt Viagenie
-March 19, 2001 Paul Hoffman
-Expires in six months IMC & VPNC
-
- Internationalized domain names using EDNS (IDNE)
-
-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 domain names (IDN). This document describes an
-extension mechanism based on EDNS which enables the use of IDN without
-causing harm to the current DNS. IDNE enables IDN host names with a as
-many characters as current ASCII-only host names. It fully supports
-UTF-8 and conforms to the IDN requirements.
-
-
-1. Introduction
-
-Various proposals for IDN have tried to integrate IDN into the current
-limited ASCII DNS. However, the compatibility issues make too many
-constraints on the architecture. Many of these proposals require
-modifications to the applications or to the DNS protocol or to the
-servers. This proposal take a different approach: it uses the
-standardized extension mechanism for DNS (EDNS) and uses UTF-8 as the
-mandatory charset. It causes no harm to the current DNS because it uses
-the EDNS extension mechanism. The major drawback of this proposal is
-that all protocols, applications and DNS servers will have to be
-upgraded to support this proposal.
-
-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 [ISO10646] names. For example, the
-letter "a" may be represented as either "U+0061" or "LATIN SMALL LETTER
-A". In the lists of prohibited characters, the "U+" is left off to make
-the lists easier to read.
-
-1.2 IDN summary
-
-Using the terminology in [IDNCOMP], this protocol specifies an IDN
-architecture of arch-2 (send binary or ACE). The binary format is
-bin-1.1 (UTF-8), and the method for distinguishing binary from current
-names is bin-2.4 (mark binary with EDNS0). The transition period is not
-specified.
-
-
-2. Functional Description
-
-DNS query and responses containing IDNE labels have the following
-properties:
-
-- The string in the label MUST be pre-processed as described in
-[NAMEPREP] before the query or response is prepared.
-
-- The characters in the label MUST be encoded using UTF-8 [RFC2279].
-
-- The entire label MUST be encoded EDNS [RFC2671].
-
-- The version of the IDN protocol MUST be identified.
-
-
-3. Encoding
-
-An IDNE label uses the EDNS extended label type prefix (0b01), as
-described in [RFC2671]. (A normal label type always begin with 0b00). A
-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
-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 ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
-
-
-ELT: The six-bit extended label type to be assigned by the IANA for an
-IDN label. In this document, the value 0b000010 is used, although that
-might be changed by IANA.
-
-Size: Size (in octets) of the IDN label following. This MUST NOT
-be zero.
-
-IDN label: Label, encoded in UTF-8 [RFC2279]. Note that this label might
-contain all ASCII characters, and thus can be used for host name labels
-that are legal in [STD13].
-
-IDNE labels can be mixed with STD13 labels in a domain name.
-
-The compression scheme in section 4.1.4 of [STD13] is supported as is.
-Pointers can refer to either IDN labels or non-IDN labels.
-
-3.1 Examples
-
-3.1.1 Basic example
-
-The following example shows the label me.com where the "e" in "me" is
-replaced by a <LATIN CAPITAL LETTER E WITH ACUTE>, which is U+00C9. The
-decomposition and downcasing specified in [NAMEPREP] changes the second
-character to <LATIN SMALL LETTER E WITH ACUTE>, U+00E9. This string is
-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 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Octet 20 means EDNS extended label type (0b01) using the IDN label
- 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
-Octet 29 is the root domain
-
-3.1.2 Example with compression
-
-Using the previous labels, one datagram might contain "www.m*.com" and
-"m*.com" (where the "*" is <LATIN CAPITAL LETTER E WITH ACUTE>).
-
-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 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-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
-concatenate a label for www to the previously defined "m*.com".
-
-
-4. Label Size
-
-In IDNE, the maximum length of a label is 255 octets, and the maximum
-size for a domain name is 1023 octets. The reason for using these values
-is so that IDNE labels can have the same number of characters as the
-ASCII-based labels in [STD13]. Because character encoding in UTF-8 is
-variable length, the maximum octet length for characters expected in the
-foreseeable future (that is, 4 octets for a single character) was used.
-Note that this extension allows some IDNE labels to be longer than 63
-characters and some IDNE names to be longer than 255 octets.
-
-Software creating DNS queries or responses using IDNE MUST verify that,
-after IDN preparation and transformation to UTF8, that no labels are
-longer than 255 octets and that no names are longer than 1023 octets. If
-there is a user interface associated with the process creating the query
-or response, that interface SHOULD give the user an error message.
-
-Software MUST NOT transmit DNS queries or responses which contain labels
-that are longer than 255 octets or names that are longer than 1023
-octets. Servers MUST NOT accept DNS queries or responses which contain
-labels that are longer than 255 octets or names that are longer than
-1023 octets, and MUST send the NOTIMPL RCODE error message if such
-queries or responses are received.
-
-
-5. UDP Packet Size
-
-IDNE-capable senders and receivers MUST support UDP packet sizes of 1220
-octets, not including IP and UDP headers (note that the minimum MTU for
-IPv6 is 1280 [RFC2460]). A sender MUST announce its capability in the
-OPT pseudo-RR described in section 4.3 of [RFC2671] by having the CLASS
-sender's UDP payload size be greater than or equal to 1220.
-
-
-6. Canonalization, Prohibited Characters, and Case Folding
-
-The string in the label MUST be pre-processed as described in [NAMEPREP]
-before the query or response is prepared. A query or response MUST NOT
-contain a label that does not conform to [NAMEPREP].
-
-
-7. Versions of IDNE
-
-The IDN protocol version number MUST be included in the OPT RR RDATA of
-EDNS (described in Section 4.4 of [RFC2671]). An OPTION-CODE will be
-assigned by IANA for storing the IDNE protocol version number; this
-document uses 0x0001 for the OPTION-CODE. The value (that
-is, the OPTION-DATA) is the version number coded in 8 bits.
-
-All requesters MUST send this information as part of the OPT RR included
-in the EDNS packet.
-
-7.1 This version of IDNE
-
-This document describes version 1 of IDNE. This version is a combination
-of the protocol in this document and the rules as described in
-[NAMEPREP]. Note that [NAMEPREP] describes a single version of the list
-of canonicalization, case folding, and prohibited characters, and that
-this document is linked to that single version of [NAMEPREP].
-
-The identifiers for this specification are:
-OPTION-CODE = 0x0001 (IDNE protocol version)
-OPTION-LENGTH = 0x0001 (1 octet following)
-OPTION-DATA = 0x01 (IDNE protocol version 1)
-
-7.2 Creating new versions of IDNE
-
-A new version of IDNE is created by a standards-track RFC that
-specifies:
-
-- a normative reference to [NAMEPREP] or a successor document to
-[NAMEPREP]
-
-- an IDNE version number that is 1 greater than the highest IDNE version
-number at the time the RFC is published
-
-If there are any changes to the encoding or interpretation of the
-protocol, they must also be specified in the same standards-track RFC.
-
-7.3 Prohibited characters and versions of IDNE
-
-If a server receives a request containing an illegal or unknown
-character (as described in the version number in the request), it MUST
-send a NOTIMPL RCODE to the client. For example, if a server that
-understands both version 1 and version 2 receives a request that is
-marked as version 1, but contains a label that includes a character that
-is prohibited in version 1 but allowed in version 2, that server must
-still send a NOTIMPL RCODE to the client.
-
-
-8. API Specifications
-
-The current API for TCP/IP uses gethostbyname and gethostbyaddr for IPv4
-and getnodeipbyname and getnodeipbyaddr (specified in [RFC 2671]) for
-both IPv4 and IPv6. These function calls returns hostent structs, where
-the h_name field contains a pointer to a char. In this context,
-receiving a UTF-8 string mean that the application should know that
-UTF-8 uses more than one octet per char.
-
-A new flag "IDN" (to appear in netdb.h) is defined to be passed in the
-flags argument of getnodeipbynode and getnodeipbyaddr. This flag tells
-the resolver to request an IDNE-encoded name. No new return code is
-defined since the returned codes in RFC 2671 are meaningful in the IDNE
-context.
-
-If one has not yet converted his code to IPv6 and still wants to enable
-IDNs with this API, one can do a macro of the getnodeipby* functions
-mapped to the IPv4 gethostby* ones, including the "IDN" flag, and then
-process differently based on the presence of the flag.
-
-
-9. Transition and Deployment
-
-Deployment of this proposal means updating clients and servers, as well
-as applications and protocols, and therefore a transition strategy is
-proposed. Because many DNS servers do not yet handle IDNE and may take
-years or decades to do so, an ASCII-compatible encoding (ACE) format for
-IDN names is also needed as a transition to an all-IDNE DNS. Note that
-IDNE and an ACE are not related, and do not interact in the DNS. If the
-IETF chooses to have an ACE mechanism in use at the same time as IDNE,
-it would be wise to choose an ACE that allows as many characters as
-possible in the name parts and full names.
-
-IDNE allows names with as many characters as current names. This means
-that it is possible to create names in IDNE that are longer than those
-that can be created in the ACE protocols that have been described so
-far. Although not prohibited, it is unwise to create a name that can be
-legally represented in IDNE but not in the ACE, or a name that can be
-legally represented in the ACE but not in IDNE.
-
-The IETF should periodically evaluate the benefits and problems
-associated with having three different formats for names (STD13, IDNE,
-and ACE). If at some point it is decided that the problems outweigh the
-benefits, the IETF can state a time when one or more of the services
-should not be used on the Internet.
-
-
-10. Root Server Considerations
-
-Because this specification uses EDNS, root servers should be prepared to
-receive EDNS requests. This specification handles IDN top-level domains
-in exactly the same fashion as it does every other domain.
-Considerations about IDN top-level domains are outside of this work, but
-the first IDN top-level domains would require all root servers to be
-ready for IDNE requests.
-
-
-11. IANA Considerations
-
-[[ TBD. This section will have two parts. The first will request an EDNS
-option code. The second will specify how IDNE version numbers are
-allocated (namely, standards-track RFC only). ]]
-
-
-12. Security Considerations
-
-Because IDNE uses EDNS, it inherits the same security considerations as
-EDNS.
-
-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] and [RFC2671],
-it includes the security considerations from those documents as well.
-
-
-13. References
-
-[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
-Proposals", draft-ietf-idn-compare.
-
-[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. [[[ THIS REFERENCE NEEDS TO BE
-UPDATED AFTER DETERMINING ACCEPTABLE WORDING ]]]
-
-[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
-Internationalized Host Names", draft-ietf-idn-nameprep.
-
-[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.
-
-[RFC2460] Steve Deering & Bob Hinden, "Internet Protocol, Version 6 (IPv6)
-Specification", December 1998, RFC 2460.
-
-[RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)", August
-1999, RFC 2671.
-
-[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
-
-This document is the result of the thinking of many people. The following
-people made significant comments on the early drafts:
-
-Andre Cormier
-Andrew Draper
-Bill Sommerfeld
-Francois Yergeau
-
-
-B. Changes from -01 to -02
-
-None.
-
-
-C. Authors' Addresses
-
-Marc Blanchet
-Viagenie
-2875 boul. Laurier, bureau 300
-Sainte-Foy, QC G1V 2M2 Canada
-Marc.Blanchet@viagenie.qc.ca
-
-Paul Hoffman
-Internet Mail Consortium and VPN Consortium
-127 Segre Place
-Santa Cruz, CA 95060 USA
-phoffman@imc.org
-
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT Hongbo Shi
-draft-ietf-idn-iptr-02.txt Waseda University
-17 May 2001 Jiang Ming Liang
-Expires: 17 November 2001 i-DNS.net
-
-
- Internationalized PTR Resource Record (IPTR)
-
-
-
-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 draft attempts to address the problem of how an IP address SHOULD
- be properly mapped to a set of Internationalized Domain Names(IDNs).
- It is currently unspecified how a PTR record can be used for this
- purpose. In addition, the syntax of the PTR resource record may be
- too restrictive for such a mapping in a more culturally meaningful
- context. This document suggests a new TYPE called IPTR using EDNS0
- and a mechanism to combined language information with such a mapping.
-
-1. Introduction
-
- Reverse mapping is a very important and essential function in the DNS.
- In today's Domain Name System, PTR RRs are used to support address-
- to-domain mappings. However, a current PTR RR does not provide support
- for proper address-to-IDN mappings, without certain modifications.
- Modifying the PTR structure will also affect the current reverse
-
-
-
-Shi, Jiang [Page 1]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- mapping architecture. This document describes a new RR TYPE named IPTR
- to provide address-to-IDN mappings and it also specifies that on
- receiving of a IPTR query a name server should respond with all the
- corresponding IPTR RRs in one response. In short, "one IP several
- IDNs".
-
-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].
-
-1.2 Background and Designs
-
- When Internationalized Domain Names come into wide use, an Internet
- host is likely to have domain names in different languages. In
- today's Internet, even thought the [RFC2181] redefine the
- consideration of PTR, because of the design of the PTR mapping
- algorithm and implementation of most resolvers, IP address to domain
- names mapping is still limited to "one IP one domain name".
-
- For example, BIND treats PTRs specially so that the normal sorting
- preference (e.g. cyclic/random) doesn't apply. But as usual, "fixed"
- order is always used. So a client that is querying a BIND server and
- doesn't look beyond the first PTR RR, no matter how many times it
- queries the name. In other words, PTR RRset is different from A RRset,
- where the first record in the RRset might differ from query to query.
-
- This is more restrictive in a world of IDNs, for choosing some names
- in a particular language. Briefly, according to the use of PTR, it is
- no meaning of returning an IDN in an unknown language.
-
- The authors also believe that putting language information into
- address-to-name mappings will be benifitial to future applications.
-
- The design purpose of the IPTR RR type is to provide a mechanism that
- can map an IP address to the corresponding IDN per language. It also
- means that IPTR suggests a new mapping algorithm for the reverse
- mapping by using an language information.
-
- CNAME MUST continue to work for IPTR as it works now for PTR records.
-
- The behavior of a resolver on the use of IPTR will be specified in a
- seperate draft or a later version of this draft.
-
-1.3 Functional Description
-
- DNS query and responses involving IPTR type MUST have the following
-
-
-
-Shi, Jiang [Page 2]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- properties:
-
-
- - When the QTYPE is IPTR, the corresponding IDNs SHOULD be
- returned in one response.
-
-
- - The characters in the label MUST be encoded using UTF-8
- [RFC2279].
-
-
- - The entire label MUST be encoded EDNS [RFC2671].
-
-
- - An exceptional handling of PTR for the IDN is REQUIRED.
-
-
-2. IPTR definition
-
- The structure of an IPTR RR is somewhat like the MX RR. In addtion to
- the IP address in the IN-ADDR.ARPA domain and the domain name field
- (similar to a PTR RR), a new field called LANGUAGE has been defined.
- A domain name in an IPTR RR MUST be encoded in UTF8. And IDN in this
- document MUST be NAMEPREPPED. [NAMEPREP] Below is an example of an
- IPTR RR:
-
- 1.2.3.4.IN-ADDR.ARPA. IPTR "LANGUAGE" "name-in-utf8"
-
- [RFC1766] describes the ISO 639/ISO 3166 conventions. A language name
- is always written in lower case, while country codes are written in
- upper case. At here, the "LANGUAGE" field in an IPTR RR SHOULD be done
- in a case-insensitive manner and MUST follow the conventions defined
- in [RFC1766].
-
- For Example:
-
- 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name-in-utf8"
- 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-TW" "name-in-utf8"
- 4.3.2.1.IN-ADDR.ARPA. IPTR "ja-JP" "name-in-utf8"
- 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name-in-utf8"
-
- The notion of canonical names and aliases described in 3.6.2
- [RFC1034], and 10.2 [RFC2181] MUST be preserved for IPTR record types.
- An IPTR RR SHOULD be limited to one primary IDN per LANGUAGE, similar
- to the a PTR RR.
-
-3. IPTR on IPv6
-
-
-
-
-Shi, Jiang [Page 3]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- Mapping IPv6 to IDNs can be similarly supported. This document recom-
- mands to continue using the IP6.INT domain defined in [RFC1886] for
- IPTR mappings. For example, the lookup corresponding to the address
- 4321:0:1:2:3:4:567:89ab would be:
- b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
- IPTR "LANGUAGE" "name-in-utf8"
-
-4. Packet format for IPTR
-
- EDNS0[RFC2671] is REQUIRED to implement IPTR.
-
-
- 0 1 2 3 4
- bits 0 1 2 3 4 5 6 7 8 9 0 1...9 0...8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 ...
- +-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+
- |0 1| ELT | LANGUAGE | Size | IDN label... |
- +-+-+-+-+-+-+-+-+-+-//-+-+-//-+-+-+-+-+-+-+-+-+-+-+-+-+-//-+-+-+
-
- LANGUAGE: An argument for IPTR to define the kind of language
- used in the following IDN label. The size is 2 octets.
- ELT: To be defined in [IDNE].
-
-
-5. Coexistence
-
-5.1 IDN Consideration
-
- IPTR described above is based on "a set of IDNs", strictly speaking, a
- set of canonical IDNs. On the other hand, confusion about IDN, such as
- "IDN MUST exist with ASCII domain name" has led to a belief that PTR
- record should have exactly RRs in its RRSet. In short, the phenomenon
- "IDN ONLY" will exist. Thus, the exceptional handling of PTR is
- REQUIRED.
-
- On the other hand, IDN is still RECOMMENDED to exist with more than
- one ASCII domain name.
-
-5.2 PTR Extension
-
- In the case of "IDN ONLY", if IPTR RR is not NULL, PTR RR MUST contain
- a domain name in ACE to coexist with those IDN unaware systems. Else a
- "Syntax Error" message SHOULD be sent back, when an administrator con-
- figures DNS zone files.
-
-5.3 IPTR and PTR
-
- It is a kind of backward compatible handle for those IDN unaware sys-
- tems that can not provide the IPTR function. Besides, if a client can
-
-
-
-Shi, Jiang [Page 4]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- not find the corresponding LANGUAGE IDN finally, then the correspond-
- ing PTR RR SHOULD be used as the answer.
-
-6. IPTR query/response
-
- When the QTYPE is IPTR in a query, all of the corresponding IPTR RRs
- SHOULD be returned in one response. DNS messages are limited to 512
- octets or less in size when sent over UDP. Therefore, if all the RRs
- cannot fit in one UDP packet, this draft describe two solutions. One
- is for recent environment and the other is for the near future.
-
-6.1 Transport
-
- Today, DNS queries and responses are carried in UDP datagrams or over
- TCP connections.[RFC1034] specifies, IPTR RRSet is RECOMMENDED to be
- returned in one response. The size of a DNS message could exceed 512
- octets, when multiple RRs are present. Therefore, this draft makes the
- two following recommendations.
-
-
- - "Use UDP first, if UDP is not large enough then change to TCP" is
- RECOMMENDED.
-
- The server MUST send back the response with the TC bit set. Then
- the resolver SHOULD resend the query using TCP on server port
- 53(decimal). This behavior is consistent with the current DNS
- specification [RFC1035].
-
-
- - In future, EDNS0 is REQUIRED to send large packets.
-
- Then, before a client send a query to ask for IPTR record, it
- MUST query the server whether it knows the EDNS0 first. If the
- server knows EDNS0, then the client MAY send the IPTR query.
- Else, unfortunally, the client MUST change the QTYPE to PTR.
-
- Hence, the size of the UDP payload is no longer limited to 512
- octets any more.
-
-6.2 Standard sample
-
- A resolver who wants to find the IDNs corresponding to an IP
- address 1.2.3.4 whould pursue a query of the form QTYPE=IPTR,
- QCLASS=IN, QNAME=4.3.2.1.IN-ADDR.ARPA, and would receive:
-
-
-
-
-
-
-
-Shi, Jiang [Page 5]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
-
- +------------------------------------------------------+
- Header | OPCODE=SQUERY, RESPONSE, AA |
- +------------------------------------------------------+
- Question | QNAME=4.3.2.1.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=IPTR |
- +------------------------------------------------------+
- Answer | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-CN" "name1-in-utf8" |
- | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-TW" "name2-in-utf8" |
- | 4.3.2.1.IN-ADDR.ARPA. IPTR "zh-JP" "name3-in-utf8" |
- | 4.3.2.1.IN-ADDR.ARPA. IPTR "ko-KR" "name4-in-utf8" |
- +------------------------------------------------------+
- Authority | ... |
- +------------------------------------------------------+
- Additional | ... |
- +------------------------------------------------------+
-
-
-7. IPTR Usage
-
- The "foo1.example" in following samples MAY or MAY NOT be
- represented in the same characters.
-
- 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[foo1.example] in utf8"
- IPTR "zh-CN" "[foo1.example] in utf8"
- IPTR "ja-JP" "[foo1.example] in utf8"
- IPTR "ko-KR" "[foo1.example] in utf8"
-
- Moreover,
-
- 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[foo1.example] in utf8"
- IPTR "zh-TW" "[foo2.example] in utf8"
- ...
- IPTR "zh-CN" "[foo1.example] in utf8"
- IPTR "zh-CN" "[foo2.example] in utf8"
- ...
- IPTR "ja-JP" "[foo1.example] in utf8"
- IPTR "ja-JP" "[foo2.example] in utf8"
- ...
- IPTR "ko-KR" "[foo1.example] in utf8"
- IPTR "ko-KR" "[foo2.example] in utf8"
- ...
-
- will exist also. And "foo2.example" MUST be different from
- "foo1.example", if they are in signed with same LANGUAGE. Or a
- "Syntax Error" SHOULD be sent back, when an administrator config-
- ures the zone files. Furthermore "foo2.example" in the samples
- above MAY or MAY NOT be represented in the same characters.
-
-
-
-
-Shi, Jiang [Page 6]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- Thus,
-
- 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8"
- IPTR "zh-TW" "[samefoo.sample] in utf8"
-
- occurs a "Syntax Error".
-
- And,
-
- 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8"
- IPTR "zh-TW" "[difffoo.sample] in utf8"
- IPTR "zh-CN" "[samefoo.sample] in utf8"
- IPTR "ja-JP" "[samefoo.sample] in utf8"
- IPTR "ko-KR" "[samefoo.sample] in utf8"
-
- is allowed.
-
-8. Changes
-
- Through the discussion on the IETF49 meeting in San Diego, we
- deleted the chapter "Open Issues" of our previous draft (version
- 01).
-
- And,
-
- 4.3.2.1.IN-ADDR.ARPA IPTR "zh-TW" "[samefoo.sample] in utf8"
- IPTR "zh-TW" "[difffoo.sample] in utf8"
- IPTR "zh-CN" "[samefoo.sample] in utf8"
- IPTR "ja-JP" "[samefoo.sample] in utf8"
- IPTR "ko-KR" "[samefoo.sample] in utf8"
-
- is allowed.
-
-8. Changes
-
- Through the discussion on the IETF49 meeting in San Diego, we
- deleted the chapter "Open Issues" of our previous draft (version
- 01).
-
-References
-
- [IDNREQ] Zita Wenzel & James Seng, "Requirements of International-
- ized Domain Names", draft-ietf-idn-requirements.
-
- [IDNE] Marc Blanchet & Paul Hoffman, "Internationalized domain
- names using EDNS", draft-ietf-idn-idne.
-
- [NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
-
-
-
-Shi, Jiang [Page 7]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- Internationalized Host Names", draft-ietf-idn-nameprep.
-
- [RFC1034] P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES",
- November 1987, RFC1034
-
- [RFC1035] P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND
- SPECIFICATION", November 1987, RFC1035
-
- [RFC1766] H. Alvestrand, "Tags for the Identification of
- Languages", March 1999, RFC 1766
-
- [RFC1886] S. Thomson, C. Huitema, "DNS Extensions to support IP
- version 6", December 1995, RFC1886
-
- [RFC2181] R. Elz, R. Bush, "Clarifications to the DNS Specifica-
- tion", July 1997, RFC2181
-
- [RFC2279] Francois Yergeau, "UTF-8, a transformation format of ISO
- 10646", January 1998, RFC 2279.
-
- [RFC2671] Paul Vixie, "Extension Mechanisms for DNS (EDNS0)",
- August 1999, RFC 2671.
-
- [ISO 639] ISO 639:1988 (E/F) - Code for the representation of names
- of languages - The International Organization for Standardization,
- 1st edition, 1988 17 pages Prepared by ISO/TC 37 - Terminology
- (principles and coordination).
-
- [ISO 3166] ISO 3166:1988 (E/F) - Codes for the representation of
- names of countries - The International Organization for Standardi-
- zation, 3rd edition, 1988-08-15.
-
-Acknowledgements
-
- James Seng and Yoshiro Yoneya have given many comments in our e-
- mail discussions. Harald Alvestrand, Mark Davis have given many
- suggestions in the idn-wg mailing list discussions. And there are
- also a lot of people who have given us their comments in the idn-wg
- and BIND-user mailing list discussions.
-
-Authors' Information
-
- Hongbo Shi
- Waseda University
- 3-4-1 Okubo, Shinjyuku-ku
- Tokyo, 169-8555 Japan
- shi@goto.info.waseda.ac.jp
-
-
-
-
-Shi, Jiang [Page 8]
-
-
-
-
-
-INTERNET-DRAFT Internationalized PTR Resource Record 17 May 2001
-
-
- Jiang Ming Liang
- i-DNS.net
- 8 Temasek Boulevard
- #24-02 Suntec Tower Three
- Singapore 038988
- jiang@i-DNS.net
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Shi, Jiang [Page 9]
-
-
+++ /dev/null
-Internet Draft Yoshiro Yoneya
-draft-ietf-idn-jpchar-01.txt Yasuhiro Morishita
-March 2, 2001 JPNIC
-Expires September 2, 2001
-
- Japanese characters in multilingual domain name labels
-
-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 explains about Japanese characters and their local mapping
-rules in multilingual domain name labels. This document is based on
-discussions and examinations in JPNIC (Japan Network Information
-Center).
-
-Despite of IDN WG's requirement [IDNREQ] that desired character set of
-multilingual domain name is UCS [UCS], most popular Japanese character
-set used in Japan is still Japanese Industrial Standards X 0208 and X
-0201 -- hereafter abbreviated as "JIS" -- [JISX0208]. This means that
-many of PCs and most of PDAs including handy phones in Japan can
-display only JIS and ASCII characters. Therefore, to handle
-multilingual domain name properly, these PCs and PDAs SHOULD meet
-conditions described below.
-
- - Use well defined widely distributed common mapping table between
- UCS and JIS.
- - Use characters commonly defined in both UCS and JIS.
-
-This document does not define common mapping table, but this document
-defines desired Japanese characters used as multilingual domain name
-labels and also describes problems and possible solutions that come
-with mapping table and normalization rules defined by the Unicode
-Consortium.
-
-
-1. Japanese characters in multilingual domain name labels
-
-In principle, domain name is a symbolic name of resources on the
-Internet for recognizing and memorizing easily to the Internet users.
-Internationalization or multilingualization of domain name MUST obey
-this principle. That is, characters in multilingualized domain name
-labels SHOULD be unambiguous.
-
-JIS has a lot of characters including graphical characters. But as
-for domain name, significant characters to represent names are
-Alpha-numerics, Kanji, Hiragana and Katakana [CJK]. Therefore,
-according to the principle, Japanese characters in multilingual domain
-name MUST be combination of Alpha-numerics, Hyphen, Kanji, Hiragana
-and Katakana.
-
-The file "idntabjp10.txt" (also included in this document) defines
-Japanese characters in the format of [VERSION], with additional
-corresponding JIS code points as 3rd field, that can be used in
-multilingual domain name labels. Some of them, such as
-KATAKANA-HIRAGANA PROLONGED SOUND MARK (U+30FC), are categorized
-into graphical character in JIS, but usage of them are part of
-Kanji, Hiragana or Katakana.
-
-
-2. Local mapping of Japanese characters in multilingual domain
- name labels
-
-Name preparation [NAMEPREP] practically works well for Japanese
-characters but there are some exceptions. These exceptions are
-depending on character mapping between UCS and JIS. As mentioned
-before, many of Japanese PCs and PDAs use JIS as local character set,
-therefore these MUST do code set conversion to handle multilingual
-domain name properly.
-
-Unfortunately, some characters such as VOICED SOUND MARK in JIS are
-mapped to characters in UCS that don't work with [NAMEPREP]. The file
-"idntabjplocalmap10.txt" (also included in this document) defines
-mapping to make these characters work with [NAMEPREP] as preferred,
-with additional corresponding UCS code points as 3rd field. This
-mapping MUST be applied before [NAMEPREP].
-
-The interfaces for mapping described in this document can be
-represented pictorially according to Internationalizing Host Names in
-Applications [IDNA] as:
-
- +------+
- | User |
- +------+
- ^
- | Input and display: local interface methods
- | (pen, keyboard, glowing phosphorus, ...)
- +--------------- v -------------------------------+
- | +-------------+ |
- | | Application | | End system
- | |+-----------+|
- | || Code conv || Code conversion between local
- | |+-----------+| encoding and UCS
- | |+-----------+|
- | || Local map || Character mapping to make NAMEPREP
- | |+-----------+| work as preferred
- | |+-----------+|
- | || NAMEPREP || Name preparation
- | |+-----------+|
- | |+-----------+|
- | || ACE conv || Encoding conversion between UCS and
- | |+-----------+| ASCII Compatible Encoding (ACE)
- | +-------------+
- | ^
- | | API call and return: nameprepped ACE
- | v
- | +----------+
- | | Resolver |
- | +----------+ |
- +----------------^--------------------------------+
- | DNS query and response: nameprepped ACE
- v
- +-------------+
- | DNS servers |
- +-------------+
-
-3. Security considerations
-
-None in particular.
-
-
-4. References
-
-[IDNREQ] "Requirements of Internationalized Domain Names",
- draft-ietf-idn-requirements-04.txt, Oct 2000, Z Wenzel, J Seng
-[UCS] "Universal Multiple-Octet Coded Character Set",
- ISO/IEC 10646-1:1993, ISBN 0-201-61633-5
-[JISX0208] "Japanese Industrial Standards",
- Information Technology (Terms/Code/Date elements)-99,
- ISBN 4-542-12976-4
-[NAMEPREP] "Preparation of Internationalized Host Names",
- draft-ietf-idn-nameprep-03.txt, Feb 2001, P Hoffman, M Blanchet
-[CJK] "Han Ideograph (CJK) for Internationalized Domain Names",
- draft-ietf-idn-cjk-00.txt, Sep 2000, J Seng, Y Yoneya,
- K Huang, K Kyongsok
-[VERSION] "Handling versions of internationalized domain names protocols",
- draft-ietf-idn-version-00.txt, Nov 2000, M Blanchet
-[IDNA] "Internationalizing Host Names In Applications (IDNA)",
- draft-ietf-idn-idna-01.txt, Feb 2001, P Hoffman, P Faltstrom
-
-
-5. Acknowledgements
-
-JPNIC IDN-TF members gave a lot of comments for early drafts.
-Mark Davis and Hideyo Imazu suggested to map KATAKANA-HIRAGANA
-VOICED/SEMI-VOICED SOUND MARK (U+309B/U+309C) onto COMBINING
-KATAKANA-HIRAGANA VOICED/SEMI-VOICED SOUND MARK (U+3099/U+309A).
-
-6. Differences between -00 and -01 drafts
-
-Focused on local mapping to make NAMEPREP work as preferred, therefore
-additional normalization rule is no longer defined and related table
-was removed.
-
-NAMEPREP now works well for compatible characters such as FULL-WIDTH
-alpha-numerics and/or HALF-WIDTH Katakana, therefore compatible
-mapping table was removed.
-
-7. Author's Address
-
-Yoshiro Yoneya
-Japan Network Information Center
-Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
-Chiyoda-ku Tokyo 101-0052, Japan
-yone@nic.ad.jp
-
-Yasuhiro Morishita
-Japan Network Information Center
-Fuundo Bldg 1F, 1-2 Kanda-ogawamachi
-Chiyoda-ku Tokyo 101-0052, Japan
-yasuhiro@nic.ad.jp
-
-
-A. idntabjp10.txt
-
-version=1.0
-
-3005;1.0;0125
-3041;1.0;0401
-3042;1.0;0402
-3043;1.0;0403
-3044;1.0;0404
-3045;1.0;0405
-3046;1.0;0406
-3047;1.0;0407
-3048;1.0;0408
-3049;1.0;0409
-304A;1.0;0410
-304B;1.0;0411
-304C;1.0;0412
-304D;1.0;0413
-304E;1.0;0414
-304F;1.0;0415
-3050;1.0;0416
-3051;1.0;0417
-3052;1.0;0418
-3053;1.0;0419
-3054;1.0;0420
-3055;1.0;0421
-3056;1.0;0422
-3057;1.0;0423
-3058;1.0;0424
-3059;1.0;0425
-305A;1.0;0426
-305B;1.0;0427
-305C;1.0;0428
-305D;1.0;0429
-305E;1.0;0430
-305F;1.0;0431
-3060;1.0;0432
-3061;1.0;0433
-3062;1.0;0434
-3063;1.0;0435
-3064;1.0;0436
-3065;1.0;0437
-3066;1.0;0438
-3067;1.0;0439
-3068;1.0;0440
-3069;1.0;0441
-306A;1.0;0442
-306B;1.0;0443
-306C;1.0;0444
-306D;1.0;0445
-306E;1.0;0446
-306F;1.0;0447
-3070;1.0;0448
-3071;1.0;0449
-3072;1.0;0450
-3073;1.0;0451
-3074;1.0;0452
-3075;1.0;0453
-3076;1.0;0454
-3077;1.0;0455
-3078;1.0;0456
-3079;1.0;0457
-307A;1.0;0458
-307B;1.0;0459
-307C;1.0;0460
-307D;1.0;0461
-307E;1.0;0462
-307F;1.0;0463
-3080;1.0;0464
-3081;1.0;0465
-3082;1.0;0466
-3083;1.0;0467
-3084;1.0;0468
-3085;1.0;0469
-3086;1.0;0470
-3087;1.0;0471
-3088;1.0;0472
-3089;1.0;0473
-308A;1.0;0474
-308B;1.0;0475
-308C;1.0;0476
-308D;1.0;0477
-308E;1.0;0478
-308F;1.0;0479
-3090;1.0;0480
-3091;1.0;0481
-3092;1.0;0482
-3093;1.0;0483
-309D;1.0;0121
-309E;1.0;0122
-30A1;1.0;0501
-30A2;1.0;0502
-30A3;1.0;0503
-30A4;1.0;0504
-30A5;1.0;0505
-30A6;1.0;0506
-30A7;1.0;0507
-30A8;1.0;0508
-30A9;1.0;0509
-30AA;1.0;0510
-30AB;1.0;0511
-30AC;1.0;0512
-30AD;1.0;0513
-30AE;1.0;0514
-30AF;1.0;0515
-30B0;1.0;0516
-30B1;1.0;0517
-30B2;1.0;0518
-30B3;1.0;0519
-30B4;1.0;0520
-30B5;1.0;0521
-30B6;1.0;0522
-30B7;1.0;0523
-30B8;1.0;0524
-30B9;1.0;0525
-30BA;1.0;0526
-30BB;1.0;0527
-30BC;1.0;0528
-30BD;1.0;0529
-30BE;1.0;0530
-30BF;1.0;0531
-30C0;1.0;0532
-30C1;1.0;0533
-30C2;1.0;0534
-30C3;1.0;0535
-30C4;1.0;0536
-30C5;1.0;0537
-30C6;1.0;0538
-30C7;1.0;0539
-30C8;1.0;0540
-30C9;1.0;0541
-30CA;1.0;0542
-30CB;1.0;0543
-30CC;1.0;0544
-30CD;1.0;0545
-30CE;1.0;0546
-30CF;1.0;0547
-30D0;1.0;0548
-30D1;1.0;0549
-30D2;1.0;0550
-30D3;1.0;0551
-30D4;1.0;0552
-30D5;1.0;0553
-30D6;1.0;0554
-30D7;1.0;0555
-30D8;1.0;0556
-30D9;1.0;0557
-30DA;1.0;0558
-30DB;1.0;0559
-30DC;1.0;0560
-30DD;1.0;0561
-30DE;1.0;0562
-30DF;1.0;0563
-30E0;1.0;0564
-30E1;1.0;0565
-30E2;1.0;0566
-30E3;1.0;0567
-30E4;1.0;0568
-30E5;1.0;0569
-30E6;1.0;0570
-30E7;1.0;0571
-30E8;1.0;0572
-30E9;1.0;0573
-30EA;1.0;0574
-30EB;1.0;0575
-30EC;1.0;0576
-30ED;1.0;0577
-30EE;1.0;0578
-30EF;1.0;0579
-30F0;1.0;0580
-30F1;1.0;0581
-30F2;1.0;0582
-30F3;1.0;0583
-30F4;1.0;0584
-30F5;1.0;0585
-30F6;1.0;0586
-30FB;1.0;0106
-30FC;1.0;0128
-30FD;1.0;0119
-30FE;1.0;0120
-4E00;1.0;1676
-4E01;1.0;3590
-4E03;1.0;2823
-4E07;1.0;4392
-4E08;1.0;3070
-4E09;1.0;2716
-4E0A;1.0;3069
-4E0B;1.0;1828
-4E0D;1.0;4152
-4E0E;1.0;4531
-4E10;1.0;4802
-4E11;1.0;1715
-4E14;1.0;1978
-4E15;1.0;4803
-4E16;1.0;3204
-4E17;1.0;5034
-4E18;1.0;2154
-4E19;1.0;4226
-4E1E;1.0;3071
-4E21;1.0;4630
-4E26;1.0;4234
-4E2A;1.0;4804
-4E2D;1.0;3570
-4E31;1.0;4805
-4E32;1.0;2290
-4E36;1.0;4806
-4E38;1.0;2061
-4E39;1.0;3516
-4E3B;1.0;2871
-4E3C;1.0;4807
-4E3F;1.0;4808
-4E42;1.0;4809
-4E43;1.0;3921
-4E45;1.0;2155
-4E4B;1.0;3923
-4E4D;1.0;3867
-4E4E;1.0;2435
-4E4F;1.0;4319
-4E55;1.0;7341
-4E56;1.0;4810
-4E57;1.0;3072
-4E58;1.0;4811
-4E59;1.0;1821
-4E5D;1.0;2269
-4E5E;1.0;2480
-4E5F;1.0;4473
-4E62;1.0;5406
-4E71;1.0;4580
-4E73;1.0;3893
-4E7E;1.0;2005
-4E80;1.0;2121
-4E82;1.0;4812
-4E85;1.0;4813
-4E86;1.0;4627
-4E88;1.0;4529
-4E89;1.0;3372
-4E8A;1.0;4815
-4E8B;1.0;2786
-4E8C;1.0;3883
-4E8E;1.0;4818
-4E91;1.0;1730
-4E92;1.0;2463
-4E94;1.0;2462
-4E95;1.0;1670
-4E98;1.0;4743
-4E99;1.0;4742
-4E9B;1.0;2619
-4E9C;1.0;1601
-4E9E;1.0;4819
-4E9F;1.0;4820
-4EA0;1.0;4821
-4EA1;1.0;4320
-4EA2;1.0;4822
-4EA4;1.0;2482
-4EA5;1.0;1671
-4EA6;1.0;4382
-4EA8;1.0;2192
-4EAB;1.0;2193
-4EAC;1.0;2194
-4EAD;1.0;3666
-4EAE;1.0;4628
-4EB0;1.0;4823
-4EB3;1.0;4824
-4EB6;1.0;4825
-4EBA;1.0;3145
-4EC0;1.0;2926
-4EC1;1.0;3146
-4EC2;1.0;4830
-4EC4;1.0;4828
-4EC6;1.0;4829
-4EC7;1.0;2156
-4ECA;1.0;2603
-4ECB;1.0;1880
-4ECD;1.0;4827
-4ECE;1.0;4826
-4ECF;1.0;4209
-4ED4;1.0;2738
-4ED5;1.0;2737
-4ED6;1.0;3430
-4ED7;1.0;4831
-4ED8;1.0;4153
-4ED9;1.0;3271
-4EDE;1.0;4832
-4EDF;1.0;4834
-4EE3;1.0;3469
-4EE4;1.0;4665
-4EE5;1.0;1642
-4EED;1.0;4833
-4EEE;1.0;1830
-4EF0;1.0;2236
-4EF2;1.0;3571
-4EF6;1.0;2379
-4EF7;1.0;4835
-4EFB;1.0;3904
-4F01;1.0;2075
-4F09;1.0;4836
-4F0A;1.0;1643
-4F0D;1.0;2464
-4F0E;1.0;2076
-4F0F;1.0;4190
-4F10;1.0;4018
-4F11;1.0;2157
-4F1A;1.0;1881
-4F1C;1.0;4871
-4F1D;1.0;3733
-4F2F;1.0;3976
-4F30;1.0;4838
-4F34;1.0;4028
-4F36;1.0;4666
-4F38;1.0;3113
-4F3A;1.0;2739
-4F3C;1.0;2787
-4F3D;1.0;1832
-4F43;1.0;3649
-4F46;1.0;3502
-4F47;1.0;4842
-4F4D;1.0;1644
-4F4E;1.0;3667
-4F4F;1.0;2927
-4F50;1.0;2620
-4F51;1.0;4504
-4F53;1.0;3446
-4F55;1.0;1831
-4F57;1.0;4841
-4F59;1.0;4530
-4F5A;1.0;4837
-4F5B;1.0;4839
-4F5C;1.0;2678
-4F5D;1.0;4840
-4F5E;1.0;5304
-4F69;1.0;4848
-4F6F;1.0;4851
-4F70;1.0;4849
-4F73;1.0;1834
-4F75;1.0;4227
-4F76;1.0;4843
-4F7B;1.0;4847
-4F7C;1.0;2483
-4F7F;1.0;2740
-4F83;1.0;2006
-4F86;1.0;4852
-4F88;1.0;4844
-4F8B;1.0;4667
-4F8D;1.0;2788
-4F8F;1.0;4845
-4F91;1.0;4850
-4F96;1.0;4853
-4F98;1.0;4846
-4F9B;1.0;2201
-4F9D;1.0;1645
-4FA0;1.0;2202
-4FA1;1.0;1833
-4FAB;1.0;5305
-4FAD;1.0;4389
-4FAE;1.0;4178
-4FAF;1.0;2484
-4FB5;1.0;3115
-4FB6;1.0;4623
-4FBF;1.0;4256
-4FC2;1.0;2324
-4FC3;1.0;3405
-4FC4;1.0;1868
-4FCA;1.0;2951
-4FCE;1.0;4857
-4FD0;1.0;4862
-4FD1;1.0;4860
-4FD4;1.0;4855
-4FD7;1.0;3415
-4FD8;1.0;4858
-4FDA;1.0;4861
-4FDB;1.0;4859
-4FDD;1.0;4261
-4FDF;1.0;4856
-4FE1;1.0;3114
-4FE3;1.0;4383
-4FE4;1.0;4863
-4FE5;1.0;4864
-4FEE;1.0;2904
-4FEF;1.0;4877
-4FF3;1.0;3948
-4FF5;1.0;4122
-4FF6;1.0;4872
-4FF8;1.0;4280
-4FFA;1.0;1822
-4FFE;1.0;4876
-5005;1.0;4870
-5006;1.0;4879
-5009;1.0;3350
-500B;1.0;2436
-500D;1.0;3960
-500F;1.0;6439
-5011;1.0;4878
-5012;1.0;3761
-5014;1.0;4867
-5016;1.0;2486
-5019;1.0;2485
-501A;1.0;4865
-501F;1.0;2858
-5021;1.0;4873
-5023;1.0;4279
-5024;1.0;3545
-5025;1.0;4869
-5026;1.0;2381
-5028;1.0;4866
-5029;1.0;4874
-502A;1.0;4868
-502B;1.0;4649
-502C;1.0;4875
-502D;1.0;4733
-5036;1.0;2270
-5039;1.0;2380
-5043;1.0;4880
-5047;1.0;4881
-5048;1.0;4885
-5049;1.0;1646
-504F;1.0;4248
-5050;1.0;4884
-5055;1.0;4883
-5056;1.0;4887
-505A;1.0;4886
-505C;1.0;3668
-5065;1.0;2382
-506C;1.0;4888
-5072;1.0;2837
-5074;1.0;3406
-5075;1.0;3669
-5076;1.0;2286
-5078;1.0;4889
-507D;1.0;2122
-5080;1.0;4890
-5085;1.0;4892
-508D;1.0;4321
-5091;1.0;2370
-5098;1.0;2717
-5099;1.0;4087
-509A;1.0;4891
-50AC;1.0;2637
-50AD;1.0;4535
-50B2;1.0;4894
-50B3;1.0;4903
-50B4;1.0;4893
-50B5;1.0;2636
-50B7;1.0;2993
-50BE;1.0;2325
-50C2;1.0;4904
-50C5;1.0;2247
-50C9;1.0;4901
-50CA;1.0;4902
-50CD;1.0;3815
-50CF;1.0;3392
-50D1;1.0;2203
-50D5;1.0;4345
-50D6;1.0;4905
-50DA;1.0;4629
-50DE;1.0;4906
-50E3;1.0;4909
-50E5;1.0;4907
-50E7;1.0;3346
-50ED;1.0;4908
-50EE;1.0;4910
-50F5;1.0;4912
-50F9;1.0;4911
-50FB;1.0;4240
-5100;1.0;2123
-5101;1.0;4914
-5102;1.0;4915
-5104;1.0;1815
-5109;1.0;4913
-5112;1.0;2884
-5114;1.0;4918
-5115;1.0;4917
-5116;1.0;4916
-5118;1.0;4854
-511A;1.0;4919
-511F;1.0;2994
-5121;1.0;4920
-512A;1.0;4505
-5132;1.0;4457
-5137;1.0;4922
-513A;1.0;4921
-513B;1.0;4924
-513C;1.0;4923
-513F;1.0;4925
-5140;1.0;4926
-5141;1.0;1684
-5143;1.0;2421
-5144;1.0;2327
-5145;1.0;2928
-5146;1.0;3591
-5147;1.0;2204
-5148;1.0;3272
-5149;1.0;2487
-514B;1.0;2578
-514C;1.0;4928
-514D;1.0;4440
-514E;1.0;3738
-5150;1.0;2789
-5152;1.0;4927
-5154;1.0;4929
-515A;1.0;3762
-515C;1.0;1985
-5162;1.0;4930
-5165;1.0;3894
-5168;1.0;3320
-5169;1.0;4932
-516A;1.0;4933
-516B;1.0;4012
-516C;1.0;2488
-516D;1.0;4727
-516E;1.0;4934
-5171;1.0;2206
-5175;1.0;4228
-5176;1.0;3422
-5177;1.0;2281
-5178;1.0;3721
-517C;1.0;2383
-5180;1.0;4935
-5182;1.0;4936
-5185;1.0;3866
-5186;1.0;1763
-5189;1.0;4939
-518A;1.0;2693
-518C;1.0;4938
-518D;1.0;2638
-518F;1.0;4940
-5190;1.0;7078
-5191;1.0;4941
-5192;1.0;4333
-5193;1.0;4942
-5195;1.0;4943
-5196;1.0;4944
-5197;1.0;3073
-5199;1.0;2844
-51A0;1.0;2007
-51A2;1.0;4947
-51A4;1.0;4945
-51A5;1.0;4429
-51A6;1.0;4946
-51A8;1.0;4158
-51A9;1.0;4948
-51AA;1.0;4949
-51AB;1.0;4950
-51AC;1.0;3763
-51B0;1.0;4954
-51B1;1.0;4952
-51B2;1.0;4953
-51B3;1.0;4951
-51B4;1.0;2667
-51B5;1.0;4955
-51B6;1.0;4474
-51B7;1.0;4668
-51BD;1.0;4956
-51C4;1.0;3208
-51C5;1.0;4957
-51C6;1.0;2958
-51C9;1.0;4958
-51CB;1.0;3592
-51CC;1.0;4631
-51CD;1.0;3764
-51D6;1.0;5037
-51DB;1.0;4959
-51DC;1.0;8405
-51DD;1.0;2237
-51E0;1.0;4960
-51E1;1.0;4362
-51E6;1.0;2972
-51E7;1.0;3492
-51E9;1.0;4962
-51EA;1.0;3868
-51ED;1.0;4963
-51F0;1.0;4964
-51F1;1.0;1914
-51F5;1.0;4965
-51F6;1.0;2207
-51F8;1.0;3844
-51F9;1.0;1790
-51FA;1.0;2948
-51FD;1.0;4001
-51FE;1.0;4966
-5200;1.0;3765
-5203;1.0;3147
-5204;1.0;4967
-5206;1.0;4212
-5207;1.0;3258
-5208;1.0;2002
-520A;1.0;2009
-520B;1.0;4968
-520E;1.0;4970
-5211;1.0;2326
-5214;1.0;4969
-5217;1.0;4683
-521D;1.0;2973
-5224;1.0;4029
-5225;1.0;4244
-5227;1.0;4971
-5229;1.0;4588
-522A;1.0;4972
-522E;1.0;4973
-5230;1.0;3794
-5233;1.0;4974
-5236;1.0;3209
-5237;1.0;2694
-5238;1.0;2384
-5239;1.0;4975
-523A;1.0;2741
-523B;1.0;2579
-5243;1.0;3670
-5244;1.0;4977
-5247;1.0;3407
-524A;1.0;2679
-524B;1.0;4978
-524C;1.0;4979
-524D;1.0;3316
-524F;1.0;4976
-5254;1.0;4981
-5256;1.0;4322
-525B;1.0;2568
-525E;1.0;4980
-5263;1.0;2385
-5264;1.0;2662
-5265;1.0;3977
-5269;1.0;4984
-526A;1.0;4982
-526F;1.0;4191
-5270;1.0;3074
-5271;1.0;4991
-5272;1.0;1968
-5273;1.0;4985
-5274;1.0;4983
-5275;1.0;3347
-527D;1.0;4987
-527F;1.0;4986
-5283;1.0;1936
-5287;1.0;2364
-5288;1.0;4992
-5289;1.0;4613
-528D;1.0;4988
-5291;1.0;4993
-5292;1.0;4990
-5294;1.0;4989
-529B;1.0;4647
-529F;1.0;2489
-52A0;1.0;1835
-52A3;1.0;4684
-52A9;1.0;2985
-52AA;1.0;3756
-52AB;1.0;2569
-52AC;1.0;5002
-52AD;1.0;5003
-52B1;1.0;4669
-52B4;1.0;4711
-52B5;1.0;5005
-52B9;1.0;2490
-52BC;1.0;5004
-52BE;1.0;1915
-52C1;1.0;5006
-52C3;1.0;4354
-52C5;1.0;3628
-52C7;1.0;4506
-52C9;1.0;4257
-52CD;1.0;5007
-52D2;1.0;8053
-52D5;1.0;3816
-52D7;1.0;5008
-52D8;1.0;2010
-52D9;1.0;4419
-52DD;1.0;3001
-52DE;1.0;5009
-52DF;1.0;4271
-52E0;1.0;5013
-52E2;1.0;3210
-52E3;1.0;5010
-52E4;1.0;2248
-52E6;1.0;5011
-52E7;1.0;2011
-52F2;1.0;2314
-52F3;1.0;5014
-52F5;1.0;5015
-52F8;1.0;5016
-52F9;1.0;5017
-52FA;1.0;2859
-52FE;1.0;2491
-52FF;1.0;4462
-5301;1.0;4472
-5302;1.0;3887
-5305;1.0;4281
-5306;1.0;5018
-5308;1.0;5019
-530D;1.0;5021
-530F;1.0;5023
-5310;1.0;5022
-5315;1.0;5024
-5316;1.0;1829
-5317;1.0;4344
-5319;1.0;2692
-531A;1.0;5025
-531D;1.0;3357
-5320;1.0;3002
-5321;1.0;2209
-5323;1.0;5026
-532A;1.0;4059
-532F;1.0;5027
-5331;1.0;5028
-5333;1.0;5029
-5338;1.0;5030
-5339;1.0;4104
-533A;1.0;2272
-533B;1.0;1669
-533F;1.0;3831
-5340;1.0;5031
-5341;1.0;2929
-5343;1.0;3273
-5345;1.0;5033
-5346;1.0;5032
-5347;1.0;3003
-5348;1.0;2465
-5349;1.0;5035
-534A;1.0;4030
-534D;1.0;5036
-5351;1.0;4060
-5352;1.0;3420
-5353;1.0;3478
-5354;1.0;2208
-5357;1.0;3878
-5358;1.0;3517
-535A;1.0;3978
-535C;1.0;4346
-535E;1.0;5038
-5360;1.0;3274
-5366;1.0;2321
-5369;1.0;5039
-536E;1.0;5040
-536F;1.0;1712
-5370;1.0;1685
-5371;1.0;2077
-5373;1.0;3408
-5374;1.0;2149
-5375;1.0;4581
-5377;1.0;5043
-5378;1.0;1823
-537B;1.0;5042
-537F;1.0;2210
-5382;1.0;5044
-5384;1.0;4481
-5396;1.0;5045
-5398;1.0;4650
-539A;1.0;2492
-539F;1.0;2422
-53A0;1.0;5046
-53A5;1.0;5048
-53A6;1.0;5047
-53A8;1.0;3163
-53A9;1.0;1725
-53AD;1.0;1762
-53AE;1.0;5049
-53B0;1.0;5050
-53B3;1.0;2423
-53B6;1.0;5051
-53BB;1.0;2178
-53C2;1.0;2718
-53C3;1.0;5052
-53C8;1.0;4384
-53C9;1.0;2621
-53CA;1.0;2158
-53CB;1.0;4507
-53CC;1.0;3348
-53CD;1.0;4031
-53CE;1.0;2893
-53D4;1.0;2939
-53D6;1.0;2872
-53D7;1.0;2885
-53D9;1.0;2986
-53DB;1.0;4032
-53DF;1.0;5055
-53E1;1.0;1735
-53E2;1.0;3349
-53E3;1.0;2493
-53E4;1.0;2437
-53E5;1.0;2271
-53E8;1.0;5059
-53E9;1.0;3501
-53EA;1.0;3494
-53EB;1.0;2211
-53EC;1.0;3004
-53ED;1.0;5060
-53EE;1.0;5058
-53EF;1.0;1836
-53F0;1.0;3470
-53F1;1.0;2824
-53F2;1.0;2743
-53F3;1.0;1706
-53F6;1.0;1980
-53F7;1.0;2570
-53F8;1.0;2742
-53FA;1.0;5061
-5401;1.0;5062
-5403;1.0;2141
-5404;1.0;1938
-5408;1.0;2571
-5409;1.0;2140
-540A;1.0;3663
-540B;1.0;1705
-540C;1.0;3817
-540D;1.0;4430
-540E;1.0;2501
-540F;1.0;4589
-5410;1.0;3739
-5411;1.0;2494
-541B;1.0;2315
-541D;1.0;5071
-541F;1.0;2267
-5420;1.0;4342
-5426;1.0;4061
-5429;1.0;5070
-542B;1.0;2062
-542C;1.0;5065
-542D;1.0;5066
-542E;1.0;5068
-5436;1.0;5069
-5438;1.0;2159
-5439;1.0;3165
-543B;1.0;4213
-543C;1.0;5067
-543D;1.0;5063
-543E;1.0;2467
-5440;1.0;5064
-5442;1.0;4704
-5446;1.0;4282
-5448;1.0;3672
-5449;1.0;2466
-544A;1.0;2580
-544E;1.0;5072
-5451;1.0;3861
-545F;1.0;5076
-5468;1.0;2894
-546A;1.0;2886
-5470;1.0;5079
-5471;1.0;5077
-5473;1.0;4403
-5475;1.0;5074
-5476;1.0;5083
-5477;1.0;5078
-547B;1.0;5081
-547C;1.0;2438
-547D;1.0;4431
-5480;1.0;5082
-5484;1.0;5084
-5486;1.0;5086
-548B;1.0;2680
-548C;1.0;4734
-548E;1.0;5075
-548F;1.0;5073
-5490;1.0;5085
-5492;1.0;5080
-54A2;1.0;5088
-54A4;1.0;5103
-54A5;1.0;5090
-54A8;1.0;5094
-54AB;1.0;5101
-54AC;1.0;5091
-54AF;1.0;5130
-54B2;1.0;2673
-54B3;1.0;1917
-54B8;1.0;5089
-54BC;1.0;5105
-54BD;1.0;1686
-54BE;1.0;5104
-54C0;1.0;1605
-54C1;1.0;4142
-54C2;1.0;5102
-54C4;1.0;5092
-54C7;1.0;5087
-54C8;1.0;5093
-54C9;1.0;2640
-54D8;1.0;5106
-54E1;1.0;1687
-54E2;1.0;5115
-54E5;1.0;5107
-54E6;1.0;5108
-54E8;1.0;3005
-54E9;1.0;4373
-54ED;1.0;5113
-54EE;1.0;5112
-54F2;1.0;3715
-54FA;1.0;5114
-54FD;1.0;5111
-5504;1.0;1720
-5506;1.0;2622
-5507;1.0;3116
-550F;1.0;5109
-5510;1.0;3766
-5514;1.0;5110
-5516;1.0;1602
-552E;1.0;5120
-552F;1.0;4503
-5531;1.0;3007
-5533;1.0;5126
-5538;1.0;5125
-5539;1.0;5116
-553E;1.0;3435
-5540;1.0;5117
-5544;1.0;3479
-5545;1.0;5122
-5546;1.0;3006
-554C;1.0;5119
-554F;1.0;4468
-5553;1.0;2328
-5556;1.0;5123
-5557;1.0;5124
-555C;1.0;5121
-555D;1.0;5127
-5563;1.0;5118
-557B;1.0;5133
-557C;1.0;5138
-557E;1.0;5134
-5580;1.0;5129
-5583;1.0;5139
-5584;1.0;3317
-5587;1.0;5141
-5589;1.0;2502
-558A;1.0;5131
-558B;1.0;3593
-5598;1.0;5135
-5599;1.0;5128
-559A;1.0;2013
-559C;1.0;2078
-559D;1.0;1969
-559E;1.0;5136
-559F;1.0;5132
-55A7;1.0;2386
-55A8;1.0;5142
-55A9;1.0;5140
-55AA;1.0;3351
-55AB;1.0;2142
-55AC;1.0;2212
-55AE;1.0;5137
-55B0;1.0;2284
-55B6;1.0;1736
-55C4;1.0;5146
-55C5;1.0;5144
-55C7;1.0;5207
-55D4;1.0;5149
-55DA;1.0;5143
-55DC;1.0;5147
-55DF;1.0;5145
-55E3;1.0;2744
-55E4;1.0;5148
-55F7;1.0;5151
-55F9;1.0;5156
-55FD;1.0;5154
-55FE;1.0;5153
-5606;1.0;3518
-5609;1.0;1837
-5614;1.0;5150
-5616;1.0;5152
-5617;1.0;3008
-5618;1.0;1719
-561B;1.0;5155
-5629;1.0;1862
-562F;1.0;5166
-5631;1.0;3092
-5632;1.0;5162
-5634;1.0;5160
-5636;1.0;5161
-5638;1.0;5163
-5642;1.0;1729
-564C;1.0;3325
-564E;1.0;5157
-5650;1.0;5158
-565B;1.0;1990
-5664;1.0;5165
-5668;1.0;2079
-566A;1.0;5168
-566B;1.0;5164
-566C;1.0;5167
-5674;1.0;4214
-5678;1.0;3853
-567A;1.0;4024
-5680;1.0;5170
-5686;1.0;5169
-5687;1.0;1937
-568A;1.0;5171
-568F;1.0;5174
-5694;1.0;5173
-56A0;1.0;5172
-56A2;1.0;3925
-56A5;1.0;5175
-56AE;1.0;5176
-56B4;1.0;5178
-56B6;1.0;5177
-56BC;1.0;5180
-56C0;1.0;5183
-56C1;1.0;5181
-56C2;1.0;5179
-56C3;1.0;5182
-56C8;1.0;5184
-56CE;1.0;5185
-56D1;1.0;5186
-56D3;1.0;5187
-56D7;1.0;5188
-56D8;1.0;4937
-56DA;1.0;2892
-56DB;1.0;2745
-56DE;1.0;1883
-56E0;1.0;1688
-56E3;1.0;3536
-56EE;1.0;5189
-56F0;1.0;2604
-56F2;1.0;1647
-56F3;1.0;3162
-56F9;1.0;5190
-56FA;1.0;2439
-56FD;1.0;2581
-56FF;1.0;5192
-5700;1.0;5191
-5703;1.0;4264
-5704;1.0;5193
-5708;1.0;5201
-5709;1.0;5194
-570B;1.0;5202
-570D;1.0;5203
-570F;1.0;2387
-5712;1.0;1764
-5713;1.0;5204
-5716;1.0;5206
-5718;1.0;5205
-571C;1.0;5208
-571F;1.0;3758
-5726;1.0;5209
-5727;1.0;1621
-5728;1.0;2663
-572D;1.0;2329
-5730;1.0;3547
-5737;1.0;5210
-5738;1.0;5211
-573B;1.0;5213
-5740;1.0;5214
-5742;1.0;2668
-5747;1.0;2249
-574A;1.0;4323
-574E;1.0;5212
-574F;1.0;5215
-5750;1.0;2633
-5751;1.0;2503
-5761;1.0;5219
-5764;1.0;2605
-5766;1.0;3519
-5769;1.0;5216
-576A;1.0;3658
-577F;1.0;5220
-5782;1.0;3166
-5788;1.0;5218
-5789;1.0;5221
-578B;1.0;2331
-5793;1.0;5222
-57A0;1.0;5223
-57A2;1.0;2504
-57A3;1.0;1932
-57A4;1.0;5225
-57AA;1.0;5226
-57B0;1.0;5227
-57B3;1.0;5224
-57C0;1.0;5217
-57C3;1.0;5228
-57C6;1.0;5229
-57CB;1.0;4368
-57CE;1.0;3075
-57D2;1.0;5231
-57D3;1.0;5232
-57D4;1.0;5230
-57D6;1.0;5234
-57DC;1.0;3924
-57DF;1.0;1672
-57E0;1.0;4154
-57E3;1.0;5235
-57F4;1.0;3093
-57F7;1.0;2825
-57F9;1.0;3961
-57FA;1.0;2080
-57FC;1.0;2675
-5800;1.0;4357
-5802;1.0;3818
-5805;1.0;2388
-5806;1.0;3447
-580A;1.0;5233
-580B;1.0;5236
-5815;1.0;3436
-5819;1.0;5237
-581D;1.0;5238
-5821;1.0;5240
-5824;1.0;3673
-582A;1.0;2014
-582F;1.0;8401
-5830;1.0;1765
-5831;1.0;4283
-5834;1.0;3076
-5835;1.0;3740
-583A;1.0;2670
-583D;1.0;5246
-5840;1.0;4229
-5841;1.0;4661
-584A;1.0;1884
-584B;1.0;5242
-5851;1.0;3326
-5852;1.0;5245
-5854;1.0;3767
-5857;1.0;3741
-5858;1.0;3768
-5859;1.0;4025
-585A;1.0;3645
-585E;1.0;2641
-5862;1.0;5241
-5869;1.0;1786
-586B;1.0;3722
-5870;1.0;5243
-5872;1.0;5239
-5875;1.0;3148
-5879;1.0;5247
-587E;1.0;2946
-5883;1.0;2213
-5885;1.0;5248
-5893;1.0;4272
-5897;1.0;3393
-589C;1.0;3638
-589F;1.0;5250
-58A8;1.0;4347
-58AB;1.0;5251
-58AE;1.0;5256
-58B3;1.0;4215
-58B8;1.0;5255
-58B9;1.0;5249
-58BA;1.0;5252
-58BB;1.0;5254
-58BE;1.0;2606
-58C1;1.0;4241
-58C5;1.0;5257
-58C7;1.0;3537
-58CA;1.0;1885
-58CC;1.0;3077
-58D1;1.0;5259
-58D3;1.0;5258
-58D5;1.0;2572
-58D7;1.0;5260
-58D8;1.0;5262
-58D9;1.0;5261
-58DC;1.0;5264
-58DE;1.0;5253
-58DF;1.0;5266
-58E4;1.0;5265
-58E5;1.0;5263
-58EB;1.0;2746
-58EC;1.0;3149
-58EE;1.0;3352
-58EF;1.0;5267
-58F0;1.0;3228
-58F1;1.0;1677
-58F2;1.0;3968
-58F7;1.0;3659
-58F9;1.0;5269
-58FA;1.0;5268
-58FB;1.0;5270
-58FC;1.0;5271
-58FD;1.0;5272
-5902;1.0;5273
-5909;1.0;4249
-590A;1.0;5274
-590F;1.0;1838
-5910;1.0;5275
-5915;1.0;4528
-5916;1.0;1916
-5918;1.0;5041
-5919;1.0;2940
-591A;1.0;3431
-591B;1.0;5276
-591C;1.0;4475
-5922;1.0;4420
-5925;1.0;5278
-5927;1.0;3471
-5929;1.0;3723
-592A;1.0;3432
-592B;1.0;4155
-592C;1.0;5279
-592D;1.0;5280
-592E;1.0;1791
-5931;1.0;2826
-5932;1.0;5281
-5937;1.0;1648
-5938;1.0;5282
-593E;1.0;5283
-5944;1.0;1766
-5947;1.0;2081
-5948;1.0;3864
-5949;1.0;4284
-594E;1.0;5287
-594F;1.0;3353
-5950;1.0;5286
-5951;1.0;2332
-5954;1.0;4359
-5955;1.0;5285
-5957;1.0;3769
-5958;1.0;5289
-595A;1.0;5288
-5960;1.0;5291
-5962;1.0;5290
-5965;1.0;1792
-5967;1.0;5292
-5968;1.0;3009
-5969;1.0;5294
-596A;1.0;3505
-596C;1.0;5293
-596E;1.0;4219
-5973;1.0;2987
-5974;1.0;3759
-5978;1.0;5301
-597D;1.0;2505
-5981;1.0;5302
-5982;1.0;3901
-5983;1.0;4062
-5984;1.0;4449
-598A;1.0;3905
-598D;1.0;5311
-5993;1.0;2124
-5996;1.0;4537
-5999;1.0;4415
-599B;1.0;5412
-599D;1.0;5303
-59A3;1.0;5306
-59A5;1.0;3437
-59A8;1.0;4324
-59AC;1.0;3742
-59B2;1.0;5307
-59B9;1.0;4369
-59BB;1.0;2642
-59BE;1.0;3010
-59C6;1.0;5308
-59C9;1.0;2748
-59CB;1.0;2747
-59D0;1.0;1625
-59D1;1.0;2440
-59D3;1.0;3211
-59D4;1.0;1649
-59D9;1.0;5312
-59DA;1.0;5313
-59DC;1.0;5310
-59E5;1.0;1724
-59E6;1.0;2015
-59E8;1.0;5309
-59EA;1.0;4437
-59EB;1.0;4117
-59F6;1.0;1608
-59FB;1.0;1689
-59FF;1.0;2749
-5A01;1.0;1650
-5A03;1.0;1603
-5A09;1.0;5318
-5A11;1.0;5316
-5A18;1.0;4428
-5A1A;1.0;5319
-5A1C;1.0;5317
-5A1F;1.0;5315
-5A20;1.0;3117
-5A25;1.0;5314
-5A29;1.0;4258
-5A2F;1.0;2468
-5A35;1.0;5323
-5A36;1.0;5324
-5A3C;1.0;3011
-5A40;1.0;5320
-5A41;1.0;4712
-5A46;1.0;3944
-5A49;1.0;5322
-5A5A;1.0;2607
-5A62;1.0;5325
-5A66;1.0;4156
-5A6A;1.0;5326
-5A6C;1.0;5321
-5A7F;1.0;4427
-5A92;1.0;3962
-5A9A;1.0;5327
-5A9B;1.0;4118
-5ABC;1.0;5328
-5ABD;1.0;5332
-5ABE;1.0;5329
-5AC1;1.0;1839
-5AC2;1.0;5331
-5AC9;1.0;2827
-5ACB;1.0;5330
-5ACC;1.0;2389
-5AD0;1.0;5344
-5AD6;1.0;5337
-5AD7;1.0;5334
-5AE1;1.0;3568
-5AE3;1.0;5333
-5AE6;1.0;5335
-5AE9;1.0;5336
-5AFA;1.0;5338
-5AFB;1.0;5339
-5B09;1.0;2082
-5B0B;1.0;5341
-5B0C;1.0;5340
-5B16;1.0;5342
-5B22;1.0;3078
-5B2A;1.0;5345
-5B2C;1.0;3660
-5B30;1.0;1737
-5B32;1.0;5343
-5B36;1.0;5346
-5B3E;1.0;5347
-5B40;1.0;5350
-5B43;1.0;5348
-5B45;1.0;5349
-5B50;1.0;2750
-5B51;1.0;5351
-5B54;1.0;2506
-5B55;1.0;5352
-5B57;1.0;2790
-5B58;1.0;3424
-5B5A;1.0;5353
-5B5B;1.0;5354
-5B5C;1.0;2758
-5B5D;1.0;2507
-5B5F;1.0;4450
-5B63;1.0;2108
-5B64;1.0;2441
-5B65;1.0;5355
-5B66;1.0;1956
-5B69;1.0;5356
-5B6B;1.0;3425
-5B70;1.0;5357
-5B71;1.0;5403
-5B73;1.0;5358
-5B75;1.0;5359
-5B78;1.0;5360
-5B7A;1.0;5362
-5B80;1.0;5363
-5B83;1.0;5364
-5B85;1.0;3480
-5B87;1.0;1707
-5B88;1.0;2873
-5B89;1.0;1634
-5B8B;1.0;3355
-5B8C;1.0;2016
-5B8D;1.0;2821
-5B8F;1.0;2508
-5B95;1.0;3770
-5B97;1.0;2901
-5B98;1.0;2017
-5B99;1.0;3572
-5B9A;1.0;3674
-5B9B;1.0;1624
-5B9C;1.0;2125
-5B9D;1.0;4285
-5B9F;1.0;2834
-5BA2;1.0;2150
-5BA3;1.0;3275
-5BA4;1.0;2828
-5BA5;1.0;4508
-5BA6;1.0;5365
-5BAE;1.0;2160
-5BB0;1.0;2643
-5BB3;1.0;1918
-5BB4;1.0;1767
-5BB5;1.0;3012
-5BB6;1.0;1840
-5BB8;1.0;5366
-5BB9;1.0;4538
-5BBF;1.0;2941
-5BC2;1.0;2868
-5BC3;1.0;5367
-5BC4;1.0;2083
-5BC5;1.0;3850
-5BC6;1.0;4409
-5BC7;1.0;5368
-5BC9;1.0;5369
-5BCC;1.0;4157
-5BD0;1.0;5371
-5BD2;1.0;2008
-5BD3;1.0;2287
-5BD4;1.0;5370
-5BDB;1.0;2018
-5BDD;1.0;3118
-5BDE;1.0;5375
-5BDF;1.0;2701
-5BE1;1.0;1841
-5BE2;1.0;5374
-5BE4;1.0;5372
-5BE5;1.0;5376
-5BE6;1.0;5373
-5BE7;1.0;3911
-5BE8;1.0;6045
-5BE9;1.0;3119
-5BEB;1.0;5377
-5BEE;1.0;4632
-5BF0;1.0;5378
-5BF3;1.0;5380
-5BF5;1.0;3594
-5BF6;1.0;5379
-5BF8;1.0;3203
-5BFA;1.0;2791
-5BFE;1.0;3448
-5BFF;1.0;2887
-5C01;1.0;4185
-5C02;1.0;3276
-5C04;1.0;2845
-5C05;1.0;5381
-5C06;1.0;3013
-5C07;1.0;5382
-5C08;1.0;5383
-5C09;1.0;1651
-5C0A;1.0;3426
-5C0B;1.0;3150
-5C0D;1.0;5384
-5C0E;1.0;3819
-5C0F;1.0;3014
-5C11;1.0;3015
-5C13;1.0;5385
-5C16;1.0;3277
-5C1A;1.0;3016
-5C20;1.0;5386
-5C22;1.0;5387
-5C24;1.0;4464
-5C28;1.0;5388
-5C2D;1.0;2238
-5C31;1.0;2902
-5C38;1.0;5389
-5C39;1.0;5390
-5C3A;1.0;2860
-5C3B;1.0;3112
-5C3C;1.0;3884
-5C3D;1.0;3152
-5C3E;1.0;4088
-5C3F;1.0;3902
-5C40;1.0;2241
-5C41;1.0;5391
-5C45;1.0;2179
-5C46;1.0;5392
-5C48;1.0;2294
-5C4A;1.0;3847
-5C4B;1.0;1816
-5C4D;1.0;2751
-5C4E;1.0;5393
-5C4F;1.0;5402
-5C50;1.0;5401
-5C51;1.0;2293
-5C53;1.0;5394
-5C55;1.0;3724
-5C5E;1.0;3416
-5C60;1.0;3743
-5C61;1.0;2840
-5C64;1.0;3356
-5C65;1.0;4590
-5C6C;1.0;5404
-5C6E;1.0;5405
-5C6F;1.0;3854
-5C71;1.0;2719
-5C76;1.0;5407
-5C79;1.0;5408
-5C8C;1.0;5409
-5C90;1.0;2084
-5C91;1.0;5410
-5C94;1.0;5411
-5CA1;1.0;1812
-5CA8;1.0;3327
-5CA9;1.0;2068
-5CAB;1.0;5413
-5CAC;1.0;4408
-5CB1;1.0;3450
-5CB3;1.0;1957
-5CB6;1.0;5415
-5CB7;1.0;5417
-5CB8;1.0;2063
-5CBB;1.0;5414
-5CBC;1.0;5416
-5CBE;1.0;5419
-5CC5;1.0;5418
-5CC7;1.0;5420
-5CD9;1.0;5421
-5CE0;1.0;3829
-5CE1;1.0;2214
-5CE8;1.0;1869
-5CE9;1.0;5422
-5CEA;1.0;5427
-5CED;1.0;5425
-5CEF;1.0;4287
-5CF0;1.0;4286
-5CF6;1.0;3771
-5CFA;1.0;5424
-5CFB;1.0;2952
-5CFD;1.0;5423
-5D07;1.0;3182
-5D0B;1.0;5428
-5D0E;1.0;2674
-5D11;1.0;5434
-5D14;1.0;5435
-5D15;1.0;5429
-5D16;1.0;1919
-5D17;1.0;5430
-5D18;1.0;5439
-5D19;1.0;5438
-5D1A;1.0;5437
-5D1B;1.0;5433
-5D1F;1.0;5432
-5D22;1.0;5436
-5D29;1.0;4288
-5D4B;1.0;5443
-5D4C;1.0;5440
-5D4E;1.0;5442
-5D50;1.0;4582
-5D52;1.0;5441
-5D5C;1.0;5431
-5D69;1.0;3183
-5D6C;1.0;5444
-5D6F;1.0;2623
-5D73;1.0;5445
-5D76;1.0;5446
-5D82;1.0;5449
-5D84;1.0;5448
-5D87;1.0;5447
-5D8B;1.0;3772
-5D8C;1.0;5426
-5D90;1.0;5455
-5D9D;1.0;5451
-5DA2;1.0;5450
-5DAC;1.0;5452
-5DAE;1.0;5453
-5DB7;1.0;5456
-5DBA;1.0;4670
-5DBC;1.0;5457
-5DBD;1.0;5454
-5DC9;1.0;5458
-5DCC;1.0;2064
-5DCD;1.0;5459
-5DD2;1.0;5461
-5DD3;1.0;5460
-5DD6;1.0;5462
-5DDB;1.0;5463
-5DDD;1.0;3278
-5DDE;1.0;2903
-5DE1;1.0;2968
-5DE3;1.0;3367
-5DE5;1.0;2509
-5DE6;1.0;2624
-5DE7;1.0;2510
-5DE8;1.0;2180
-5DEB;1.0;5464
-5DEE;1.0;2625
-5DF1;1.0;2442
-5DF2;1.0;5465
-5DF3;1.0;4406
-5DF4;1.0;3935
-5DF5;1.0;5466
-5DF7;1.0;2511
-5DFB;1.0;2012
-5DFD;1.0;3507
-5DFE;1.0;2250
-5E02;1.0;2752
-5E03;1.0;4159
-5E06;1.0;4033
-5E0B;1.0;5467
-5E0C;1.0;2085
-5E11;1.0;5470
-5E16;1.0;3601
-5E19;1.0;5469
-5E1A;1.0;5468
-5E1B;1.0;5471
-5E1D;1.0;3675
-5E25;1.0;3167
-5E2B;1.0;2753
-5E2D;1.0;3242
-5E2F;1.0;3451
-5E30;1.0;2102
-5E33;1.0;3602
-5E36;1.0;5472
-5E37;1.0;5473
-5E38;1.0;3079
-5E3D;1.0;4325
-5E40;1.0;5476
-5E43;1.0;5475
-5E44;1.0;5474
-5E45;1.0;4193
-5E47;1.0;5483
-5E4C;1.0;4358
-5E4E;1.0;5477
-5E54;1.0;5479
-5E55;1.0;4375
-5E57;1.0;5478
-5E5F;1.0;5480
-5E61;1.0;4008
-5E62;1.0;5481
-5E63;1.0;4230
-5E64;1.0;5482
-5E72;1.0;2019
-5E73;1.0;4231
-5E74;1.0;3915
-5E75;1.0;5484
-5E76;1.0;5485
-5E78;1.0;2512
-5E79;1.0;2020
-5E7A;1.0;5486
-5E7B;1.0;2424
-5E7C;1.0;4536
-5E7D;1.0;4509
-5E7E;1.0;2086
-5E7F;1.0;5488
-5E81;1.0;3603
-5E83;1.0;2513
-5E84;1.0;3017
-5E87;1.0;4063
-5E8A;1.0;3018
-5E8F;1.0;2988
-5E95;1.0;3676
-5E96;1.0;4289
-5E97;1.0;3725
-5E9A;1.0;2514
-5E9C;1.0;4160
-5EA0;1.0;5489
-5EA6;1.0;3757
-5EA7;1.0;2634
-5EAB;1.0;2443
-5EAD;1.0;3677
-5EB5;1.0;1635
-5EB6;1.0;2978
-5EB7;1.0;2515
-5EB8;1.0;4539
-5EC1;1.0;5490
-5EC2;1.0;5491
-5EC3;1.0;3949
-5EC8;1.0;5492
-5EC9;1.0;4687
-5ECA;1.0;4713
-5ECF;1.0;5494
-5ED0;1.0;5493
-5ED3;1.0;1939
-5ED6;1.0;5501
-5EDA;1.0;5504
-5EDB;1.0;5505
-5EDD;1.0;5503
-5EDF;1.0;4132
-5EE0;1.0;3019
-5EE1;1.0;5507
-5EE2;1.0;5506
-5EE3;1.0;5502
-5EE8;1.0;5508
-5EE9;1.0;5509
-5EEC;1.0;5510
-5EF0;1.0;5513
-5EF1;1.0;5511
-5EF3;1.0;5512
-5EF4;1.0;5514
-5EF6;1.0;1768
-5EF7;1.0;3678
-5EF8;1.0;5515
-5EFA;1.0;2390
-5EFB;1.0;1886
-5EFC;1.0;3922
-5EFE;1.0;5516
-5EFF;1.0;3891
-5F01;1.0;4259
-5F03;1.0;5517
-5F04;1.0;4714
-5F09;1.0;5518
-5F0A;1.0;4232
-5F0B;1.0;5521
-5F0C;1.0;4801
-5F0D;1.0;4817
-5F0F;1.0;2816
-5F10;1.0;3885
-5F11;1.0;5522
-5F13;1.0;2161
-5F14;1.0;3604
-5F15;1.0;1690
-5F16;1.0;5523
-5F17;1.0;4206
-5F18;1.0;2516
-5F1B;1.0;3548
-5F1F;1.0;3679
-5F25;1.0;4479
-5F26;1.0;2425
-5F27;1.0;2444
-5F29;1.0;5524
-5F2D;1.0;5525
-5F2F;1.0;5531
-5F31;1.0;2869
-5F35;1.0;3605
-5F37;1.0;2215
-5F38;1.0;5526
-5F3C;1.0;4111
-5F3E;1.0;3538
-5F41;1.0;5527
-5F48;1.0;5528
-5F4A;1.0;2216
-5F4C;1.0;5529
-5F4E;1.0;5530
-5F51;1.0;5532
-5F53;1.0;3786
-5F56;1.0;5533
-5F57;1.0;5534
-5F59;1.0;5535
-5F5C;1.0;5520
-5F5D;1.0;5519
-5F61;1.0;5536
-5F62;1.0;2333
-5F66;1.0;4107
-5F69;1.0;2644
-5F6A;1.0;4123
-5F6B;1.0;3606
-5F6C;1.0;4143
-5F6D;1.0;5537
-5F70;1.0;3020
-5F71;1.0;1738
-5F73;1.0;5538
-5F77;1.0;5539
-5F79;1.0;4482
-5F7C;1.0;4064
-5F7F;1.0;5542
-5F80;1.0;1793
-5F81;1.0;3212
-5F82;1.0;5541
-5F83;1.0;5540
-5F84;1.0;2334
-5F85;1.0;3452
-5F87;1.0;5546
-5F88;1.0;5544
-5F8A;1.0;5543
-5F8B;1.0;4607
-5F8C;1.0;2469
-5F90;1.0;2989
-5F91;1.0;5545
-5F92;1.0;3744
-5F93;1.0;2930
-5F97;1.0;3832
-5F98;1.0;5549
-5F99;1.0;5548
-5F9E;1.0;5547
-5FA0;1.0;5550
-5FA1;1.0;2470
-5FA8;1.0;5551
-5FA9;1.0;4192
-5FAA;1.0;2959
-5FAD;1.0;5552
-5FAE;1.0;4089
-5FB3;1.0;3833
-5FB4;1.0;3607
-5FB9;1.0;3716
-5FBC;1.0;5553
-5FBD;1.0;2111
-5FC3;1.0;3120
-5FC5;1.0;4112
-5FCC;1.0;2087
-5FCD;1.0;3906
-5FD6;1.0;5554
-5FD7;1.0;2754
-5FD8;1.0;4326
-5FD9;1.0;4327
-5FDC;1.0;1794
-5FDD;1.0;5559
-5FE0;1.0;3573
-5FE4;1.0;5556
-5FEB;1.0;1887
-5FF0;1.0;5613
-5FF1;1.0;5558
-5FF5;1.0;3916
-5FF8;1.0;5557
-5FFB;1.0;5555
-5FFD;1.0;2590
-5FFF;1.0;5561
-600E;1.0;5567
-600F;1.0;5573
-6010;1.0;5565
-6012;1.0;3760
-6015;1.0;5570
-6016;1.0;4161
-6019;1.0;5564
-601B;1.0;5569
-601C;1.0;4671
-601D;1.0;2755
-6020;1.0;3453
-6021;1.0;5562
-6025;1.0;2162
-6026;1.0;5572
-6027;1.0;3213
-6028;1.0;1769
-6029;1.0;5566
-602A;1.0;1888
-602B;1.0;5571
-602F;1.0;2217
-6031;1.0;5568
-603A;1.0;5574
-6041;1.0;5576
-6042;1.0;5586
-6043;1.0;5584
-6046;1.0;5581
-604A;1.0;5580
-604B;1.0;4688
-604D;1.0;5582
-6050;1.0;2218
-6052;1.0;2517
-6055;1.0;2990
-6059;1.0;5589
-605A;1.0;5575
-605F;1.0;5579
-6060;1.0;5563
-6062;1.0;1890
-6063;1.0;5583
-6064;1.0;5585
-6065;1.0;3549
-6068;1.0;2608
-6069;1.0;1824
-606A;1.0;5577
-606B;1.0;5588
-606C;1.0;5587
-606D;1.0;2219
-606F;1.0;3409
-6070;1.0;1970
-6075;1.0;2335
-6077;1.0;5578
-6081;1.0;5590
-6083;1.0;5593
-6084;1.0;5601
-6089;1.0;2829
-608B;1.0;5607
-608C;1.0;3680
-608D;1.0;5591
-6092;1.0;5605
-6094;1.0;1889
-6096;1.0;5603
-6097;1.0;5604
-609A;1.0;5594
-609B;1.0;5602
-609F;1.0;2471
-60A0;1.0;4510
-60A3;1.0;2021
-60A6;1.0;1757
-60A7;1.0;5606
-60A9;1.0;3926
-60AA;1.0;1613
-60B2;1.0;4065
-60B3;1.0;5560
-60B4;1.0;5612
-60B5;1.0;5616
-60B6;1.0;4469
-60B8;1.0;5609
-60BC;1.0;3773
-60BD;1.0;5614
-60C5;1.0;3080
-60C6;1.0;5615
-60C7;1.0;3855
-60D1;1.0;4739
-60D3;1.0;5611
-60D8;1.0;5617
-60DA;1.0;2591
-60DC;1.0;3243
-60DF;1.0;1652
-60E0;1.0;5610
-60E1;1.0;5608
-60E3;1.0;3358
-60E7;1.0;5592
-60E8;1.0;2720
-60F0;1.0;3438
-60F1;1.0;5629
-60F3;1.0;3359
-60F4;1.0;5624
-60F6;1.0;5621
-60F7;1.0;5622
-60F9;1.0;2870
-60FA;1.0;5625
-60FB;1.0;5628
-6100;1.0;5623
-6101;1.0;2905
-6103;1.0;5626
-6106;1.0;5620
-6108;1.0;4492
-6109;1.0;4491
-610D;1.0;5630
-610E;1.0;5631
-610F;1.0;1653
-6115;1.0;5619
-611A;1.0;2282
-611B;1.0;1606
-611F;1.0;2022
-6121;1.0;5627
-6127;1.0;5635
-6128;1.0;5634
-612C;1.0;5639
-6134;1.0;5640
-613C;1.0;5638
-613D;1.0;5641
-613E;1.0;5633
-613F;1.0;5637
-6142;1.0;5642
-6144;1.0;5643
-6147;1.0;5632
-6148;1.0;2792
-614A;1.0;5636
-614B;1.0;3454
-614C;1.0;2518
-614D;1.0;5618
-614E;1.0;3121
-6153;1.0;5656
-6155;1.0;4273
-6158;1.0;5646
-6159;1.0;5647
-615A;1.0;5648
-615D;1.0;5655
-615F;1.0;5654
-6162;1.0;4393
-6163;1.0;2023
-6165;1.0;5652
-6167;1.0;2337
-6168;1.0;1920
-616B;1.0;5649
-616E;1.0;4624
-616F;1.0;5651
-6170;1.0;1654
-6171;1.0;5653
-6173;1.0;5644
-6174;1.0;5650
-6175;1.0;5657
-6176;1.0;2336
-6177;1.0;5645
-617E;1.0;4561
-6182;1.0;4511
-6187;1.0;5660
-618A;1.0;5664
-618E;1.0;3394
-6190;1.0;4689
-6191;1.0;5665
-6194;1.0;5662
-6196;1.0;5659
-6199;1.0;5658
-619A;1.0;5663
-61A4;1.0;4216
-61A7;1.0;3820
-61A9;1.0;2338
-61AB;1.0;5666
-61AC;1.0;5661
-61AE;1.0;5667
-61B2;1.0;2391
-61B6;1.0;1817
-61BA;1.0;5675
-61BE;1.0;2024
-61C3;1.0;5673
-61C6;1.0;5674
-61C7;1.0;2609
-61C8;1.0;5672
-61C9;1.0;5670
-61CA;1.0;5669
-61CB;1.0;5676
-61CC;1.0;5668
-61CD;1.0;5678
-61D0;1.0;1891
-61E3;1.0;5680
-61E6;1.0;5679
-61F2;1.0;3608
-61F4;1.0;5683
-61F6;1.0;5681
-61F7;1.0;5671
-61F8;1.0;2392
-61FA;1.0;5682
-61FC;1.0;5686
-61FD;1.0;5685
-61FE;1.0;5687
-61FF;1.0;5684
-6200;1.0;5688
-6208;1.0;5689
-6209;1.0;5690
-620A;1.0;4274
-620C;1.0;5692
-620D;1.0;5691
-620E;1.0;2931
-6210;1.0;3214
-6211;1.0;1870
-6212;1.0;1892
-6214;1.0;5693
-6216;1.0;1631
-621A;1.0;3244
-621B;1.0;5694
-621D;1.0;7635
-621E;1.0;5701
-621F;1.0;2365
-6221;1.0;5702
-6226;1.0;3279
-622A;1.0;5703
-622E;1.0;5704
-622F;1.0;2126
-6230;1.0;5705
-6232;1.0;5706
-6233;1.0;5707
-6234;1.0;3455
-6238;1.0;2445
-623B;1.0;4465
-623F;1.0;4328
-6240;1.0;2974
-6241;1.0;5708
-6247;1.0;3280
-6248;1.0;7829
-6249;1.0;4066
-624B;1.0;2874
-624D;1.0;2645
-624E;1.0;5709
-6253;1.0;3439
-6255;1.0;4207
-6258;1.0;3481
-625B;1.0;5712
-625E;1.0;5710
-6260;1.0;5713
-6263;1.0;5711
-6268;1.0;5714
-626E;1.0;4217
-6271;1.0;1623
-6276;1.0;4162
-6279;1.0;4067
-627C;1.0;5715
-627E;1.0;5718
-627F;1.0;3021
-6280;1.0;2127
-6282;1.0;5716
-6283;1.0;5723
-6284;1.0;3022
-6289;1.0;5717
-628A;1.0;3936
-6291;1.0;4562
-6292;1.0;5719
-6293;1.0;5720
-6294;1.0;5724
-6295;1.0;3774
-6296;1.0;5721
-6297;1.0;2519
-6298;1.0;3262
-629B;1.0;5738
-629C;1.0;4020
-629E;1.0;3482
-62AB;1.0;4068
-62AC;1.0;5813
-62B1;1.0;4290
-62B5;1.0;3681
-62B9;1.0;4385
-62BB;1.0;5727
-62BC;1.0;1801
-62BD;1.0;3574
-62C2;1.0;5736
-62C5;1.0;3520
-62C6;1.0;5730
-62C7;1.0;5737
-62C8;1.0;5732
-62C9;1.0;5739
-62CA;1.0;5735
-62CC;1.0;5734
-62CD;1.0;3979
-62CF;1.0;5728
-62D0;1.0;1893
-62D1;1.0;5726
-62D2;1.0;2181
-62D3;1.0;3483
-62D4;1.0;5722
-62D7;1.0;5725
-62D8;1.0;2520
-62D9;1.0;3259
-62DB;1.0;3023
-62DC;1.0;5733
-62DD;1.0;3950
-62E0;1.0;2182
-62E1;1.0;1940
-62EC;1.0;1971
-62ED;1.0;3101
-62EE;1.0;5741
-62EF;1.0;5746
-62F1;1.0;5742
-62F3;1.0;2393
-62F5;1.0;5747
-62F6;1.0;2702
-62F7;1.0;2573
-62FE;1.0;2906
-62FF;1.0;5729
-6301;1.0;2793
-6302;1.0;5744
-6307;1.0;2756
-6308;1.0;5745
-6309;1.0;1636
-630C;1.0;5740
-6311;1.0;3609
-6319;1.0;2183
-631F;1.0;2220
-6327;1.0;5743
-6328;1.0;1607
-632B;1.0;2635
-632F;1.0;3122
-633A;1.0;3682
-633D;1.0;4052
-633E;1.0;5749
-633F;1.0;3362
-6349;1.0;3410
-634C;1.0;2711
-634D;1.0;5750
-634F;1.0;5752
-6350;1.0;5748
-6355;1.0;4265
-6357;1.0;3629
-635C;1.0;3360
-6367;1.0;4291
-6368;1.0;2846
-6369;1.0;5764
-636B;1.0;5763
-636E;1.0;3188
-6372;1.0;2394
-6376;1.0;5757
-6377;1.0;3025
-637A;1.0;3872
-637B;1.0;3917
-6380;1.0;5755
-6383;1.0;3361
-6388;1.0;2888
-6389;1.0;5760
-638C;1.0;3024
-638E;1.0;5754
-638F;1.0;5759
-6392;1.0;3951
-6396;1.0;5753
-6398;1.0;2301
-639B;1.0;1961
-639F;1.0;5761
-63A0;1.0;4611
-63A1;1.0;2646
-63A2;1.0;3521
-63A3;1.0;5758
-63A5;1.0;3260
-63A7;1.0;2521
-63A8;1.0;3168
-63A9;1.0;1770
-63AA;1.0;3328
-63AB;1.0;5756
-63AC;1.0;2137
-63B2;1.0;2339
-63B4;1.0;3647
-63B5;1.0;5762
-63BB;1.0;3363
-63BE;1.0;5765
-63C0;1.0;5767
-63C3;1.0;3423
-63C4;1.0;5773
-63C6;1.0;5768
-63C9;1.0;5770
-63CF;1.0;4133
-63D0;1.0;3683
-63D2;1.0;5771
-63D6;1.0;4512
-63DA;1.0;4540
-63DB;1.0;2025
-63E1;1.0;1614
-63E3;1.0;5769
-63E9;1.0;5766
-63EE;1.0;2088
-63F4;1.0;1771
-63F6;1.0;5772
-63FA;1.0;4541
-6406;1.0;5776
-640D;1.0;3427
-640F;1.0;5783
-6413;1.0;5777
-6416;1.0;5774
-6417;1.0;5781
-641C;1.0;5751
-6426;1.0;5778
-6428;1.0;5782
-642C;1.0;4034
-642D;1.0;3775
-6434;1.0;5775
-6436;1.0;5779
-643A;1.0;2340
-643E;1.0;2681
-6442;1.0;3261
-644E;1.0;5787
-6458;1.0;3706
-6467;1.0;5784
-6469;1.0;4364
-646F;1.0;5785
-6476;1.0;5786
-6478;1.0;4446
-647A;1.0;3202
-6483;1.0;2366
-6488;1.0;5793
-6492;1.0;2721
-6493;1.0;5790
-6495;1.0;5789
-649A;1.0;3918
-649E;1.0;3821
-64A4;1.0;3717
-64A5;1.0;5791
-64A9;1.0;5792
-64AB;1.0;4179
-64AD;1.0;3937
-64AE;1.0;2703
-64B0;1.0;3281
-64B2;1.0;4348
-64B9;1.0;1941
-64BB;1.0;5805
-64BC;1.0;5794
-64C1;1.0;4542
-64C2;1.0;5807
-64C5;1.0;5803
-64C7;1.0;5804
-64CD;1.0;3364
-64D2;1.0;5802
-64D4;1.0;5731
-64D8;1.0;5806
-64DA;1.0;5801
-64E0;1.0;5811
-64E1;1.0;5812
-64E2;1.0;3707
-64E3;1.0;5814
-64E6;1.0;2704
-64E7;1.0;5809
-64EC;1.0;2128
-64EF;1.0;5815
-64F1;1.0;5808
-64F2;1.0;5819
-64F4;1.0;5818
-64F6;1.0;5817
-64FA;1.0;5820
-64FD;1.0;5822
-64FE;1.0;3081
-6500;1.0;5821
-6505;1.0;5825
-6518;1.0;5823
-651C;1.0;5824
-651D;1.0;5780
-6523;1.0;5827
-6524;1.0;5826
-652A;1.0;5788
-652B;1.0;5828
-652C;1.0;5816
-652F;1.0;2757
-6534;1.0;5829
-6535;1.0;5830
-6536;1.0;5832
-6537;1.0;5831
-6538;1.0;5833
-6539;1.0;1894
-653B;1.0;2522
-653E;1.0;4292
-653F;1.0;3215
-6545;1.0;2446
-6548;1.0;5835
-654D;1.0;5838
-654F;1.0;4150
-6551;1.0;2163
-6555;1.0;5837
-6556;1.0;5836
-6557;1.0;3952
-6558;1.0;5839
-6559;1.0;2221
-655D;1.0;5841
-655E;1.0;5840
-6562;1.0;2026
-6563;1.0;2722
-6566;1.0;3856
-656C;1.0;2341
-6570;1.0;3184
-6572;1.0;5842
-6574;1.0;3216
-6575;1.0;3708
-6577;1.0;4163
-6578;1.0;5843
-6582;1.0;5844
-6583;1.0;5845
-6587;1.0;4224
-6588;1.0;5361
-6589;1.0;3238
-658C;1.0;4144
-658E;1.0;2656
-6590;1.0;4069
-6591;1.0;4035
-6597;1.0;3745
-6599;1.0;4633
-659B;1.0;5847
-659C;1.0;2848
-659F;1.0;5848
-65A1;1.0;1622
-65A4;1.0;2252
-65A5;1.0;3245
-65A7;1.0;4164
-65AB;1.0;5849
-65AC;1.0;2734
-65AD;1.0;3539
-65AF;1.0;2759
-65B0;1.0;3123
-65B7;1.0;5850
-65B9;1.0;4293
-65BC;1.0;1787
-65BD;1.0;2760
-65C1;1.0;5853
-65C3;1.0;5851
-65C4;1.0;5854
-65C5;1.0;4625
-65C6;1.0;5852
-65CB;1.0;3291
-65CC;1.0;5855
-65CF;1.0;3418
-65D2;1.0;5856
-65D7;1.0;2090
-65D9;1.0;5858
-65DB;1.0;5857
-65E0;1.0;5859
-65E1;1.0;5860
-65E2;1.0;2091
-65E5;1.0;3892
-65E6;1.0;3522
-65E7;1.0;2176
-65E8;1.0;2761
-65E9;1.0;3365
-65EC;1.0;2960
-65ED;1.0;1616
-65F1;1.0;5861
-65FA;1.0;1802
-65FB;1.0;5865
-6602;1.0;2523
-6603;1.0;5864
-6606;1.0;2611
-6607;1.0;3026
-660A;1.0;5863
-660C;1.0;3027
-660E;1.0;4432
-660F;1.0;2610
-6613;1.0;1655
-6614;1.0;3246
-661C;1.0;5870
-661F;1.0;3217
-6620;1.0;1739
-6625;1.0;2953
-6627;1.0;4370
-6628;1.0;2682
-662D;1.0;3028
-662F;1.0;3207
-6634;1.0;5869
-6635;1.0;5867
-6636;1.0;5868
-663C;1.0;3575
-663F;1.0;5906
-6641;1.0;5874
-6642;1.0;2794
-6643;1.0;2524
-6644;1.0;5872
-6649;1.0;5873
-664B;1.0;3124
-664F;1.0;5871
-6652;1.0;2715
-665D;1.0;5876
-665E;1.0;5875
-665F;1.0;5880
-6662;1.0;5881
-6664;1.0;5877
-6666;1.0;1902
-6667;1.0;5878
-6668;1.0;5879
-6669;1.0;4053
-666E;1.0;4165
-666F;1.0;2342
-6670;1.0;5882
-6674;1.0;3218
-6676;1.0;3029
-667A;1.0;3550
-6681;1.0;2239
-6683;1.0;5883
-6684;1.0;5887
-6687;1.0;1843
-6688;1.0;5884
-6689;1.0;5886
-668E;1.0;5885
-6691;1.0;2975
-6696;1.0;3540
-6697;1.0;1637
-6698;1.0;5888
-669D;1.0;5889
-66A2;1.0;3610
-66A6;1.0;4681
-66AB;1.0;2735
-66AE;1.0;4275
-66B4;1.0;4329
-66B8;1.0;5902
-66B9;1.0;5891
-66BC;1.0;5894
-66BE;1.0;5893
-66C1;1.0;5890
-66C4;1.0;5901
-66C7;1.0;3862
-66C9;1.0;5892
-66D6;1.0;5903
-66D9;1.0;2976
-66DA;1.0;5904
-66DC;1.0;4543
-66DD;1.0;3988
-66E0;1.0;5905
-66E6;1.0;5907
-66E9;1.0;5908
-66F0;1.0;5909
-66F2;1.0;2242
-66F3;1.0;1740
-66F4;1.0;2525
-66F5;1.0;5910
-66F7;1.0;5911
-66F8;1.0;2981
-66F9;1.0;3366
-66FC;1.0;5056
-66FD;1.0;3330
-66FE;1.0;3329
-66FF;1.0;3456
-6700;1.0;2639
-6703;1.0;4882
-6708;1.0;2378
-6709;1.0;4513
-670B;1.0;4294
-670D;1.0;4194
-670F;1.0;5912
-6714;1.0;2683
-6715;1.0;3631
-6716;1.0;5913
-6717;1.0;4715
-671B;1.0;4330
-671D;1.0;3611
-671E;1.0;5914
-671F;1.0;2092
-6726;1.0;5915
-6727;1.0;5916
-6728;1.0;4458
-672A;1.0;4404
-672B;1.0;4386
-672C;1.0;4360
-672D;1.0;2705
-672E;1.0;5918
-6731;1.0;2875
-6734;1.0;4349
-6736;1.0;5920
-6737;1.0;5923
-6738;1.0;5922
-673A;1.0;2089
-673D;1.0;2164
-673F;1.0;5919
-6741;1.0;5921
-6746;1.0;5924
-6749;1.0;3189
-674E;1.0;4591
-674F;1.0;1641
-6750;1.0;2664
-6751;1.0;3428
-6753;1.0;2861
-6756;1.0;3083
-6759;1.0;5927
-675C;1.0;3746
-675E;1.0;5925
-675F;1.0;3411
-6760;1.0;5926
-6761;1.0;3082
-6762;1.0;4461
-6763;1.0;5928
-6764;1.0;5929
-6765;1.0;4572
-676A;1.0;5934
-676D;1.0;2526
-676F;1.0;3953
-6770;1.0;5931
-6771;1.0;3776
-6772;1.0;5862
-6773;1.0;5866
-6775;1.0;2147
-6777;1.0;3939
-677C;1.0;5933
-677E;1.0;3030
-677F;1.0;4036
-6785;1.0;5939
-6787;1.0;4090
-6789;1.0;5930
-678B;1.0;5936
-678C;1.0;5935
-6790;1.0;3247
-6795;1.0;4377
-6797;1.0;4651
-679A;1.0;4371
-679C;1.0;1844
-679D;1.0;2762
-67A0;1.0;4740
-67A1;1.0;5938
-67A2;1.0;3185
-67A6;1.0;5937
-67A9;1.0;5932
-67AF;1.0;2447
-67B3;1.0;5944
-67B4;1.0;5942
-67B6;1.0;1845
-67B7;1.0;5940
-67B8;1.0;5946
-67B9;1.0;5952
-67C1;1.0;3440
-67C4;1.0;4233
-67C6;1.0;5954
-67CA;1.0;4102
-67CE;1.0;5953
-67CF;1.0;3980
-67D0;1.0;4331
-67D1;1.0;2027
-67D3;1.0;3287
-67D4;1.0;2932
-67D8;1.0;3651
-67DA;1.0;4514
-67DD;1.0;5949
-67DE;1.0;5948
-67E2;1.0;5950
-67E4;1.0;5947
-67E7;1.0;5955
-67E9;1.0;5945
-67EC;1.0;5943
-67EE;1.0;5951
-67EF;1.0;5941
-67F1;1.0;3576
-67F3;1.0;4488
-67F4;1.0;2838
-67F5;1.0;2684
-67FB;1.0;2626
-67FE;1.0;4379
-67FF;1.0;1933
-6802;1.0;3646
-6803;1.0;3842
-6804;1.0;1741
-6813;1.0;3282
-6816;1.0;3220
-6817;1.0;2310
-681E;1.0;5957
-6821;1.0;2527
-6822;1.0;1992
-6829;1.0;5959
-682A;1.0;1984
-682B;1.0;5965
-6832;1.0;5962
-6834;1.0;3283
-6838;1.0;1943
-6839;1.0;2612
-683C;1.0;1942
-683D;1.0;2647
-6840;1.0;5960
-6841;1.0;2369
-6842;1.0;2343
-6843;1.0;3777
-6846;1.0;5958
-6848;1.0;1638
-684D;1.0;5961
-684E;1.0;5963
-6850;1.0;2245
-6851;1.0;2312
-6853;1.0;2028
-6854;1.0;2143
-6859;1.0;5966
-685C;1.0;2689
-685D;1.0;4381
-685F;1.0;2723
-6863;1.0;5967
-6867;1.0;4116
-6874;1.0;5979
-6876;1.0;1819
-6877;1.0;5968
-687E;1.0;5985
-687F;1.0;5969
-6881;1.0;4634
-6883;1.0;5976
-6885;1.0;3963
-688D;1.0;5984
-688F;1.0;5971
-6893;1.0;1620
-6894;1.0;5973
-6897;1.0;2528
-689B;1.0;5975
-689D;1.0;5974
-689F;1.0;5970
-68A0;1.0;5981
-68A2;1.0;3031
-68A6;1.0;5277
-68A7;1.0;2472
-68A8;1.0;4592
-68AD;1.0;5972
-68AF;1.0;3684
-68B0;1.0;1903
-68B1;1.0;2613
-68B3;1.0;5964
-68B5;1.0;5980
-68B6;1.0;1965
-68B9;1.0;5978
-68BA;1.0;5982
-68BC;1.0;3778
-68C4;1.0;2094
-68C6;1.0;6018
-68C9;1.0;4441
-68CA;1.0;5987
-68CB;1.0;2093
-68CD;1.0;5994
-68D2;1.0;4332
-68D4;1.0;6001
-68D5;1.0;6003
-68D7;1.0;6007
-68D8;1.0;5989
-68DA;1.0;3510
-68DF;1.0;3779
-68E0;1.0;6011
-68E1;1.0;5992
-68E3;1.0;6008
-68E7;1.0;6002
-68EE;1.0;3125
-68EF;1.0;6012
-68F2;1.0;3219
-68F9;1.0;6010
-68FA;1.0;2029
-6900;1.0;4748
-6901;1.0;5986
-6904;1.0;6006
-6905;1.0;1656
-6908;1.0;5988
-690B;1.0;4426
-690C;1.0;5993
-690D;1.0;3102
-690E;1.0;3639
-690F;1.0;5983
-6912;1.0;6005
-6919;1.0;3190
-691A;1.0;6015
-691B;1.0;1981
-691C;1.0;2401
-6921;1.0;6017
-6922;1.0;5990
-6923;1.0;6016
-6925;1.0;6009
-6926;1.0;5991
-6928;1.0;6013
-692A;1.0;6014
-6930;1.0;6031
-6934;1.0;3846
-6936;1.0;6004
-6939;1.0;6027
-693D;1.0;6029
-693F;1.0;3656
-694A;1.0;4544
-6953;1.0;4186
-6954;1.0;6024
-6955;1.0;3442
-6959;1.0;6030
-695A;1.0;3331
-695C;1.0;6021
-695D;1.0;6034
-695E;1.0;6033
-6960;1.0;3879
-6961;1.0;6032
-6962;1.0;3874
-696A;1.0;6036
-696B;1.0;6023
-696D;1.0;2240
-696E;1.0;6026
-696F;1.0;2961
-6973;1.0;3964
-6974;1.0;6028
-6975;1.0;2243
-6977;1.0;6020
-6978;1.0;6022
-6979;1.0;6019
-697C;1.0;4716
-697D;1.0;1958
-697E;1.0;6025
-6981;1.0;6035
-6982;1.0;1921
-698A;1.0;2671
-698E;1.0;1761
-6991;1.0;6052
-6994;1.0;4717
-6995;1.0;6055
-699B;1.0;3126
-699C;1.0;6054
-69A0;1.0;6053
-69A7;1.0;6050
-69AE;1.0;6038
-69B1;1.0;6067
-69B2;1.0;6037
-69B4;1.0;6056
-69BB;1.0;6048
-69BE;1.0;6043
-69BF;1.0;6040
-69C1;1.0;6041
-69C3;1.0;6049
-69C7;1.0;8402
-69CA;1.0;6046
-69CB;1.0;2529
-69CC;1.0;3640
-69CD;1.0;3368
-69CE;1.0;6044
-69D0;1.0;6039
-69D3;1.0;6042
-69D8;1.0;4545
-69D9;1.0;4374
-69DD;1.0;6047
-69DE;1.0;6057
-69E7;1.0;6065
-69E8;1.0;6058
-69EB;1.0;6071
-69ED;1.0;6069
-69F2;1.0;6064
-69F9;1.0;6063
-69FB;1.0;3648
-69FD;1.0;3369
-69FF;1.0;6061
-6A02;1.0;6059
-6A05;1.0;6066
-6A0A;1.0;6072
-6A0B;1.0;4085
-6A0C;1.0;6078
-6A12;1.0;6073
-6A13;1.0;6076
-6A14;1.0;6070
-6A17;1.0;3584
-6A19;1.0;4124
-6A1B;1.0;6060
-6A1E;1.0;6068
-6A1F;1.0;3032
-6A21;1.0;4447
-6A22;1.0;6088
-6A23;1.0;6075
-6A29;1.0;2402
-6A2A;1.0;1803
-6A2B;1.0;1963
-6A2E;1.0;6051
-6A35;1.0;3033
-6A36;1.0;6080
-6A38;1.0;6087
-6A39;1.0;2889
-6A3A;1.0;1982
-6A3D;1.0;3514
-6A44;1.0;6077
-6A47;1.0;6082
-6A48;1.0;6086
-6A4B;1.0;2222
-6A58;1.0;2144
-6A59;1.0;6084
-6A5F;1.0;2101
-6A61;1.0;3843
-6A62;1.0;6083
-6A66;1.0;6085
-6A72;1.0;6079
-6A78;1.0;6081
-6A7F;1.0;1964
-6A80;1.0;3541
-6A84;1.0;6092
-6A8D;1.0;6090
-6A8E;1.0;2473
-6A90;1.0;6089
-6A97;1.0;6101
-6A9C;1.0;5956
-6AA0;1.0;6091
-6AA2;1.0;6093
-6AA3;1.0;6094
-6AAA;1.0;6112
-6AAC;1.0;6108
-6AAE;1.0;5977
-6AB3;1.0;6107
-6AB8;1.0;6106
-6ABB;1.0;6103
-6AC1;1.0;6074
-6AC2;1.0;6105
-6AC3;1.0;6104
-6AD1;1.0;6110
-6AD3;1.0;4706
-6ADA;1.0;6113
-6ADB;1.0;2291
-6ADE;1.0;6109
-6ADF;1.0;6111
-6AE8;1.0;4007
-6AEA;1.0;6114
-6AFA;1.0;6118
-6AFB;1.0;6115
-6B04;1.0;4583
-6B05;1.0;6116
-6B0A;1.0;6062
-6B12;1.0;6119
-6B16;1.0;6120
-6B1D;1.0;1721
-6B1F;1.0;6122
-6B20;1.0;2371
-6B21;1.0;2801
-6B23;1.0;2253
-6B27;1.0;1804
-6B32;1.0;4563
-6B37;1.0;6124
-6B38;1.0;6123
-6B39;1.0;6126
-6B3A;1.0;2129
-6B3D;1.0;2254
-6B3E;1.0;2030
-6B43;1.0;6129
-6B47;1.0;6128
-6B49;1.0;6130
-6B4C;1.0;1846
-6B4E;1.0;3523
-6B50;1.0;6131
-6B53;1.0;2031
-6B54;1.0;6133
-6B59;1.0;6132
-6B5B;1.0;6134
-6B5F;1.0;6135
-6B61;1.0;6136
-6B62;1.0;2763
-6B63;1.0;3221
-6B64;1.0;2601
-6B66;1.0;4180
-6B69;1.0;4266
-6B6A;1.0;4736
-6B6F;1.0;2785
-6B73;1.0;2648
-6B74;1.0;4682
-6B78;1.0;6137
-6B79;1.0;6138
-6B7B;1.0;2764
-6B7F;1.0;6139
-6B80;1.0;6140
-6B83;1.0;6142
-6B84;1.0;6141
-6B86;1.0;4356
-6B89;1.0;2962
-6B8A;1.0;2876
-6B8B;1.0;2736
-6B8D;1.0;6143
-6B95;1.0;6145
-6B96;1.0;3103
-6B98;1.0;6144
-6B9E;1.0;6146
-6BA4;1.0;6147
-6BAA;1.0;6148
-6BAB;1.0;6149
-6BAF;1.0;6150
-6BB1;1.0;6152
-6BB2;1.0;6151
-6BB3;1.0;6153
-6BB4;1.0;1805
-6BB5;1.0;3542
-6BB7;1.0;6154
-6BBA;1.0;2706
-6BBB;1.0;1944
-6BBC;1.0;6155
-6BBF;1.0;3734
-6BC0;1.0;5244
-6BC5;1.0;2103
-6BC6;1.0;6156
-6BCB;1.0;6157
-6BCD;1.0;4276
-6BCE;1.0;4372
-6BD2;1.0;3839
-6BD3;1.0;6158
-6BD4;1.0;4070
-6BD8;1.0;4091
-6BDB;1.0;4451
-6BDF;1.0;6159
-6BEB;1.0;6161
-6BEC;1.0;6160
-6BEF;1.0;6163
-6BF3;1.0;6162
-6C08;1.0;6165
-6C0F;1.0;2765
-6C11;1.0;4417
-6C13;1.0;6166
-6C14;1.0;6167
-6C17;1.0;2104
-6C1B;1.0;6168
-6C23;1.0;6170
-6C24;1.0;6169
-6C34;1.0;3169
-6C37;1.0;4125
-6C38;1.0;1742
-6C3E;1.0;4037
-6C40;1.0;3685
-6C41;1.0;2933
-6C42;1.0;2165
-6C4E;1.0;4038
-6C50;1.0;2814
-6C55;1.0;6172
-6C57;1.0;2032
-6C5A;1.0;1788
-6C5D;1.0;3882
-6C5E;1.0;6171
-6C5F;1.0;2530
-6C60;1.0;3551
-6C62;1.0;6173
-6C68;1.0;6181
-6C6A;1.0;6174
-6C70;1.0;3433
-6C72;1.0;2166
-6C73;1.0;6182
-6C7A;1.0;2372
-6C7D;1.0;2105
-6C7E;1.0;6180
-6C81;1.0;6178
-6C82;1.0;6175
-6C83;1.0;4564
-6C88;1.0;3632
-6C8C;1.0;3857
-6C8D;1.0;6176
-6C90;1.0;6184
-6C92;1.0;6183
-6C93;1.0;2303
-6C96;1.0;1813
-6C99;1.0;2627
-6C9A;1.0;6177
-6C9B;1.0;6179
-6CA1;1.0;4355
-6CA2;1.0;3484
-6CAB;1.0;4387
-6CAE;1.0;6192
-6CB1;1.0;6193
-6CB3;1.0;1847
-6CB8;1.0;4208
-6CB9;1.0;4493
-6CBA;1.0;6201
-6CBB;1.0;2803
-6CBC;1.0;3034
-6CBD;1.0;6188
-6CBE;1.0;6194
-6CBF;1.0;1772
-6CC1;1.0;2223
-6CC4;1.0;6185
-6CC5;1.0;6190
-6CC9;1.0;3284
-6CCA;1.0;3981
-6CCC;1.0;4071
-6CD3;1.0;6187
-6CD5;1.0;4301
-6CD7;1.0;6189
-6CD9;1.0;6204
-6CDB;1.0;6202
-6CDD;1.0;6191
-6CE1;1.0;4302
-6CE2;1.0;3940
-6CE3;1.0;2167
-6CE5;1.0;3705
-6CE8;1.0;3577
-6CEA;1.0;6205
-6CEF;1.0;6203
-6CF0;1.0;3457
-6CF1;1.0;6186
-6CF3;1.0;1743
-6D0B;1.0;4546
-6D0C;1.0;6216
-6D12;1.0;6215
-6D17;1.0;3286
-6D19;1.0;6212
-6D1B;1.0;4576
-6D1E;1.0;3822
-6D1F;1.0;6206
-6D25;1.0;3637
-6D29;1.0;1744
-6D2A;1.0;2531
-6D2B;1.0;6209
-6D32;1.0;2907
-6D33;1.0;6214
-6D35;1.0;6213
-6D36;1.0;6208
-6D38;1.0;6211
-6D3B;1.0;1972
-6D3D;1.0;6210
-6D3E;1.0;3941
-6D41;1.0;4614
-6D44;1.0;3084
-6D45;1.0;3285
-6D59;1.0;6222
-6D5A;1.0;6220
-6D5C;1.0;4145
-6D63;1.0;6217
-6D64;1.0;6219
-6D66;1.0;1726
-6D69;1.0;2532
-6D6A;1.0;4718
-6D6C;1.0;1929
-6D6E;1.0;4166
-6D74;1.0;4565
-6D77;1.0;1904
-6D78;1.0;3127
-6D79;1.0;6221
-6D85;1.0;6226
-6D88;1.0;3035
-6D8C;1.0;4516
-6D8E;1.0;6223
-6D93;1.0;6218
-6D95;1.0;6224
-6D99;1.0;4662
-6D9B;1.0;3783
-6D9C;1.0;3834
-6DAF;1.0;1922
-6DB2;1.0;1753
-6DB5;1.0;6230
-6DB8;1.0;6233
-6DBC;1.0;4635
-6DC0;1.0;4568
-6DC5;1.0;6240
-6DC6;1.0;6234
-6DC7;1.0;6231
-6DCB;1.0;4652
-6DCC;1.0;6237
-6DD1;1.0;2942
-6DD2;1.0;6239
-6DD5;1.0;6244
-6DD8;1.0;3781
-6DD9;1.0;6242
-6DDE;1.0;6236
-6DE1;1.0;3524
-6DE4;1.0;6243
-6DE6;1.0;6232
-6DE8;1.0;6238
-6DEA;1.0;6245
-6DEB;1.0;1692
-6DEC;1.0;6235
-6DEE;1.0;6246
-6DF1;1.0;3128
-6DF3;1.0;2963
-6DF5;1.0;4205
-6DF7;1.0;2614
-6DF9;1.0;6227
-6DFA;1.0;6241
-6DFB;1.0;3726
-6E05;1.0;3222
-6E07;1.0;1973
-6E08;1.0;2649
-6E09;1.0;3036
-6E0A;1.0;6229
-6E0B;1.0;2934
-6E13;1.0;2344
-6E15;1.0;6228
-6E19;1.0;6250
-6E1A;1.0;2977
-6E1B;1.0;2426
-6E1D;1.0;6265
-6E1F;1.0;6259
-6E20;1.0;2184
-6E21;1.0;3747
-6E23;1.0;6254
-6E24;1.0;6263
-6E25;1.0;1615
-6E26;1.0;1718
-6E29;1.0;1825
-6E2B;1.0;6256
-6E2C;1.0;3412
-6E2D;1.0;6247
-6E2E;1.0;6249
-6E2F;1.0;2533
-6E38;1.0;6266
-6E3A;1.0;6261
-6E3E;1.0;6253
-6E43;1.0;6260
-6E4A;1.0;4411
-6E4D;1.0;6258
-6E4E;1.0;6262
-6E56;1.0;2448
-6E58;1.0;3037
-6E5B;1.0;3525
-6E5F;1.0;6252
-6E67;1.0;4515
-6E6B;1.0;6255
-6E6E;1.0;6248
-6E6F;1.0;3782
-6E72;1.0;6251
-6E76;1.0;6257
-6E7E;1.0;4749
-6E7F;1.0;2830
-6E80;1.0;4394
-6E82;1.0;6267
-6E8C;1.0;4014
-6E8F;1.0;6279
-6E90;1.0;2427
-6E96;1.0;2964
-6E98;1.0;6269
-6E9C;1.0;4615
-6E9D;1.0;2534
-6E9F;1.0;6282
-6EA2;1.0;1678
-6EA5;1.0;6280
-6EAA;1.0;6268
-6EAF;1.0;6274
-6EB2;1.0;6276
-6EB6;1.0;4547
-6EB7;1.0;6271
-6EBA;1.0;3714
-6EBD;1.0;6273
-6EC2;1.0;6281
-6EC4;1.0;6275
-6EC5;1.0;4439
-6EC9;1.0;6270
-6ECB;1.0;2802
-6ECC;1.0;6294
-6ED1;1.0;1974
-6ED3;1.0;6272
-6ED4;1.0;6277
-6ED5;1.0;6278
-6EDD;1.0;3476
-6EDE;1.0;3458
-6EEC;1.0;6286
-6EEF;1.0;6292
-6EF2;1.0;6290
-6EF4;1.0;3709
-6EF7;1.0;6303
-6EF8;1.0;6287
-6EFE;1.0;6288
-6EFF;1.0;6264
-6F01;1.0;2189
-6F02;1.0;4126
-6F06;1.0;2831
-6F09;1.0;2587
-6F0F;1.0;4719
-6F11;1.0;6284
-6F13;1.0;6302
-6F14;1.0;1773
-6F15;1.0;3370
-6F20;1.0;3989
-6F22;1.0;2033
-6F23;1.0;4690
-6F2B;1.0;4401
-6F2C;1.0;3650
-6F31;1.0;6291
-6F32;1.0;6293
-6F38;1.0;3318
-6F3E;1.0;6301
-6F3F;1.0;6289
-6F41;1.0;6283
-6F45;1.0;2035
-6F54;1.0;2373
-6F58;1.0;6315
-6F5B;1.0;6310
-6F5C;1.0;3288
-6F5F;1.0;1967
-6F64;1.0;2965
-6F66;1.0;6319
-6F6D;1.0;6312
-6F6E;1.0;3612
-6F6F;1.0;6309
-6F70;1.0;3657
-6F74;1.0;6344
-6F78;1.0;6306
-6F7A;1.0;6305
-6F7C;1.0;6314
-6F80;1.0;6308
-6F81;1.0;6307
-6F82;1.0;6313
-6F84;1.0;3201
-6F86;1.0;6304
-6F8E;1.0;6316
-6F91;1.0;6317
-6F97;1.0;2034
-6FA1;1.0;6322
-6FA3;1.0;6321
-6FA4;1.0;6323
-6FAA;1.0;6326
-6FB1;1.0;3735
-6FB3;1.0;6320
-6FB9;1.0;6324
-6FC0;1.0;2367
-6FC1;1.0;3489
-6FC2;1.0;6318
-6FC3;1.0;3927
-6FC6;1.0;6325
-6FD4;1.0;6330
-6FD5;1.0;6328
-6FD8;1.0;6331
-6FDB;1.0;6334
-6FDF;1.0;6327
-6FE0;1.0;2574
-6FE1;1.0;3908
-6FE4;1.0;6225
-6FEB;1.0;4584
-6FEC;1.0;6329
-6FEE;1.0;6333
-6FEF;1.0;3485
-6FF1;1.0;6332
-6FF3;1.0;6311
-6FF6;1.0;7973
-6FFA;1.0;6337
-6FFE;1.0;6341
-7001;1.0;6339
-7009;1.0;6335
-700B;1.0;6336
-700F;1.0;6340
-7011;1.0;6338
-7015;1.0;4146
-7018;1.0;6346
-701A;1.0;6343
-701B;1.0;6342
-701D;1.0;6345
-701E;1.0;3852
-701F;1.0;6347
-7026;1.0;3585
-7027;1.0;3477
-702C;1.0;3205
-7030;1.0;6348
-7032;1.0;6350
-703E;1.0;6349
-704C;1.0;6285
-7051;1.0;6351
-7058;1.0;3871
-7063;1.0;6352
-706B;1.0;1848
-706F;1.0;3784
-7070;1.0;1905
-7078;1.0;2168
-707C;1.0;2862
-707D;1.0;2650
-7089;1.0;4707
-708A;1.0;3170
-708E;1.0;1774
-7092;1.0;6354
-7099;1.0;6353
-70AC;1.0;6357
-70AD;1.0;3526
-70AE;1.0;6360
-70AF;1.0;6355
-70B3;1.0;6359
-70B8;1.0;6358
-70B9;1.0;3732
-70BA;1.0;1657
-70C8;1.0;4685
-70CB;1.0;6362
-70CF;1.0;1708
-70D9;1.0;6364
-70DD;1.0;6363
-70DF;1.0;6361
-70F1;1.0;6356
-70F9;1.0;4303
-70FD;1.0;6366
-7109;1.0;6365
-7114;1.0;1775
-7119;1.0;6368
-711A;1.0;4218
-711C;1.0;6367
-7121;1.0;4421
-7126;1.0;3039
-7136;1.0;3319
-713C;1.0;3038
-7149;1.0;4691
-714C;1.0;6374
-714E;1.0;3289
-7155;1.0;6370
-7156;1.0;6375
-7159;1.0;1776
-7162;1.0;6373
-7164;1.0;3965
-7165;1.0;6369
-7166;1.0;6372
-7167;1.0;3040
-7169;1.0;4049
-716C;1.0;6376
-716E;1.0;2849
-717D;1.0;3290
-7184;1.0;6379
-7188;1.0;6371
-718A;1.0;2307
-718F;1.0;6377
-7194;1.0;4548
-7195;1.0;6380
-7199;1.0;8406
-719F;1.0;2947
-71A8;1.0;6381
-71AC;1.0;6382
-71B1;1.0;3914
-71B9;1.0;6384
-71BE;1.0;6385
-71C3;1.0;3919
-71C8;1.0;3785
-71C9;1.0;6387
-71CE;1.0;6389
-71D0;1.0;4653
-71D2;1.0;6386
-71D4;1.0;6388
-71D5;1.0;1777
-71D7;1.0;6383
-71DF;1.0;5159
-71E0;1.0;6390
-71E5;1.0;3371
-71E6;1.0;2724
-71E7;1.0;6392
-71EC;1.0;6391
-71ED;1.0;3104
-71EE;1.0;5057
-71F5;1.0;6393
-71F9;1.0;6401
-71FB;1.0;6378
-71FC;1.0;6394
-71FF;1.0;6402
-7206;1.0;3990
-720D;1.0;6403
-7210;1.0;6404
-721B;1.0;6405
-7228;1.0;6406
-722A;1.0;3662
-722C;1.0;6408
-722D;1.0;6407
-7230;1.0;6409
-7232;1.0;6410
-7235;1.0;2863
-7236;1.0;4167
-723A;1.0;4476
-723B;1.0;6411
-723C;1.0;6412
-723D;1.0;3354
-723E;1.0;2804
-723F;1.0;6413
-7240;1.0;6414
-7246;1.0;6415
-7247;1.0;4250
-7248;1.0;4039
-724B;1.0;6416
-724C;1.0;3955
-7252;1.0;3613
-7258;1.0;6417
-7259;1.0;1871
-725B;1.0;2177
-725D;1.0;4438
-725F;1.0;4422
-7261;1.0;1820
-7262;1.0;4720
-7267;1.0;4350
-7269;1.0;4210
-7272;1.0;3223
-7274;1.0;6418
-7279;1.0;3835
-727D;1.0;2403
-727E;1.0;6419
-7280;1.0;2652
-7281;1.0;6421
-7282;1.0;6420
-7287;1.0;6422
-7292;1.0;6423
-7296;1.0;6424
-72A0;1.0;2130
-72A2;1.0;6425
-72A7;1.0;6426
-72AC;1.0;2404
-72AF;1.0;4040
-72B2;1.0;6428
-72B6;1.0;3085
-72B9;1.0;6427
-72C2;1.0;2224
-72C3;1.0;6429
-72C4;1.0;6431
-72C6;1.0;6430
-72CE;1.0;6432
-72D0;1.0;2449
-72D2;1.0;6433
-72D7;1.0;2273
-72D9;1.0;3332
-72DB;1.0;2593
-72E0;1.0;6435
-72E1;1.0;6436
-72E2;1.0;6434
-72E9;1.0;2877
-72EC;1.0;3840
-72ED;1.0;2225
-72F7;1.0;6438
-72F8;1.0;3512
-72F9;1.0;6437
-72FC;1.0;4721
-72FD;1.0;3966
-730A;1.0;6441
-7316;1.0;6443
-7317;1.0;6440
-731B;1.0;4452
-731C;1.0;6442
-731D;1.0;6444
-731F;1.0;4636
-7325;1.0;6448
-7329;1.0;6447
-732A;1.0;3586
-732B;1.0;3913
-732E;1.0;2405
-732F;1.0;6446
-7334;1.0;6445
-7336;1.0;4517
-7337;1.0;4518
-733E;1.0;6449
-733F;1.0;1778
-7344;1.0;2586
-7345;1.0;2766
-734E;1.0;6450
-734F;1.0;6451
-7357;1.0;6453
-7363;1.0;2935
-7368;1.0;6455
-736A;1.0;6454
-7370;1.0;6456
-7372;1.0;1945
-7375;1.0;6458
-7378;1.0;6457
-737A;1.0;6460
-737B;1.0;6459
-7384;1.0;2428
-7387;1.0;4608
-7389;1.0;2244
-738B;1.0;1806
-7396;1.0;2274
-73A9;1.0;2065
-73B2;1.0;4672
-73B3;1.0;6462
-73BB;1.0;6464
-73C0;1.0;6465
-73C2;1.0;1849
-73C8;1.0;6461
-73CA;1.0;2725
-73CD;1.0;3633
-73CE;1.0;6463
-73DE;1.0;6468
-73E0;1.0;2878
-73E5;1.0;6466
-73EA;1.0;2330
-73ED;1.0;4041
-73EE;1.0;6467
-73F1;1.0;6494
-73F8;1.0;6473
-73FE;1.0;2429
-7403;1.0;2169
-7405;1.0;6470
-7406;1.0;4593
-7409;1.0;4616
-7422;1.0;3486
-7425;1.0;6472
-7432;1.0;6474
-7433;1.0;4654
-7434;1.0;2255
-7435;1.0;4092
-7436;1.0;3942
-743A;1.0;6475
-743F;1.0;6477
-7441;1.0;6480
-7455;1.0;6476
-7459;1.0;6479
-745A;1.0;2474
-745B;1.0;1745
-745C;1.0;6481
-745E;1.0;3180
-745F;1.0;6478
-7460;1.0;4660
-7463;1.0;6484
-7464;1.0;8404
-7469;1.0;6482
-746A;1.0;6485
-746F;1.0;6471
-7470;1.0;6483
-7473;1.0;2628
-7476;1.0;6486
-747E;1.0;6487
-7483;1.0;4594
-748B;1.0;6488
-749E;1.0;6489
-74A2;1.0;6469
-74A7;1.0;6490
-74B0;1.0;2036
-74BD;1.0;2805
-74CA;1.0;6491
-74CF;1.0;6492
-74D4;1.0;6493
-74DC;1.0;1727
-74E0;1.0;6501
-74E2;1.0;4127
-74E3;1.0;6502
-74E6;1.0;2004
-74E7;1.0;6503
-74E9;1.0;6504
-74EE;1.0;6505
-74F0;1.0;6507
-74F1;1.0;6508
-74F2;1.0;6506
-74F6;1.0;4151
-74F7;1.0;6510
-74F8;1.0;6509
-7503;1.0;6512
-7504;1.0;6511
-7505;1.0;6513
-750C;1.0;6514
-750D;1.0;6516
-750E;1.0;6515
-7511;1.0;2589
-7513;1.0;6518
-7515;1.0;6517
-7518;1.0;2037
-751A;1.0;3151
-751C;1.0;3728
-751E;1.0;6519
-751F;1.0;3224
-7523;1.0;2726
-7525;1.0;1789
-7526;1.0;6520
-7528;1.0;4549
-752B;1.0;4267
-752C;1.0;6521
-7530;1.0;3736
-7531;1.0;4519
-7532;1.0;2535
-7533;1.0;3129
-7537;1.0;3543
-7538;1.0;5020
-753A;1.0;3614
-753B;1.0;1872
-753C;1.0;6522
-7544;1.0;6523
-7546;1.0;6528
-7549;1.0;6526
-754A;1.0;6525
-754B;1.0;5834
-754C;1.0;1906
-754D;1.0;6524
-754F;1.0;1658
-7551;1.0;4010
-7554;1.0;4042
-7559;1.0;4617
-755A;1.0;6529
-755B;1.0;6527
-755C;1.0;3560
-755D;1.0;3206
-7560;1.0;4011
-7562;1.0;4113
-7564;1.0;6531
-7565;1.0;4612
-7566;1.0;2345
-7567;1.0;6532
-7569;1.0;6530
-756A;1.0;4054
-756B;1.0;6533
-756D;1.0;6534
-7570;1.0;1659
-7573;1.0;3086
-7574;1.0;6539
-7576;1.0;6536
-7577;1.0;3877
-7578;1.0;6535
-757F;1.0;2106
-7582;1.0;6542
-7586;1.0;6537
-7587;1.0;6538
-7589;1.0;6541
-758A;1.0;6540
-758B;1.0;4105
-758E;1.0;3334
-758F;1.0;3333
-7591;1.0;2131
-7594;1.0;6543
-759A;1.0;6544
-759D;1.0;6545
-75A3;1.0;6547
-75A5;1.0;6546
-75AB;1.0;1754
-75B1;1.0;6555
-75B2;1.0;4072
-75B3;1.0;6549
-75B5;1.0;6551
-75B8;1.0;6553
-75B9;1.0;3130
-75BC;1.0;6554
-75BD;1.0;6552
-75BE;1.0;2832
-75C2;1.0;6548
-75C3;1.0;6550
-75C5;1.0;4134
-75C7;1.0;3041
-75CA;1.0;6557
-75CD;1.0;6556
-75D2;1.0;6558
-75D4;1.0;2806
-75D5;1.0;2615
-75D8;1.0;3787
-75D9;1.0;6559
-75DB;1.0;3643
-75DE;1.0;6561
-75E2;1.0;4601
-75E3;1.0;6560
-75E9;1.0;3373
-75F0;1.0;6566
-75F2;1.0;6568
-75F3;1.0;6569
-75F4;1.0;3552
-75FA;1.0;6567
-75FC;1.0;6564
-75FE;1.0;6562
-75FF;1.0;6563
-7601;1.0;6565
-7609;1.0;6572
-760B;1.0;6570
-760D;1.0;6571
-761F;1.0;6573
-7620;1.0;6575
-7621;1.0;6576
-7622;1.0;6577
-7624;1.0;6578
-7627;1.0;6574
-7630;1.0;6580
-7634;1.0;6579
-763B;1.0;6581
-7642;1.0;4637
-7646;1.0;6584
-7647;1.0;6582
-7648;1.0;6583
-764C;1.0;2066
-7652;1.0;4494
-7656;1.0;4242
-7658;1.0;6586
-765C;1.0;6585
-7661;1.0;6587
-7662;1.0;6588
-7667;1.0;6592
-7668;1.0;6589
-7669;1.0;6590
-766A;1.0;6591
-766C;1.0;6593
-7670;1.0;6594
-7672;1.0;6601
-7676;1.0;6602
-7678;1.0;6603
-767A;1.0;4015
-767B;1.0;3748
-767C;1.0;6604
-767D;1.0;3982
-767E;1.0;4120
-7680;1.0;6605
-7683;1.0;6606
-7684;1.0;3710
-7686;1.0;1907
-7687;1.0;2536
-7688;1.0;6607
-768B;1.0;6608
-768E;1.0;6609
-7690;1.0;2709
-7693;1.0;6611
-7696;1.0;6610
-7699;1.0;6612
-769A;1.0;6613
-76AE;1.0;4073
-76B0;1.0;6614
-76B4;1.0;6615
-76B7;1.0;8373
-76B8;1.0;6616
-76B9;1.0;6617
-76BA;1.0;6618
-76BF;1.0;2714
-76C2;1.0;6619
-76C3;1.0;3954
-76C6;1.0;4363
-76C8;1.0;1746
-76CA;1.0;1755
-76CD;1.0;6620
-76D2;1.0;6622
-76D6;1.0;6621
-76D7;1.0;3780
-76DB;1.0;3225
-76DC;1.0;6125
-76DE;1.0;6623
-76DF;1.0;4433
-76E1;1.0;6624
-76E3;1.0;2038
-76E4;1.0;4055
-76E5;1.0;6625
-76E7;1.0;6626
-76EA;1.0;6627
-76EE;1.0;4460
-76F2;1.0;4453
-76F4;1.0;3630
-76F8;1.0;3374
-76FB;1.0;6629
-76FE;1.0;2966
-7701;1.0;3042
-7704;1.0;6632
-7707;1.0;6631
-7708;1.0;6630
-7709;1.0;4093
-770B;1.0;2039
-770C;1.0;2409
-771B;1.0;6638
-771E;1.0;6635
-771F;1.0;3131
-7720;1.0;4418
-7724;1.0;6634
-7725;1.0;6636
-7726;1.0;6637
-7729;1.0;6633
-7737;1.0;6639
-7738;1.0;6640
-773A;1.0;3615
-773C;1.0;2067
-7740;1.0;3569
-7747;1.0;6641
-775A;1.0;6642
-775B;1.0;6645
-7761;1.0;3171
-7763;1.0;3836
-7765;1.0;6646
-7766;1.0;4351
-7768;1.0;6643
-776B;1.0;6644
-7779;1.0;6649
-777E;1.0;6648
-777F;1.0;6647
-778B;1.0;6651
-778E;1.0;6650
-7791;1.0;6652
-779E;1.0;6654
-77A0;1.0;6653
-77A5;1.0;4245
-77AC;1.0;2954
-77AD;1.0;4638
-77B0;1.0;6655
-77B3;1.0;3823
-77B6;1.0;6656
-77B9;1.0;6657
-77BB;1.0;6661
-77BC;1.0;6659
-77BD;1.0;6660
-77BF;1.0;6658
-77C7;1.0;6662
-77CD;1.0;6663
-77D7;1.0;6664
-77DA;1.0;6665
-77DB;1.0;4423
-77DC;1.0;6666
-77E2;1.0;4480
-77E3;1.0;6667
-77E5;1.0;3546
-77E7;1.0;3974
-77E9;1.0;2275
-77ED;1.0;3527
-77EE;1.0;6668
-77EF;1.0;2226
-77F3;1.0;3248
-77FC;1.0;6669
-7802;1.0;2629
-780C;1.0;6670
-7812;1.0;6671
-7814;1.0;2406
-7815;1.0;2653
-7820;1.0;6673
-7825;1.0;3754
-7826;1.0;2654
-7827;1.0;2146
-7832;1.0;4304
-7834;1.0;3943
-783A;1.0;3755
-783F;1.0;2560
-7845;1.0;6675
-785D;1.0;3043
-786B;1.0;4618
-786C;1.0;2537
-786F;1.0;2407
-7872;1.0;4003
-7874;1.0;6677
-787C;1.0;6679
-7881;1.0;2475
-7886;1.0;6678
-7887;1.0;3686
-788C;1.0;6681
-788D;1.0;1923
-788E;1.0;6676
-7891;1.0;4074
-7893;1.0;1716
-7895;1.0;2676
-7897;1.0;4750
-789A;1.0;6680
-78A3;1.0;6682
-78A7;1.0;4243
-78A9;1.0;3257
-78AA;1.0;6684
-78AF;1.0;6685
-78B5;1.0;6683
-78BA;1.0;1946
-78BC;1.0;6691
-78BE;1.0;6690
-78C1;1.0;2807
-78C5;1.0;6692
-78C6;1.0;6687
-78CA;1.0;6693
-78CB;1.0;6688
-78D0;1.0;4056
-78D1;1.0;6686
-78D4;1.0;6689
-78DA;1.0;6702
-78E7;1.0;6701
-78E8;1.0;4365
-78EC;1.0;6694
-78EF;1.0;1675
-78F4;1.0;6704
-78FD;1.0;6703
-7901;1.0;3044
-7907;1.0;6705
-790E;1.0;3335
-7911;1.0;6707
-7912;1.0;6706
-7919;1.0;6708
-7926;1.0;6672
-792A;1.0;6674
-792B;1.0;6710
-792C;1.0;6709
-793A;1.0;2808
-793C;1.0;4673
-793E;1.0;2850
-7940;1.0;6711
-7941;1.0;2323
-7947;1.0;2132
-7948;1.0;2107
-7949;1.0;2767
-7950;1.0;4520
-7953;1.0;6717
-7955;1.0;6716
-7956;1.0;3336
-7957;1.0;6713
-795A;1.0;6715
-795D;1.0;2943
-795E;1.0;3132
-795F;1.0;6714
-7960;1.0;6712
-7962;1.0;3910
-7965;1.0;3045
-7968;1.0;4128
-796D;1.0;2655
-7977;1.0;3788
-797A;1.0;6718
-797F;1.0;6719
-7980;1.0;6741
-7981;1.0;2256
-7984;1.0;4729
-7985;1.0;3321
-798A;1.0;6720
-798D;1.0;1850
-798E;1.0;3687
-798F;1.0;4201
-799D;1.0;6721
-79A6;1.0;2190
-79A7;1.0;6722
-79AA;1.0;6724
-79AE;1.0;6725
-79B0;1.0;3909
-79B3;1.0;6726
-79B9;1.0;6727
-79BA;1.0;6728
-79BD;1.0;2257
-79BE;1.0;1851
-79BF;1.0;3837
-79C0;1.0;2908
-79C1;1.0;2768
-79C9;1.0;6729
-79CB;1.0;2909
-79D1;1.0;1842
-79D2;1.0;4135
-79D5;1.0;6730
-79D8;1.0;4075
-79DF;1.0;3337
-79E1;1.0;6733
-79E3;1.0;6734
-79E4;1.0;3973
-79E6;1.0;3133
-79E7;1.0;6731
-79E9;1.0;3565
-79EC;1.0;6732
-79F0;1.0;3046
-79FB;1.0;1660
-7A00;1.0;2109
-7A08;1.0;6735
-7A0B;1.0;3688
-7A0D;1.0;6736
-7A0E;1.0;3239
-7A14;1.0;4413
-7A17;1.0;4103
-7A18;1.0;6737
-7A19;1.0;6738
-7A1A;1.0;3553
-7A1C;1.0;4639
-7A1F;1.0;6740
-7A20;1.0;6739
-7A2E;1.0;2879
-7A31;1.0;6742
-7A32;1.0;1680
-7A37;1.0;6745
-7A3B;1.0;6743
-7A3C;1.0;1852
-7A3D;1.0;2346
-7A3E;1.0;6744
-7A3F;1.0;2538
-7A40;1.0;2582
-7A42;1.0;4270
-7A43;1.0;6746
-7A46;1.0;4352
-7A49;1.0;6748
-7A4D;1.0;3249
-7A4E;1.0;1747
-7A4F;1.0;1826
-7A50;1.0;1612
-7A57;1.0;6747
-7A61;1.0;6749
-7A62;1.0;6750
-7A63;1.0;3087
-7A69;1.0;6751
-7A6B;1.0;1947
-7A70;1.0;6753
-7A74;1.0;2374
-7A76;1.0;2170
-7A79;1.0;6754
-7A7A;1.0;2285
-7A7D;1.0;6755
-7A7F;1.0;3292
-7A81;1.0;3845
-7A83;1.0;3264
-7A84;1.0;2685
-7A88;1.0;6756
-7A92;1.0;3566
-7A93;1.0;3375
-7A95;1.0;6758
-7A96;1.0;6760
-7A97;1.0;6757
-7A98;1.0;6759
-7A9F;1.0;2302
-7AA9;1.0;6761
-7AAA;1.0;2306
-7AAE;1.0;2171
-7AAF;1.0;4550
-7AB0;1.0;6763
-7AB6;1.0;6764
-7ABA;1.0;1714
-7ABF;1.0;6767
-7AC3;1.0;1986
-7AC4;1.0;6766
-7AC5;1.0;6765
-7AC7;1.0;6769
-7AC8;1.0;6762
-7ACA;1.0;6770
-7ACB;1.0;4609
-7ACD;1.0;6771
-7ACF;1.0;6772
-7AD2;1.0;5284
-7AD3;1.0;6774
-7AD5;1.0;6773
-7AD9;1.0;6775
-7ADA;1.0;6776
-7ADC;1.0;4621
-7ADD;1.0;6777
-7ADF;1.0;8079
-7AE0;1.0;3047
-7AE1;1.0;6778
-7AE2;1.0;6779
-7AE3;1.0;2955
-7AE5;1.0;3824
-7AE6;1.0;6780
-7AEA;1.0;3508
-7AED;1.0;6781
-7AEF;1.0;3528
-7AF0;1.0;6782
-7AF6;1.0;2205
-7AF8;1.0;4931
-7AF9;1.0;3561
-7AFA;1.0;2819
-7AFF;1.0;2040
-7B02;1.0;6783
-7B04;1.0;6802
-7B06;1.0;6786
-7B08;1.0;2172
-7B0A;1.0;6785
-7B0B;1.0;6804
-7B0F;1.0;6784
-7B11;1.0;3048
-7B18;1.0;6788
-7B19;1.0;6789
-7B1B;1.0;3711
-7B1E;1.0;6790
-7B20;1.0;1962
-7B25;1.0;3158
-7B26;1.0;4168
-7B28;1.0;6792
-7B2C;1.0;3472
-7B33;1.0;6787
-7B35;1.0;6791
-7B36;1.0;6793
-7B39;1.0;2691
-7B45;1.0;6806
-7B46;1.0;4114
-7B48;1.0;4006
-7B49;1.0;3789
-7B4B;1.0;2258
-7B4C;1.0;6805
-7B4D;1.0;6803
-7B4F;1.0;4021
-7B50;1.0;6794
-7B51;1.0;3562
-7B52;1.0;3791
-7B54;1.0;3790
-7B56;1.0;2686
-7B5D;1.0;6824
-7B65;1.0;6808
-7B67;1.0;6810
-7B6C;1.0;6813
-7B6E;1.0;6814
-7B70;1.0;6811
-7B71;1.0;6812
-7B74;1.0;6809
-7B75;1.0;6807
-7B7A;1.0;6801
-7B86;1.0;4247
-7B87;1.0;1853
-7B8B;1.0;6821
-7B8D;1.0;6818
-7B8F;1.0;6823
-7B92;1.0;6822
-7B94;1.0;3983
-7B95;1.0;4407
-7B97;1.0;2727
-7B98;1.0;6816
-7B99;1.0;6825
-7B9A;1.0;6820
-7B9C;1.0;6819
-7B9D;1.0;6815
-7B9F;1.0;6817
-7BA1;1.0;2041
-7BAA;1.0;3529
-7BAD;1.0;3293
-7BB1;1.0;4002
-7BB4;1.0;6830
-7BB8;1.0;4004
-7BC0;1.0;3265
-7BC1;1.0;6827
-7BC4;1.0;4047
-7BC6;1.0;6831
-7BC7;1.0;4251
-7BC9;1.0;3559
-7BCB;1.0;6826
-7BCC;1.0;6828
-7BCF;1.0;6829
-7BDD;1.0;6832
-7BE0;1.0;2836
-7BE4;1.0;3838
-7BE5;1.0;6837
-7BE6;1.0;6836
-7BE9;1.0;6833
-7BED;1.0;4722
-7BF3;1.0;6842
-7BF6;1.0;6846
-7BF7;1.0;6843
-7C00;1.0;6839
-7C07;1.0;6840
-7C0D;1.0;6845
-7C11;1.0;6834
-7C12;1.0;5053
-7C13;1.0;6841
-7C14;1.0;6835
-7C17;1.0;6844
-7C1F;1.0;6850
-7C21;1.0;2042
-7C23;1.0;6847
-7C27;1.0;6848
-7C2A;1.0;6849
-7C2B;1.0;6852
-7C37;1.0;6851
-7C38;1.0;4086
-7C3D;1.0;6853
-7C3E;1.0;4692
-7C3F;1.0;4277
-7C40;1.0;6858
-7C43;1.0;6855
-7C4C;1.0;6854
-7C4D;1.0;3250
-7C4F;1.0;6857
-7C50;1.0;6859
-7C54;1.0;6856
-7C56;1.0;6863
-7C58;1.0;6860
-7C5F;1.0;6861
-7C60;1.0;6838
-7C64;1.0;6862
-7C65;1.0;6864
-7C6C;1.0;6865
-7C73;1.0;4238
-7C75;1.0;6866
-7C7E;1.0;4466
-7C81;1.0;2246
-7C82;1.0;2309
-7C83;1.0;6867
-7C89;1.0;4220
-7C8B;1.0;3172
-7C8D;1.0;4416
-7C90;1.0;6868
-7C92;1.0;4619
-7C95;1.0;3984
-7C97;1.0;3338
-7C98;1.0;3920
-7C9B;1.0;2945
-7C9F;1.0;1632
-7CA1;1.0;6873
-7CA2;1.0;6871
-7CA4;1.0;6869
-7CA5;1.0;2001
-7CA7;1.0;3049
-7CA8;1.0;6874
-7CAB;1.0;6872
-7CAD;1.0;6870
-7CAE;1.0;6878
-7CB1;1.0;6877
-7CB2;1.0;6876
-7CB3;1.0;6875
-7CB9;1.0;6879
-7CBD;1.0;6880
-7CBE;1.0;3226
-7CC0;1.0;6881
-7CC2;1.0;6883
-7CC5;1.0;6882
-7CCA;1.0;2450
-7CCE;1.0;3324
-7CD2;1.0;6885
-7CD6;1.0;3792
-7CD8;1.0;6884
-7CDC;1.0;6886
-7CDE;1.0;4221
-7CDF;1.0;3376
-7CE0;1.0;2539
-7CE2;1.0;6887
-7CE7;1.0;4640
-7CEF;1.0;6889
-7CF2;1.0;6890
-7CF4;1.0;6891
-7CF6;1.0;6892
-7CF8;1.0;2769
-7CFA;1.0;6893
-7CFB;1.0;2347
-7CFE;1.0;2174
-7D00;1.0;2110
-7D02;1.0;6901
-7D04;1.0;4483
-7D05;1.0;2540
-7D06;1.0;6894
-7D0A;1.0;6904
-7D0B;1.0;4470
-7D0D;1.0;3928
-7D10;1.0;4119
-7D14;1.0;2967
-7D15;1.0;6903
-7D17;1.0;2851
-7D18;1.0;2541
-7D19;1.0;2770
-7D1A;1.0;2173
-7D1B;1.0;4222
-7D1C;1.0;6902
-7D20;1.0;3339
-7D21;1.0;4334
-7D22;1.0;2687
-7D2B;1.0;2771
-7D2C;1.0;3661
-7D2E;1.0;6907
-7D2F;1.0;4663
-7D30;1.0;2657
-7D32;1.0;6908
-7D33;1.0;3134
-7D35;1.0;6910
-7D39;1.0;3050
-7D3A;1.0;2616
-7D3F;1.0;6909
-7D42;1.0;2910
-7D43;1.0;2430
-7D44;1.0;3340
-7D45;1.0;6905
-7D46;1.0;6911
-7D4B;1.0;6906
-7D4C;1.0;2348
-7D4E;1.0;6914
-7D4F;1.0;6918
-7D50;1.0;2375
-7D56;1.0;6913
-7D5B;1.0;6922
-7D5E;1.0;2542
-7D61;1.0;4577
-7D62;1.0;1628
-7D63;1.0;6919
-7D66;1.0;2175
-7D68;1.0;6916
-7D6E;1.0;6917
-7D71;1.0;3793
-7D72;1.0;6915
-7D73;1.0;6912
-7D75;1.0;1908
-7D76;1.0;3268
-7D79;1.0;2408
-7D7D;1.0;6924
-7D89;1.0;6921
-7D8F;1.0;6923
-7D93;1.0;6920
-7D99;1.0;2349
-7D9A;1.0;3419
-7D9B;1.0;6925
-7D9C;1.0;3378
-7D9F;1.0;6938
-7DA2;1.0;6934
-7DA3;1.0;6928
-7DAB;1.0;6932
-7DAC;1.0;2890
-7DAD;1.0;1661
-7DAE;1.0;6927
-7DAF;1.0;6935
-7DB0;1.0;6939
-7DB1;1.0;2543
-7DB2;1.0;4454
-7DB4;1.0;3654
-7DB5;1.0;6929
-7DB8;1.0;6937
-7DBA;1.0;6926
-7DBB;1.0;3530
-7DBD;1.0;6931
-7DBE;1.0;1629
-7DBF;1.0;4442
-7DC7;1.0;6930
-7DCA;1.0;2259
-7DCB;1.0;4076
-7DCF;1.0;3377
-7DD1;1.0;4648
-7DD2;1.0;2979
-7DD5;1.0;6978
-7DD8;1.0;6940
-7DDA;1.0;3294
-7DDC;1.0;6936
-7DDD;1.0;6941
-7DDE;1.0;6943
-7DE0;1.0;3689
-7DE1;1.0;6946
-7DE4;1.0;6942
-7DE8;1.0;4252
-7DE9;1.0;2043
-7DEC;1.0;4443
-7DEF;1.0;1662
-7DF2;1.0;6945
-7DF4;1.0;4693
-7DFB;1.0;6944
-7E01;1.0;1779
-7E04;1.0;3876
-7E05;1.0;6947
-7E09;1.0;6954
-7E0A;1.0;6948
-7E0B;1.0;6955
-7E12;1.0;6951
-7E1B;1.0;3991
-7E1E;1.0;2842
-7E1F;1.0;6953
-7E21;1.0;6950
-7E22;1.0;6956
-7E23;1.0;6949
-7E26;1.0;2936
-7E2B;1.0;4305
-7E2E;1.0;2944
-7E31;1.0;6952
-7E32;1.0;6964
-7E35;1.0;6960
-7E37;1.0;6963
-7E39;1.0;6961
-7E3A;1.0;6965
-7E3B;1.0;6959
-7E3D;1.0;6933
-7E3E;1.0;3251
-7E41;1.0;4043
-7E43;1.0;6962
-7E46;1.0;6957
-7E4A;1.0;3301
-7E4B;1.0;2350
-7E4D;1.0;2911
-7E54;1.0;3105
-7E55;1.0;3322
-7E56;1.0;6968
-7E59;1.0;6970
-7E5A;1.0;6971
-7E5D;1.0;6967
-7E5E;1.0;6969
-7E66;1.0;6958
-7E67;1.0;6966
-7E69;1.0;6974
-7E6A;1.0;6973
-7E6D;1.0;4390
-7E70;1.0;2311
-7E79;1.0;6972
-7E7B;1.0;6976
-7E7C;1.0;6975
-7E7D;1.0;6979
-7E7F;1.0;6981
-7E82;1.0;2728
-7E83;1.0;6977
-7E88;1.0;6982
-7E89;1.0;6983
-7E8C;1.0;6984
-7E8E;1.0;6990
-7E8F;1.0;3727
-7E90;1.0;6986
-7E92;1.0;6985
-7E93;1.0;6987
-7E94;1.0;6988
-7E96;1.0;6989
-7E9B;1.0;6991
-7E9C;1.0;6992
-7F36;1.0;2044
-7F38;1.0;6993
-7F3A;1.0;6994
-7F45;1.0;7001
-7F4C;1.0;7002
-7F4D;1.0;7003
-7F4E;1.0;7004
-7F50;1.0;7005
-7F51;1.0;7006
-7F54;1.0;7008
-7F55;1.0;7007
-7F58;1.0;7009
-7F5F;1.0;7010
-7F60;1.0;7011
-7F67;1.0;7014
-7F68;1.0;7012
-7F69;1.0;7013
-7F6A;1.0;2665
-7F6B;1.0;2351
-7F6E;1.0;3554
-7F70;1.0;4019
-7F72;1.0;2980
-7F75;1.0;3945
-7F77;1.0;4077
-7F78;1.0;7015
-7F79;1.0;5677
-7F82;1.0;7016
-7F83;1.0;7018
-7F85;1.0;4569
-7F86;1.0;7017
-7F87;1.0;7020
-7F88;1.0;7019
-7F8A;1.0;4551
-7F8C;1.0;7021
-7F8E;1.0;4094
-7F94;1.0;7022
-7F9A;1.0;7025
-7F9D;1.0;7024
-7F9E;1.0;7023
-7FA3;1.0;7026
-7FA4;1.0;2318
-7FA8;1.0;3302
-7FA9;1.0;2133
-7FAE;1.0;7030
-7FAF;1.0;7027
-7FB2;1.0;7028
-7FB6;1.0;7031
-7FB8;1.0;7032
-7FB9;1.0;7029
-7FBD;1.0;1709
-7FC1;1.0;1807
-7FC5;1.0;7034
-7FC6;1.0;7035
-7FCA;1.0;7036
-7FCC;1.0;4566
-7FD2;1.0;2912
-7FD4;1.0;7038
-7FD5;1.0;7037
-7FE0;1.0;3173
-7FE1;1.0;7039
-7FE6;1.0;7040
-7FE9;1.0;7041
-7FEB;1.0;2069
-7FF0;1.0;2045
-7FF3;1.0;7042
-7FF9;1.0;7043
-7FFB;1.0;4361
-7FFC;1.0;4567
-8000;1.0;4552
-8001;1.0;4723
-8003;1.0;2545
-8004;1.0;7046
-8005;1.0;2852
-8006;1.0;7045
-800B;1.0;7047
-800C;1.0;2809
-8010;1.0;3449
-8012;1.0;7048
-8015;1.0;2544
-8017;1.0;4455
-8018;1.0;7049
-8019;1.0;7050
-801C;1.0;7051
-8021;1.0;7052
-8028;1.0;7053
-8033;1.0;2810
-8036;1.0;4477
-803B;1.0;7055
-803D;1.0;3531
-803F;1.0;7054
-8046;1.0;7057
-804A;1.0;7056
-8052;1.0;7058
-8056;1.0;3227
-8058;1.0;7059
-805A;1.0;7060
-805E;1.0;4225
-805F;1.0;7061
-8061;1.0;3379
-8062;1.0;7062
-8068;1.0;7063
-806F;1.0;4694
-8070;1.0;7066
-8072;1.0;7065
-8073;1.0;7064
-8074;1.0;3616
-8076;1.0;7067
-8077;1.0;3106
-8079;1.0;7068
-807D;1.0;7069
-807E;1.0;4724
-807F;1.0;7070
-8084;1.0;7071
-8085;1.0;7073
-8086;1.0;7072
-8087;1.0;4005
-8089;1.0;3889
-808B;1.0;4730
-808C;1.0;4009
-8093;1.0;7075
-8096;1.0;3051
-8098;1.0;4110
-809A;1.0;7076
-809B;1.0;7074
-809D;1.0;2046
-80A1;1.0;2452
-80A2;1.0;2772
-80A5;1.0;4078
-80A9;1.0;2410
-80AA;1.0;4335
-80AC;1.0;7079
-80AD;1.0;7077
-80AF;1.0;2546
-80B1;1.0;2547
-80B2;1.0;1673
-80B4;1.0;2672
-80BA;1.0;3957
-80C3;1.0;1663
-80C4;1.0;7084
-80C6;1.0;3532
-80CC;1.0;3956
-80CE;1.0;3459
-80D6;1.0;7086
-80D9;1.0;7082
-80DA;1.0;7085
-80DB;1.0;7080
-80DD;1.0;7083
-80DE;1.0;4306
-80E1;1.0;2453
-80E4;1.0;1693
-80E5;1.0;7081
-80EF;1.0;7088
-80F1;1.0;7089
-80F4;1.0;3825
-80F8;1.0;2227
-80FC;1.0;7106
-80FD;1.0;3929
-8102;1.0;2773
-8105;1.0;2228
-8106;1.0;3240
-8107;1.0;4738
-8108;1.0;4414
-8109;1.0;7087
-810A;1.0;3252
-811A;1.0;2151
-811B;1.0;7090
-8123;1.0;7092
-8129;1.0;7091
-812F;1.0;7093
-8131;1.0;3506
-8133;1.0;3930
-8139;1.0;3617
-813E;1.0;7103
-8146;1.0;7102
-814B;1.0;7094
-814E;1.0;3153
-8150;1.0;4169
-8151;1.0;7105
-8153;1.0;7104
-8154;1.0;2548
-8155;1.0;4751
-815F;1.0;7121
-8165;1.0;7109
-8166;1.0;7110
-816B;1.0;2880
-816E;1.0;7108
-8170;1.0;2588
-8171;1.0;7107
-8174;1.0;7111
-8178;1.0;3618
-8179;1.0;4202
-817A;1.0;3303
-817F;1.0;3460
-8180;1.0;7115
-8182;1.0;7116
-8183;1.0;7112
-8188;1.0;7113
-818A;1.0;7114
-818F;1.0;2549
-8193;1.0;7122
-8195;1.0;7118
-819A;1.0;4170
-819C;1.0;4376
-819D;1.0;4108
-81A0;1.0;7117
-81A3;1.0;7120
-81A4;1.0;7119
-81A8;1.0;4336
-81A9;1.0;7123
-81B0;1.0;7124
-81B3;1.0;3323
-81B5;1.0;7125
-81B8;1.0;7127
-81BA;1.0;7131
-81BD;1.0;7128
-81BE;1.0;7126
-81BF;1.0;3931
-81C0;1.0;7129
-81C2;1.0;7130
-81C6;1.0;1818
-81C8;1.0;7137
-81C9;1.0;7132
-81CD;1.0;7133
-81D1;1.0;7134
-81D3;1.0;3401
-81D8;1.0;7136
-81D9;1.0;7135
-81DA;1.0;7138
-81DF;1.0;7139
-81E0;1.0;7140
-81E3;1.0;3135
-81E5;1.0;1873
-81E7;1.0;7141
-81E8;1.0;4655
-81EA;1.0;2811
-81ED;1.0;2913
-81F3;1.0;2774
-81F4;1.0;3555
-81FA;1.0;7142
-81FB;1.0;7143
-81FC;1.0;1717
-81FE;1.0;7144
-8201;1.0;7145
-8202;1.0;7146
-8205;1.0;7147
-8207;1.0;7148
-8208;1.0;2229
-8209;1.0;5810
-820A;1.0;7149
-820C;1.0;3269
-820D;1.0;7150
-820E;1.0;2843
-8210;1.0;7151
-8212;1.0;4816
-8216;1.0;7152
-8217;1.0;4262
-8218;1.0;2060
-821B;1.0;3304
-821C;1.0;2956
-821E;1.0;4181
-821F;1.0;2914
-8229;1.0;7153
-822A;1.0;2550
-822B;1.0;7154
-822C;1.0;4044
-822E;1.0;7168
-8233;1.0;7156
-8235;1.0;3441
-8236;1.0;3985
-8237;1.0;2431
-8238;1.0;7155
-8239;1.0;3305
-8240;1.0;7157
-8247;1.0;3690
-8258;1.0;7159
-8259;1.0;7158
-825A;1.0;7161
-825D;1.0;7160
-825F;1.0;7162
-8262;1.0;7164
-8264;1.0;7163
-8266;1.0;2047
-8268;1.0;7165
-826A;1.0;7166
-826B;1.0;7167
-826E;1.0;2617
-826F;1.0;4641
-8271;1.0;7169
-8272;1.0;3107
-8276;1.0;1780
-8277;1.0;7170
-8278;1.0;7171
-827E;1.0;7172
-828B;1.0;1682
-828D;1.0;7173
-8292;1.0;7174
-8299;1.0;4171
-829D;1.0;2839
-829F;1.0;7176
-82A5;1.0;1909
-82A6;1.0;1618
-82AB;1.0;7175
-82AC;1.0;7178
-82AD;1.0;3946
-82AF;1.0;3136
-82B1;1.0;1854
-82B3;1.0;4307
-82B8;1.0;2361
-82B9;1.0;2260
-82BB;1.0;7177
-82BD;1.0;1874
-82C5;1.0;2003
-82D1;1.0;1781
-82D2;1.0;7182
-82D3;1.0;4674
-82D4;1.0;3461
-82D7;1.0;4136
-82D9;1.0;7194
-82DB;1.0;1855
-82DC;1.0;7192
-82DE;1.0;7190
-82DF;1.0;7181
-82E1;1.0;7179
-82E3;1.0;7180
-82E5;1.0;2867
-82E6;1.0;2276
-82E7;1.0;3587
-82EB;1.0;3849
-82F1;1.0;1749
-82F3;1.0;7184
-82F4;1.0;7183
-82F9;1.0;7189
-82FA;1.0;7185
-82FB;1.0;7188
-8302;1.0;4448
-8303;1.0;7187
-8304;1.0;1856
-8305;1.0;1993
-8306;1.0;7191
-8309;1.0;7193
-830E;1.0;2352
-8316;1.0;7203
-8317;1.0;7212
-8318;1.0;7213
-831C;1.0;1611
-8323;1.0;7220
-8328;1.0;1681
-832B;1.0;7211
-832F;1.0;7210
-8331;1.0;7205
-8332;1.0;7204
-8334;1.0;7202
-8335;1.0;7201
-8336;1.0;3567
-8338;1.0;3491
-8339;1.0;7207
-8340;1.0;7206
-8345;1.0;7209
-8349;1.0;3380
-834A;1.0;2353
-834F;1.0;1733
-8350;1.0;7208
-8352;1.0;2551
-8358;1.0;3381
-8373;1.0;7226
-8375;1.0;7227
-8377;1.0;1857
-837B;1.0;1814
-837C;1.0;7224
-8385;1.0;7214
-8387;1.0;7222
-8389;1.0;7229
-838A;1.0;7223
-838E;1.0;7221
-8393;1.0;7186
-8396;1.0;7219
-839A;1.0;7215
-839E;1.0;2048
-839F;1.0;7217
-83A0;1.0;7228
-83A2;1.0;7218
-83A8;1.0;7230
-83AA;1.0;7216
-83AB;1.0;3992
-83B1;1.0;4573
-83B5;1.0;7225
-83BD;1.0;7247
-83C1;1.0;7239
-83C5;1.0;3191
-83CA;1.0;2138
-83CC;1.0;2261
-83CE;1.0;7234
-83D3;1.0;1859
-83D6;1.0;3052
-83D8;1.0;7237
-83DC;1.0;2658
-83DF;1.0;3749
-83E0;1.0;7242
-83E9;1.0;4278
-83EB;1.0;7233
-83EF;1.0;1858
-83F0;1.0;2454
-83F1;1.0;4109
-83F2;1.0;7243
-83F4;1.0;7231
-83F7;1.0;7240
-83FB;1.0;7250
-83FD;1.0;7235
-8403;1.0;7236
-8404;1.0;3826
-8407;1.0;7241
-840B;1.0;7238
-840C;1.0;4308
-840D;1.0;7244
-840E;1.0;1664
-8413;1.0;7232
-8420;1.0;7246
-8422;1.0;7245
-8429;1.0;3975
-842A;1.0;7252
-842C;1.0;7263
-8431;1.0;1994
-8435;1.0;7266
-8438;1.0;7248
-843C;1.0;7253
-843D;1.0;4578
-8446;1.0;7262
-8449;1.0;4553
-844E;1.0;4610
-8457;1.0;3588
-845B;1.0;1975
-8461;1.0;4182
-8462;1.0;7268
-8463;1.0;3801
-8466;1.0;1617
-8469;1.0;7261
-846B;1.0;7257
-846C;1.0;3382
-846D;1.0;7251
-846E;1.0;7259
-846F;1.0;7264
-8471;1.0;3912
-8475;1.0;1610
-8477;1.0;7256
-8479;1.0;7265
-847A;1.0;4188
-8482;1.0;7260
-8484;1.0;7255
-848B;1.0;3053
-8490;1.0;2915
-8494;1.0;2812
-8499;1.0;4456
-849C;1.0;4139
-849F;1.0;7271
-84A1;1.0;7280
-84AD;1.0;7258
-84B2;1.0;1987
-84B8;1.0;3088
-84B9;1.0;7269
-84BB;1.0;7274
-84BC;1.0;3383
-84BF;1.0;7270
-84C1;1.0;7277
-84C4;1.0;3563
-84C6;1.0;7278
-84C9;1.0;4554
-84CA;1.0;7267
-84CB;1.0;1924
-84CD;1.0;7273
-84D0;1.0;7276
-84D1;1.0;4412
-84D6;1.0;7279
-84D9;1.0;7272
-84DA;1.0;7275
-84EC;1.0;4309
-84EE;1.0;4701
-84F4;1.0;7283
-84FC;1.0;7290
-84FF;1.0;7282
-8500;1.0;2835
-8506;1.0;7249
-8511;1.0;4246
-8513;1.0;4402
-8514;1.0;7289
-8515;1.0;7288
-8517;1.0;7284
-8518;1.0;7285
-851A;1.0;1722
-851F;1.0;7287
-8521;1.0;7281
-8526;1.0;3653
-852C;1.0;7286
-852D;1.0;1694
-8535;1.0;3402
-853D;1.0;4235
-8540;1.0;7291
-8541;1.0;7301
-8543;1.0;4057
-8548;1.0;7294
-8549;1.0;3054
-854A;1.0;2841
-854B;1.0;7303
-854E;1.0;2230
-8555;1.0;7304
-8557;1.0;4189
-8558;1.0;7293
-855A;1.0;7254
-8563;1.0;7292
-8568;1.0;4747
-8569;1.0;3802
-856A;1.0;4183
-856D;1.0;7311
-8577;1.0;7317
-857E;1.0;7318
-8580;1.0;7305
-8584;1.0;3986
-8587;1.0;7315
-8588;1.0;7307
-858A;1.0;7309
-8590;1.0;7319
-8591;1.0;7308
-8594;1.0;7312
-8597;1.0;1782
-8599;1.0;3869
-859B;1.0;7313
-859C;1.0;7316
-85A4;1.0;7306
-85A6;1.0;3306
-85A8;1.0;7310
-85A9;1.0;2707
-85AA;1.0;3137
-85AB;1.0;2316
-85AC;1.0;4484
-85AE;1.0;4489
-85AF;1.0;2982
-85B9;1.0;7323
-85BA;1.0;7321
-85C1;1.0;4746
-85C9;1.0;7320
-85CD;1.0;4585
-85CF;1.0;7322
-85D0;1.0;7324
-85D5;1.0;7325
-85DC;1.0;7328
-85DD;1.0;7326
-85E4;1.0;3803
-85E5;1.0;7327
-85E9;1.0;4045
-85EA;1.0;7314
-85F7;1.0;2983
-85F9;1.0;7329
-85FA;1.0;7334
-85FB;1.0;3384
-85FE;1.0;7333
-8602;1.0;7302
-8606;1.0;7335
-8607;1.0;3341
-860A;1.0;7330
-860B;1.0;7332
-8613;1.0;7331
-8616;1.0;6117
-8617;1.0;6102
-861A;1.0;7337
-8622;1.0;7336
-862D;1.0;4586
-862F;1.0;6628
-8630;1.0;7338
-863F;1.0;7339
-864D;1.0;7340
-864E;1.0;2455
-8650;1.0;2152
-8654;1.0;7342
-8655;1.0;4961
-865A;1.0;2185
-865C;1.0;4626
-865E;1.0;2283
-865F;1.0;7343
-8667;1.0;7344
-866B;1.0;3578
-8671;1.0;7345
-8679;1.0;3890
-867B;1.0;1626
-868A;1.0;1867
-868B;1.0;7350
-868C;1.0;7351
-8693;1.0;7346
-8695;1.0;2729
-86A3;1.0;7347
-86A4;1.0;3934
-86A9;1.0;7348
-86AA;1.0;7349
-86AB;1.0;7359
-86AF;1.0;7353
-86B0;1.0;7356
-86B6;1.0;7352
-86C4;1.0;7354
-86C6;1.0;7355
-86C7;1.0;2856
-86C9;1.0;7357
-86CB;1.0;3533
-86CD;1.0;2354
-86CE;1.0;1934
-86D4;1.0;7360
-86D9;1.0;1931
-86DB;1.0;7365
-86DE;1.0;7361
-86DF;1.0;7364
-86E4;1.0;4026
-86E9;1.0;7362
-86EC;1.0;7363
-86ED;1.0;4140
-86EE;1.0;4058
-86EF;1.0;7366
-86F8;1.0;3493
-86F9;1.0;7376
-86FB;1.0;7372
-86FE;1.0;1875
-8700;1.0;7370
-8702;1.0;4310
-8703;1.0;7371
-8706;1.0;7368
-8708;1.0;7369
-8709;1.0;7374
-870A;1.0;7377
-870D;1.0;7375
-8711;1.0;7373
-8712;1.0;7367
-8718;1.0;3556
-871A;1.0;7384
-871C;1.0;4410
-8725;1.0;7382
-8729;1.0;7383
-8734;1.0;7378
-8737;1.0;7380
-873B;1.0;7381
-873F;1.0;7379
-8749;1.0;3270
-874B;1.0;4725
-874C;1.0;7388
-874E;1.0;7389
-8753;1.0;7401
-8755;1.0;3110
-8757;1.0;7391
-8759;1.0;7394
-875F;1.0;7386
-8760;1.0;7385
-8763;1.0;7402
-8766;1.0;1860
-8768;1.0;7392
-876A;1.0;7403
-876E;1.0;7393
-8774;1.0;7390
-8776;1.0;3619
-8778;1.0;7387
-877F;1.0;3972
-8782;1.0;7407
-878D;1.0;4527
-879F;1.0;7406
-87A2;1.0;7405
-87AB;1.0;7414
-87AF;1.0;7408
-87B3;1.0;7416
-87BA;1.0;4570
-87BB;1.0;7419
-87BD;1.0;7410
-87C0;1.0;7411
-87C4;1.0;7415
-87C6;1.0;7418
-87C7;1.0;7417
-87CB;1.0;7409
-87D0;1.0;7412
-87D2;1.0;7429
-87E0;1.0;7422
-87EF;1.0;7420
-87F2;1.0;7421
-87F6;1.0;7426
-87F7;1.0;7427
-87F9;1.0;1910
-87FB;1.0;2134
-87FE;1.0;7425
-8805;1.0;7404
-880D;1.0;7424
-880E;1.0;7428
-880F;1.0;7423
-8811;1.0;7430
-8815;1.0;7432
-8816;1.0;7431
-8821;1.0;7434
-8822;1.0;7433
-8823;1.0;7358
-8827;1.0;7438
-8831;1.0;7435
-8836;1.0;7436
-8839;1.0;7437
-883B;1.0;7439
-8840;1.0;2376
-8842;1.0;7441
-8844;1.0;7440
-8846;1.0;2916
-884C;1.0;2552
-884D;1.0;6207
-8852;1.0;7442
-8853;1.0;2949
-8857;1.0;1925
-8859;1.0;7443
-885B;1.0;1750
-885D;1.0;3055
-885E;1.0;7444
-8861;1.0;2553
-8862;1.0;7445
-8863;1.0;1665
-8868;1.0;4129
-886B;1.0;7446
-8870;1.0;3174
-8872;1.0;7453
-8875;1.0;7450
-8877;1.0;3579
-887D;1.0;7451
-887E;1.0;7448
-887F;1.0;2262
-8881;1.0;7447
-8882;1.0;7454
-8888;1.0;2322
-888B;1.0;3462
-888D;1.0;7460
-8892;1.0;7456
-8896;1.0;3421
-8897;1.0;7455
-8899;1.0;7458
-889E;1.0;7449
-88A2;1.0;7459
-88A4;1.0;7461
-88AB;1.0;4079
-88AE;1.0;7457
-88B0;1.0;7462
-88B1;1.0;7464
-88B4;1.0;2451
-88B5;1.0;7452
-88B7;1.0;1633
-88BF;1.0;7463
-88C1;1.0;2659
-88C2;1.0;4686
-88C3;1.0;7465
-88C4;1.0;7466
-88C5;1.0;3385
-88CF;1.0;4602
-88D4;1.0;7467
-88D5;1.0;4521
-88D8;1.0;7468
-88D9;1.0;7469
-88DC;1.0;4268
-88DD;1.0;7470
-88DF;1.0;2632
-88E1;1.0;4603
-88E8;1.0;7475
-88F2;1.0;7476
-88F3;1.0;3056
-88F4;1.0;7474
-88F8;1.0;4571
-88F9;1.0;7471
-88FC;1.0;7473
-88FD;1.0;3229
-88FE;1.0;3194
-8902;1.0;7472
-8904;1.0;7477
-8907;1.0;4203
-890A;1.0;7479
-890C;1.0;7478
-8910;1.0;1976
-8912;1.0;4311
-8913;1.0;7480
-891D;1.0;7492
-891E;1.0;7482
-8925;1.0;7483
-892A;1.0;7484
-892B;1.0;7485
-8936;1.0;7489
-8938;1.0;7490
-893B;1.0;7488
-8941;1.0;7486
-8943;1.0;7481
-8944;1.0;7487
-894C;1.0;7491
-894D;1.0;8023
-8956;1.0;1808
-895E;1.0;7494
-895F;1.0;2263
-8960;1.0;7493
-8964;1.0;7502
-8966;1.0;7501
-896A;1.0;7504
-896D;1.0;7503
-896F;1.0;7505
-8972;1.0;2917
-8974;1.0;7506
-8977;1.0;7507
-897E;1.0;7508
-897F;1.0;3230
-8981;1.0;4555
-8983;1.0;7509
-8986;1.0;4204
-8987;1.0;3938
-8988;1.0;7510
-898A;1.0;7511
-898B;1.0;2411
-898F;1.0;2112
-8993;1.0;7512
-8996;1.0;2775
-8997;1.0;3933
-8998;1.0;7513
-899A;1.0;1948
-89A1;1.0;7514
-89A6;1.0;7516
-89A7;1.0;4587
-89A9;1.0;7515
-89AA;1.0;3138
-89AC;1.0;7517
-89AF;1.0;7518
-89B2;1.0;7519
-89B3;1.0;2049
-89BA;1.0;7520
-89BD;1.0;7521
-89BF;1.0;7522
-89C0;1.0;7523
-89D2;1.0;1949
-89DA;1.0;7524
-89DC;1.0;7525
-89DD;1.0;7526
-89E3;1.0;1882
-89E6;1.0;3108
-89E7;1.0;7527
-89F4;1.0;7528
-89F8;1.0;7529
-8A00;1.0;2432
-8A02;1.0;3691
-8A03;1.0;7530
-8A08;1.0;2355
-8A0A;1.0;3154
-8A0C;1.0;7533
-8A0E;1.0;3804
-8A10;1.0;7532
-8A13;1.0;2317
-8A16;1.0;7531
-8A17;1.0;3487
-8A18;1.0;2113
-8A1B;1.0;7534
-8A1D;1.0;7535
-8A1F;1.0;3057
-8A23;1.0;2377
-8A25;1.0;7536
-8A2A;1.0;4312
-8A2D;1.0;3263
-8A31;1.0;2186
-8A33;1.0;4485
-8A34;1.0;3342
-8A36;1.0;7537
-8A3A;1.0;3139
-8A3B;1.0;3580
-8A3C;1.0;3058
-8A41;1.0;7538
-8A46;1.0;7541
-8A48;1.0;7542
-8A50;1.0;2630
-8A51;1.0;3434
-8A52;1.0;7540
-8A54;1.0;3059
-8A55;1.0;4130
-8A5B;1.0;7539
-8A5E;1.0;2776
-8A60;1.0;1751
-8A62;1.0;7546
-8A63;1.0;2356
-8A66;1.0;2778
-8A69;1.0;2777
-8A6B;1.0;4745
-8A6C;1.0;7545
-8A6D;1.0;7544
-8A6E;1.0;3307
-8A70;1.0;2145
-8A71;1.0;4735
-8A72;1.0;1926
-8A73;1.0;3060
-8A7C;1.0;7543
-8A82;1.0;7548
-8A84;1.0;7549
-8A85;1.0;7547
-8A87;1.0;2456
-8A89;1.0;4532
-8A8C;1.0;2779
-8A8D;1.0;3907
-8A91;1.0;7552
-8A93;1.0;3232
-8A95;1.0;3534
-8A98;1.0;4522
-8A9A;1.0;7555
-8A9E;1.0;2476
-8AA0;1.0;3231
-8AA1;1.0;7551
-8AA3;1.0;7556
-8AA4;1.0;2477
-8AA5;1.0;7553
-8AA6;1.0;7554
-8AA8;1.0;7550
-8AAC;1.0;3266
-8AAD;1.0;3841
-8AB0;1.0;3515
-8AB2;1.0;1861
-8AB9;1.0;4080
-8ABC;1.0;2135
-8ABF;1.0;3620
-8AC2;1.0;7559
-8AC4;1.0;7557
-8AC7;1.0;3544
-8ACB;1.0;3233
-8ACC;1.0;2050
-8ACD;1.0;7558
-8ACF;1.0;3159
-8AD2;1.0;4642
-8AD6;1.0;4732
-8ADA;1.0;7560
-8ADB;1.0;7571
-8ADC;1.0;3621
-8ADE;1.0;7570
-8AE0;1.0;7567
-8AE1;1.0;7575
-8AE2;1.0;7568
-8AE4;1.0;7564
-8AE6;1.0;3692
-8AE7;1.0;7563
-8AEB;1.0;7561
-8AED;1.0;4501
-8AEE;1.0;2780
-8AF1;1.0;7565
-8AF3;1.0;7562
-8AF7;1.0;7569
-8AF8;1.0;2984
-8AFA;1.0;2433
-8AFE;1.0;3490
-8B00;1.0;4337
-8B01;1.0;1758
-8B02;1.0;1666
-8B04;1.0;3805
-8B07;1.0;7573
-8B0C;1.0;7572
-8B0E;1.0;3870
-8B10;1.0;7577
-8B14;1.0;7566
-8B16;1.0;7576
-8B17;1.0;7578
-8B19;1.0;2412
-8B1A;1.0;7574
-8B1B;1.0;2554
-8B1D;1.0;2853
-8B20;1.0;7579
-8B21;1.0;4556
-8B26;1.0;7582
-8B28;1.0;7585
-8B2B;1.0;7583
-8B2C;1.0;4121
-8B33;1.0;7580
-8B39;1.0;2264
-8B3E;1.0;7584
-8B41;1.0;7586
-8B49;1.0;7590
-8B4C;1.0;7587
-8B4E;1.0;7589
-8B4F;1.0;7588
-8B56;1.0;7591
-8B58;1.0;2817
-8B5A;1.0;7593
-8B5B;1.0;7592
-8B5C;1.0;4172
-8B5F;1.0;7601
-8B66;1.0;2357
-8B6B;1.0;7594
-8B6C;1.0;7602
-8B6F;1.0;7603
-8B70;1.0;2136
-8B71;1.0;7033
-8B72;1.0;3089
-8B74;1.0;7604
-8B77;1.0;2478
-8B7D;1.0;7605
-8B80;1.0;7606
-8B83;1.0;2730
-8B8A;1.0;5846
-8B8C;1.0;7607
-8B8E;1.0;7608
-8B90;1.0;2918
-8B92;1.0;7609
-8B93;1.0;7610
-8B96;1.0;7611
-8B99;1.0;7612
-8B9A;1.0;7613
-8C37;1.0;3511
-8C3A;1.0;7614
-8C3F;1.0;7616
-8C41;1.0;7615
-8C46;1.0;3806
-8C48;1.0;7617
-8C4A;1.0;4313
-8C4C;1.0;7618
-8C4E;1.0;7619
-8C50;1.0;7620
-8C55;1.0;7621
-8C5A;1.0;3858
-8C61;1.0;3061
-8C62;1.0;7622
-8C6A;1.0;2575
-8C6B;1.0;4814
-8C6C;1.0;7623
-8C78;1.0;7624
-8C79;1.0;4131
-8C7A;1.0;7625
-8C7C;1.0;7633
-8C82;1.0;7626
-8C85;1.0;7628
-8C89;1.0;7627
-8C8A;1.0;7629
-8C8C;1.0;4338
-8C8D;1.0;7630
-8C8E;1.0;7631
-8C94;1.0;7632
-8C98;1.0;7634
-8C9D;1.0;1913
-8C9E;1.0;3671
-8CA0;1.0;4173
-8CA1;1.0;2666
-8CA2;1.0;2555
-8CA7;1.0;4147
-8CA8;1.0;1863
-8CA9;1.0;4046
-8CAA;1.0;7637
-8CAB;1.0;2051
-8CAC;1.0;3253
-8CAD;1.0;7636
-8CAE;1.0;7641
-8CAF;1.0;3589
-8CB0;1.0;4467
-8CB2;1.0;7639
-8CB3;1.0;7640
-8CB4;1.0;2114
-8CB6;1.0;7642
-8CB7;1.0;3967
-8CB8;1.0;3463
-8CBB;1.0;4081
-8CBC;1.0;3729
-8CBD;1.0;7638
-8CBF;1.0;4339
-8CC0;1.0;1876
-8CC1;1.0;7644
-8CC2;1.0;4708
-8CC3;1.0;3634
-8CC4;1.0;4737
-8CC7;1.0;2781
-8CC8;1.0;7643
-8CCA;1.0;3417
-8CCD;1.0;7660
-8CCE;1.0;3308
-8CD1;1.0;3888
-8CD3;1.0;4148
-8CDA;1.0;7647
-8CDB;1.0;2731
-8CDC;1.0;2782
-8CDE;1.0;3062
-8CE0;1.0;3969
-8CE2;1.0;2413
-8CE3;1.0;7646
-8CE4;1.0;7645
-8CE6;1.0;4174
-8CEA;1.0;2833
-8CED;1.0;3750
-8CFA;1.0;7649
-8CFB;1.0;7650
-8CFC;1.0;2556
-8CFD;1.0;7648
-8D04;1.0;7651
-8D05;1.0;7652
-8D07;1.0;7654
-8D08;1.0;3403
-8D0A;1.0;7653
-8D0B;1.0;2070
-8D0D;1.0;7656
-8D0F;1.0;7655
-8D10;1.0;7657
-8D13;1.0;7659
-8D14;1.0;7661
-8D16;1.0;7662
-8D64;1.0;3254
-8D66;1.0;2847
-8D67;1.0;7663
-8D6B;1.0;1950
-8D6D;1.0;7664
-8D70;1.0;3386
-8D71;1.0;7665
-8D73;1.0;7666
-8D74;1.0;4175
-8D77;1.0;2115
-8D81;1.0;7667
-8D85;1.0;3622
-8D8A;1.0;1759
-8D99;1.0;7668
-8DA3;1.0;2881
-8DA8;1.0;3186
-8DB3;1.0;3413
-8DBA;1.0;7671
-8DBE;1.0;7670
-8DC2;1.0;7669
-8DCB;1.0;7677
-8DCC;1.0;7675
-8DCF;1.0;7672
-8DD6;1.0;7674
-8DDA;1.0;7673
-8DDB;1.0;7676
-8DDD;1.0;2187
-8DDF;1.0;7680
-8DE1;1.0;3255
-8DE3;1.0;7681
-8DE8;1.0;2457
-8DEA;1.0;7678
-8DEB;1.0;7679
-8DEF;1.0;4709
-8DF3;1.0;3623
-8DF5;1.0;3309
-8DFC;1.0;7682
-8DFF;1.0;7685
-8E08;1.0;7683
-8E09;1.0;7684
-8E0A;1.0;4557
-8E0F;1.0;3807
-8E10;1.0;7688
-8E1D;1.0;7686
-8E1E;1.0;7687
-8E1F;1.0;7689
-8E2A;1.0;7709
-8E30;1.0;7692
-8E34;1.0;7693
-8E35;1.0;7691
-8E42;1.0;7690
-8E44;1.0;3693
-8E47;1.0;7701
-8E48;1.0;7705
-8E49;1.0;7702
-8E4A;1.0;7694
-8E4C;1.0;7703
-8E50;1.0;7704
-8E55;1.0;7711
-8E59;1.0;7706
-8E5F;1.0;3256
-8E60;1.0;7708
-8E63;1.0;7710
-8E64;1.0;7707
-8E72;1.0;7713
-8E74;1.0;2919
-8E76;1.0;7712
-8E7C;1.0;7714
-8E81;1.0;7715
-8E84;1.0;7718
-8E85;1.0;7717
-8E87;1.0;7716
-8E8A;1.0;7720
-8E8B;1.0;7719
-8E8D;1.0;4486
-8E91;1.0;7722
-8E93;1.0;7721
-8E94;1.0;7723
-8E99;1.0;7724
-8EA1;1.0;7726
-8EAA;1.0;7725
-8EAB;1.0;3140
-8EAC;1.0;7727
-8EAF;1.0;2277
-8EB0;1.0;7728
-8EB1;1.0;7730
-8EBE;1.0;7731
-8EC5;1.0;7732
-8EC6;1.0;7729
-8EC8;1.0;7733
-8ECA;1.0;2854
-8ECB;1.0;7734
-8ECC;1.0;2116
-8ECD;1.0;2319
-8ED2;1.0;2414
-8EDB;1.0;7735
-8EDF;1.0;3880
-8EE2;1.0;3730
-8EE3;1.0;7736
-8EEB;1.0;7739
-8EF8;1.0;2820
-8EFB;1.0;7738
-8EFC;1.0;7737
-8EFD;1.0;2358
-8EFE;1.0;7740
-8F03;1.0;1951
-8F05;1.0;7742
-8F09;1.0;2660
-8F0A;1.0;7741
-8F0C;1.0;7750
-8F12;1.0;7744
-8F13;1.0;7746
-8F14;1.0;4269
-8F15;1.0;7743
-8F19;1.0;7745
-8F1B;1.0;7749
-8F1C;1.0;7747
-8F1D;1.0;2117
-8F1F;1.0;7748
-8F26;1.0;7751
-8F29;1.0;3958
-8F2A;1.0;4656
-8F2F;1.0;2920
-8F33;1.0;7752
-8F38;1.0;4502
-8F39;1.0;7754
-8F3B;1.0;7753
-8F3E;1.0;7757
-8F3F;1.0;4533
-8F42;1.0;7756
-8F44;1.0;1977
-8F45;1.0;7755
-8F46;1.0;7760
-8F49;1.0;7759
-8F4C;1.0;7758
-8F4D;1.0;3718
-8F4E;1.0;7761
-8F57;1.0;7762
-8F5C;1.0;7763
-8F5F;1.0;2576
-8F61;1.0;2305
-8F62;1.0;7764
-8F63;1.0;7765
-8F64;1.0;7766
-8F9B;1.0;3141
-8F9C;1.0;7767
-8F9E;1.0;2813
-8F9F;1.0;7768
-8FA3;1.0;7769
-8FA7;1.0;5001
-8FA8;1.0;4994
-8FAD;1.0;7770
-8FAE;1.0;6980
-8FAF;1.0;7771
-8FB0;1.0;3504
-8FB1;1.0;3111
-8FB2;1.0;3932
-8FB7;1.0;7772
-8FBA;1.0;4253
-8FBB;1.0;3652
-8FBC;1.0;2594
-8FBF;1.0;3509
-8FC2;1.0;1710
-8FC4;1.0;4388
-8FC5;1.0;3155
-8FCE;1.0;2362
-8FD1;1.0;2265
-8FD4;1.0;4254
-8FDA;1.0;7773
-8FE2;1.0;7775
-8FE5;1.0;7774
-8FE6;1.0;1864
-8FE9;1.0;3886
-8FEA;1.0;7776
-8FEB;1.0;3987
-8FED;1.0;3719
-8FEF;1.0;7777
-8FF0;1.0;2950
-8FF4;1.0;7779
-8FF7;1.0;4434
-8FF8;1.0;7794
-8FF9;1.0;7781
-8FFA;1.0;7782
-8FFD;1.0;3641
-9000;1.0;3464
-9001;1.0;3387
-9003;1.0;3808
-9005;1.0;7780
-9006;1.0;2153
-900B;1.0;7789
-900D;1.0;7786
-900E;1.0;7805
-900F;1.0;3809
-9010;1.0;3564
-9011;1.0;7783
-9013;1.0;3694
-9014;1.0;3751
-9015;1.0;7784
-9016;1.0;7788
-9017;1.0;3164
-9019;1.0;3971
-901A;1.0;3644
-901D;1.0;3234
-901E;1.0;7787
-901F;1.0;3414
-9020;1.0;3404
-9021;1.0;7785
-9022;1.0;1609
-9023;1.0;4702
-9027;1.0;7790
-902E;1.0;3465
-9031;1.0;2921
-9032;1.0;3142
-9035;1.0;7792
-9036;1.0;7791
-9038;1.0;1679
-9039;1.0;7793
-903C;1.0;4115
-903E;1.0;7807
-9041;1.0;3859
-9042;1.0;3175
-9045;1.0;3557
-9047;1.0;2288
-9049;1.0;7806
-904A;1.0;4523
-904B;1.0;1731
-904D;1.0;4255
-904E;1.0;1865
-904F;1.0;7801
-9050;1.0;7802
-9051;1.0;7803
-9052;1.0;7804
-9053;1.0;3827
-9054;1.0;3503
-9055;1.0;1667
-9056;1.0;7808
-9058;1.0;7809
-9059;1.0;8403
-905C;1.0;3429
-905E;1.0;7810
-9060;1.0;1783
-9061;1.0;3344
-9063;1.0;2415
-9065;1.0;4558
-9068;1.0;7811
-9069;1.0;3712
-906D;1.0;3388
-906E;1.0;2855
-906F;1.0;7812
-9072;1.0;7815
-9075;1.0;2969
-9076;1.0;7813
-9077;1.0;3311
-9078;1.0;3310
-907A;1.0;1668
-907C;1.0;4643
-907D;1.0;7817
-907F;1.0;4082
-9080;1.0;7819
-9081;1.0;7818
-9082;1.0;7816
-9083;1.0;6768
-9084;1.0;2052
-9087;1.0;7778
-9089;1.0;7821
-908A;1.0;7820
-908F;1.0;7822
-9091;1.0;4524
-90A3;1.0;3865
-90A6;1.0;4314
-90A8;1.0;7823
-90AA;1.0;2857
-90AF;1.0;7824
-90B1;1.0;7825
-90B5;1.0;7826
-90B8;1.0;3701
-90C1;1.0;1674
-90CA;1.0;2557
-90CE;1.0;4726
-90DB;1.0;7830
-90E1;1.0;2320
-90E2;1.0;7827
-90E4;1.0;7828
-90E8;1.0;4184
-90ED;1.0;1952
-90F5;1.0;4525
-90F7;1.0;2231
-90FD;1.0;3752
-9102;1.0;7831
-9112;1.0;7832
-9119;1.0;7833
-912D;1.0;3702
-9130;1.0;7835
-9132;1.0;7834
-9149;1.0;3851
-914A;1.0;7836
-914B;1.0;2922
-914C;1.0;2864
-914D;1.0;3959
-914E;1.0;3581
-9152;1.0;2882
-9154;1.0;3176
-9156;1.0;7837
-9158;1.0;7838
-9162;1.0;3161
-9163;1.0;7839
-9165;1.0;7840
-9169;1.0;7841
-916A;1.0;4579
-916C;1.0;2923
-9172;1.0;7843
-9173;1.0;7842
-9175;1.0;2558
-9177;1.0;2583
-9178;1.0;2732
-9182;1.0;7846
-9187;1.0;2970
-9189;1.0;7845
-918B;1.0;7844
-918D;1.0;3473
-9190;1.0;2479
-9192;1.0;3235
-9197;1.0;4016
-919C;1.0;2925
-91A2;1.0;7847
-91A4;1.0;3063
-91AA;1.0;7850
-91AB;1.0;7848
-91AF;1.0;7849
-91B4;1.0;7852
-91B5;1.0;7851
-91B8;1.0;3090
-91BA;1.0;7853
-91C0;1.0;7854
-91C1;1.0;7855
-91C6;1.0;4048
-91C7;1.0;2651
-91C8;1.0;2865
-91C9;1.0;7856
-91CB;1.0;7857
-91CC;1.0;4604
-91CD;1.0;2937
-91CE;1.0;4478
-91CF;1.0;4644
-91D0;1.0;7858
-91D1;1.0;2266
-91D6;1.0;7859
-91D8;1.0;3703
-91DB;1.0;7862
-91DC;1.0;1988
-91DD;1.0;3143
-91DF;1.0;7860
-91E1;1.0;7861
-91E3;1.0;3664
-91E6;1.0;4353
-91E7;1.0;2292
-91F5;1.0;7864
-91F6;1.0;7865
-91FC;1.0;7863
-91FF;1.0;7867
-920D;1.0;3863
-920E;1.0;1935
-9211;1.0;7871
-9214;1.0;7868
-9215;1.0;7870
-921E;1.0;7866
-9229;1.0;7947
-922C;1.0;7869
-9234;1.0;4675
-9237;1.0;2458
-923F;1.0;7879
-9244;1.0;3720
-9245;1.0;7874
-9248;1.0;7877
-9249;1.0;7875
-924B;1.0;7880
-9250;1.0;7881
-9257;1.0;7873
-925A;1.0;7886
-925B;1.0;1784
-925E;1.0;7872
-9262;1.0;4013
-9264;1.0;7876
-9266;1.0;3064
-9271;1.0;2559
-927E;1.0;4340
-9280;1.0;2268
-9283;1.0;2938
-9285;1.0;3828
-9291;1.0;3313
-9293;1.0;7884
-9295;1.0;7878
-9296;1.0;7883
-9298;1.0;4435
-929A;1.0;3624
-929B;1.0;7885
-929C;1.0;7882
-92AD;1.0;3312
-92B7;1.0;7889
-92B9;1.0;7888
-92CF;1.0;7887
-92D2;1.0;4315
-92E4;1.0;2991
-92E9;1.0;7890
-92EA;1.0;4263
-92ED;1.0;1752
-92F2;1.0;4138
-92F3;1.0;3582
-92F8;1.0;2188
-92FA;1.0;7892
-92FC;1.0;2561
-9306;1.0;2712
-930F;1.0;7891
-9310;1.0;3177
-9318;1.0;3178
-9319;1.0;7901
-931A;1.0;7903
-9320;1.0;3091
-9322;1.0;7902
-9323;1.0;7904
-9326;1.0;2251
-9328;1.0;4137
-932B;1.0;2866
-932C;1.0;4703
-932E;1.0;7894
-932F;1.0;2688
-9332;1.0;4731
-9335;1.0;7906
-933A;1.0;7905
-933B;1.0;7907
-9344;1.0;7893
-934B;1.0;3873
-934D;1.0;3753
-9354;1.0;3655
-9356;1.0;7912
-935B;1.0;3535
-935C;1.0;7908
-9360;1.0;7909
-936C;1.0;2313
-936E;1.0;7911
-9375;1.0;2416
-937C;1.0;7910
-937E;1.0;3065
-938C;1.0;1989
-9394;1.0;7916
-9396;1.0;2631
-9397;1.0;3389
-939A;1.0;3642
-93A7;1.0;1927
-93AC;1.0;7914
-93AD;1.0;7915
-93AE;1.0;3635
-93B0;1.0;7913
-93B9;1.0;7917
-93C3;1.0;7923
-93C8;1.0;7926
-93D0;1.0;7925
-93D1;1.0;3713
-93D6;1.0;7918
-93D7;1.0;7919
-93D8;1.0;7922
-93DD;1.0;7924
-93E1;1.0;2232
-93E4;1.0;7927
-93E5;1.0;7921
-93E8;1.0;7920
-9403;1.0;7931
-9407;1.0;7932
-9410;1.0;7933
-9413;1.0;7930
-9414;1.0;7929
-9418;1.0;3066
-9419;1.0;3810
-941A;1.0;7928
-9421;1.0;7937
-942B;1.0;7935
-9435;1.0;7936
-9436;1.0;7934
-9438;1.0;3488
-943A;1.0;7938
-9441;1.0;7939
-9444;1.0;7941
-9451;1.0;2053
-9452;1.0;7940
-9453;1.0;4490
-945A;1.0;7952
-945B;1.0;7942
-945E;1.0;7945
-9460;1.0;7943
-9462;1.0;7944
-946A;1.0;7946
-9470;1.0;7948
-9475;1.0;7949
-9477;1.0;7950
-947C;1.0;7953
-947D;1.0;7951
-947E;1.0;7954
-947F;1.0;7956
-9481;1.0;7955
-9577;1.0;3625
-9580;1.0;4471
-9582;1.0;7957
-9583;1.0;3314
-9587;1.0;7958
-9589;1.0;4236
-958A;1.0;7959
-958B;1.0;1911
-958F;1.0;1728
-9591;1.0;2055
-9593;1.0;2054
-9594;1.0;7960
-9596;1.0;7961
-9598;1.0;7962
-9599;1.0;7963
-95A0;1.0;7964
-95A2;1.0;2056
-95A3;1.0;1953
-95A4;1.0;2562
-95A5;1.0;4022
-95A7;1.0;7966
-95A8;1.0;7965
-95AD;1.0;7967
-95B2;1.0;1760
-95B9;1.0;7970
-95BB;1.0;7969
-95BC;1.0;7968
-95BE;1.0;7971
-95C3;1.0;7974
-95C7;1.0;1639
-95CA;1.0;7972
-95CC;1.0;7976
-95CD;1.0;7975
-95D4;1.0;7978
-95D5;1.0;7977
-95D6;1.0;7979
-95D8;1.0;3814
-95DC;1.0;7980
-95E1;1.0;7981
-95E2;1.0;7983
-95E5;1.0;7982
-961C;1.0;4176
-9621;1.0;7984
-9628;1.0;7985
-962A;1.0;2669
-962E;1.0;7986
-962F;1.0;7987
-9632;1.0;4341
-963B;1.0;3343
-963F;1.0;1604
-9640;1.0;3443
-9642;1.0;7988
-9644;1.0;4177
-964B;1.0;7991
-964C;1.0;7989
-964D;1.0;2563
-964F;1.0;7990
-9650;1.0;2434
-965B;1.0;4237
-965C;1.0;7993
-965D;1.0;8001
-965E;1.0;7994
-965F;1.0;8002
-9662;1.0;1701
-9663;1.0;3156
-9664;1.0;2992
-9665;1.0;2057
-9666;1.0;8003
-966A;1.0;3970
-966C;1.0;8005
-9670;1.0;1702
-9672;1.0;8004
-9673;1.0;3636
-9675;1.0;4645
-9676;1.0;3811
-9677;1.0;7992
-9678;1.0;4606
-967A;1.0;2417
-967D;1.0;4559
-9685;1.0;2289
-9686;1.0;4620
-9688;1.0;2308
-968A;1.0;3466
-968B;1.0;7101
-968D;1.0;8006
-968E;1.0;1912
-968F;1.0;3179
-9694;1.0;1954
-9695;1.0;8008
-9697;1.0;8009
-9698;1.0;8007
-9699;1.0;2368
-969B;1.0;2661
-969C;1.0;3067
-96A0;1.0;1703
-96A3;1.0;4657
-96A7;1.0;8011
-96A8;1.0;7814
-96AA;1.0;8010
-96B0;1.0;8014
-96B1;1.0;8012
-96B2;1.0;8013
-96B4;1.0;8015
-96B6;1.0;8016
-96B7;1.0;4676
-96B8;1.0;8017
-96B9;1.0;8018
-96BB;1.0;3241
-96BC;1.0;4027
-96C0;1.0;3193
-96C1;1.0;2071
-96C4;1.0;4526
-96C5;1.0;1877
-96C6;1.0;2924
-96C7;1.0;2459
-96C9;1.0;8021
-96CB;1.0;8020
-96CC;1.0;2783
-96CD;1.0;8022
-96CE;1.0;8019
-96D1;1.0;2708
-96D5;1.0;8026
-96D6;1.0;7413
-96D9;1.0;5054
-96DB;1.0;3187
-96DC;1.0;8024
-96E2;1.0;4605
-96E3;1.0;3881
-96E8;1.0;1711
-96EA;1.0;3267
-96EB;1.0;2822
-96F0;1.0;4223
-96F2;1.0;1732
-96F6;1.0;4677
-96F7;1.0;4575
-96F9;1.0;8027
-96FB;1.0;3737
-9700;1.0;2891
-9704;1.0;8028
-9706;1.0;8029
-9707;1.0;3144
-9708;1.0;8030
-970A;1.0;4678
-970D;1.0;8025
-970E;1.0;8032
-970F;1.0;8034
-9711;1.0;8033
-9713;1.0;8031
-9716;1.0;8035
-9719;1.0;8036
-971C;1.0;3390
-971E;1.0;1866
-9724;1.0;8037
-9727;1.0;4424
-972A;1.0;8038
-9730;1.0;8039
-9732;1.0;4710
-9738;1.0;5917
-9739;1.0;8040
-973D;1.0;8041
-973E;1.0;8042
-9742;1.0;8046
-9744;1.0;8043
-9746;1.0;8044
-9748;1.0;8045
-9749;1.0;8047
-9752;1.0;3236
-9756;1.0;4487
-9759;1.0;3237
-975C;1.0;8048
-975E;1.0;4083
-9760;1.0;8049
-9761;1.0;8351
-9762;1.0;4444
-9764;1.0;8050
-9766;1.0;8051
-9768;1.0;8052
-9769;1.0;1955
-976B;1.0;8054
-976D;1.0;3157
-9771;1.0;8055
-9774;1.0;2304
-9779;1.0;8056
-977A;1.0;8060
-977C;1.0;8058
-9781;1.0;8059
-9784;1.0;1983
-9785;1.0;8057
-9786;1.0;8061
-978B;1.0;8062
-978D;1.0;1640
-978F;1.0;8063
-9790;1.0;8064
-9798;1.0;3068
-979C;1.0;8065
-97A0;1.0;2139
-97A3;1.0;8068
-97A6;1.0;8067
-97A8;1.0;8066
-97AB;1.0;7581
-97AD;1.0;4260
-97B3;1.0;8069
-97B4;1.0;8070
-97C3;1.0;8071
-97C6;1.0;8072
-97C8;1.0;8073
-97CB;1.0;8074
-97D3;1.0;2058
-97DC;1.0;8075
-97ED;1.0;8076
-97EE;1.0;3903
-97F2;1.0;8078
-97F3;1.0;1827
-97F5;1.0;8081
-97F6;1.0;8080
-97FB;1.0;1704
-97FF;1.0;2233
-9801;1.0;4239
-9802;1.0;3626
-9803;1.0;2602
-9805;1.0;2564
-9806;1.0;2971
-9808;1.0;3160
-980C;1.0;8083
-980F;1.0;8082
-9810;1.0;4534
-9811;1.0;2072
-9812;1.0;4050
-9813;1.0;3860
-9817;1.0;3192
-9818;1.0;4646
-981A;1.0;2359
-9821;1.0;8086
-9824;1.0;8085
-982C;1.0;4343
-982D;1.0;3812
-9834;1.0;1748
-9837;1.0;8087
-9838;1.0;8084
-983B;1.0;4149
-983C;1.0;4574
-983D;1.0;8088
-9846;1.0;8089
-984B;1.0;8091
-984C;1.0;3474
-984D;1.0;1959
-984E;1.0;1960
-984F;1.0;8090
-9854;1.0;2073
-9855;1.0;2418
-9858;1.0;2074
-985B;1.0;3731
-985E;1.0;4664
-9867;1.0;2460
-986B;1.0;8092
-986F;1.0;8093
-9870;1.0;8094
-9871;1.0;8101
-9873;1.0;8103
-9874;1.0;8102
-98A8;1.0;4187
-98AA;1.0;8104
-98AF;1.0;8105
-98B1;1.0;8106
-98B6;1.0;8107
-98C3;1.0;8109
-98C4;1.0;8108
-98C6;1.0;8110
-98DB;1.0;4084
-98DC;1.0;7044
-98DF;1.0;3109
-98E2;1.0;2118
-98E9;1.0;8111
-98EB;1.0;8112
-98ED;1.0;5012
-98EE;1.0;6127
-98EF;1.0;4051
-98F2;1.0;1691
-98F4;1.0;1627
-98FC;1.0;2784
-98FD;1.0;4316
-98FE;1.0;3094
-9903;1.0;8113
-9905;1.0;4463
-9909;1.0;8114
-990A;1.0;4560
-990C;1.0;1734
-9910;1.0;2733
-9912;1.0;8115
-9913;1.0;1878
-9914;1.0;8116
-9918;1.0;8117
-991D;1.0;8119
-991E;1.0;8120
-9920;1.0;8122
-9921;1.0;8118
-9924;1.0;8121
-9928;1.0;2059
-992C;1.0;8123
-992E;1.0;8124
-993D;1.0;8125
-993E;1.0;8126
-9942;1.0;8127
-9945;1.0;8129
-9949;1.0;8128
-994B;1.0;8131
-994C;1.0;8134
-9950;1.0;8130
-9951;1.0;8132
-9952;1.0;8133
-9955;1.0;8135
-9957;1.0;2234
-9996;1.0;2883
-9997;1.0;8136
-9998;1.0;8137
-9999;1.0;2565
-99A5;1.0;8138
-99A8;1.0;1930
-99AC;1.0;3947
-99AD;1.0;8139
-99AE;1.0;8140
-99B3;1.0;3558
-99B4;1.0;3875
-99BC;1.0;8141
-99C1;1.0;3993
-99C4;1.0;3444
-99C5;1.0;1756
-99C6;1.0;2278
-99C8;1.0;2279
-99D0;1.0;3583
-99D1;1.0;8146
-99D2;1.0;2280
-99D5;1.0;1879
-99D8;1.0;8145
-99DB;1.0;8143
-99DD;1.0;8144
-99DF;1.0;8142
-99E2;1.0;8156
-99ED;1.0;8147
-99EE;1.0;8148
-99F1;1.0;8149
-99F2;1.0;8150
-99F8;1.0;8152
-99FB;1.0;8151
-99FF;1.0;2957
-9A01;1.0;8153
-9A05;1.0;8155
-9A0E;1.0;2119
-9A0F;1.0;8154
-9A12;1.0;3391
-9A13;1.0;2419
-9A19;1.0;8157
-9A28;1.0;3445
-9A2B;1.0;8158
-9A30;1.0;3813
-9A37;1.0;8159
-9A3E;1.0;8164
-9A40;1.0;8162
-9A42;1.0;8161
-9A43;1.0;8163
-9A45;1.0;8160
-9A4D;1.0;8166
-9A55;1.0;8165
-9A57;1.0;8168
-9A5A;1.0;2235
-9A5B;1.0;8167
-9A5F;1.0;8169
-9A62;1.0;8170
-9A64;1.0;8172
-9A65;1.0;8171
-9A69;1.0;8173
-9A6A;1.0;8175
-9A6B;1.0;8174
-9AA8;1.0;2592
-9AAD;1.0;8176
-9AB0;1.0;8177
-9AB8;1.0;1928
-9ABC;1.0;8178
-9AC0;1.0;8179
-9AC4;1.0;3181
-9ACF;1.0;8180
-9AD1;1.0;8181
-9AD3;1.0;8182
-9AD4;1.0;8183
-9AD8;1.0;2566
-9ADE;1.0;8184
-9ADF;1.0;8185
-9AE2;1.0;8186
-9AE3;1.0;8187
-9AE6;1.0;8188
-9AEA;1.0;4017
-9AEB;1.0;8190
-9AED;1.0;4106
-9AEE;1.0;8191
-9AEF;1.0;8189
-9AF1;1.0;8193
-9AF4;1.0;8192
-9AF7;1.0;8194
-9AFB;1.0;8201
-9B06;1.0;8202
-9B18;1.0;8203
-9B1A;1.0;8204
-9B1F;1.0;8205
-9B22;1.0;8206
-9B23;1.0;8207
-9B25;1.0;8208
-9B27;1.0;8209
-9B28;1.0;8210
-9B29;1.0;8211
-9B2A;1.0;8212
-9B2E;1.0;8213
-9B2F;1.0;8214
-9B31;1.0;6121
-9B32;1.0;8215
-9B3B;1.0;6888
-9B3C;1.0;2120
-9B41;1.0;1901
-9B42;1.0;2618
-9B43;1.0;8217
-9B44;1.0;8216
-9B45;1.0;4405
-9B4D;1.0;8219
-9B4E;1.0;8220
-9B4F;1.0;8218
-9B51;1.0;8221
-9B54;1.0;4366
-9B58;1.0;8222
-9B5A;1.0;2191
-9B6F;1.0;4705
-9B74;1.0;8223
-9B83;1.0;8225
-9B8E;1.0;1630
-9B91;1.0;8226
-9B92;1.0;4211
-9B93;1.0;8224
-9B96;1.0;8227
-9B97;1.0;8228
-9B9F;1.0;8229
-9BA0;1.0;8230
-9BA8;1.0;8231
-9BAA;1.0;4378
-9BAB;1.0;2713
-9BAD;1.0;2690
-9BAE;1.0;3315
-9BB4;1.0;8232
-9BB9;1.0;8235
-9BC0;1.0;8233
-9BC6;1.0;8236
-9BC9;1.0;2481
-9BCA;1.0;8234
-9BCF;1.0;8237
-9BD1;1.0;8238
-9BD2;1.0;8239
-9BD4;1.0;8243
-9BD6;1.0;2710
-9BDB;1.0;3468
-9BE1;1.0;8244
-9BE2;1.0;8241
-9BE3;1.0;8240
-9BE4;1.0;8242
-9BE8;1.0;2363
-9BF0;1.0;8248
-9BF1;1.0;8247
-9BF2;1.0;8246
-9BF5;1.0;1619
-9C04;1.0;8258
-9C06;1.0;8254
-9C08;1.0;8255
-9C09;1.0;8251
-9C0A;1.0;8257
-9C0C;1.0;8253
-9C0D;1.0;1966
-9C10;1.0;4744
-9C12;1.0;8256
-9C13;1.0;8252
-9C14;1.0;8250
-9C15;1.0;8249
-9C1B;1.0;8260
-9C21;1.0;8263
-9C24;1.0;8262
-9C25;1.0;8261
-9C2D;1.0;4141
-9C2E;1.0;8259
-9C2F;1.0;1683
-9C30;1.0;8264
-9C32;1.0;8266
-9C39;1.0;1979
-9C3A;1.0;8245
-9C3B;1.0;1723
-9C3E;1.0;8268
-9C46;1.0;8267
-9C47;1.0;8265
-9C48;1.0;3513
-9C52;1.0;4380
-9C57;1.0;4658
-9C5A;1.0;8269
-9C60;1.0;8270
-9C67;1.0;8271
-9C76;1.0;8272
-9C78;1.0;8273
-9CE5;1.0;3627
-9CE7;1.0;8274
-9CE9;1.0;4023
-9CEB;1.0;8279
-9CEC;1.0;8275
-9CF0;1.0;8276
-9CF3;1.0;4317
-9CF4;1.0;4436
-9CF6;1.0;3848
-9D03;1.0;8280
-9D06;1.0;8281
-9D07;1.0;3830
-9D08;1.0;8278
-9D09;1.0;8277
-9D0E;1.0;1810
-9D12;1.0;8289
-9D15;1.0;8288
-9D1B;1.0;1785
-9D1F;1.0;8286
-9D23;1.0;8285
-9D26;1.0;8283
-9D28;1.0;1991
-9D2A;1.0;8282
-9D2B;1.0;2818
-9D2C;1.0;1809
-9D3B;1.0;2567
-9D3E;1.0;8292
-9D3F;1.0;8291
-9D41;1.0;8290
-9D44;1.0;8287
-9D46;1.0;8293
-9D48;1.0;8294
-9D50;1.0;8305
-9D51;1.0;8304
-9D59;1.0;8306
-9D5C;1.0;1713
-9D5D;1.0;8301
-9D5E;1.0;8302
-9D60;1.0;2584
-9D61;1.0;4425
-9D64;1.0;8303
-9D6C;1.0;4318
-9D6F;1.0;8311
-9D72;1.0;8307
-9D7A;1.0;8312
-9D87;1.0;8309
-9D89;1.0;8308
-9D8F;1.0;2360
-9D9A;1.0;8313
-9DA4;1.0;8314
-9DA9;1.0;8315
-9DAB;1.0;8310
-9DAF;1.0;8284
-9DB2;1.0;8316
-9DB4;1.0;3665
-9DB8;1.0;8320
-9DBA;1.0;8321
-9DBB;1.0;8319
-9DC1;1.0;8318
-9DC2;1.0;8324
-9DC4;1.0;8317
-9DC6;1.0;8322
-9DCF;1.0;8323
-9DD3;1.0;8326
-9DD9;1.0;8325
-9DE6;1.0;8328
-9DED;1.0;8329
-9DEF;1.0;8330
-9DF2;1.0;4741
-9DF8;1.0;8327
-9DF9;1.0;3475
-9DFA;1.0;2677
-9DFD;1.0;8331
-9E1A;1.0;8332
-9E1B;1.0;8333
-9E1E;1.0;8334
-9E75;1.0;8335
-9E78;1.0;2420
-9E79;1.0;8336
-9E7D;1.0;8337
-9E7F;1.0;2815
-9E81;1.0;8338
-9E88;1.0;8339
-9E8B;1.0;8340
-9E8C;1.0;8341
-9E91;1.0;8344
-9E92;1.0;8342
-9E93;1.0;4728
-9E95;1.0;8343
-9E97;1.0;4679
-9E9D;1.0;8345
-9E9F;1.0;4659
-9EA5;1.0;8346
-9EA6;1.0;3994
-9EA9;1.0;8347
-9EAA;1.0;8349
-9EAD;1.0;8350
-9EB8;1.0;8348
-9EB9;1.0;2577
-9EBA;1.0;4445
-9EBB;1.0;4367
-9EBC;1.0;5487
-9EBE;1.0;6164
-9EBF;1.0;4391
-9EC4;1.0;1811
-9ECC;1.0;8352
-9ECD;1.0;2148
-9ECE;1.0;8353
-9ECF;1.0;8354
-9ED0;1.0;8355
-9ED2;1.0;2585
-9ED4;1.0;8356
-9ED8;1.0;6452
-9ED9;1.0;4459
-9EDB;1.0;3467
-9EDC;1.0;8357
-9EDD;1.0;8359
-9EDE;1.0;8358
-9EE0;1.0;8360
-9EE5;1.0;8361
-9EE8;1.0;8362
-9EEF;1.0;8363
-9EF4;1.0;8364
-9EF6;1.0;8365
-9EF7;1.0;8366
-9EF9;1.0;8367
-9EFB;1.0;8368
-9EFC;1.0;8369
-9EFD;1.0;8370
-9F07;1.0;8371
-9F08;1.0;8372
-9F0E;1.0;3704
-9F13;1.0;2461
-9F15;1.0;8374
-9F20;1.0;3345
-9F21;1.0;8375
-9F2C;1.0;8376
-9F3B;1.0;4101
-9F3E;1.0;8377
-9F4A;1.0;8378
-9F4B;1.0;6723
-9F4E;1.0;7658
-9F4F;1.0;8077
-9F52;1.0;8379
-9F54;1.0;8380
-9F5F;1.0;8382
-9F60;1.0;8383
-9F61;1.0;8384
-9F62;1.0;4680
-9F63;1.0;8381
-9F66;1.0;8385
-9F67;1.0;8386
-9F6A;1.0;8388
-9F6C;1.0;8387
-9F72;1.0;8390
-9F76;1.0;8391
-9F77;1.0;8389
-9F8D;1.0;4622
-9F95;1.0;8392
-9F9C;1.0;8393
-9F9D;1.0;6752
-9FA0;1.0;8394
-
-
-B. idntabjplocalmap10.txt
-
-version=1.0
-
-2212;1.0;FF0D
-309B;1.0;3099
-309C;1.0;309A
+++ /dev/null
-Internet Draft Mark Davis
-draft-ietf-idn-lace-01.txt IBM
-January 5, 2001 Paul Hoffman
-Expires July 5, 2001 IMC & VPNC
-
- LACE: Length-based ASCII Compatible Encoding for IDN
-
-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 transformation method for representing
-non-ASCII characters in host name parts in a fashion that is completely
-compatible with the current DNS. It is a potential candidate for an
-ASCII-Compatible Encoding (ACE) for internationalized host names, as
-described in the comparison document from the IETF IDN Working Group.
-This method is based on the observation that many internationalized host
-name parts will have a few substrings from a small number of rows of the
-ISO 10646 repertoire. Run-length encoding for these types of
-host names will be fairly compact, and is fairly easy to describe.
-
-
-1. Introduction
-
-There is a strong world-wide desire to use characters other than plain
-ASCII in host names. Host names have become the equivalent of business
-or product names for many services on the Internet, so there is a need
-to make them usable by people whose native scripts are not representable
-by ASCII. The requirements for internationalizing host names are
-described in the IDN WG's requirements document, [IDNReq].
-
-The IDN WG's comparison document [IDNComp] describes three potential
-main architectures for IDN: arch-1 (just send binary), arch-2 (send
-binary or ACE), and arch-3 (just send ACE). LACE is an ACE, called
-Length-based ACE or LACE, that can be used with protocols that match arch-2
-or arch-3. LACE specifies an ACE format as specified in ace-1 in
-[IDNComp]. Further, it specifies an identifying mechanism for ace-2 in
-[IDNComp], namely ace-2.1.1 (add hopefully-unique legal tag to the
-beginning of the name part).
-
-In formal terms, LACE describes a character encoding scheme of the
-ISO/IEC 10646 [ISO10646] coded character set (whose assignment of
-characters is synchronized with Unicode [Unicode3]) and the rules for
-using that scheme in the DNS. As such, it could also be called a
-"charset" as defined in [IDNReq]. It can also be viewed as a specialized
-UTF (transformation format), designed to work within the restrictions of
-the DNS.
-
-The LACE protocol has the following features:
-
-- There is exactly one way to convert internationalized host parts to
-and from LACE parts. Host name part uniqueness is preserved.
-
-- Host parts that have no international characters are not changed.
-
-- Names using LACE can include more internationalized characters than
-with other ACE protocols that have been suggested to date. LACE-encoded
-names are variable length, depending on the number of transitions
-between rows in the ISO 10646 repertoire that appear in the name part.
-Name parts that cannot be compressed using run-length encoding can have
-up to 17 characters, and names that can be compressed can have up to 35
-characters. Further, a name that has just a few row transitions
-typically can have over 30 characters.
-
-It is important to note that the following sections contain many
-normative statements with "MUST" and "MUST NOT". Any implementation that
-does not follow these statements exactly is likely to cause damage to
-the Internet by creating non-unique representations of host names.
-
-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 for code points and names
-from the Unicode Standard [Unicode3] and ISO 10646. For example, the
-letter "a" may be represented as either "U+0061" or "LATIN SMALL LETTER
-A".
-
-LACE 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".
-
-1.2 IDN summary
-
-Using the terminology in [IDNComp], LACE specifies an ACE format as
-specified in ace-1. Further, it specifies an identifying mechanism for
-ace-2, namely ace-2.1.1 (add hopefully-unique legal tag to the beginning
-of the name part).
-
-LACE has the following length characteristics.
-
-- LACE-encoded names are variable length, depending on the number of
-transitions between rows that appear in the name part.
-
-- Name parts that cannot be compressed using run-length encoding can
-have up to 17 characters.
-
-- Names that can be compressed can have up to 35 characters.
-
--A name that has just a few row transitions typically can have over 30
-characters.
-
-
-2. Host Part Transformation
-
-According to [STD13], host parts must be case-insensitive, start and
-end with a letter or digit, and contain only letters, digits, and the
-hyphen character ("-"). This, of course, excludes any internationalized
-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 Name tagging
-
-All post-converted name parts that contain internationalized characters
-begin with the string "lq--". (Of course, because host name parts are
-case-insensitive, this might also be represented as "Lq--" or "lQ--" or
-"LQ--".) The string "lq--" was chosen because it is extremely unlikely
-to exist in host parts before this specification was produced. As a
-historical note, in late October 2000, none of the second-level host
-name parts in any of the .com, .edu, .net, and .org top-level domains
-began with "lq--"; there are many tens of thousands of other strings of
-three characters followed by a hyphen that have this property and could
-be used instead. The string "lq--" will change to other strings with the
-same properties in future versions of this draft.
-
-Note that a zone administrator might still choose to use "lq--" at the
-beginning of a host name part even if that part does not contain
-internationalized characters. Zone administrators SHOULD NOT create host
-part names that begin with "lq--" unless those names are post-converted
-names. Creating host part names that begin with "lq--" but that are not
-post-converted names may cause two distinct problems. Some display
-systems, after converting the post-converted name part back to an
-internationalized name part, might display the name parts in a
-possibly-confusing fashion to users. More seriously, some resolvers,
-after converting the post-converted name part back to an
-internationalized name part, might reject the host name if it contains
-illegal characters.
-
-2.2 Converting an internationalized name to an ACE name part
-
-To convert a string of internationalized characters into an ACE name
-part, the following steps MUST be preformed in the exact order of the
-subsections given here.
-
-If a name part consists exclusively of characters that conform to the
-host name requirements in [STD13], the name MUST NOT be converted to
-LACE. That is, a name part that can be represented without LACE MUST NOT
-be encoded using LACE. This absolute requirement prevents there from
-being two different encodings for a single DNS host name.
-
-If any checking for prohibited name parts (such as ones that are
-prohibited characters, case-folding, or canonicalization) is to be done,
-it MUST be done before doing the conversion to an ACE name part.
-
-Characters outside the first plane of characters (those with codepoints
-above U+FFFF) MUST be represented using surrogates, as described in
-RFC 2781 [RFC2781].
-
-The input name string consists of characters from the ISO 10646
-character set in big-endian UTF-16 encoding. This is the pre-converted
-string.
-
-2.2.1 Check the input string for disallowed names
-
-If the input string consists only of characters that conform to the host
-name requirements in [STD13], the conversion MUST stop with an error.
-
-2.2.2 Compress the pre-converted string
-
-The entire pre-converted string MUST be compressed using the compression
-algorithm specified in section 2.4. The result of this step is the
-compressed string.
-
-2.2.3 Check the length of the compressed string
-
-The compressed string MUST be 36 octets or shorter. If the compressed
-string is 37 octets or longer, the conversion MUST stop with an error.
-
-2.2.4 Encode the compressed string with Base32
-
-The compressed string MUST be converted using the Base32 encoding
-described in section 2.5. The result of this step is the encoded string.
-
-2.2.5 Prepend "lq--" to the encoded string and finish
-
-Prepend the characters "lq--" to the encoded string. This is the host
-name part that can be used in DNS resolution.
-
-2.3 Converting a host name part to an internationalized name
-
-The input string for conversion is a valid host name part. Note that if
-any checking for prohibited name parts (such as prohibited characters,
-case-folding, or canonicalization is to be done, it MUST be done after
-doing the conversion from an ACE name part.
-
-If a decoded name part consists exclusively of characters that conform
-to the host name requirements in [STD13], the conversion from LACE MUST
-fail. Because a name part that can be represented without LACE MUST NOT
-be encoded using LACE, the decoding process MUST check for name parts
-that consists exclusively of characters that conform to the host name
-requirements in [STD13] and, if such a name part is found, MUST
-beconsidered an error (and possibly a security violation).
-
-2.3.1 Strip the "lq--"
-
-The input string MUST begin with the characters "lq--". If it does not,
-the conversion MUST stop with an error. Otherwise, remove the characters
-"lq--" from the input string. The result of this step is the stripped
-string.
-
-2.3.2 Decode the stripped string with Base32
-
-The entire stripped string MUST be checked to see if it is valid Base32
-output. The entire stripped string MUST be changed to all lower-case
-letters and digits. If any resulting characters are not in Table 1, the
-conversion MUST stop with an error; the input string is the
-post-converted string. Otherwise, the entire resulting string MUST be
-converted to a binary format using the Base32 decoding described in
-section 2.5. The result of this step is the decoded string.
-
-2.3.3 Decompress the decoded string
-
-The entire decoded string MUST be converted to ISO 10646 characters
-using the decompression algorithm described in section 2.4. The result
-of this is the internationalized string.
-
-2.3.4 Check the internationalized string for disallowed names
-
-If the internationalized string consists only of characters that conform
-to the host name requirements in [STD13], the conversion MUST stop with
-an error.
-
-2.4 Compression algorithm
-
-The basic method for compression is to reduce a substring that consists
-of characters all from a single row of the ISO 10646 repertoire to a
-count octet followed by the row header followed by the lower octets of
-the characters. If this ends up being longer than the input, the string
-is not compressed, but instead has a unique one-octet header attached.
-
-Although the uncompressed mode limits the number of characters in a LACE
-name part to 17, this is still generally enough for all names in almost
-scripts. Also, this limit is close to the limits set by other encoding
-proposals.
-
-Note that the compression and decompression rules MUST be followed
-exactly. This requirement prevents a single host name part from having
-two encodings. Thus, for any input to the algorithm, there is only one
-possible output. An implementation cannot chose to use one-octet mode or
-two-octet mode using anything other than the logic given in this
-section.
-
-2.4.1 Compressing a string
-
-The input string is in the UTF-16 encoding (big-endian UTF-16 with no
-byte order mark).
-
-Design note: No checking is done on the input to this algorithm. It is
-assumed that all checking for valid ISO/IEC 10646 characters has already
-been done by a previous step in the conversion process.
-
-1) If the length (measured in octets) of the input is not even, or is
-less than 2, stop with an error.
-
-2) Set the input pointer, called IP, to the first octet of the input
-string.
-
-3) Set the variable called HIGH to the octet at IP.
-
-4) Determine the number of contiguous pairs at or after IP that have
-HIGH as the first octet; call this COUNT.
-
-5) Put into an output buffer the single octet for COUNT followed by the
-single octet for HIGH, followed by all those low octets. Move IP to the
-end of those pairs; that is, set IP to IP+(2*COUNT).
-
-6) If IP is not at the end of the input string, go to step 3.
-
-7) If the length of the output buffer is less than or equal to the
-length of the input buffer (in octets, not in characters), emit the
-output buffer. Otherwise, output the octet 0xFF followed by the input
-buffer. Note that there can only be one possible representation for a
-name part, so that outputting the wrong name part is a serious security
-error. Decompression schemes MUST accept only the valid form and MUST
-NOT accept invalid forms.
-
-2.4.2 Decompressing a string
-
-1. Set the input pointer, called IP, to the first octet of the input
-string. If there is no first octet, stop with an error.
-
-2. If the octet at IP is 0xFF, set IP to IP+1, copy the rest of the
-input buffer to the output buffer, and go to step 9.
-
-3. Get the octet at IP, call it COUNT. If COUNT equals zero or is
-greater than 36, stop with an error. Set IP to IP+1. If IP is now at the
-end of the input string, stop with an error.
-
-4. Get the octet at IP, call it HIGH. Set IP to IP+1.
-
-5. If IP is now at the end of the input string, stop with an error. Get
-the octet at IP, call it LOW. Set IP to IP+1.
-
-6. Output HIGH, then LOW, to the output buffer.
-
-7. Decrement COUNT. If COUNT is greater than 0, go to step 5.
-
-8. If IP is not at the end of the input buffer, go to step 3.
-
-9. If the length of the output buffer is odd, stop with an error.
-Compress the output buffer into a separate comparison buffer following
-the steps for compression above. If the contents of the comparison
-buffer does not equal the input to the compression step, stop with an
-error. Otherwise, send out the output buffer and stop.
-
-2.4.3 Compression examples
-
-The five input characters <U+30E6 U+30CB U+30B3 U+30FC U+30C9> are
-represented in big-endian UTF-16 as the ten octets <30 E6 30 CB 30 B3 30
-FC 30 C9>. All the code units are in the same row (03). The output
-buffer has seven octets <05 30 E6 CB B3 FC C9>, which is shorter than
-the input string. Thus the output is <05 30 E6 CB B3 FC C9>.
-
-The four input characters <U+012F U+0111 U+0149 U+00E5> are represented
-in big-endian UTF-16 as the eight octets <01 2F 01 11 01 49 00 E5>. The
-output buffer has eight octets <03 01 2F 11 49 01 00 E5>, which is the
-same length as the input string. Thus, the output is <03 01 2F 11 49 01
-00 E5>.
-
-The three input characters <U+012F U+00E0 U+014B> are represented in
-big-endian UTF-16 as the six octets <01 2F 00 E0 01 4B>. The output
-buffer is nine octets <01 01 2F 01 00 E0 01 01 4B>, which is longer than
-the input buffer. Thus, the output is <FF 01 2F 00 E0 01 4B>.
-
-2.5 Base32
-
-In order to encode non-ASCII characters in DNS-compatible host name parts,
-they must be converted into legal characters. This is done with Base32
-encoding, described here.
-
-Table 1 shows the mapping between input bits and output characters in
-Base32. Design note: the digits used in Base32 are "2" through "7"
-instead of "0" through "6" in order to avoid digits "0" and "1". This
-helps reduce errors for users who are entering a Base32 stream and may
-misinterpret a "0" for an "O" or a "1" for an "l".
-
- Table 1: Base32 conversion
- bits char hex bits char hex
- 00000 a 0x61 10000 q 0x71
- 00001 b 0x62 10001 r 0x72
- 00010 c 0x63 10010 s 0x73
- 00011 d 0x64 10011 t 0x74
- 00100 e 0x65 10100 u 0x75
- 00101 f 0x66 10101 v 0x76
- 00110 g 0x67 10110 w 0x77
- 00111 h 0x68 10111 x 0x78
- 01000 i 0x69 11000 y 0x79
- 01001 j 0x6a 11001 z 0x7a
- 01010 k 0x6b 11010 2 0x32
- 01011 l 0x6c 11011 3 0x33
- 01100 m 0x6d 11100 4 0x34
- 01101 n 0x6e 11101 5 0x35
- 01110 o 0x6f 11110 6 0x36
- 01111 p 0x70 11111 7 0x37
-
-2.5.1 Encoding octets as Base32
-
-The input is a stream of octets. However, the octets are then treated
-as a stream of bits.
-
-Design note: The assumption that the input is a stream of octets
-(instead of a stream of bits) was made so that no padding was needed.
-If you are reusing this algorithm for a stream of bits, you must add a
-padding mechanism in order to differentiate different lengths of input.
-
-1) Set the read pointer to the beginning of the input bit stream.
-
-2) Look at the five bits after the read pointer. If there are not five
-bits, go to step 5.
-
-3) Look up the value of the set of five bits in the bits column of
-Table 1, and output the character from the char column (whose hex value
-is in the hex column).
-
-4) Move the read pointer five bits forward. If the read pointer is at
-the end of the input bit stream (that is, there are no more bits in the
-input), stop. Otherwise, go to step 2.
-
-5) Pad the bits seen until there are five bits.
-
-6) Look up the value of the set of five bits in the bits column of
-Table 1, and output the character from the char column (whose hex value
-is in the hex column).
-
-2.5.2 Decoding Base32 as octets
-
-The input is octets in network byte order. The input octets MUST be
-values from the second column in Table 1.
-
-1) Count the number of octets in the input and divide it by 8; call the
-remainder INPUTCHECK. If INPUTCHECK is 1 or 3 or 6, stop with an error.
-
-2) Set the read pointer to the beginning of the input octet stream.
-
-3) Look up the character value of the octet in the char column (or hex
-value in hex column) of Table 1, and add the five bits from the bits
-column to the output buffer.
-
-4) Move the read pointer one octet forward. If the read pointer is not
-at the end of the input octet stream (that is, there are more octets in
-the input), go to step 3.
-
-5) Count the number of bits that are in the output buffer and divide it
-by 8; call the remainder PADDING. If the PADDING number of bits at the
-end of the output buffer are not all zero, stop with an error.
-Otherwise, emit the output buffer and stop.
-
-2.5.3 Base32 example
-
-Assume you want to encode the value 0x3a270f93. The bit string is:
-
-3 a 2 7 0 f 9 3
-00111010 00100111 00001111 10010011
-
-Broken into chunks of five bits, this is:
-
-00111 01000 10011 10000 11111 00100 11
-
-Padding is added to make the last chunk five bits:
-
-00111 01000 10011 10000 11111 00100 11000
-
-The output of encoding is:
-
-00111 01000 10011 10000 11111 00100 11000
- h i t q 7 e y
-or "hitq7ey".
-
-
-3. 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. Thus, LACE makes no changes to the DNS
-itself.
-
-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.
-
-LACE is designed so that every internationalized host name part
-can be represented as one and only one DNS-compatible string. If there
-is any way to follow the steps in this document and get two or more
-different results, it is a severe and fatal error in the protocol.
-
-
-4. References
-
-[IDNComp] Paul Hoffman, "Comparison of Internationalized Domain Name Proposals",
-draft-ietf-idn-compare.
-
-[IDNReq] James Seng, "Requirements of Internationalized Domain Names",
-draft-ietf-idn-requirement.
-
-[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. [[[ THIS REFERENCE
-NEEDS TO BE UPDATED AFTER DETERMINING ACCEPTABLE WORDING ]]]
-
-[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels", March 1997, RFC 2119.
-
-[RFC2781] Paul Hoffman and Francois Yergeau, "UTF-16, an encoding of ISO
-10646", February 2000, RFC 2781.
-
-[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
-
-Rick Wesson pointed out some error conditions that need to be
-tested for. Scott Hollenbeck pointed out some errors in the
-compression.
-
-Base32 is quite obviously inspired by the tried-and-true Base64
-Content-Transfer-Encoding from MIME.
-
-
-B. Sample code
-
-The following is sample Javascript code for the LACE algorithm.
-This code is believed to be correct, but there may be errors in
-it. The code is provided as-is and comes with no warranty of
-fitness, correctness, blah blah blah.
-
-/**
- * Converts to LACE compression format (without Base32) from
- * UTF-16BE array
- * @parameter iArray Array of bytes in UTF16-BE
- * @parameter iCount Number of elements. Must be 0..63
- * @parameter oArray Array for output of LACE bytes.
- * Must be at least 100 octets long to provide internal working space
- * @return Length of output array used
- * @parameter parseResult output error value if any
- * @author Mark Davis
- */
-
-function toLACE(iArray, iCount, oArray, parseResult) {
-//debugger;
- if (iCount < 1 || iCount > 62) ×{
- parseResult.set("Lace: count out of range", iCount);
- return;
- }
- if ((iCount % 2) == 1) ×{
- parseResult.set("Lace: odd length, can't be UTF-16", iCount);
- return;
- }
- var op = 0; ×// input index
- var ip = 0; ×// output index
- var lastHigh = -1;
- var lenp = 0;
- while (ip < iCount) {
- var high = iArray[ip++];
- if (high != lastHigh) {
- if (lastHigh != -1) { ×// store last length
- var len = op - lenp - 2;
- oArray[lenp] = len;
- } ×
- lenp = op++; // reserve space
- oArray[op++] = high;
- lastHigh = high;
- }
- oArray[op++] = iArray[ip++];
- }
-
- // store last len
-
- var len = op - lenp - 2;
- oArray[lenp] = len;
-
- // see if the input is short, and we should
- // just copy
-
- if (op > iCount) {
- if (op > 63) ×{
- parseResult.set("Lace: output too long", op);
- return;
- }
- oArray[0] = 0xFF;
- copyTo(iArray, 0, iCount, oArray, 1);
- op = iCount + 1;
- }
- return op;
-}
-
-/**
- * Converts from LACE compressed format (without Base32) to
- * UTF-16BE array
- * @parameter iArray Array of bytes in LACE format
- * @parameter iCount Number of elements
- * @parameter oArray Array for output of bytes, UTF16-BE.
- * Must be at least iCount+1 long
- * @return Length of output array used
- * @parameter parseResult output error value if any
- * @author Mark Davis
- */
-
-function fromLACE(iArray, iCount, oArray, parseResult) {
- var high;
- if (iCount < 1 || iCount > 63) {
- parseResult.set("fromLACE: count out of range", iCount);
- return;
- }
- var op = 0;
- var ip = 0;
- var result = 0;
- if (iArray[ip] == 0xFF) { ×// special case FF
- copyTo(iArray, 1, iCount-1, oArray, 0);
- result = iCount-1;
- } else {
- while (ip < iCount) { ×// loop over runs
- var count = iArray[ip++];
- if (ip == iCount) {
- parseResult.set("fromLACE: truncated before high", ip);
- return;
- }
- high = iArray[ip++];
- for (var i = 0; i < count; ++i) {
- oArray[op++] = high;
- if (ip == iCount) ×{
- parseResult.set("fromLACE: truncated from count", ip);
- return;
- }
- oArray[op++] = iArray[ip++];
- }
- }
- result = op;
- }
-
- // check for uniqueness
-
- var checkArray = [];
- var checkCount = toLACE(oArray, result, checkArray, parseResult);
- if (!equals(iArray, iCount, checkArray, checkCount)) {
- parseResult.set("fromLACE: illegal input form");
- return;
- } ×
- return result;
-}
-
-/**
- * Utility routine for comparing arrays
- * @parameter array1 first array to compare
- * @parameter count1 number of elements to compare in first array
- * @parameter array2 second array to compare
- * @parameter count1 number of elements to compare in second array
- * @return true iff counts are same, and elements from 0 to count-1
- * are the same
- */
-
-function equals(array1, count1, array2, count2) {
- if (count1 != count2) return false;
- for (var i = 0; i < count1; ++i) {
- if (array1[i] != array2[i]) return false;
- }
- return true;
-}
-
-/**
- * Utility routine for getting array of bytes from UTF-16 string
- * @parameter str source string
- * @parameter oArray output array to fill in
- * @return count of bytes put into oArray
- */
-
-function utf16FromString(str, oArray) {
- var op = 0;
- for (var i = 0; i < str.length; ++i) {
- var code = str.charCodeAt(i);
- oArray[op++] = (code >>> 8); ×// top byte
- oArray[op++] = (code & 0xFF); // bottom byte
- }
- return op;
-}
-
-/**
- * Utility routine to see if string doesn't need LACE
- * @parameter str source string
- * @return true if ok already
- */
-
-function okAlready(str) {
- for (var i = 0; i < str.length; ++i) {
- var c = str.charAt(i);
- if (c == '-' || 'a' <= c && c <= 'z' || '0' <= c && c <= '9')
- continue;
- return false;
- }
- return true
-}
-
-/**
- * Convert from bytes to base32
- * @parameter input Input buffer of bytes with values 00 to FF
- * @parameter inputLength Length of input buffer
- * @parameter output Output buffer, to be filled with with values from
-a-z2-7.
- * Must be of at least length input*8/5 + 1
- * @return Length of output buffer used
- * @author Mark Davis
- */
-
-function toBase32(input, inputLength, output, parseResult) {
- //debugger;
- var bits = 0;
- var bitCount = 0;
- var ip = 0;
- var op = 0;
- var val = 0;
- while (true) {
-
- // get bits if we don't have enough
-
- if (bitCount < 5) {
- if (ip >= inputLength) break;
- // get another input
- bits <<= 8;
- if (baseDebugTo) alert("byte: " + input[ip].toString(16) + ",
- bitCount: " + (bitCount+8));
-
- bits = bits | input[ip++];
- bitCount += 8;
- }
-
- // emit and remove them
-
- bitCount -= 5;
- val = (bits >> bitCount);
- if (baseDebugTo) alert("Val: " + val.toString(16) + ", bitCount: "
- + bitCount);
- output[op++] = toLetter(val);
- //if (baseDebugTo) alert("out: " + output[op-1].toString(16));
- bits &= ~(0x1F << bitCount);
- }
-
- // add padding and output if necessary
-
- if (bitCount > 0) {
- if (baseDebugTo) alert("bits*: " + bits.toString(16) +
- ", bitCount: " + bitCount);
- val = bits << (5 - bitCount);
- if (baseDebugTo) alert("out*: " + val.toString(16));
- output[op++] = toLetter(val);
- }
- return op;
-}
-
-/**
- * Convert from base32 to bytes
- * @parameter input Input buffer of bytes with values from a-z2-7
- * @parameter inputLength Length of input buffer
- * @parameter output Output buffer, to be filled with bytes from
- * 00 to FF
- * Must be of at least length input*5/8 + 1
- * @return Length of output buffer used
- * @author Mark Davis
- */
-
-function fromBase32(input, inputLength, output, parseResult) {
- //debugger;
- var inputCheck = inputLength % 8;
- if (inputCheck == 1 || inputCheck == 3 || inputCheck == 6) {
- parseResult.set("Base32 excess length", null, inputLength);
- return;
- }
- var bits = 0;
- var bitCount = 0;
- var ip = 0;
- var op = 0;
- var val = 0;
- while (ip < inputLength) {
-
- // get more bits
- var val = input[ip++];
- val = fromLetter(val);
- if (val < 0 || val > 0x3F) {
- parseResult.set("Bad Base32 byte", val, ip-1);
- return;
- }
- if (baseDebugFrom) alert("base32: " + val.toString(16));
- bits <<= 5;
- bits = bits | val;
- bitCount += 5;
- if (baseDebugFrom) alert("from: " + val.toString(16) +
- ", bitCount: " + bitCount);
-
- // emit & remove if we can
-
- if (bitCount >= 8) {
- bitCount -= 8;
- output[op++] = bits >> bitCount;
- if (baseDebugFrom) alert("out2: " + (bits >> bitCount) +
- ", bitCount: " + bitCount);
- bits &= ~(0xFF << bitCount);
- }
- }
-
- // check that padding is with zero!
- if (bits != 0) return -ip;
- return op;
-}
-
-
-function toLetter(val) {
- if (val > 25) return val - 26 + 0x32;
- return val + 0x61;
- // return val + (val < 26 ? 0x61 : 0x18);
-}
-
-function fromLetter(val) {
- if (val < 0x61) return val + 26 - 0x32;
- return val - 0x61;
-}
-
-
-
-C. Difrerences between -00 and -01
-
-1: Minor typos.
-
-2.1: Changed the tag to 'lq--'.
-
-2.2 and 2.3: Added check for all-STD13 names in the steps.
-
-2.4.1: Clarified first sentence. Step 5: fixed the moving of the IP.
-
-2.4.2: Moved the last sentence of step 4 to be the first sentence of
-step 5. Added the check for odd-length output. Changed the exit
-comparision to doing a full comparison (instead of looking for lengths).
-
-2.5.2: Changed the sense of the test in step 3 and added step 4 to check
-for malformed input. Also made the output a buffer. Also added new step
-1.
-
-Changed Appendix B from IANA Considerations (of which there are none) to
-Javascript code sample.
-
-
-D. Author Contact Information
-
-Mark Davis
-IBM
-10275 N. De Anza Blvd
-Cupertino, CA 95014
-mark.davis@us.ibm.com and mark.davis@macchiato.com
-
-Paul Hoffman
-Internet Mail Consortium and VPN Consortium
-127 Segre Place
-Santa Cruz, CA 95060 USA
-paul.hoffman@imc.org and paul.hoffman@vpnc.org
+++ /dev/null
-Internet Draft Maynard Kang
-draft-ietf-idn-mua-00.txt i-EMAIL.net
-February 5, 2001
-Expires on August 5, 2001
-
- Internationalizing Domain Names in Mail User Agents
-
-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 where domain names used in Internet e-mail
-can be internationalized by making changes only to end-user Mail User
-Agents and, by doing so, avoid damaging other applications which handle
-Internet e-mail, such as Message Transfer Agents and Delivery Agents.
-
-1. Introduction
-
-One of the proposed solutions for internationalized domain names (IDN)
-involves only updating the user applications with no changes required
-to the DNS protocol, servers and resolvers [IDNA] compared to other
-solutions which require changes to be made to protocol, servers,
-resolvers and applications.
-
-The underlying principle of [IDNA] may be similarly applied to the
-Internet e-mail system today - by effecting changes to only the Mail
-User Agent (MUA) component of the e-mail system. Thus, existing
-Message Transfer Agents, Delivery Agents and other applications which
-handle e-mail do not have to be changed at all.
-
-1.1 Definitions and Conventions
-
-Usage of terms related to the character encoding model are in
-reference to Unicode Technical Report 17 [UTR17].
-
-The terms "international character", "non-ASCII character" and
-"multilingual character", which are used interchangeably, are taken
-to mean any abstract character which is not included in the range
-specified by [US-ASCII].
-
-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. Design Philosophy
-
-As the Internet e-mail system is a diverse, distributed and
-heterogeneous system with many vendors deploying a vast number of
-applications, it is of utmost importance that interoperability amongst
-these various components is maintained. Thus, the ideal solution would
-be one which does not compromise or damage the operation of any of these
-existing components once internationalized domain names are encountered.
-
-Also, solutions which call for changes to be made to many or even all
-components of the Internet e-mail system would require far too much
-time and effort to deploy, given that Internet e-mail has such a huge
-installed base.
-
-This solution adheres to both of the above principles, in that
-interoperability is preserved and that the cost and speed of
-implementation is low. All that the user has to do to use IDNs in e-mail
-is update his or her MUA.
-
-1.4. IDN Summary
-
-This solution specifies an IDN architecture of arch-3 (just send ACE)
-and a transition strategy of trans-1 (always do current plus new
-architecture) as described in [IDNCOMP]. The choice of ACE format is not
-defined in this document, but MUST be the same as that specified in
-[IDNA] in order to maintain uniqueness and consistency.
-
-1.5. E-mail Internationalization Summary
-
-As many Internet e-mail standards such as the SMTP protocol [RFC821]
-and the e-mail message format [RFC822] only specify usage of the 7-bit
-ASCII character set [US-ASCII], international characters which use octet-
-based character encoding schemes (CES) cannot be used in e-mail
-transmission, headers and bodies.
-
-Although this issue has been addressed in [RFC2045] for message bodies
-and [RFC2047] for message headers through the use of a Transfer Encoding
-Syntax (TES) such as Quoted-Printable or Base64, there is no similar
-solution which extends the functionality of [RFC821] to include usage of
-international characters, except for [RFC1652] which allows transmission
-of 8-bit data passed by the DATA command in an SMTP session.
-
-[RFC1652] however, does not fully address the problem of using IDNs in
-an SMTP session - the IDN may be used in areas within the SMTP session
-other than the DATA command, such as the MAIL FROM and RCPT TO commands,
-where an IDN may be part of the e-mail address(es) specified there.
-
-Hence, this would be a major stumbling block to deploying "just-send-
-8bit" IDNs for use in Internet e-mail, as these IDNs would not be able
-to be used in SMTP e-mail transmissions due to [RFC821] restrictions.
-
-2. Architectural Overview
-
-The end-user MUA may encounter IDNs in the scenarios below:
-
-(i) When specifying the transmission server (i.e. SMTP server)
-(ii) When specifying the retrieval server (i.e. POP3/IMAP4/any other
- retrieval mechanism)
-(iii) When specifying e-mail addresses during composition of a message
-(iv) When reading messages with e-mail addresses in it
-
-As with [IDNA], the MUA is updated in a similar fashion to process IDNs
-which are input by users and process IDNs which are displayed to users,
-in all of the scenarios above.
-
-For (i) and (ii), the IDN MUST be handled in the same manner as
-specified in [IDNA]. The method of handling an IDN For (iii) and (iv) is
-described below in 2.1.
-
-2.1 Interfaces between E-mail components when composing/reading a mail
-
-The interfaces between e-mail components can be pictorially represented
-as shown below.
-
-The example assumes the setup of a POP3/IMAP4 retrieval client and
-server, but the exact nature of end-to-end e-mail transmission may vary
-accordingly (e.g. elm or pine would read directly from the mail store).
-However, these variations do not impact an accurate description of this
-solution to a large extent as no changes are required at these levels.
-
- +------+ +------+
- | User | | User |
- +------+ +---^--|
- | User Input: User Display: Characters/ |
- | Keyboard/Pen/etc Glyphs on CRT or other |
- +-----v---------------+ Representation (e.g. sound) |
- | Input Method Editor | +------------|-----+
- +---------------------+ | Rendering Engine |
- | Input: Any localized/ +---------^--------+
- | internationalized Output: Any localized/ |
- | charset internationalized |
- +----v-----------------+ charset |
- | +------------------+ | +----------|-------------+
- | | Mail Composition | | | +--------------+ |
- | | Interface | | Sender's | | Mail Reading | |
- | +------------------+ | MUA | | Interface | |
- | | | | +--------^-----+ |
- | | Nameprepped ACE | Receiver's | | Nameprepped |
- | v | MUA | | ACE |
- | +-------------+ | | +-------------------+ |
- | | SMTP Client | | | | POP3/IMAP4 Client | |
- | +-------------+ | | +-------------------+ |
- +----|-----------------+ +----------^-------------+
- | Nameprepped | Nameprepped
- v ACE Nameprepped Nameprepped | ACE
- +-------------+ ACE +------------+ ACE +-------------------+
- | SMTP Server | -----> | Mail Store | -----> | POP3/IMAP4 Server |
- +-------------+ +------------+ +-------------------+
-
-2.1.1 Interface between User and Input Method Editor
-
-For ASCII characters, input is straightforward: the user types on the
-keyboard and whichever character that is pressed is sent to the
-application.
-
-However, for international characters, the end-user has to use a script-
-specific Input Method Editor (IME), which may or may not be built-into
-the OS, to interpret what the user communicates to the system and
-thereafter send the respective international characters to the
-application.
-
-For example, for input of Chinese characters, some users use IMEs
-which support the "Pinyin" input method. When a user types "zhongguo"
-(in ASCII characters) on the keyboard and selects the characters which
-represent "China" (in Chinese) from a list, the IME sends the
-international characters to the application in a user-determined
-charset (e.g. GB2312).
-
-2.1.2 Interface between Input Method Editor and MUA Composition
- Interface
-
-The MUA mail composition interface (i.e. the "Compose Message"
-function of the MUA) SHOULD be able to accept IDNs using 8-bit character
-encoding schemes, including those represented in any localized (e.g.
-GB2312) or internationalized (e.g. UTF-8) charsets.
-
-This input typically takes place where e-mail addresses are entered
-such as the "From", "To", "Cc", "Bcc" fields, amongst others, as IDNs
-may be used at the right-hand-side of the "@" sign in an e-mail address
-(domain-parts).
-
-The mail composition interface MAY allow ACE input for the same
-reasons as specified in [IDNA], but is not recommended as ACE is opaque
-and ugly.
-
-2.1.3 Interface between MUA Composition Interface and SMTP Client
-
-The MUA composition interface communicates with the SMTP client in the
-MUA typically through internal function calls within the software itself
-or through an API. It is at this level where ACE conversion of any IDN
-encountered by the MUA composition interface takes place.
-
-Before converting the name parts of the IDN into ACE, the MUA MUST
-prepare each name part as specified in [NAMEPREP]. Thereafter, the MUA
-MUST convert the name parts into ACE before passing any data to the SMTP
-client.
-
-The SMTP client then prepares the e-mail for transmission using the
-SMTP protocol [RFC821], and thereafter establishes an SMTP connection
-with the user-specified SMTP server to transmit the e-mail.
-
-It is important to note that an IDN specified in the parameters of any
-SMTP command MUST be represented in nameprepped ACE at this point in
-time. This includes SMTP commands which require domain parameters (such
-as the HELO and EHLO commands) and commands where e-mail addresses are
-specified (such as the MAIL FROM, RCPT TO, DATA, VRFY, EXPN, SEND, SOML
-and SAML commands).
-
-As for data passed by the DATA command, ACE conversion MUST be
-performed when the "domain" portion of an "addr-spec" or when a "domain"
-itself, within the context of [RFC822], is encountered. This is
-necessary as an updated MUA may originate a message which is read by a
-non-updated MUA. If this happens, the non-updated MUA may face
-operational problems dealing with IDNs that appear in the "addr-spec"
-which are not in ACE.
-
-Any transfer encoding syntax to be applied to the mail headers as
-specified in [RFC2047] SHOULD be performed before nameprepped ACE
-conversion. This is to reduce confusion between IDNs within "addr-spec"
-and "domain" portions, in the context of [RFC822], and IDNs which appear
-as arbitrary data in mail headers and bodies.
-
-2.1.4. Interface between POP3/IMAP4 client (or local mail store) and
- Mail Reading Interface
-
-The MUA mail reading interface (i.e. "Read mail" function of an MUA)
-typically displays e-mail data retrieved from either a POP3/IMAP4
-client or from a local mail store through internal function calls within
-the MUA software or through an API.
-
-When e-mail containing an ACE-represented IDN is to be displayed, the
-MUA SHOULD convert the ACE-represented IDN contained within the
-"addr-spec" or "domain" portion specified in [RFC822] back into any
-localized or internationalized charset of the user's choice, whenever
-possible. In the event that it is impossible to achieve conversion back
-into the selected localized charset (for example, conversion of RACE-
-represented Hangeul characters into ISO-8859-1 is impossible), the MUA
-should prompt the user with an error message.
-
-It may be possible to save and retrieve information about the original
-charset of the ACE-converted IDN through the use of additional
-[RFC822] mail headers, but that is not (yet) addressed by this memo.
-
-Although it is possible to render ACE into properly decoded glyphs and
-display the actual abstract characters without any conversion to other
-charsets, the MUA SHOULD NOT do this as it is not the primary function
-of an MUA to render characters. This should be left to a rendering
-engine which is separate from the MUA and typically embedded into the
-OS. It is sufficient for the MUA to pass the appropriate charset to the
-rendering engine for proper display.
-
-3. ACE Length Considerations
-
-As [RFC821] in Section 4.5.3 restricts the maximum total length of a
-domain name to 64 characters, representation of IDNs using ACE may
-pose a potential problem. Most ACEs typically require 3-4 ASCII
-characters to represent one international character (especially in the
-case of CJK characters, where compression is less effective).
-
-That would leave only about 16-24 characters for the whole IDN,
-including all name parts and dots. This is highly undesirable as some
-languages such as Arabic are unable to be abbreviated and the domain
-names may require a larger length than that which is allowed by
-[RFC821].
-
-To further complicate matters, several mailing list software such as
-ezmlm embed domain names into the local-parts portion of an e-mail
-address during management of subscriptions, together with randomly-
-generated subscription information. This would leave an even smaller
-maximum ACE length, if interoperability with these mailing list software
-were to be maintained, given that there is also a 64 character
-restriction on local parts.
-
-4. Security Considerations
-
-As this memo is based on [IDNA], security considerations are similar
-to that faced by [IDNA]. This includes security considerations from
-[NAMEPREP] as well.
-
-5. Other Considerations
-
-Although this document addresses end-user MUAs (e.g. elm, mutt, pine,
-Eudora, Outlook Express, etc) to a large extent, the definition of an
-MUA could be extended to include web-based e-mail server software and
-automated programs such as mailing list management software.
-
-End-user MUAs may also include additional functionality where IDNs may
-be encountered, such as calendaring/scheduling, directory services and
-digital certificate storage. This is not (yet) addressed in this memo.
-
-6. Future Extensions
-
-It is possible to achieve internationalization of the entire e-mail
-address by representation of international characters in the local-parts
-of an "addr-spec" using nameprepped ACE conversion in a similar fashion
-as described in this memo.
-
-However, this is a different problem altogether and is currently beyond
-the scope of this memo.
-
-7. References
-
-[IDNA] Paul Hoffman & Patrik Faltstrom, "Internationalizing Host Names
-in Applications (IDNA)", draft-ietf-idn-idna.
-
-[UTR17] K. Whistler & M. Davis, Unicode Consortium, "Character Encoding
-Model", Unicode Technical Report #17,
-http://www.unicode.org/unicode/reports/tr17/
-
-[US-ASCII] United States of America Standards Institute, "USA Code for
-Information Interchange", X3.4, 1968.
-
-[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels", March 1997, RFC 2119.
-
-[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
-Proposals", draft-ietf-idn-compare.
-
-[RFC821] Jonathan B. Postel, "Simple Mail Transfer Protocol", August
-1982, RFC 821.
-
-[RFC822] David H. Crocker, "Standard for the Format of ARPA Internet
-Text Messages", August 1982, RFC 822.
-
-[RFC2045] N. Freed & N. Borenstein, "Multipurpose Internet Mail
-Extensions (MIME) Part One: Format of Internet Message Bodies",
-November 1996, RFC 2045.
-
-[RFC2047] K. Moore, "MIME (Multipurpose Internet Mail Extensions)
-Part Three: Message Header Extensions for Non-ASCII Text", November
-1996, RFC 2047.
-
-[RFC1652] J. Klensin et al., "SMTP Service Extension for 8bit-
-MIMEtransport", July 1994, RFC 1652.
-
-
-[NAMEPREP] Paul Hoffman & Marc Blanchet, "Preparation of
-Internationalized Host Names", draft-ietf-idn-nameprep.
-
-A. Author's Address
-
-Maynard Kang
-i-EMAIL.net Pte Ltd
-1 Kim Seng Promenade #12-07
-Great World City West Tower
-Singapore 237994
-E-mail: maynard@i-email.net
\ No newline at end of file
+++ /dev/null
-Internet Draft Paul Hoffman
-draft-ietf-idn-nameprep-03.txt IMC & VPNC
-February 24, 2001 Marc Blanchet
-Expires in six months ViaGenie
-
- Preparation of Internationalized Host Names
-
-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."
-
-To view the list Internet-Draft Shadow Directories, see
-http://www.ietf.org/shadow.html.
-
-
-Abstract
-
-This document describes how to prepare internationalized host names for
-use in the DNS. The steps include:
- - mapping characters to other characters, such as to change their case
- - normalizing the characters
- - excluding characters that are prohibited from appearing in
- internationalized host names
-This document does not specify a wire protocol. This preparation should
-be done before the DNS request.
-
-1. Introduction
-
-When expanding today's DNS to include internationalized host names,
-those new names will be handled in many parts of the DNS. The
-Internationalized Domain Name (IDN) Working Group's requirements
-document [IDNReq] describes a framework for domain name handling as well
-as requirements for the new names.
-
-A user can enter a domain name into an application program in a myriad
-of fashions. Depending on the input method, the characters entered in
-the domain name may or may not be those that are allowed in
-internationalized host names. Thus, there must be a way to normalized
-the user's input before the name is resolved in the DNS.
-
-It is a design goal of this document to allow users to enter host names
-in applications and have the highest chance of getting the name correct.
-Another, often conflicting, design goal is to allow as wide of a range
-of characters as possible to be allowed in host names. The user should
-not be limited to only entering exactly the characters that might have
-been used, but to instead be able to enter characters that unambiguously
-normalize to characters in the desired host name. Although it would be
-easy to use the process in this step to "correct" perceived mis-features
-or bugs in the current character standards, this document expressly does
-not do so.
-
-This document describes the steps needed to convert a name part from one
-that is entered by the user to one that can be used in the DNS.
-
-Within a fully-qualified domain name, some labels may be
-internationalized, while others are not. This specification should be
-applied to all internationalized labels. An application must be able to
-recognize which part is internationalized; the method for such
-recognition is outside of the scope of this document. Note that this
-specification is harmless to the non-internationalized labels: when the
-steps described here are applied to non-internationalized labels, the
-label will not change.
-
-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].
-
-Examples in this document use the notation for code points and names
-from the Unicode Standard [Unicode3] and ISO/IEC 10646 [ISO10646]. For
-example, the letter "a" may be represented as either "U+0061" or "LATIN
-SMALL LETTER A". In the lists of prohibited characters, the "U+" is left
-off to make the lists easier to read. The names of character ranges are
-shown in square brackets (such as "[SYMBOLS]") and do not come from the
-standards.
-
-Note: A glossary of terms used in Unicode and ISO/IEC 10646 can be found
-in [Glossary]. Information on the 10646/Unicode character model can be
-found in [CharModel].
-
-
-2. Preparation Overview
-
-The steps for preparing names are:
-
-1) Input from the application service interface -- This can be done in
-many ways and is not specified in this document
-
-2) Map -- For each character in the input, check if it has a mapping
-and, if so, replace it with its mapping. The mappings are a combination
-of folding uppercase characters to lowercase and hyphen mapping. This is
-described in Section 4.
-
-3) Normalize -- Normalize the characters. This is described in Section
-5.
-
-4) Look for prohibited output -- Check for any characters that are not
-allowed in the output. If any are found, return an error to the
-application service interface. This is described in Section 6.
-
-5) Resolution of the prepared name -- This must be specified in a
-different IDN document.
-
-The above steps MUST be performed in the order given in order to comply
-with this specification.
-
-The steps in this document have associated tables in the document. The
-tables are derived from outside sources, and the derivation is briefly
-described in the document. Although a great deal of effort has gone into
-preparing the tables, there is a chance that the tables do not correctly
-reflect the outside sources. Regardless of whether or not the tables
-differ from the sources, implementations MUST use the tables in this
-document for their processing. That is, if there is an error in the
-tables, the tables must still be used. Future versions of this document
-may include corrections and additions to the tables.
-
-
-3. Mapping
-
-Each character in the input stream is checked against the mapping table.
-The mapping table can be found in Appendix E of this document. That
-table includes all the steps described in the subsections below.
-
-The mappings can be one-to-none, one-to-one, or one-to-many. That is,
-some characters may be eliminated or replaced by more than one
-character, and the output of this step might be shorter or longer than
-the input. Because of this, an application MUST be prepared to receive a
-longer or shorter string than the one input in the nameprep algorithm.
-
-Rationale: Characters that are not wanted in internationalized name
-parts can either be mapped to nothing in the mapping step, or cause an
-error in the prohibition step. The general guideline used to pick
-between the two outcomes was that removing alphabetic, non-protocol
-characters be done in the mapping step, but all other removals be done
-in the prohibition step. This allows for simple linguistic errors on the
-part of an input mechanism to be caught in the mapping step, but to not
-hide serious errors such as entering protocol characters or invisible
-characters from the user.
-
-3.1 Case mapping
-
-The input string is case folded according to [UTR21]. For most
-characters, this is the same thing as changing the input character to a
-lowercase character. For some characters, however, more complex
-transformations occur. The mapping table in Appendix E is derived by
-applying the rules for equivalence classes from [UTR21].
-
-Rationale: This step could have been "change all lowercase characters
-into uppercase characters". However, the upper-to-lower folding was
-chosen because most users of the Internet today enter host names in
-lowercase.
-
-3.2 Additional folding mappings
-
-There are some characters that do not have mappings in [UTR21] but still
-need processing. These characters include a few Greek characters and
-many symbols that contain Latin characters. The list of characters to
-add to the mapping table were determined by the following algorithm:
-
-b = NormalizeWithKC(Fold(a));
-c = NormalizeWithKC(Fold(b));
-if c is not the same as b, add a mapping for "a to c".
-
-Because NormalizeWithKC(Fold(c)) always equals c, the table is stable
-from that point on.
-
-3.3 Mapped out
-
-The following characters are simply deleted from the input (that is,
-they are mapped to nothing) because their presence or absence should not
-make two domain names different.
-
-Some characters are only useful in line-based text, and are otherwise
-invisible and ignored.
-
-00AD; SOFT HYPHEN
-1806; MONGOLIAN TODO SOFT HYPHEN
-200B; ZERO WIDTH SPACE
-FEFF; ZERO WIDTH NO-BREAK SPACE
-
-Variation selectors and cursive connectors select different glyphs, but
-do not bear semantics.
-
-180B; MONGOLIAN FREE VARIATION SELECTOR ONE
-180C; MONGOLIAN FREE VARIATION SELECTOR TWO
-180D; MONGOLIAN FREE VARIATION SELECTOR THREE
-200C; ZERO WIDTH NON-JOINER
-200D; ZERO WIDTH JOINER
-
-
-4. Normalization
-
-The output of the mapping step is normalized using form KC, as described
-in [UTR15]. Using form KC instead of form C causes many characters that
-are identical or near-identical to be converted into a single character.
-Note that this specification refers to a specific version of [UTR15]. If
-a later version of [UTR15] changes the algorithm used for normalizing,
-that later version MUST NOT be used with this specification. Note that
-it is likely that this specification will be revised if UTR15 is
-changed, but until that happens, only the specified version of [UTR15]
-must be used.
-
-
-5. Prohibited Output
-
-Before the text can be emitted, it must be checked for prohibited code
-points. There is a variety of prohibited code points, as described in
-this section.
-
-One of the goals of IDN is to allow the widest possible set of host
-names as long as those host names do not cause other problems, such as
-conflict with other standards. Specifically, experience with current DNS
-names have shown that there is a desire for host names that include
-personal names, company names, and spoken phrases. A goal of this
-section is to prohibit as few characters that might be used in these
-contexts as possible.
-
-The collected list of prohibited code points can be found in Appendix F
-of this document. The list in Appendix F MUST be used by implementations
-of this specification. If there are any discrepancies between the list
-in Appendix F and subsections below, the list Appendix F always takes
-precedence.
-
-Some code points listed in one section would also appear in other
-sections. Each code point is only listed once in the table in Appendix
-F.
-
-5.1 Currently-prohibited ASCII characters
-
-Some of the ASCII characters that are currently prohibited in host names
-by [STD13] are also used in protocol elements such as URIs [URI]. The other
-characters in the range U+0000 to U+007F that are not currently allowed
-are also prohibited in host name parts to reserve them for future use in
-protocol elements.
-
-0000-002C; [ASCII]
-002E-002F; [ASCII]
-003A-0040; [ASCII]
-005B-0060; [ASCII]
-007B-007F; [ASCII]
-
-5.2 Space characters
-
-Space characters would make visual transcription of URLs nearly
-impossible and could lead to user entry errors in many ways.
-
-0020; SPACE
-00A0; NO-BREAK SPACE
-2000; EN QUAD
-2001; EM QUAD
-2002; EN SPACE
-2003; EM SPACE
-2004; THREE-PER-EM SPACE
-2005; FOUR-PER-EM SPACE
-2006; SIX-PER-EM SPACE
-2007; FIGURE SPACE
-2008; PUNCTUATION SPACE
-2009; THIN SPACE
-200A; HAIR SPACE
-202F; NARROW NO-BREAK SPACE
-3000; IDEOGRAPHIC SPACE
-1680; OGHAM SPACE MARK
-200B; ZERO WIDTH SPACE
-
-5.3 Control characters
-
-Control characters cannot be seen and can cause unpredictable results
-when displayed.
-
-0000-001F; [CONTROL CHARACTERS]
-007F; DELETE
-0080-009F; [CONTROL CHARACTERS]
-2028; LINE SEPARATOR
-2029; PARAGRAPH SEPARATOR
-
-5.4 Private use and replacement characters
-
-Because private-use characters do not have defined meanings, they are
-prohibited. The private-use characters are:
-
-E000-F8FF; [PRIVATE USE, PLANE 0]
-F0000-FFFFD; [PRIVATE USE, PLANE 15]
-100000-10FFFD; [PRIVATE USE, PLANE 16]
-
-The replacement character (U+FFFD) has no known semantic definition in a
-name, and is often displayed by renderers to indicate "there would be some
-character here, but it cannot be rendered". For example, on a computer
-with no Asian fonts, a name with three katakana characters might be
-rendered with three replacement characters.
-
-FFFD; REPLACEMENT CHARACTER
-
-5.5 Non-character code points
-
-Non-character code points are code points that have been assigned in
-ISO/IEC 10646 but are not characters. Because they are already assigned,
-they are guaranteed not to later change into characters.
-
-FFFE-FFFF; [NONCHARACTER CODE POINTS]
-1FFFE-1FFFF; [NONCHARACTER CODE POINTS]
-2FFFE-2FFFF; [NONCHARACTER CODE POINTS]
-3FFFE-3FFFF; [NONCHARACTER CODE POINTS]
-4FFFE-4FFFF; [NONCHARACTER CODE POINTS]
-5FFFE-5FFFF; [NONCHARACTER CODE POINTS]
-6FFFE-6FFFF; [NONCHARACTER CODE POINTS]
-7FFFE-7FFFF; [NONCHARACTER CODE POINTS]
-8FFFE-8FFFF; [NONCHARACTER CODE POINTS]
-9FFFE-9FFFF; [NONCHARACTER CODE POINTS]
-AFFFE-AFFFF; [NONCHARACTER CODE POINTS]
-BFFFE-BFFFF; [NONCHARACTER CODE POINTS]
-CFFFE-CFFFF; [NONCHARACTER CODE POINTS]
-DFFFE-DFFFF; [NONCHARACTER CODE POINTS]
-EFFFE-EFFFF; [NONCHARACTER CODE POINTS]
-FFFFE-FFFFF; [NONCHARACTER CODE POINTS]
-10FFFE-10FFFF; [NONCHARACTER CODE POINTS]
-
-5.6 Surrogate codes
-
-The following code points are permanently reserved for use as surrogate
-code values in the UTF-16 encoding, will never be assigned to
-characters, and are therefore prohibited:
-
-D800-DFFF; [SURROGATE CODES]
-
-5.7 Inappropriate for plain text
-
-The following characters should not appear in regular text.
-
-FFF9; INTERLINEAR ANNOTATION ANCHOR
-FFFA; INTERLINEAR ANNOTATION SEPARATOR
-FFFB; INTERLINEAR ANNOTATION TERMINATOR
-FFFC; OBJECT REPLACEMENT CHARACTER
-
-5.8 Inappropriate for domain names
-
-The ideographic description characters allow different sequences of
-characters to be rendered the same way, which makes them inappropriate
-for host names that must have a single canonical order.
-
-2FF0-2FFF; [IDEOGRAPHIC DESCRIPTION CHARACTERS]
-
-5.9 Change display properties
-
-The following characters, some of which are deprecated in ISO/IEC 10646,
-can cause changes in display or the order in which characters appear
-when rendered.
-
-200E; LEFT-TO-RIGHT MARK
-200F; RIGHT-TO-LEFT MARK
-202A; LEFT-TO-RIGHT EMBEDDING
-202B; RIGHT-TO-LEFT EMBEDDING
-202C; POP DIRECTIONAL FORMATTING
-202D; LEFT-TO-RIGHT OVERRIDE
-202E; RIGHT-TO-LEFT OVERRIDE
-206A; INHIBIT SYMMETRIC SWAPPING
-206B; ACTIVATE SYMMETRIC SWAPPING
-206C; INHIBIT ARABIC FORM SHAPING
-206D; ACTIVATE ARABIC FORM SHAPING
-206E; NATIONAL DIGIT SHAPES
-206F; NOMINAL DIGIT SHAPES
-
-5.10 Inappropriate characters from common input mechanisms
-
-U+3002 is used as if it were U+002E in many input mechanisms,
-particularly in Asia. This prohibition allows input mechanisms to safely
-map U+3002 to U+002E before doing nameprep without worrying about
-preventing users from accessing legitimate host name parts.
-
-3002; IDEOGRAPHIC FULL STOP
-
-
-
-6. Unassigned Code Points
-
-All code points not assigned in ISO/IEC 10646 are called "unassigned
-code points". Authoritative name servers MUST NOT have internationalized
-name parts that contain any unassigned code points. DNS requests MAY
-contain name parts that contain unassigned code points. Note that this
-is the only part of this document where the requirements for queries
-differs from the requirements for names in DNS zones.
-
-Using two different policies for where unassigned code points can appear
-in the DNS prevents the need for versioning the IDN protocol [IDNrev].
-This is very useful since it makes the overall processing simpler and do
-not impose a "protocol" to handle versioning. It is expected that ISO/IEC
-10646 will be updated fairly frequently; recently, it has happened
-approximately once a year. Each time a new version of ISO/IEC 10646 appears,
-a new version of this document can be created. Some end users will want
-to use the new code points as soon as they are defined.
-
-The list of unassigned code points can be found in Appendix G of this
-document. The list in Appendix G MUST be used by implementations of this
-specification. If there are any discrepancies between the list in
-Appendix G and the ISO/IEC 10646 specification, the list Appendix G
-always takes precedence.
-
-Due to the way that versioning is handled in this section, host names
-that are embedded in structures that cannot be changed (such as the
-signed parts of digital certificates) MUST NOT have internationalized
-name parts that contain any unassigned code points.
-
-6.1 Categories of code points
-
-Each code point in ISO/IEC 10646 can be categorized by how it acts in the
-process described in earlier sections of this document:
-
-AO Code points that may be in the output
-
-MN Code points that cannot be in the output because they are
- mapped to nothing or never appear as output from
- normalization
-
-D Code points that cannot be in the output because they are
- disallowed in the prohibition step
-
-U Unassigned code points
-
-A subsequent version of this document that references a newer version of
-ISO/IEC 10646 with new code points will inherently have some code points
-move from category U to either D, MN, or AO. For backwards
-compatibility, no future version of this document will move code points
-from any other category. That is, no current AO, MN, or D code points
-will ever change to a different category.
-
-Authoritative name servers MUST NOT contain any name that has code
-points outside of AO for the latest version of this document. That is,
-they are forbidden to contain any IDN names containing code points from
-the MN, D, or U categories.
-
-Applications creating name queries MUST treat U code points as if they
-were AO when preparing the name parts according to this document. Those
-applications MAY optionally have a preprocess that provide stricter
-checks: treating unassigned code points in the input as errors, or
-warning the user about the fact that the code point is unassigned in the
-version of this document that the software is based on; such a choice is
-a local matter for the software.
-
-Non-authoritative DNS servers MAY reject names that contain code points
-that are in categories MN or D for the version of this document that
-they implement, but MUST NOT reject names because they contain name
-parts with code points from category U.
-
-6.2 Reasons for difference between authoritative servers and requests
-
-Different software using different versions of this document need to
-interoperate with maximal compatibility. The scheme described in this
-section (authoritative name servers MUST NOT use unassigned code points,
-requests MAY include unassigned code points) allows that compatibility
-without introducing any known security or interoperability issues.
-
-The list below shows what happens if a request contains a code point
-from category U that is allowed in a newer version of this document. The
-request either resolves to the domain name that was intended, or
-resolves to no domain at all. In this list, the request comes from an
-application using version "oldVersion" of this document, the
-authoritative name server is using version "newVersion" of this
-document, and the code point X was in category U on oldVersion, and has
-changed category to AO, MN, or D. There are 3 possible scenarios:
-
-1. X becomes AO -- In newVersion, X is in category AO. Because the
-application passed X through, it gets back correct data from the
-authoritative name server. There is one exceptional case, where X is a
-combining mark.
-
-The order of combining marks is normalized, so if another combining mark
-Y has a lower combining class than X then XY will be put in the
-canonical order YX. (Unassigned code points are never reordered, so this
-doesn't happen in oldVersion). If the request contains YX, the request
-will get correct data from the authoritative name server. However, no
-domain name can be registered with XY, so a request with XY will get a
-"no such host" error.
-
-2. X becomes MN -- In newVersion, X is normalized to code point "nX" and
-therefore X is now put in category MN. This cannot exist in any domain
-name, so any request containing X will get back a "no such host" error.
-Note, however, if the request had contained the letter nX, it would have
-gotten back correct data.
-
-3. X becomes D -- In newVersion, X is in category MN. This cannot exist
-in any domain name, so any request containing X will get back a "no such
-host" error.
-
-In none of the cases does the request get data for a host name other
-than the one it actually wanted.
-
-The processing in this document is always stable. If a string S is the
-result of processing on newVersion, then it will remain the same when
-processed on oldVersion.
-
-There is always a way for the application to get the correct data from
-the authoritative name server. For example, suppose that <ALPHA> was
-unassigned in oldVersion, and that it is assigned in newVersion, but
-case-folded to <alpha>. As long as the application supplies strings
-containing <alpha> instead of <ALPHA>, the correct data will be
-returned. Because the processing is stable, a different application
-running newVersion can pass a processed host name to the application
-running oldVersion. It will only contain <alpha>, and will return the
-correct results from the authoritative name server.
-
-6.3 Versions of applications and authoritative name servers
-
-Another way to see that this versioning system works is to compare what
-happens when an application uses a newer or older version of this
-document.
-
-Newer application -- Suppose that a application or intermediary DNS
-server is using version newVersion and the authoritative name server is
-using version oldVersion. This case is simple: there will be no names on
-the server that cannot be accessed by the application because the
-resolver uses a superset of the code points accepted by the server.
-
-Newer server -- Suppose that an application or intermediary DNS server
-is using oldVersion and the authoritative name server is using
-newVersion. Because the application passed through any unassigned code
-points, the user can access names on the server that use code points in
-newVersion. No names on the site can have code points that are
-unassigned in newVersion, since that is illegal. In this case, the
-application has to enter the unassigned code points in the correct
-order, and has to use unassigned code points that would make it through
-both the mapping and the normalization steps.
-
-
-7. 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.
-
-Current applications may assume that the characters allowed in host
-names will always be the same as they are in [STD13]. This document
-vastly increases the number of characters available in host names. Every
-program that uses "special" characters in conjunction with host names
-may be vulnerable to attack based on the new characters allowed by this
-specification.
-
-
-8. References
-
-[CharModel] Unicode Technical Report;17, Character Model.
-<http://www.unicode.org/unicode/reports/tr17/>.
-
-[Glossary] Unicode Glossary, <http://www.unicode.org/glossary/>.
-
-[IDNReq] Zita Wenzel and James Seng, "Requirements of Internationalized
-Domain Names", draft-ietf-idn-requirements
-
-[IDNRev] Marc Blanchet, "Handling versions of internationalized domain
-names protocols", draft-ietf-idn-version
-
-[ISO10646] ISO/IEC 10646-1:2000. International Standard -- Information
-technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part
-1: Architecture and Basic Multilingual Plane.
-
-[Normalize] Character Normalization in IETF Protocols,
-draft-duerst-i18n-norm-03
-
-[RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
-Requirement Levels", March 1997, RFC 2119.
-
-[RFC2396] Tim Berners-Lee, et. al., "Uniform Resource Identifiers (URI):
-Generic Syntax", August 1998, RFC 2396.
-
-[RFC2732] Robert Hinden, et. al., Format for Literal IPv6 Addresses in
-URL's, December 1999, RFC 2732.
-
-[STD13] Paul Mockapetris, "Domain names - concepts and facilities" (RFC
-1034) and "Domain names - implementation and specification" (RFC 1035,
-STD 13, November 1987.
-
-[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>.
-
-[URIs] For example: Roy Fielding et. al., "Uniform Resource Identifiers:
-Generic Syntax", August 1998, RFC 2396; Robert Hinden et. al, "IPv6
-Literal Addresses in URL's", December 1999, RFC 2732.
-
-[UTR15] Mark Davis and Martin Duerst. Unicode Normalization Forms.
-Unicode Technical Report;15.
-<http://www.unicode.org/unicode/reports/tr15/>.
-
-[UTR21] Mark Davis. Case Mappings. Unicode Technical Report;21.
-<http://www.unicode.org/unicode/reports/tr21/>.
-
-
-A. Acknowledgements
-
-Many people from the IETF IDN Working Group and the Unicode Technical
-Committee contributed ideas that went into the first draft of this
-document. Mark Davis and Patrik Faltstrom were particularly helpful in
-some of the ideas, such as the versioning description.
-
-The IDN namprep design team made many useful changes to the first
-draft. That team and its advisors include:
-
-Asmus Freytag
-Cathy Wissink
-Francois Yergeau
-James Seng
-Marc Blanchet
-Mark Davis
-Martin Duerst
-Patrik Faltstrom
-Paul Hoffman
-
-Additional significant improvements were proposed by:
-
-Jonathan Rosenne
-Kent Karlsson
-Scott Hollenbeck
-
-
-B. Differences Between -02 and -03 Drafts
-
-Throughout: Changed "ISO 10646" to "ISO/IEC 10646". Changed "codepoint"
-to "code point".
-
-Abstract: Added last sentence.
-
-1: Removed the sentence about [IDNComp] in the first paragraph.
-Clarified the design goals in the third paragraph. Added new last
-paragraph about processing name parts.
-
-3: Added sentence at the end of the second paragraph about accepting
-shorter or longer responses. Changed "Design note" to "Rationale".
-
-3.1: Revised the first paragraph to make it clearer that the mapping is
-not simple lowercasing. Changed "Design note" to "Rationale".
-
-3.2: Made it clearer that the normalization is with form KC.
-
-5: Removed the previous third paragraph, which discussed the DNS service
-interface.
-
-5.1: Added references for URIs.
-
-5.4: Changed the sentence about the replacement character to read
-"...and is often displayed by renderers to indicate...".
-
-5.10: Added this section, which prohibits U+3002.
-
-6: Removed "yet" from the first sentence.
-
-8: Fixed the reference for [IDNReq] and [STD13]. Removed the reference
-to [IDNComp]. Added the reference for [URIs].
-
-C: Changed wording of the section.
-
-E, F, G: Added tags to the beginning and end of the tables.
-
-F: Added 3002 (from section 5.10). Added FDD0-FDEF, which were omitted
-in error.
-
-
-C. IANA Considerations
-
-None.
-
-
-D. Author Contact Information
-
-Paul Hoffman
-Internet Mail Consortium and VPN Consortium
-127 Segre Place
-Santa Cruz, CA 95060 USA
-paul.hoffman@imc.org and paul.hoffman@vpnc.org
-
-Marc Blanchet
-Viagenie inc.
-2875 boul. Laurier, bur. 300
-Ste-Foy, Quebec, Canada, G1V 2M2
-Marc.Blanchet@viagenie.qc.ca
-
-
-E. Mapping Table
-
-The following is the mapping table from Section 3. The table has three
-columns:
-- the character that is mapped from
-- the zero or more characters that it is mapped to
-- the reason for the mapping
-The columns are separated by semicolons. Note that the second column may
-be empty, or it may have one character, or it may have more than one
-character, with each character separated by a space.
-
------ Start Mapping Table -----
-0041; 0061; Case map
-0042; 0062; Case map
-0043; 0063; Case map
-0044; 0064; Case map
-0045; 0065; Case map
-0046; 0066; Case map
-0047; 0067; Case map
-0048; 0068; Case map
-0049; 0069; Case map
-004A; 006A; Case map
-004B; 006B; Case map
-004C; 006C; Case map
-004D; 006D; Case map
-004E; 006E; Case map
-004F; 006F; Case map
-0050; 0070; Case map
-0051; 0071; Case map
-0052; 0072; Case map
-0053; 0073; Case map
-0054; 0074; Case map
-0055; 0075; Case map
-0056; 0076; Case map
-0057; 0077; Case map
-0058; 0078; Case map
-0059; 0079; Case map
-005A; 007A; Case map
-00AD; ; Map out
-00B5; 03BC; Case map
-00C0; 00E0; Case map
-00C1; 00E1; Case map
-00C2; 00E2; Case map
-00C3; 00E3; Case map
-00C4; 00E4; Case map
-00C5; 00E5; Case map
-00C6; 00E6; Case map
-00C7; 00E7; Case map
-00C8; 00E8; Case map
-00C9; 00E9; Case map
-00CA; 00EA; Case map
-00CB; 00EB; Case map
-00CC; 00EC; Case map
-00CD; 00ED; Case map
-00CE; 00EE; Case map
-00CF; 00EF; Case map
-00D0; 00F0; Case map
-00D1; 00F1; Case map
-00D2; 00F2; Case map
-00D3; 00F3; Case map
-00D4; 00F4; Case map
-00D5; 00F5; Case map
-00D6; 00F6; Case map
-00D8; 00F8; Case map
-00D9; 00F9; Case map
-00DA; 00FA; Case map
-00DB; 00FB; Case map
-00DC; 00FC; Case map
-00DD; 00FD; Case map
-00DE; 00FE; Case map
-00DF; 0073 0073; Case map
-0100; 0101; Case map
-0102; 0103; Case map
-0104; 0105; Case map
-0106; 0107; Case map
-0108; 0109; Case map
-010A; 010B; Case map
-010C; 010D; Case map
-010E; 010F; Case map
-0110; 0111; Case map
-0112; 0113; Case map
-0114; 0115; Case map
-0116; 0117; Case map
-0118; 0119; Case map
-011A; 011B; Case map
-011C; 011D; Case map
-011E; 011F; Case map
-0120; 0121; Case map
-0122; 0123; Case map
-0124; 0125; Case map
-0126; 0127; Case map
-0128; 0129; Case map
-012A; 012B; Case map
-012C; 012D; Case map
-012E; 012F; Case map
-0130; 0069; Case map
-0131; 0069; Case map
-0132; 0133; Case map
-0134; 0135; Case map
-0136; 0137; Case map
-0139; 013A; Case map
-013B; 013C; Case map
-013D; 013E; Case map
-013F; 0140; Case map
-0141; 0142; Case map
-0143; 0144; Case map
-0145; 0146; Case map
-0147; 0148; Case map
-0149; 02BC 006E; Case map
-014A; 014B; Case map
-014C; 014D; Case map
-014E; 014F; Case map
-0150; 0151; Case map
-0152; 0153; Case map
-0154; 0155; Case map
-0156; 0157; Case map
-0158; 0159; Case map
-015A; 015B; Case map
-015C; 015D; Case map
-015E; 015F; Case map
-0160; 0161; Case map
-0162; 0163; Case map
-0164; 0165; Case map
-0166; 0167; Case map
-0168; 0169; Case map
-016A; 016B; Case map
-016C; 016D; Case map
-016E; 016F; Case map
-0170; 0171; Case map
-0172; 0173; Case map
-0174; 0175; Case map
-0176; 0177; Case map
-0178; 00FF; Case map
-0179; 017A; Case map
-017B; 017C; Case map
-017D; 017E; Case map
-017F; 0073; Case map
-0181; 0253; Case map
-0182; 0183; Case map
-0184; 0185; Case map
-0186; 0254; Case map
-0187; 0188; Case map
-0189; 0256; Case map
-018A; 0257; Case map
-018B; 018C; Case map
-018E; 01DD; Case map
-018F; 0259; Case map
-0190; 025B; Case map
-0191; 0192; Case map
-0193; 0260; Case map
-0194; 0263; Case map
-0196; 0269; Case map
-0197; 0268; Case map
-0198; 0199; Case map
-019C; 026F; Case map
-019D; 0272; Case map
-019F; 0275; Case map
-01A0; 01A1; Case map
-01A2; 01A3; Case map
-01A4; 01A5; Case map
-01A6; 0280; Case map
-01A7; 01A8; Case map
-01A9; 0283; Case map
-01AC; 01AD; Case map
-01AE; 0288; Case map
-01AF; 01B0; Case map
-01B1; 028A; Case map
-01B2; 028B; Case map
-01B3; 01B4; Case map
-01B5; 01B6; Case map
-01B7; 0292; Case map
-01B8; 01B9; Case map
-01BC; 01BD; Case map
-01C4; 01C6; Case map
-01C5; 01C6; Case map
-01C7; 01C9; Case map
-01C8; 01C9; Case map
-01CA; 01CC; Case map
-01CB; 01CC; Case map
-01CD; 01CE; Case map
-01CF; 01D0; Case map
-01D1; 01D2; Case map
-01D3; 01D4; Case map
-01D5; 01D6; Case map
-01D7; 01D8; Case map
-01D9; 01DA; Case map
-01DB; 01DC; Case map
-01DE; 01DF; Case map
-01E0; 01E1; Case map
-01E2; 01E3; Case map
-01E4; 01E5; Case map
-01E6; 01E7; Case map
-01E8; 01E9; Case map
-01EA; 01EB; Case map
-01EC; 01ED; Case map
-01EE; 01EF; Case map
-01F0; 006A 030C; Case map
-01F1; 01F3; Case map
-01F2; 01F3; Case map
-01F4; 01F5; Case map
-01F6; 0195; Case map
-01F7; 01BF; Case map
-01F8; 01F9; Case map
-01FA; 01FB; Case map
-01FC; 01FD; Case map
-01FE; 01FF; Case map
-0200; 0201; Case map
-0202; 0203; Case map
-0204; 0205; Case map
-0206; 0207; Case map
-0208; 0209; Case map
-020A; 020B; Case map
-020C; 020D; Case map
-020E; 020F; Case map
-0210; 0211; Case map
-0212; 0213; Case map
-0214; 0215; Case map
-0216; 0217; Case map
-0218; 0219; Case map
-021A; 021B; Case map
-021C; 021D; Case map
-021E; 021F; Case map
-0222; 0223; Case map
-0224; 0225; Case map
-0226; 0227; Case map
-0228; 0229; Case map
-022A; 022B; Case map
-022C; 022D; Case map
-022E; 022F; Case map
-0230; 0231; Case map
-0232; 0233; Case map
-0345; 03B9; Case map
-037A; 0020 03B9; Additional folding
-0386; 03AC; Case map
-0388; 03AD; Case map
-0389; 03AE; Case map
-038A; 03AF; Case map
-038C; 03CC; Case map
-038E; 03CD; Case map
-038F; 03CE; Case map
-0390; 03B9 0308 0301; Case map
-0391; 03B1; Case map
-0392; 03B2; Case map
-0393; 03B3; Case map
-0394; 03B4; Case map
-0395; 03B5; Case map
-0396; 03B6; Case map
-0397; 03B7; Case map
-0398; 03B8; Case map
-0399; 03B9; Case map
-039A; 03BA; Case map
-039B; 03BB; Case map
-039C; 03BC; Case map
-039D; 03BD; Case map
-039E; 03BE; Case map
-039F; 03BF; Case map
-03A0; 03C0; Case map
-03A1; 03C1; Case map
-03A3; 03C2; Case map
-03A4; 03C4; Case map
-03A5; 03C5; Case map
-03A6; 03C6; Case map
-03A7; 03C7; Case map
-03A8; 03C8; Case map
-03A9; 03C9; Case map
-03AA; 03CA; Case map
-03AB; 03CB; Case map
-03B0; 03C5 0308 0301; Case map
-03C2; 03C2; Case map
-03C3; 03C2; Case map
-03D0; 03B2; Case map
-03D1; 03B8; Case map
-03D2; 03C5; Additional folding
-03D3; 03CD; Additional folding
-03D4; 03CB; Additional folding
-03D5; 03C6; Case map
-03D6; 03C0; Case map
-03DA; 03DB; Case map
-03DC; 03DD; Case map
-03DE; 03DF; Case map
-03E0; 03E1; Case map
-03E2; 03E3; Case map
-03E4; 03E5; Case map
-03E6; 03E7; Case map
-03E8; 03E9; Case map
-03EA; 03EB; Case map
-03EC; 03ED; Case map
-03EE; 03EF; Case map
-03F0; 03BA; Case map
-03F1; 03C1; Case map
-03F2; 03C2; Case map
-0400; 0450; Case map
-0401; 0451; Case map
-0402; 0452; Case map
-0403; 0453; Case map
-0404; 0454; Case map
-0405; 0455; Case map
-0406; 0456; Case map
-0407; 0457; Case map
-0408; 0458; Case map
-0409; 0459; Case map
-040A; 045A; Case map
-040B; 045B; Case map
-040C; 045C; Case map
-040D; 045D; Case map
-040E; 045E; Case map
-040F; 045F; Case map
-0410; 0430; Case map
-0411; 0431; Case map
-0412; 0432; Case map
-0413; 0433; Case map
-0414; 0434; Case map
-0415; 0435; Case map
-0416; 0436; Case map
-0417; 0437; Case map
-0418; 0438; Case map
-0419; 0439; Case map
-041A; 043A; Case map
-041B; 043B; Case map
-041C; 043C; Case map
-041D; 043D; Case map
-041E; 043E; Case map
-041F; 043F; Case map
-0420; 0440; Case map
-0421; 0441; Case map
-0422; 0442; Case map
-0423; 0443; Case map
-0424; 0444; Case map
-0425; 0445; Case map
-0426; 0446; Case map
-0427; 0447; Case map
-0428; 0448; Case map
-0429; 0449; Case map
-042A; 044A; Case map
-042B; 044B; Case map
-042C; 044C; Case map
-042D; 044D; Case map
-042E; 044E; Case map
-042F; 044F; Case map
-0460; 0461; Case map
-0462; 0463; Case map
-0464; 0465; Case map
-0466; 0467; Case map
-0468; 0469; Case map
-046A; 046B; Case map
-046C; 046D; Case map
-046E; 046F; Case map
-0470; 0471; Case map
-0472; 0473; Case map
-0474; 0475; Case map
-0476; 0477; Case map
-0478; 0479; Case map
-047A; 047B; Case map
-047C; 047D; Case map
-047E; 047F; Case map
-0480; 0481; Case map
-048C; 048D; Case map
-048E; 048F; Case map
-0490; 0491; Case map
-0492; 0493; Case map
-0494; 0495; Case map
-0496; 0497; Case map
-0498; 0499; Case map
-049A; 049B; Case map
-049C; 049D; Case map
-049E; 049F; Case map
-04A0; 04A1; Case map
-04A2; 04A3; Case map
-04A4; 04A5; Case map
-04A6; 04A7; Case map
-04A8; 04A9; Case map
-04AA; 04AB; Case map
-04AC; 04AD; Case map
-04AE; 04AF; Case map
-04B0; 04B1; Case map
-04B2; 04B3; Case map
-04B4; 04B5; Case map
-04B6; 04B7; Case map
-04B8; 04B9; Case map
-04BA; 04BB; Case map
-04BC; 04BD; Case map
-04BE; 04BF; Case map
-04C1; 04C2; Case map
-04C3; 04C4; Case map
-04C7; 04C8; Case map
-04CB; 04CC; Case map
-04D0; 04D1; Case map
-04D2; 04D3; Case map
-04D4; 04D5; Case map
-04D6; 04D7; Case map
-04D8; 04D9; Case map
-04DA; 04DB; Case map
-04DC; 04DD; Case map
-04DE; 04DF; Case map
-04E0; 04E1; Case map
-04E2; 04E3; Case map
-04E4; 04E5; Case map
-04E6; 04E7; Case map
-04E8; 04E9; Case map
-04EA; 04EB; Case map
-04EC; 04ED; Case map
-04EE; 04EF; Case map
-04F0; 04F1; Case map
-04F2; 04F3; Case map
-04F4; 04F5; Case map
-04F8; 04F9; Case map
-0531; 0561; Case map
-0532; 0562; Case map
-0533; 0563; Case map
-0534; 0564; Case map
-0535; 0565; Case map
-0536; 0566; Case map
-0537; 0567; Case map
-0538; 0568; Case map
-0539; 0569; Case map
-053A; 056A; Case map
-053B; 056B; Case map
-053C; 056C; Case map
-053D; 056D; Case map
-053E; 056E; Case map
-053F; 056F; Case map
-0540; 0570; Case map
-0541; 0571; Case map
-0542; 0572; Case map
-0543; 0573; Case map
-0544; 0574; Case map
-0545; 0575; Case map
-0546; 0576; Case map
-0547; 0577; Case map
-0548; 0578; Case map
-0549; 0579; Case map
-054A; 057A; Case map
-054B; 057B; Case map
-054C; 057C; Case map
-054D; 057D; Case map
-054E; 057E; Case map
-054F; 057F; Case map
-0550; 0580; Case map
-0551; 0581; Case map
-0552; 0582; Case map
-0553; 0583; Case map
-0554; 0584; Case map
-0555; 0585; Case map
-0556; 0586; Case map
-0587; 0565 0582; Case map
-1806; ; Map out
-180B; ; Map out
-180C; ; Map out
-180D; ; Map out
-1E00; 1E01; Case map
-1E02; 1E03; Case map
-1E04; 1E05; Case map
-1E06; 1E07; Case map
-1E08; 1E09; Case map
-1E0A; 1E0B; Case map
-1E0C; 1E0D; Case map
-1E0E; 1E0F; Case map
-1E10; 1E11; Case map
-1E12; 1E13; Case map
-1E14; 1E15; Case map
-1E16; 1E17; Case map
-1E18; 1E19; Case map
-1E1A; 1E1B; Case map
-1E1C; 1E1D; Case map
-1E1E; 1E1F; Case map
-1E20; 1E21; Case map
-1E22; 1E23; Case map
-1E24; 1E25; Case map
-1E26; 1E27; Case map
-1E28; 1E29; Case map
-1E2A; 1E2B; Case map
-1E2C; 1E2D; Case map
-1E2E; 1E2F; Case map
-1E30; 1E31; Case map
-1E32; 1E33; Case map
-1E34; 1E35; Case map
-1E36; 1E37; Case map
-1E38; 1E39; Case map
-1E3A; 1E3B; Case map
-1E3C; 1E3D; Case map
-1E3E; 1E3F; Case map
-1E40; 1E41; Case map
-1E42; 1E43; Case map
-1E44; 1E45; Case map
-1E46; 1E47; Case map
-1E48; 1E49; Case map
-1E4A; 1E4B; Case map
-1E4C; 1E4D; Case map
-1E4E; 1E4F; Case map
-1E50; 1E51; Case map
-1E52; 1E53; Case map
-1E54; 1E55; Case map
-1E56; 1E57; Case map
-1E58; 1E59; Case map
-1E5A; 1E5B; Case map
-1E5C; 1E5D; Case map
-1E5E; 1E5F; Case map
-1E60; 1E61; Case map
-1E62; 1E63; Case map
-1E64; 1E65; Case map
-1E66; 1E67; Case map
-1E68; 1E69; Case map
-1E6A; 1E6B; Case map
-1E6C; 1E6D; Case map
-1E6E; 1E6F; Case map
-1E70; 1E71; Case map
-1E72; 1E73; Case map
-1E74; 1E75; Case map
-1E76; 1E77; Case map
-1E78; 1E79; Case map
-1E7A; 1E7B; Case map
-1E7C; 1E7D; Case map
-1E7E; 1E7F; Case map
-1E80; 1E81; Case map
-1E82; 1E83; Case map
-1E84; 1E85; Case map
-1E86; 1E87; Case map
-1E88; 1E89; Case map
-1E8A; 1E8B; Case map
-1E8C; 1E8D; Case map
-1E8E; 1E8F; Case map
-1E90; 1E91; Case map
-1E92; 1E93; Case map
-1E94; 1E95; Case map
-1E96; 0068 0331; Case map
-1E97; 0074 0308; Case map
-1E98; 0077 030A; Case map
-1E99; 0079 030A; Case map
-1E9A; 0061 02BE; Case map
-1E9B; 1E61; Case map
-1EA0; 1EA1; Case map
-1EA2; 1EA3; Case map
-1EA4; 1EA5; Case map
-1EA6; 1EA7; Case map
-1EA8; 1EA9; Case map
-1EAA; 1EAB; Case map
-1EAC; 1EAD; Case map
-1EAE; 1EAF; Case map
-1EB0; 1EB1; Case map
-1EB2; 1EB3; Case map
-1EB4; 1EB5; Case map
-1EB6; 1EB7; Case map
-1EB8; 1EB9; Case map
-1EBA; 1EBB; Case map
-1EBC; 1EBD; Case map
-1EBE; 1EBF; Case map
-1EC0; 1EC1; Case map
-1EC2; 1EC3; Case map
-1EC4; 1EC5; Case map
-1EC6; 1EC7; Case map
-1EC8; 1EC9; Case map
-1ECA; 1ECB; Case map
-1ECC; 1ECD; Case map
-1ECE; 1ECF; Case map
-1ED0; 1ED1; Case map
-1ED2; 1ED3; Case map
-1ED4; 1ED5; Case map
-1ED6; 1ED7; Case map
-1ED8; 1ED9; Case map
-1EDA; 1EDB; Case map
-1EDC; 1EDD; Case map
-1EDE; 1EDF; Case map
-1EE0; 1EE1; Case map
-1EE2; 1EE3; Case map
-1EE4; 1EE5; Case map
-1EE6; 1EE7; Case map
-1EE8; 1EE9; Case map
-1EEA; 1EEB; Case map
-1EEC; 1EED; Case map
-1EEE; 1EEF; Case map
-1EF0; 1EF1; Case map
-1EF2; 1EF3; Case map
-1EF4; 1EF5; Case map
-1EF6; 1EF7; Case map
-1EF8; 1EF9; Case map
-1F08; 1F00; Case map
-1F09; 1F01; Case map
-1F0A; 1F02; Case map
-1F0B; 1F03; Case map
-1F0C; 1F04; Case map
-1F0D; 1F05; Case map
-1F0E; 1F06; Case map
-1F0F; 1F07; Case map
-1F18; 1F10; Case map
-1F19; 1F11; Case map
-1F1A; 1F12; Case map
-1F1B; 1F13; Case map
-1F1C; 1F14; Case map
-1F1D; 1F15; Case map
-1F28; 1F20; Case map
-1F29; 1F21; Case map
-1F2A; 1F22; Case map
-1F2B; 1F23; Case map
-1F2C; 1F24; Case map
-1F2D; 1F25; Case map
-1F2E; 1F26; Case map
-1F2F; 1F27; Case map
-1F38; 1F30; Case map
-1F39; 1F31; Case map
-1F3A; 1F32; Case map
-1F3B; 1F33; Case map
-1F3C; 1F34; Case map
-1F3D; 1F35; Case map
-1F3E; 1F36; Case map
-1F3F; 1F37; Case map
-1F48; 1F40; Case map
-1F49; 1F41; Case map
-1F4A; 1F42; Case map
-1F4B; 1F43; Case map
-1F4C; 1F44; Case map
-1F4D; 1F45; Case map
-1F50; 03C5 0313; Case map
-1F52; 03C5 0313 0300; Case map
-1F54; 03C5 0313 0301; Case map
-1F56; 03C5 0313 0342; Case map
-1F59; 1F51; Case map
-1F5B; 1F53; Case map
-1F5D; 1F55; Case map
-1F5F; 1F57; Case map
-1F68; 1F60; Case map
-1F69; 1F61; Case map
-1F6A; 1F62; Case map
-1F6B; 1F63; Case map
-1F6C; 1F64; Case map
-1F6D; 1F65; Case map
-1F6E; 1F66; Case map
-1F6F; 1F67; Case map
-1F80; 1F00 03B9; Case map
-1F81; 1F01 03B9; Case map
-1F82; 1F02 03B9; Case map
-1F83; 1F03 03B9; Case map
-1F84; 1F04 03B9; Case map
-1F85; 1F05 03B9; Case map
-1F86; 1F06 03B9; Case map
-1F87; 1F07 03B9; Case map
-1F88; 1F00 03B9; Case map
-1F89; 1F01 03B9; Case map
-1F8A; 1F02 03B9; Case map
-1F8B; 1F03 03B9; Case map
-1F8C; 1F04 03B9; Case map
-1F8D; 1F05 03B9; Case map
-1F8E; 1F06 03B9; Case map
-1F8F; 1F07 03B9; Case map
-1F90; 1F20 03B9; Case map
-1F91; 1F21 03B9; Case map
-1F92; 1F22 03B9; Case map
-1F93; 1F23 03B9; Case map
-1F94; 1F24 03B9; Case map
-1F95; 1F25 03B9; Case map
-1F96; 1F26 03B9; Case map
-1F97; 1F27 03B9; Case map
-1F98; 1F20 03B9; Case map
-1F99; 1F21 03B9; Case map
-1F9A; 1F22 03B9; Case map
-1F9B; 1F23 03B9; Case map
-1F9C; 1F24 03B9; Case map
-1F9D; 1F25 03B9; Case map
-1F9E; 1F26 03B9; Case map
-1F9F; 1F27 03B9; Case map
-1FA0; 1F60 03B9; Case map
-1FA1; 1F61 03B9; Case map
-1FA2; 1F62 03B9; Case map
-1FA3; 1F63 03B9; Case map
-1FA4; 1F64 03B9; Case map
-1FA5; 1F65 03B9; Case map
-1FA6; 1F66 03B9; Case map
-1FA7; 1F67 03B9; Case map
-1FA8; 1F60 03B9; Case map
-1FA9; 1F61 03B9; Case map
-1FAA; 1F62 03B9; Case map
-1FAB; 1F63 03B9; Case map
-1FAC; 1F64 03B9; Case map
-1FAD; 1F65 03B9; Case map
-1FAE; 1F66 03B9; Case map
-1FAF; 1F67 03B9; Case map
-1FB2; 1F70 03B9; Case map
-1FB3; 03B1 03B9; Case map
-1FB4; 03AC 03B9; Case map
-1FB6; 03B1 0342; Case map
-1FB7; 03B1 0342 03B9; Case map
-1FB8; 1FB0; Case map
-1FB9; 1FB1; Case map
-1FBA; 1F70; Case map
-1FBB; 1F71; Case map
-1FBC; 03B1 03B9; Case map
-1FBE; 03B9; Case map
-1FC2; 1F74 03B9; Case map
-1FC3; 03B7 03B9; Case map
-1FC4; 03AE 03B9; Case map
-1FC6; 03B7 0342; Case map
-1FC7; 03B7 0342 03B9; Case map
-1FC8; 1F72; Case map
-1FC9; 1F73; Case map
-1FCA; 1F74; Case map
-1FCB; 1F75; Case map
-1FCC; 03B7 03B9; Case map
-1FD2; 03B9 0308 0300; Case map
-1FD3; 03B9 0308 0301; Case map
-1FD6; 03B9 0342; Case map
-1FD7; 03B9 0308 0342; Case map
-1FD8; 1FD0; Case map
-1FD9; 1FD1; Case map
-1FDA; 1F76; Case map
-1FDB; 1F77; Case map
-1FE2; 03C5 0308 0300; Case map
-1FE3; 03C5 0308 0301; Case map
-1FE4; 03C1 0313; Case map
-1FE6; 03C5 0342; Case map
-1FE7; 03C5 0308 0342; Case map
-1FE8; 1FE0; Case map
-1FE9; 1FE1; Case map
-1FEA; 1F7A; Case map
-1FEB; 1F7B; Case map
-1FEC; 1FE5; Case map
-1FF2; 1F7C 03B9; Case map
-1FF3; 03C9 03B9; Case map
-1FF4; 03CE 03B9; Case map
-1FF6; 03C9 0342; Case map
-1FF7; 03C9 0342 03B9; Case map
-1FF8; 1F78; Case map
-1FF9; 1F79; Case map
-1FFA; 1F7C; Case map
-1FFB; 1F7D; Case map
-1FFC; 03C9 03B9; Case map
-200B; ; Map out
-200C; ; Map out
-200D; ; Map out
-20A8; 0072 0073; Additional folding
-2102; 0063; Additional folding
-2103; 00B0 0063; Additional folding
-2107; 025B; Additional folding
-2109; 00B0 0066; Additional folding
-210B; 0068; Additional folding
-210C; 0068; Additional folding
-210D; 0068; Additional folding
-2110; 0069; Additional folding
-2111; 0069; Additional folding
-2112; 006C; Additional folding
-2115; 006E; Additional folding
-2116; 006E 006F; Additional folding
-2119; 0070; Additional folding
-211A; 0071; Additional folding
-211B; 0072; Additional folding
-211C; 0072; Additional folding
-211D; 0072; Additional folding
-2120; 0073 006D; Additional folding
-2121; 0074 0065 006C; Additional folding
-2122; 0074 006D; Additional folding
-2124; 007A; Additional folding
-2126; 03C9; Case map
-2128; 007A; Additional folding
-212A; 006B; Case map
-212B; 00E5; Case map
-212C; 0062; Additional folding
-212D; 0063; Additional folding
-2130; 0065; Additional folding
-2131; 0066; Additional folding
-2133; 006D; Additional folding
-2160; 2170; Case map
-2161; 2171; Case map
-2162; 2172; Case map
-2163; 2173; Case map
-2164; 2174; Case map
-2165; 2175; Case map
-2166; 2176; Case map
-2167; 2177; Case map
-2168; 2178; Case map
-2169; 2179; Case map
-216A; 217A; Case map
-216B; 217B; Case map
-216C; 217C; Case map
-216D; 217D; Case map
-216E; 217E; Case map
-216F; 217F; Case map
-24B6; 24D0; Case map
-24B7; 24D1; Case map
-24B8; 24D2; Case map
-24B9; 24D3; Case map
-24BA; 24D4; Case map
-24BB; 24D5; Case map
-24BC; 24D6; Case map
-24BD; 24D7; Case map
-24BE; 24D8; Case map
-24BF; 24D9; Case map
-24C0; 24DA; Case map
-24C1; 24DB; Case map
-24C2; 24DC; Case map
-24C3; 24DD; Case map
-24C4; 24DE; Case map
-24C5; 24DF; Case map
-24C6; 24E0; Case map
-24C7; 24E1; Case map
-24C8; 24E2; Case map
-24C9; 24E3; Case map
-24CA; 24E4; Case map
-24CB; 24E5; Case map
-24CC; 24E6; Case map
-24CD; 24E7; Case map
-24CE; 24E8; Case map
-24CF; 24E9; Case map
-3371; 0068 0070 0061; Additional folding
-3373; 0061 0075; Additional folding
-3375; 006F 0076; Additional folding
-3380; 0070 0061; Additional folding
-3381; 006E 0061; Additional folding
-3382; 03BC 0061; Additional folding
-3383; 006D 0061; Additional folding
-3384; 006B 0061; Additional folding
-3385; 006B 0062; Additional folding
-3386; 006D 0062; Additional folding
-3387; 0067 0062; Additional folding
-338A; 0070 0066; Additional folding
-338B; 006E 0066; Additional folding
-338C; 03BC 0066; Additional folding
-3390; 0068 007A; Additional folding
-3391; 006B 0068 007A; Additional folding
-3392; 006D 0068 007A; Additional folding
-3393; 0067 0068 007A; Additional folding
-3394; 0074 0068 007A; Additional folding
-33A9; 0070 0061; Additional folding
-33AA; 006B 0070 0061; Additional folding
-33AB; 006D 0070 0061; Additional folding
-33AC; 0067 0070 0061; Additional folding
-33B4; 0070 0076; Additional folding
-33B5; 006E 0076; Additional folding
-33B6; 03BC 0076; Additional folding
-33B7; 006D 0076; Additional folding
-33B8; 006B 0076; Additional folding
-33B9; 006D 0076; Additional folding
-33BA; 0070 0077; Additional folding
-33BB; 006E 0077; Additional folding
-33BC; 03BC 0077; Additional folding
-33BD; 006D 0077; Additional folding
-33BE; 006B 0077; Additional folding
-33BF; 006D 0077; Additional folding
-33C0; 006B 03C9; Additional folding
-33C1; 006D 03C9; Additional folding
-33C3; 0062 0071; Additional folding
-33C6; 0063 2215 006B 0067; Additional folding
-33C7; 0063 006F 002E; Additional folding
-33C8; 0064 0062; Additional folding
-33C9; 0067 0079; Additional folding
-33CB; 0068 0070; Additional folding
-33CD; 006B 006B; Additional folding
-33CE; 006B 006D; Additional folding
-33D7; 0070 0068; Additional folding
-33D9; 0070 0070 006D; Additional folding
-33DA; 0070 0072; Additional folding
-33DC; 0073 0076; Additional folding
-33DD; 0077 0062; Additional folding
-FB00; 0066 0066; Case map
-FB01; 0066 0069; Case map
-FB02; 0066 006C; Case map
-FB03; 0066 0066 0069; Case map
-FB04; 0066 0066 006C; Case map
-FB05; 0073 0074; Case map
-FB06; 0073 0074; Case map
-FB13; 0574 0576; Case map
-FB14; 0574 0565; Case map
-FB15; 0574 056B; Case map
-FB16; 057E 0576; Case map
-FB17; 0574 056D; Case map
-FEFF; ; Map out
-FF21; FF41; Case map
-FF22; FF42; Case map
-FF23; FF43; Case map
-FF24; FF44; Case map
-FF25; FF45; Case map
-FF26; FF46; Case map
-FF27; FF47; Case map
-FF28; FF48; Case map
-FF29; FF49; Case map
-FF2A; FF4A; Case map
-FF2B; FF4B; Case map
-FF2C; FF4C; Case map
-FF2D; FF4D; Case map
-FF2E; FF4E; Case map
-FF2F; FF4F; Case map
-FF30; FF50; Case map
-FF31; FF51; Case map
-FF32; FF52; Case map
-FF33; FF53; Case map
-FF34; FF54; Case map
-FF35; FF55; Case map
-FF36; FF56; Case map
-FF37; FF57; Case map
-FF38; FF58; Case map
-FF39; FF59; Case map
-FF3A; FF5A; Case map
------ End Mapping Table -----
-
-
-F. Prohibited Code Point List
-
------ Start Prohibited Table -----
-0000-002C
-002E-002F
-003A-0040
-005B-0060
-007B-007F
-0080-009F
-00A0
-1680
-2000
-2001
-2002
-2003
-2004
-2005
-2006
-2007
-2008
-2009
-200A
-200B
-200E
-200F
-2028
-2029
-202A
-202B
-202C
-202D
-202E
-202F
-206A
-206B
-206C
-206D
-206E
-206F
-2FF0-2FFF
-3000
-3002
-D800-DFFF
-E000-F8FF
-FFF9
-FFFA
-FFFB
-FFFC
-FFFD
-FFFE-FFFF
-1FFFE-1FFFF
-2FFFE-2FFFF
-3FFFE-3FFFF
-4FFFE-4FFFF
-5FFFE-5FFFF
-6FFFE-6FFFF
-7FFFE-7FFFF
-8FFFE-8FFFF
-9FFFE-9FFFF
-AFFFE-AFFFF
-BFFFE-BFFFF
-CFFFE-CFFFF
-DFFFE-DFFFF
-EFFFE-EFFFF
-F0000-FFFFD
-FFFFE-FFFFF
-100000-10FFFD
-10FFFE-10FFFF
------ End Prohibited Table -----
-
-NOTE WELL: Software that follows this specification that will be used to
-check names before they are put in authoritative name servers MUST add
-all unassigned code pints to the list of characters that are prohibited.
-See Section 6 for more details.
-
-
-G. Unassigned Code Point List
-
------ Start Unassigned Table -----
-0220-0221
-0234-024F
-02AE-02AF
-02EF-02FF
-034F-035F
-0363-0373
-0376-0379
-037B-037D
-037F-0383
-038B
-038D
-03A2
-03CF
-03D8-03D9
-03F4-03FF
-0487
-048A-048B
-04C5-04C6
-04C9-04CA
-04CD-04CF
-04F6-04F7
-04FA-0530
-0557-0558
-0560
-0588
-058B-0590
-05A2
-05BA
-05C5-05CF
-05EB-05EF
-05F5-060B
-060D-061A
-061C-061E
-0620
-063B-063F
-0656-065F
-066E-066F
-06EE-06EF
-06FF
-070E
-072D-072F
-074B-077F
-07B1-0900
-0904
-093A-093B
-094E-094F
-0955-0957
-0971-0980
-0984
-098D-098E
-0991-0992
-09A9
-09B1
-09B3-09B5
-09BA-09BB
-09BD
-09C5-09C6
-09C9-09CA
-09CE-09D6
-09D8-09DB
-09DE
-09E4-09E5
-09FB-0A01
-0A03-0A04
-0A0B-0A0E
-0A11-0A12
-0A29
-0A31
-0A34
-0A37
-0A3A-0A3B
-0A3D
-0A43-0A46
-0A49-0A4A
-0A4E-0A58
-0A5D
-0A5F-0A65
-0A75-0A80
-0A84
-0A8C
-0A8E
-0A92
-0AA9
-0AB1
-0AB4
-0ABA-0ABB
-0AC6
-0ACA
-0ACE-0ACF
-0AD1-0ADF
-0AE1-0AE5
-0AF0-0B00
-0B04
-0B0D-0B0E
-0B11-0B12
-0B29
-0B31
-0B34-0B35
-0B3A-0B3B
-0B44-0B46
-0B49-0B4A
-0B4E-0B55
-0B58-0B5B
-0B5E
-0B62-0B65
-0B71-0B81
-0B84
-0B8B-0B8D
-0B91
-0B96-0B98
-0B9B
-0B9D
-0BA0-0BA2
-0BA5-0BA7
-0BAB-0BAD
-0BB6
-0BBA-0BBD
-0BC3-0BC5
-0BC9
-0BCE-0BD6
-0BD8-0BE6
-0BF3-0C00
-0C04
-0C0D
-0C11
-0C29
-0C34
-0C3A-0C3D
-0C45
-0C49
-0C4E-0C54
-0C57-0C5F
-0C62-0C65
-0C70-0C81
-0C84
-0C8D
-0C91
-0CA9
-0CB4
-0CBA-0CBD
-0CC5
-0CC9
-0CCE-0CD4
-0CD7-0CDD
-0CDF
-0CE2-0CE5
-0CF0-0D01
-0D04
-0D0D
-0D11
-0D29
-0D3A-0D3D
-0D44-0D45
-0D49
-0D4E-0D56
-0D58-0D5F
-0D62-0D65
-0D70-0D81
-0D84
-0D97-0D99
-0DB2
-0DBC
-0DBE-0DBF
-0DC7-0DC9
-0DCB-0DCE
-0DD5
-0DD7
-0DE0-0DF1
-0DF5-0E00
-0E3B-0E3E
-0E5C-0E80
-0E83
-0E85-0E86
-0E89
-0E8B-0E8C
-0E8E-0E93
-0E98
-0EA0
-0EA4
-0EA6
-0EA8-0EA9
-0EAC
-0EBA
-0EBE-0EBF
-0EC5
-0EC7
-0ECE-0ECF
-0EDA-0EDB
-0EDE-0EFF
-0F48
-0F6B-0F70
-0F8C-0F8F
-0F98
-0FBD
-0FCD-0FCE
-0FD0-0FFF
-1022
-1028
-102B
-1033-1035
-103A-103F
-105A-109F
-10C6-10CF
-10F7-10FA
-10FC-10FF
-115A-115E
-11A3-11A7
-11FA-11FF
-1207
-1247
-1249
-124E-124F
-1257
-1259
-125E-125F
-1287
-1289
-128E-128F
-12AF
-12B1
-12B6-12B7
-12BF
-12C1
-12C6-12C7
-12CF
-12D7
-12EF
-130F
-1311
-1316-1317
-131F
-1347
-135B-1360
-137D-139F
-13F5-1400
-1677-167F
-169D-169F
-16F1-177F
-17DD-17DF
-17EA-17FF
-180F
-181A-181F
-1878-187F
-18AA-1DFF
-1E9C-1E9F
-1EFA-1EFF
-1F16-1F17
-1F1E-1F1F
-1F46-1F47
-1F4E-1F4F
-1F58
-1F5A
-1F5C
-1F5E
-1F7E-1F7F
-1FB5
-1FC5
-1FD4-1FD5
-1FDC
-1FF0-1FF1
-1FF5
-1FFF
-2047
-204E-2069
-2071-2073
-208F-209F
-20B0-20CF
-20E4-20FF
-213B-2152
-2184-218F
-21F4-21FF
-22F2-22FF
-237C
-239B-23FF
-2427-243F
-244B-245F
-24EB-24FF
-2596-259F
-25F8-25FF
-2614-2618
-2672-2700
-2705
-270A-270B
-2728
-274C
-274E
-2753-2755
-2757
-275F-2760
-2768-2775
-2795-2797
-27B0
-27BF-27FF
-2900-2E7F
-2E9A
-2EF4-2EFF
-2FD6-2FEF
-2FFC-2FFF
-303B-303D
-3040
-3095-3098
-309F-30A0
-30FF-3104
-312D-3130
-318F
-31B8-31FF
-321D-321F
-3244-325F
-327C-327E
-32B1-32BF
-32CC-32CF
-32FF
-3377-337A
-33DE-33DF
-33FF
-4DB6-4DFF
-9FA6-9FFF
-A48D-A48F
-A4A2-A4A3
-A4B4
-A4C1
-A4C5
-A4C7-ABFF
-D7A4-D7FF
-FA2E-FAFF
-FB07-FB12
-FB18-FB1C
-FB37
-FB3D
-FB3F
-FB42
-FB45
-FBB2-FBD2
-FD40-FD4F
-FD90-FD91
-FDC8-FDEF
-FDFC-FE1F
-FE24-FE2F
-FE45-FE48
-FE53
-FE67
-FE6C-FE6F
-FE73
-FE75
-FEFD-FEFE
-FF00
-FF5F-FF60
-FFBF-FFC1
-FFC8-FFC9
-FFD0-FFD1
-FFD8-FFD9
-FFDD-FFDF
-FFE7
-FFEF-FFF8
-10000-1FFFD
-20000-2FFFD
-30000-3FFFD
-40000-4FFFD
-50000-5FFFD
-60000-6FFFD
-70000-7FFFD
-80000-8FFFD
-90000-9FFFD
-A0000-AFFFD
-B0000-BFFFD
-C0000-CFFFD
-D0000-DFFFD
-E0000-EFFFD
------ End Unassigned Table -----
-
+++ /dev/null
-Internet Draft Paul Hoffman
-draft-ietf-idn-race-03.txt IMC & VPNC
-November 22, 2000
-Expires in six months
-
- RACE: Row-based ASCII Compatible Encoding for IDN
-
-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 transformation method for representing
-non-ASCII characters in host name parts in a fashion that is completely
-compatible with the current DNS. It is a potential candidate for an
-ASCII-Compatible Encoding (ACE) for internationalized host names, as
-described in the comparison document from the IETF IDN Working Group.
-This method is based on the observation that many internationalized
-host name parts will have all their characters in one row of the ISO
-10646 repertoire.
-
-
-1. Introduction
-
-There is a strong world-wide desire to use characters other than plain
-ASCII in host names. Host names have become the equivalent of business
-or product names for many services on the Internet, so there is a need
-to make them usable by people whose native scripts are not representable
-by ASCII. The requirements for internationalizing host names are
-described in the IDN WG's requirements document, [IDNReq].
-
-The IDN WG's comparison document [IDNComp] describes three potential
-main architectures for IDN: arch-1 (just send binary), arch-2 (send
-binary or ACE), and arch-3 (just send ACE). RACE is an ACE, called
-Row-based ACE or RACE, that can be used with protocols that match arch-2
-or arch-3. RACE specifies an ACE format as specified in ace-1 in
-[IDNComp]. Further, it specifies an identifying mechanism for ace-2 in
-[IDNComp], namely ace-2.1.1 (add hopefully-unique legal tag to the
-beginning of the name part).
-
-Author's note: although earlier drafts of this document supported the
-ideas in arch-3, I no longer support that idea and instead only support
-arch-2. Of course, someone else might right an IDN proposal that matches
-arch-3 and use RACE as the protocol.
-
-In formal terms, RACE describes a character encoding scheme of the
-ISO/IEC 10646 [ISO10646] coded character set (whose assignment of
-characters is synchronized with Unicode [Unicode3]) and the rules for
-using that scheme in the DNS. As such, it could also be called a
-"charset" as defined in [IDNReq].
-
-The RACE protocol has the following features:
-
-- There is exactly one way to convert internationalized host parts to
-and from RACE parts. Host name part uniqueness is preserved.
-
-- Host parts that have no international characters are not changed.
-
-- Names using RACE can include more internationalized characters than
-with other ACE protocols that have been suggested to date. Names in the
-Han, Yi, Hangul syllables, or Ethiopic scripts can have up to 17
-characters, and names in most other scripts can have up to 35
-characters. Further, a name that consist of characters from one
-non-Latin script but also contains some Latin characters such as digits
-or hyphens can have close to 33 characters.
-
-It is important to note that the following sections contain many
-normative statements with "MUST" and "MUST NOT". Any implementation that
-does not follow these statements exactly is likely to cause damage to
-the Internet by creating non-unique representations of host names.
-
-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".
-
-RACE 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".
-
-1.2 IDN summary
-
-Using the terminology in [IDNComp], RACE specifies an ACE format as
-specified in ace-1. Further, it specifies an identifying mechanism for
-ace-2, namely ace-2.1.1 (add hopefully-unique legal tag to the beginning
-of the name part).
-
-RACE has the following length characteristics. In this list, "row" means
-a row from ISO 10646.
-
-- If the characters in the input all come from the same row, up to 35
-characters per name part are allowed.
-
-- If the characters in the input come from two or more rows, neither of
-which is row 0, up to 17 characters per name part are allowed.
-
-- If the characters in the input come from two rows, one of which is row
-0, between 17 and 33 characters per name part are allowed.
-
-
-2. Host Part Transformation
-
-According to [STD13], host parts must be case-insensitive, start and
-end with a letter or digit, and contain only letters, digits, and the
-hyphen character ("-"). This, of course, excludes any internationalized
-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 Name tagging
-
-All post-converted name parts that contain internationalized characters
-begin with the string "bq--". (Of course, because host name parts are
-case-insensitive, this might also be represented as "Bq--" or "bQ--" or
-"BQ--".) The string "bq--" was chosen because it is extremely unlikely
-to exist in host parts before this specification was produced. As a
-historical note, in late August 2000, none of the second-level host name
-parts in any of the .com, .edu, .net, and .org top-level domains began
-with "bq--"; there are many tens of thousands of other strings of three
-characters followed by a hyphen that have this property and could be
-used instead. The string "bq--" will change to other strings with the
-same properties in future versions of this draft.
-
-Note that a zone administrator might still choose to use "bq--" at the
-beginning of a host name part even if that part does not contain
-internationalized characters. Zone administrators SHOULD NOT create host
-part names that begin with "bq--" unless those names are post-converted
-names. Creating host part names that begin with "bq--" but that are not
-post-converted names may cause two distinct problems. Some display
-systems, after converting the post-converted name part back to an
-internationalized name part, might display the name parts in a
-possibly-confusing fashion to users. More seriously, some resolvers,
-after converting the post-converted name part back to an
-internationalized name part, might reject the host name if it contains
-illegal characters.
-
-2.2 Converting an internationalized name to an ACE name part
-
-To convert a string of internationalized characters into an ACE name
-part, the following steps MUST be preformed in the exact order of the
-subsections given here.
-
-If a name part consists exclusively of characters that conform to the
-host name requirements in [STD13], the name MUST NOT be converted to
-LACE. That is, a name part that can be represented without LACE MUST NOT
-be encoded using LACE. This absolute requirement prevents there from
-being two different encodings for a single DNS host name.
-
-If any checking for prohibited name parts (such as ones that are
-prohibited characters, case-folding, or canonicalization) is to be done,
-it MUST be done before doing the conversion to an ACE name part.
-
-Characters outside the first plane of characters (those with codepoints
-above U+FFFF) MUST be represented using surrogates, as described in the
-UTF-16 description in ISO 10646.
-
-The input name string consists of characters from the ISO 10646
-character set in big-endian UTF-16 encoding. This is the pre-converted
-string.
-
-2.2.1 Check the input string for disallowed names
-
-If the input string consists only of characters that conform to the host
-name requirements in [STD13], the conversion MUST stop with an error.
-
-2.2.2 Compress the pre-converted string
-
-The entire pre-converted string MUST be compressed using the compression
-algorithm specified in section 2.4. The result of this step is the
-compressed string.
-
-2.2.3 Check the length of the compressed string
-
-The compressed string MUST be 36 octets or shorter. If the compressed
-string is 37 octets or longer, the conversion MUST stop with an error.
-
-2.2.4 Encode the compressed string with Base32
-
-The compressed string MUST be converted using the Base32 encoding
-described in section 2.5. The result of this step is the encoded string.
-
-2.2.5 Prepend "bq--" to the encoded string and finish
-
-Prepend the characters "bq--" to the encoded string. This is the host
-name part that can be used in DNS resolution.
-
-2.3 Converting a host name part to an internationalized name
-
-The input string for conversion is a valid host name part. Note that if
-any checking for prohibited name parts (such as prohibited characters,
-case-folding, or canonicalization is to be done, it MUST be done after
-doing the conversion from an ACE name part.
-
-If a decoded name part consists exclusively of characters that conform
-to the host name requirements in [STD13], the conversion from LACE MUST
-fail. Because a name part that can be represented without LACE MUST NOT
-be encoded using LACE, the decoding process MUST check for name parts
-that consists exclusively of characters that conform to the host name
-requirements in [STD13] and, if such a name part is found, MUST
-beconsidered an error (and possibly a security violation).
-
-2.3.1 Strip the "bq--"
-
-The input string MUST begin with the characters "bq--". If it does not,
-the conversion MUST stop with an error. Otherwise, remove the characters
-"bq--" from the input string. The result of this step is the stripped
-string.
-
-2.3.2 Decode the stripped string with Base32
-
-The entire stripped string MUST be checked to see if it is valid Base32
-output. The entire stripped string MUST be changed to all lower-case
-letters and digits. If any resulting characters are not in Table 1, the
-conversion MUST stop with an error; the input string is the
-post-converted string. Otherwise, the entire resulting string MUST be
-converted to a binary format using the Base32 decoding described in
-section 2.5. The result of this step is the decoded string.
-
-2.3.3 Decompress the decoded string
-
-The entire decoded string MUST be converted to ISO 10646 characters
-using the decompression algorithm described in section 2.4. The result
-of this is the internationalized string.
-
-2.3.4 Check the internationalized string for disallowed names
-
-If the internationalized string consists only of characters that conform
-to the host name requirements in [STD13], the conversion MUST stop with
-an error.
-
-2.4 Compression algorithm
-
-The basic method for compression is to reduce a full string that
-consists of characters all from a single row of the ISO 10646
-repertoire, or all from a single row plus from row 0, to as few octets
-as possible. Any full string that has characters that come from two
-rows, neither of which are row 0, or three or more rows, has all the
-octets of the input string in the output string.
-
-If the string comes from only one row, compression is to one octet per
-character in the string. If the string comes from only one row other
-than row 0, but also has characters only from row 0, compression is to
-one octet for the characters from the non-0 row and two octets for the
-characters from row 0. Otherwise, there is no compression and the output
-is a string that has two octets per input character.
-
-The compressed string always has a one-octet header. If the string comes
-from only one row, the header octet is the upper octet of the
-characters. If the string comes from only one row other than row 0, but
-also has characters only from row 0, the header octet is the upper octet
-of the characters from the non-0 row. Otherwise, the header octet is
-0xD8, which is the upper octet of a surrogate pair. Design note: It is
-impossible to have a legal stream of UTF-16 characters that has all the
-upper octets being 0xD8 because a character whose upper octet is 0xD8
-must be followed by one whose upper octet is in the range 0xDC through
-0xDF.
-
-Although the two-octet mode limits the number of characters in a RACE
-name part to 17, this is still generally enough for almost all names in
-almost scripts. Also, this limit is close to the limits set by other
-encoding proposals.
-
-Note that the compression and decompression rules MUST be followed
-exactly. This requirement prevents a single host name part from having
-two encodings. Thus, for any input to the algorithm, there is only one
-possible output. An implementation cannot chose to use one-octet mode or
-two-octet mode using anything other than the logic given in this
-section.
-
-2.4.1 Compressing a string
-
-The input string is in big-endian UTF-16 encoding with no byte order
-mark.
-
-Design note: No checking is done on the input to this algorithm. It is
-assumed that all checking for valid ISO/IEC 10646 characters has already
-been done by a previous step in the conversion process.
-
-Design note: In step 5, 0xFF was chosen as the escape character because
-it appears in the fewest number of scripts in ISO 10646, and therefore
-the "escaped escape" will be needed the least. 0x99 was chosen as the
-second octet for the "escaped escape" because the character U+0099 has
-no value, and is not even used as a control character in the C1 controls
-or in ISO 6429.
-
-1) Starting at the beginning of the input, read each pair of octets in
-the input stream, comparing the upper octet of each. Reset the input
-pointer to the beginning of the input again. If all of the upper octets
-(called U1) are the same, go to step 4. Note that if the input is only
-one character, this test will always be true.
-
-2) Read each pair of octets in the input stream, comparing the upper
-octet of each. Reset the input pointer to the beginning of the input
-again. If all of the upper octets are either 0x00 or one single other
-value (called U1), go to step 4.
-
-3) Output 0xD8, followed by the entire input stream. Finish.
-
-4) If U1 is in the range 0xD8 to 0xDC, stop with an error. Otherwise,
-output U1.
-
-5) If you are at the end of the input string, finish. Otherwise, read
-the next octet, called U2, and the octet after that, called N1. If U2 is
-0x00 and N1 is 0x99, stop with an error.
-
-6) If U2 is equal to U1, and N1 is not equal to 0xFF, output N1, and go
-to step 5.
-
-7) If U2 is equal to U1, and N1 is equal to 0xFF, output 0xFF followed
-by 0x99, and go to step 5.
-
-8) Output 0xFF followed by N1. Go to step 5.
-
-2.4.2 Decompressing a string
-
-1) Read the first octet of the input string. Call the value of the first
-octet U1. If there are no more octets in the input string (that is, if
-the input string had only one octet total), stop with an error. If U1 is
-0xD8, go to step 8.
-
-2) If you are at the end of the input string, go to step 11. Otherwise,
-read the next octet in the input string, called N1. If N1 is 0xFF, go to
-step 5.
-
-3) If U1 is 0x00 and N1 is 0x99, stop with an error.
-
-4) Put U1 followed by N1 in the output buffer. Go to step 2.
-
-5) If you are at the end of the input string, stop with an error.
-
-6) Read the next octet of the input string, called N1. If N1 is 0x99,
-put U1 followed by 0xFF in the output buffer, and go to step 2.
-
-7) Put 0x00 followed by N1 in the output buffer. Go to step 2.
-
-8) Read the rest of the input stream into a temporary string called
-LCHECK. If the length of LCHECK is an odd number, stop with an error.
-
-9) Perform the checks from steps 1 and 2 of the compression algorithm in
-section 2.4.1 on LCHECK. If either checks pass (that is, if either would
-have created a compressed string), stop with an error because the input
-to the decompression is in the wrong format.
-
-10) If the length of LCHECK is odd, stop with and error. Otherwise,
-output LCHECK and finish.
-
-11) If the length of the output buffer is odd, stop with and error.
-Otherwise, emit the output buffer and finish.
-
-2.4.3 Compression examples
-
-For the input string of <U+012D><U+0111><U+014B>, all characters are in
-the same row, 0x01. Thus, the output is 0x012D114B.
-
-For the input string of <U+012D><U+00E0><U+014B>, the characters are all
-in row 0x01 or row 0x00. Thus, the output is 0x012DFFE04B.
-
-For the input string of <U+1290><U+12FF><U+120C>, the characters are all
-in row 0x12. Thus, the output is 0x1290FF990C.
-
-For the input string of <U+012D><U+00E0><U+24D3>, the characters are
-from two rows other than 0x00. Thus, the output is 0xD8012D00E024D3.
-
-2.5 Base32
-
-In order to encode non-ASCII characters in DNS-compatible host name parts,
-they must be converted into legal characters. This is done with Base32
-encoding, described here.
-
-Table 1 shows the mapping between input bits and output characters in
-Base32. Design note: the digits used in Base32 are "2" through "7"
-instead of "0" through "6" in order to avoid digits "0" and "1". This
-helps reduce errors for users who are entering a Base32 stream and may
-misinterpret a "0" for an "O" or a "1" for an "l".
-
- Table 1: Base32 conversion
- bits char hex bits char hex
- 00000 a 0x61 10000 q 0x71
- 00001 b 0x62 10001 r 0x72
- 00010 c 0x63 10010 s 0x73
- 00011 d 0x64 10011 t 0x74
- 00100 e 0x65 10100 u 0x75
- 00101 f 0x66 10101 v 0x76
- 00110 g 0x67 10110 w 0x77
- 00111 h 0x68 10111 x 0x78
- 01000 i 0x69 11000 y 0x79
- 01001 j 0x6a 11001 z 0x7a
- 01010 k 0x6b 11010 2 0x32
- 01011 l 0x6c 11011 3 0x33
- 01100 m 0x6d 11100 4 0x34
- 01101 n 0x6e 11101 5 0x35
- 01110 o 0x6f 11110 6 0x36
- 01111 p 0x70 11111 7 0x37
-
-2.5.1 Encoding octets as Base32
-
-The input is a stream of octets. However, the octets are then treated
-as a stream of bits.
-
-Design note: The assumption that the input is a stream of octets
-(instead of a stream of bits) was made so that no padding was needed.
-If you are reusing this algorithm for a stream of bits, you must add a
-padding mechanism in order to differentiate different lengths of input.
-
-1) If the input bit stream is not an even multiple of five bits, pad
-the input stream with 0 bits until it is an even multiple of five bits.
-Set the read pointer to the beginning of the input bit stream.
-
-2) Look at the five bits after the read pointer.
-
-3) Look up the value of the set of five bits in the bits column of
-Table 1, and output the character from the char column (whose hex value
-is in the hex column).
-
-4) Move the read pointer five bits forward. If the read pointer is at
-the end of the input bit stream (that is, there are no more bits in the
-input), stop. Otherwise, go to step 2.
-
-2.5.2 Decoding Base32 as octets
-
-The input is octets in network byte order. The input octets MUST be
-values from the second column in Table 1.
-
-1) Count the number of octets in the input and divide it by 8; call the
-remainder INPUTCHECK. If INPUTCHECK is 1 or 3 or 6, stop with an error.
-
-2) Set the read pointer to the beginning of the input octet stream.
-
-3) Look up the character value of the octet in the char column (or hex
-value in hex column) of Table 1, and add the five bits from the bits
-column to the output buffer.
-
-4) Move the read pointer one octet forward. If the read pointer is not
-at the end of the input octet stream (that is, there are more octets in
-the input), go to step 3.
-
-5) Count the number of bits that are in the output buffer and divide it
-by 8; call the remainder PADDING. If the PADDING number of bits at the
-end of the output buffer are not all zero, stop with an error.
-Otherwise, emit the output buffer and stop.
-
-2.5.3 Base32 example
-
-Assume you want to encode the value 0x3a270f93. The bit string is:
-
-3 a 2 7 0 f 9 3
-00111010 00100111 00001111 10010011
-
-Broken into chunks of five bits, this is:
-
-00111 01000 10011 10000 11111 00100 11
-
-Padding is added to make the last chunk five bits:
-
-00111 01000 10011 10000 11111 00100 11000
-
-The output of encoding is:
-
-00111 01000 10011 10000 11111 00100 11000
- h i t q 7 e y
-or "hitq7ey".
-
-
-3. 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. Thus, RACE makes no changes to the DNS
-itself.
-
-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.
-
-RACE is designed so that every internationalized host name part
-can be represented as one and only one DNS-compatible string. If there
-is any way to follow the steps in this document and get two or more
-different results, it is a severe and fatal error in the protocol.
-
-
-4. References
-
-[IDNComp] Paul Hoffman, "Comparison of Internationalized Domain Name Proposals",
-draft-ietf-idn-compare.
-
-[IDNReq] James Seng, "Requirements of Internationalized Domain Names",
-draft-ietf-idn-requirement.
-
-[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. [[[ THIS REFERENCE
-NEEDS TO BE UPDATED AFTER DETERMINING ACCEPTABLE WORDING ]]]
-
-[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
-
-Mark Davis contributed many ideas to the initial draft of this document,
-as well as comments in later versions. Graham Klyne and Martin Duerst
-offered technical comments on the algorithms used. GIM Gyeongseog and
-Pongtorn Jentaweepornkul helped fix technical errors in early drafts.
-Rick Wesson and Mark Davis contributed many suggestions on error
-conditions in the processing.
-
-Base32 is quite obviously inspired by the tried-and-true Base64
-Content-Transfer-Encoding from MIME.
-
-
-
-B. Changes from Versions -02 to -03 of this Draft
-
-1: Wording corrections to third paragraph.
-
-2.2 and 2.3: Added need to check for all-STD13.
-
-2.4.1: Wording corrections in the first two paragraphs. Made step 1 and
-2 clearer with resetting the input pointer. Also added sentence at the
-end of step 1. Also added error conditions in steps 4 and 5.
-
-2.4.2: Added error condition in step 1. Added a new step 3 for an error
-check. Expanded step 8 to check for malformed input error. Added error
-check for odd-length output.
-
-2.4.3: Changed all the examples to use lowercase characters on input.
-
-2.5.1: Made the list of steps shorter by padding with 0 bits at the
-beginning of the steps.
-
-2.5.2: Changed the sense of the test in step 3 and added step 4 to be
-checkfor malformed input. Also made the output a buffer. Also added
-new step 1.
-
-
-C. IANA Considerations
-
-There are no IANA considerations in this document.
-
-
-D. Author Contact Information
-
-Paul Hoffman
-Internet Mail Consortium and VPN Consortium
-127 Segre Place
-Santa Cruz, CA 95060 USA
-paul.hoffman@imc.org and paul.hoffman@vpnc.org
+++ /dev/null
-IETF IDN Working Group Editors Zita Wenzel, James Seng
-Internet Draft draft-ietf-idn-requirements-05.txt
-24 April 2001 Expires 24 October 2001
-
- Requirements of Internationalized Domain Names
-
-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.
-
-Intended Scope
-
-The intended scope of this document is to explore requirements for the
-internationalization of domain names on the Internet. It is not
-intended to document user requirements. It is recommended that
-solutions not necessarily be within the DNS itself, but could be a layer
-interjected between the application and the DNS. Proposals SHOULD
-fulfill most, if not all, of the requirements. This document MAY be
-updated based on clinical trials.
-
-Abstract
-
-This document describes the requirement for encoding international
-characters into DNS names and records. This document is guidance for
-developing protocols for internationalized domain names.
-
-1. Introduction
-
-At present, the encoding of Internet domain names is restricted to a
-subset of 7-bit ASCII (ISO/IEC 646). HTML, XML, IMAP, FTP, and many
-other text based items on the Internet have already been at least
-partially internationalized. It is important for domain names to be
-similarly internationalized or for an equivalent solution to be found.
-This document assumes that the most effective solution involves putting
-non-ASCII names inside some parts of the overall DNS system.
-
-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 Definitions and Conventions
-
-A language is a way that humans interact. In computerised form, a text
-in a written language can be expressed as a string of characters.
-The same set of characters can often be used for many written languages,
-and many written languages can be expressed using different scripts.
-The same characters are often shown with somewhat different glyphs
-(shapes) for display of a text depending on the font used, the
-automatic shaping applied, or the automatic formation of ligatures. In
-addition, the same characters can be shown with somewhat different
-glyphs (shapes) for display of a text depending on the language being
-used, even within the same font or trough automatic font change.
-
-A character is a member of a set of elements used for organization,
-control, or representation of textual data.
-
-A graphic character is a character, other than a control function,
-that has a visual representation normally handwritten, printed, or
-displayed.
-
-Characters mentioned in this document are identified by their position
-in the Unicode [UNICODE] character set. This character set is also
-known as the UCS [ISO10646]. The notation U+12AB, for example, indicates
-the character at position 12AB (hexadecimal) in the Unicode character
-set. Note that the use of this notation is not an indication of a
-requirement to use Unicode.
-
-Examples quoted in this document should be considered as a method to
-further explain the meanings and principles adopted by the document. It
-is not a requirement for the protocol to satisfy the examples.
-
-Unicode Technical Report 17 [UTR17] defines a character encoding
-model in several levels (much of the text below is quoted from
-Unicode Technical Report 17 [UTR17]):
-
-1. A abstract character repertoire (ACR) is defined as the set of
- abstract characters to be encoded, normally a familiar alphabet
- or symbol set. The word abstract just means that these objects
- are defined by convention (such as the 26 letters of the English
- alphabet, uppercase and lowercase forms). Examples: the ASCII
- repertoire, the Latin-15 repertoire, the JIS X 0208 repertoire,
- the UCS repertiore (of a particular version).
-
-2. A coded character set (CCS) is defined to be a mapping from a
- set of abstract characters to the set of non-negative integers.
- This range of integers need not be contiguous. An abstract
- character is defined to be in a coded character set if the coded
- character set maps from it to an integer. That integer is said
- to be the code point for the abstract character. That abstract
- character is then an encoded character. Examples: ASCII, Latin-15,
- JIS X 0208, the UCS.
-
-3. A character encoding form (CEF) is a mapping from the set of integers
- used in a CCS to the set of sequences of code units. A code unit
- is an integer occupying a specified binary width in a computer
- architecture, such as a septet, an octet, or a 16-bit unit. The
- encoding form enables character representation as actual data in
- a computer. The sequences of code units do not necessarily have the
- same length. Examples: ASCII, Latin-15, Shift-JIS, UTF-16, UTF-8.
-
-4. A character encoding scheme (CES) is a mapping of code units into
- serialized octet sequences. Character encoding schemes are relevant
- to the issue of cross-platform persistent data involving code units
- wider than a byte, where byte-swapping may be required to put data
- into the byte polarity canonical for a particular platform.
-
- The CES may involve two or more CCS's, and may include code units
- (e.g. single shifts, SI/SO, or escape sequences) that are not part
- of the CCS per se, but which are defined by the character encoding
- architecture and which may require an external registry of particular
- values (as for the ISO 2022 escape sequences). In such a case, the
- CES is called a compound CES. (A CES that only involves a single
- CCS is called a simple CES.)
-
- Examples: ASCII, Latin-15, Shift-JIS, UTF-16BE, UTF-16LE, UTF-8.
-
-5. The mapping from an abstract character repertoire (ACR) to a
- serialised sequence of octets is called a Character Map (CM). A simple
- character map thus implicitly includes a CCS, a CEF, and a CES,
- mapping from abstract characters to code units to octets. A compound
- character map includes a compound CES, and thus includes more than one
- CCS and CEF. In that case, the abstract character repertoire for the
- character map is the union of the repertoires covered by the coded
- character sets involved.
-
- Character Maps are the things that in the IAB architecture get IANA
- charset identifiers. A sequence of encoded characters must be
- unambiguously mapped onto a sequence of octets by the charset. The
- charset must be specified in all instances, as in Internet
- protocols, where textual content is treated as a ordered sequence
- of octets, and where the textual content must be reconstructible
- from that sequence of octets. Charset names are registered by the
- IANA according to procedures documented in [RFC2278]. In many cases,
- the same name is used for both a character map and for a character
- encoding scheme, such as UTF-16BE. Typically this is done for simple
- character maps when such usage is clear from context.
-
-6. A transfer encoding syntax (TES) is a reversible transform of encoded
- data which may (or may not) include textual data represented in
- one or more character encoding schemes. Examples: 8bit,
- Quoted-Printable, BASE64, UTF-7 (defunct), (UTF-5, and RACE).
-
-1.2 Description of the Domain Name System
-
-The Domain Name System is defined by [RFC1034] and [RFC1035], with
-clarifications, extensions and modifications given in [RFC1123],
-[RFC1996], [RFC2181], and others. Of special importance here is the
-security extensions described in [RFC2535] and companions.
-
-Over the years, many different words have been used to describe the
-components of resource naming on the Internet (e.g., URI, URN); to make
-certain that the set of terms used in this document are well-defined and
-non-ambiguous, the definitions are given here.
-
-A master server for a zone holds the main copy of that zone. This copy
-is sometimes stored in a zone file. A slave server for a zone holds a
-complete copy of the records for that zone. Slave servers MAY be either
-authorized by the zone owner (secondary servers) or unauthorized
-(so-called "stealth secondaries"). Master and authorized slave servers
-are listed in the NS records for the zone, and are termed
-"authoritative" servers. In many contexts, outside this document the
-term "primary" is used interchangeably with "master" and "secondary" is
-used interchangeably with "slave".
-
-A caching server holds temporary copies of DNS records; it uses records
-to answer queries about domain names. Further explanation of these terms
-can be found in [RFC1034] and [RFC1996].
-
-DNS names can be represented in multiple forms, with different
-properties for internationalization. The most important ones are:
-
-- Domain name: The binary representation of a name used internally in
- the DNS protocol. This consists of a series of components of 1-63
- octets, with an overall length limited to 255 octets (including the
- length fields).
-
-- Master file format domain name: This is a representation of the name
- as a sequence of characters in some character sets; the common
- convention (derived from [RFC1035] section 5.1) is to represent the
- octets of the name as ASCII characters where the octet is in the set
- corresponding to the ASCII values for [a-zA-Z0-9-], using an escape
- mechanism (\x or \NNN) where not, and separating the components of the
- name by the dot character (".").
-
-The form specified for most protocols using the DNS is a limited form of
-the master file format domain name. This limited form is defined in
-[RFC1034] Section 3.5 and [RFC1123]. In most implementations of
-applications today, domain names in the Internet have been limited to
-the much more restricted forms used, e.g., in email. Those names are
-limited to the upper- and lower-case letters a-z (interpreted in a
-case-independent fashion), the digits, and the hyphen-minus, all in
-ASCII.
-
-1.3 Definition of "hostname" and "Internationalized Domain Name"
-
-In the DNS protocols, a name is referred to as a sequence of octets.
-However, when discussing requirements for internationalized domain
-names, what we are looking for are ways to represent characters that
-are meaningful for humans.
-
-In this document, this is referred to as a "hostname". While this term
-has been used for many different purposes over the years, it is used
-here in the sense of sequence of characters (not octets) representing a
-domain name conforming to the limited hostname syntax [RFC952].
-
-This document attempts to define the requirements for an
-"Internationalized Domain Name" (IDN). This is defined as a sequence of
-characters that can be used in the context of functions where a hostname
-is used today, but contains one or more characters that are outside the
-set of characters specified as legal characters for host names
-[RFC1123].
-
-1.4 A multilayer model of the DNS function
-
-The DNS can be seen as a multilayer function:
-
-- The bottom layer is where the packets are passed across the Internet
- in a DNS query and a DNS response. At this level, what matters is
- the format and meaning of bits and octets in a DNS packet.
-
-- Above that is the "DNS service", created by an infrastructure of DNS
- servers, NS records that point to those DNS servers, that is
- pointed to by the root servers (listed in the "root cache file" on
- each DNS server, often called "named.cache". It is at this level
- that the statement "the DNS has a single root" [RFC2826] makes
- sense, but still, what are being transferred are octets, not
- characters.
-
-- Interfacing to the user is a service layer, often called "the resolver
- library", and often embedded in the operating system or system
- libraries of the client machines. It is at the top of this layer that
- the API calls commonly known as "gethostbyname" and "gethostbyaddress"
- reside. These calls are modified to support IPv6 [RFC2553]. A
- conceptually similar layer exists in authoritative DNS servers,
- comprising the parts that generate "meaningful" strings in DNS files.
- Due to the popularity of the "master file" format, this layer often
- exists only in the administrative routines of the service maintainers.
-
-- The user of this layer (resolver library) is the application programs
- that use the DNS, such as mailers, mail servers, Web clients, Web
- servers, Web caches, IRC clients, FTP clients, distributed file
- systems, distributed databases, and almost all other applications on
- TCP/IP.
-
-Graphically, one can illustrate it like this:
-
-+---------------+ +---------------------+
-| Application | | (Base data) |
-+---------------+ +---------------------+
- | Application service interface |
- | For ex. GethostbyXXXX interface | (no standard)
-+---------------+ +---------------------+
-| Resolver | | Auth DNS server |
-+---------------+ +---------------------+
- | <----- DNS service interface -----> |
-+------------------------------------------------------------------+
-| DNS service |
-| +-----------------------+ +--------------------+ |
-| | Forwarding DNS server | | Caching DNS server | |
-| +-----------------------+ +--------------------+ |
-| |
-| +-------------------------+ |
-| | Parent-zone DNS servers | |
-| +-------------------------+ |
-| |
-| +-------------------------+ |
-| | Root DNS servers | |
-| +-------------------------+ |
-| |
-+------------------------------------------------------------------+
-
-1.5 Service model of the DNS
-
-The Domain Name Service is used for multiple purposes, each of which is
-characterized by what it puts into the system (the query) and what it
-expects as a result (the reply).
-
-The most used ones in the current DNS are:
-
-- Hostname-to-address service (A, AAAA, A6): Enter a hostname, and get
- back an IPv4 or IPv6 address.
-
-- Hostname-to-Mail server service (MX): As above, but the expected
- return value is a hostname and a priority for SMTP servers.
-
-- Address-to-hostname service (PTR): Enter an IPv4 or IPv6 address (in
- in-addr.arpa or ip6.int form respectively) and get back a hostname.
-
-- Domain delegation service (NS). Enter a domain name and get back
- nameserver records (designated hosts who provides authoritive
- nameservice) for the domain.
-
-New services are being defined, either as entirely new services (IPv6 to
-hostname mapping using binary labels) or as embellishments to other
-services (DNSSEC returning information about whether a given DNS service
-is performed securely or not).
-
-These services exist, conceptually, at the Application/Resolver
-interface, NOT at the DNS-service interface. This document attempts to
-set requirements for an equivalent of the "used services" given above,
-where "hostname" is replaced by "Internationalized Domain Name". This
-doesn't preclude the fact that IDN should work with any kind of DNS
-queries. IDN is a new service. Since existing protocols like SMTP or
-HTTP use the old service, it is a matter of great concern how the new
-and old services work together, and how other protocols can take
-advantage of the new service.
-
-2. General Requirements
-
-These requirements address two concerns: The service offered to the
-users (the application service), and the protocol extensions, if needed,
-added to support this service.
-
-In the requirements, we attempt to use the term "service" whenever a
-requirement concerns the service, and "protocol" whenever a requirement
-is believed to constrain the possible implementation.
-
-2.1 Compatibility and Interoperability
-
-[1] The DNS is essential to the entire Internet. Therefore, the service
-MUST NOT damage present DNS protocol interoperability. It MUST make the
-minimum number of changes to existing protocols on all layers of the
-stack. It MUST continue to allow any system anywhere to resolve any
-internationalized domain name.
-
-[2] The service MUST preserve the basic concept and facilities of domain
-names as described in [RFC1034]. It MUST maintain a single, global,
-universal, and consistent hierarchical namespace.
-
-[3] The DNS protocol (the packet formats that go on the wire) MUST
-NOT limit the codepoints that can be used. A service defined on top of
-the DNS, for instance the IDN-to-address function, MAY limit the
-codepoints that can be used. The service descriptions MUST describe
-what limitations are imposed.
-
-[4] The protocol MUST work for all features of DNS, IPv4, and
-IPv6. The protocol MUST NOT allow an IDN to be returned to a requestor
-that requests the IP-to-(old)-domain-name mapping service.
-
-[5] The same name resolution request MUST generate the same response,
-regardless of the location or localization settings in the resolver, in
-the master server, and in any slave servers involved in the resolution
-process.
-
-[6] The protocol MUST NOT require that the current DNS cache
-servers be modified to support IDN. If a cache server can have
-additional functionality to support IDN better, this additional
-functionality MUST NOT cause problems for resolving correctly
-functioning current domain names.
-
-[7] A caching server MUST NOT return data in response to a query that
-would not have been returned if the same query had been presented to an
-authoritative server. This applies fully for the cases when:
-
-- The caching server does not know about IDN
-- The caching server implements the whole specification
-- The caching server implements a valid subset of the specification
-
-[8] The service MAY modify the DNS protocol [RFC1035] and other related
-work undertaken by the [DNSEXT] WG. However, these changes SHOULD be as
-small as possible and any changes SHOULD be coordinated with the
-[DNSEXT] WG.
-
-[9] The protocol supporting the service SHOULD be as simple as possible
-from the user's perspective. Ideally, users SHOULD NOT realize that IDN
-was added on to the existing DNS.
-
-[10] The best solution is one that maintains maximum feasible
-compatibility with current DNS standards as long as it meets the other
-requirements in this document.
-
-[11] The protocol should handle with care new revisions of the CCS.
-Undefined codepoints should not be allowed unless a new revision of
-the protocol can handle it. Protocol revisions should be tagged.
-
-2.2 Internationalization
-
-[12] Internationalized characters MUST be allowed to be represented and
-used in DNS names and records. The protocol MUST specify what charset is
-used when resolving domain names and how characters are encoded in DNS
-records.
-
-[13] Codepoints SHOULD be from the Universal Set as defined in
-ISO-10646 or Unicode. The specifics of versions MUST be defined in the
-proposed solution. If multiple charsets are allowed, each charset MUST
-be tagged and conform to [RFC2277].
-
-[14] The protocol MUST NOT reject any non-IDN characters (to be
-defined) in any queries or responses.
-
-[15] The protocol SHOULD NOT invent a new CCS for the purpose of IDN
-only and SHOULD use existing CES. The charset(s) chosen SHOULD also be
-non-ambiguous.
-
-[16] The protocol SHOULD NOT make any assumptions about the location
-in a domain name where internationalization might appear. In other
-words, it SHOULD NOT differentiate between any part of a domain name
-because this MAY impose restrictions on future internationalization
-efforts. For example, the TLDs can be internationalized.
-
-[17] The protocol also SHOULD NOT make any localized restrictions in the
-protocol. For example, an IDN implementation which only allows domain
-names to use a single local script would immediately restrict
-multinational organization.
-
-[18] While there are a wide range of devices that use the DNS and a wide
-range of characteristics of international scripts and methods of
-domain name input and display, IDN is only concerned with the
-protocol. Therefore, there MUST be a single way of encoding an
-internationalized domain name within the DNS.
-
-2.4 Canonicalization
-
-Matching rules are a complicated process for IDN. Canonicalization
-of characters MUST follow precise and predictable rules to ensure
-consistency. [CHARREQ] is RECOMMENDED as a guide on canonicalization.
-
-The DNS has to match a host name in a request with a host name held
-in one or more zones. It also needs to sort names into order. It is
-expected that some sort of canonicalization algorithm will be used as
-the first step of this process. This section discusses some of the
-properties which will be REQUIRED of that algorithm.
-
-[19] To achieve interoperability, canonicalization MUST be done at a
-single well-defined place in the DNS resolution process. The protocol
-MUST specify canonicalization; it MUST specify exactly where in the
-DNS that canonicalization happens and does not happen; it MUST specify
-how additions to ISO 10646 will affect the stability of the DNS and
-the amount of work done on the root DNS servers.
-
-[20] The canonicalization algorithm MAY specify operations for case,
-ligature, and punctuation folding.
-
-[21] In order to retain backwards compatibility with the current DNS,
-the service MUST retain the case-insensitive comparison for [US-ASCII]
-as specified in [RFC1035]. For example, Latin capital letter A (U+0041)
-MUST match Latin small letter a (U+0061). [UTR21] describes some of
-the issues with case mapping. Case-insensitivity for non [US-ASCII]
-MUST be discussed in the protocol proposal.
-
-[22] Case folding MUST be locale independent. If it were
-locale-dependent, then different clients would get different results.
-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).
-
-[23] If other canonicalization is done, it MUST be done before the
-domain name is resolved. Further, the canonicalization MUST be easily
-upgradable as new languages and writing systems are added.
-
-[24] Any conversion (case, ligature folding, punctuation folding, etc)
-from what the user enters into a client to what the client asks for
-resolution MUST be done identically on any request from any client.
-
-[25] If the charset can be normalized, then it SHOULD be normalized
-before it is used in IDN. Normalization SHOULD follow [UTR15].
-
-[26] The protocol SHOULD avoid inventing a new normalization form
-provided a technically sufficient one is available.
-
-2.5 Operational Issues
-
-[27] Zone files SHOULD remain easily editable.
-
-[28] An IDN-capable resolver or server SHALL NOT generate more traffic
-than a non-IDN-capable resolver or server would when resolving an
-ASCII-only domain name. The amount of traffic generated when resolving
-an IDN SHALL be similar to that generated when resolving an ASCII-only
-name.
-
-[29] The service SHOULD NOT add new centralized administration for the
-DNS. A domain administrator SHOULD be able to create internationalized
-names as easily as adding current domain names.
-
-[30] Within a single zone, the zone manager MUST be able to define
-equivalence rules that suit the purpose of the zone, such as, but not
-limited to, and not necessarily, non-ASCII case folding, Unicode
-normalizations (if Unicode is chosen), Cyrillic/Greek/Latin folding, or
-traditional/simplified Chinese equivalence. Such defined equivalences
-MUST NOT remove equivalences that are assumed by (old or
-local-rule-ignorant) caches.
-
-[31] The protocol MUST work with DNSSEC. The protocol MAY break
-language sort order.
-
-3. Security Considerations
-
-Any solution that meets the requirements in this document MUST NOT be
-less secure than the current DNS. Specifically, the mapping of
-internationalized host names to and from IP addresses MUST have the
-same characteristics as the mapping of today's host names.
-
-Specifying requirements for internationalized domain names does not
-itself raise any new security issues. However, any change to the DNS MAY
-affect the security of any protocol that relies on the DNS or on
-DNS names. A thorough evaluation of those protocols for security
-concerns will be needed when they are developed. In particular, IDNs
-MUST be compatible with DNSSEC and, if multiple charsets or
-representation forms are permitted, the implications of this name-spoof
-MUST be throughly understood.
-
-4. References
-
-[CHARREQ] "Requirements for string identity matching and String
- Indexing", http://www.w3.org/TR/WD-charreq, July 1998,
- World Wide Web Consortium.
-
-[DNSEXT] "IETF DNS Extensions Working Group",
- namedroppers@ops.ietf.org, Olafur Gudmundson, Randy Bush.
-
-[RFC952] "DoD Internet Host Table Specification", rfc952.txt,
- October 1985, K. Harrenstien, M.K. Stahl, E.J. Feinler.
-
-[RFC1034] "Domain Names - Concepts and Facilities", rfc1034.txt,
- November 1987, P. Mockapetris.
-
-[RFC1035] "Domain Names - Implementation and Specification",
- rfc1035.txt, November 1987, P. Mockapetris.
-
-[RFC1123] "Requirements for Internet Hosts -- Application and
- Support", rfc1123.txt, October 1989, R. Braden.
-
-[RFC1996] "A Mechanism for Prompt Notification of Zone Changes
- (DNS NOTIFY)", rfc1996.txt, August 1996, P. Vixie.
-
-[RFC2119] "Key words for use in RFCs to Indicate Requirement
- Levels", rfc2119.txt, March 1997, S. Bradner.
-
-[RFC2181] "Clarifications to the DNS Specification", rfc2181.txt,
- July 1997, R. Elz, R. Bush.
-
-[RFC2277] "IETF Policy on Character Sets and Languages",
- rfc2277.txt, January 1998, H. Alvestrand.
-
-[RFC2278] "IANA Charset Registration Procedures", rfc2278.txt,
- January 1998, N. Freed and J. Postel.
-
-[RFC2279] "UTF-8, a transformation format of ISO 10646",
- rfc2279.txt, F. Yergeau, January 1998.
-
-[RFC2535] "Domain Name System Security Extensions", rfc2535.txt,
- March 1999, D. Eastlake.
-
-[RFC2553] "Basic Socket Interface Extensions for IPv6", rfc2553.txt,
- March 1999, R. Gilligan et al.
-
-[RFC2825] "A Tangled Web: Issues of I18N, Domain Names, and the
- Other Internet protocols", rfc2825.txt, May 2000,
- L. Daigle et al.
-
-[RFC2826] "IAB Technical Comment on the Unique DNS Root",
- rfc2826.txt, May 2000, Internet Architecture Board.
-
-[IDNCOMP] "Comparison of Internationalized Domain Name Proposals",
- draft-ietf-idn-compare-00.txt, June 2000, P. Hoffman.
-
-[ISO10646] ISO/IEC 10646-1:2000 (note that an amendment 1 is in
- preparation), ISO/IEC 10646-2 (in preparation), plus
- corrigenda and amendments to these standards.
-
-[UNICODE] The Unicode Consortium, "The Unicode Standard". Described at
- http://www.unicode.org/unicode/standard/versions/.
-
-[UNICODE30] The Unicode Consortium, "The Unicode Standard -- Version
- 3.0", ISBN 0-201-61633-5. Same repertoire as ISO/IEC
- 10646-1:2000. Described at http://www.unicode.org/unicode/
- standard/versions/Unicode3.0.html.
-
-[US-ASCII] Coded Character Set -- 7-bit American Standard Code for
- Information Interchange, ANSI X3.4-1986; also: ISO/IEC
- 646 (IRV).
-
-[UAX15] "Unicode Normalization Forms", Unicode Standard Annex #15,
- http://www.unicode.org/unicode/reports/tr15/, 2000-08-31,
- M. Davis and M. Duerst, Unicode Consortium.
-
-[UTR17] "Character Encoding Model", Unicode Technical Report #17,
- http://www.unicode.org/unicode/reports/tr17/, 2000-08-31,
- K. Whistler and M. Davis, Unicode Consortium.
-
-[UTR21] "Case Mappings", Unicode Technical Report #21,
- http://www.unicode.org/unicode/reports/tr21/, 2000-09-12,
- M. Davis, Unicode Consortium.
-
-5. Editors' Contact
-
-Zita Wenzel, Ph.D.
-Information Sciences Institute
-University of Southern California
-4676 Admiralty Way
-Marina del Rey, CA
-90292 USA
-Tel: +1 310 448 8462
-Fax: +1 310 823 6714
-zita@isi.edu
-
-James Seng
-i-DNS.net International Pte Ltd.
-8 Temesek Boulevand
-#24-02 Suntec Tower 3
-Singapore 038988
-Tel: +65 248 6208
-Fax: +65 248 6198
-Email: jseng@pobox.org.sg
-
-6. Acknowledgements
-
-The editors gratefully acknowledge the contributions of:
-
-Harald Tveit Alvestrand <Harald@Alvestrand.no>
-Mark Andrews <Mark.Andrews@nominum.com>
-RJ Atkinson <request not to have email>
-Alan Barret <apb@cequrux.com>
-Marc Blanchet <blanchet@mailviagenie.qc.ca>
-Randy Bush <randy@psg.com>
-Andrew Draper <ADRAPER@altera.com>
-Martin Duerst <duerst@w3.org>
-Patrik Faltstrom <paf@swip.net>
-Ned Freed <ned.freed@innosoft.com>
-Olafur Gudmundsson <ogud@tislabs.com>
-Paul Hoffman <phoffman@imc.org>
-Simon Josefsson <jas+idn@pdc.kth.se>
-Kent Karlsson <keka@im.se>
-John Klensin <klensin+idn@jck.com>
-Tan Juay Kwang <tanjk@i-dns.net>
-Dongman Lee <dlee@icu.ac.kr>
-Bill Manning <bmanning@ISI.EDU>
-Dan Oscarsson <Dan.Oscarsson@trab.se>
-J. William Semich <bill@mail.nic.nu>
-Yoshiro Yoneda <<yone@nic.ad.jp>
+++ /dev/null
-Internet Draft Dan Oscarsson
-draft-ietf-idn-udns-02.txt Telia ProSoft
-Updates: RFC 2181, 1035, 1034, 2535 24 February
-2001 Expires: 24 August 2001
-
- Using the Universal Character Set in the Domain Name System (UDNS)
-
-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
-
- Since the Domain Name System (DNS) [RFC1035] was created there have
- been a desire to use other characters than ASCII in domain names.
- Lately this desire have grown very strong and several groups have
- started to experiment with non-ASCII names.
-
- This document defines how the Universal Character Set (UCS)
- [ISO10646] is to be used in DNS.
-
- It includes both a transition scheme for older software supporting
- non-ASCII handling in applications only, as well as how to use UCS in
- labels and having more than 63 octets in a label.
-
-
-1. Introduction
-
- While the need for non-ASCII domain names have existed since the
- creation of the DNS, the need have increased very much during the
- last few years. Currently there are at least two implementations
-
-
-
-Dan Oscarsson Expires: 24 August 2001 [Page 1]
-\f
-Internet Draft Universal DNS 24 February 2001
-
-
- using UTF-8 in use, and others using other methods.
-
- To avoid several different implementations of non-ASCII names in DNS
- that do not work together, and to avoid breaking the current ASCII
- only DNS, there is an immediate need to standardise how DNS shall
- handle non-ASCII names.
-
- While the DNS protocol allow any octet in character data, so far the
- octets are only defined for the ASCII code points. Octets outside the
- ASCII range have no defined interpretation. This document defines how
- all octets are to be used in character data allowing a standardised
- way to use non-ASCII in DNS.
-
- The specification here conforms to the IDN requirements [IDNREQ].
-
-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].
-
- IDN: Internationalised Domain Name, here used to mean a domain name
- containing non-ASCII characters.
-
- ACE: ASCII Compatible Encoding. Used to encode IDNs in a way
- compatible with the ASCII host name syntax.
-
-1.2 Previous versions of this document
-
- The third version of this document included a way to return both
- ASCII and non-ASCII versions of a name. As this could not be
- guaranteed to work it has been removed.
-
- The second version of this document was available as draft-ietf-idn-
- udns-00.txt. It included a lot of possibilities as well as a flag bit
- that is now removed.
-
- The first version of this document was available as draft-oscarsson-
- i18ndns-00.txt.
-
-
-2. The DNS Protocol
-
- The DNS protocol is used when communicating between DNS servers and
- other DNS servers or DNS clients. User interface issues like the
- format of zone files or how to enter or display domain names are not
- part of the protocol.
-
-
-
-
-Dan Oscarsson Expires: 24 August 2001 [Page 2]
-\f
-Internet Draft Universal DNS 24 February 2001
-
-
- The update of the protocol defined here can be used immediately as it
- is fully compatible with the DNS of today.
-
- For a long time there will be software understanding UCS in DNS and
- software only understanding ASCII in DNS. It is therefore necessary
- to support a mixing of both types. For the following text software
- understanding UCS in DNS will be called UDNS aware.
-
- This specification supports the following scenarios:
-
- - UDNS unaware client, UDNS aware DNS server
- - UDNS aware client, UDNS unaware DNS server
- - UDNS aware client, UDNS unaware DNS server
-
-
-2.1 Fundamentals
-
-2.1.1 Standard Character Encoding (SCE)
-
- Character data need to be able to represent as much as possible of
- the characters in the world as well as being compatible with ASCII.
- Character data is used in labels and in text fields in the RDATA part
- of a RR.
-
- The Standard Character Encoding of character data used in the DNS
- protocol MUST:
- - Use ISO 10646 (UCS) [ISO10646] as coded character set.
- - Be normalised using form C as defined in Unicode technical report
- #15 [UTR15]. See also [CHNORM].
- - Encoded using the UTF-8 [RFC2279] character encoding scheme.
-
-2.1.2 Binary Comparison Format (BCF)
-
- RFC 1035 states that the labels of a name are matched case-
- insensitively. When using UCS this is no longer enough as there are
- other forms than case that need to match as equivalent. Form-
- insensitive matching of UCS includes:
- - Letters of different case are compared as the same character.
- - Code points of primary typographical variations of the same
- character are compared as the same character. An example is double
- width/normal width characters or presentation forms of a
- character.
- - Some characters are represented with multiple code points in UCS.
- All code points of one character must compare as the same. For
- example the degree Kelvin sign is the same as the letter K.
-
- The original definition is now extended to be: labels must be
- compared using form-insensitivity.
-
-
-
-Dan Oscarsson Expires: 24 August 2001 [Page 3]
-\f
-Internet Draft Universal DNS 24 February 2001
-
-
- To handle form-insensitivity it is here defined the Binary Comparison
- Format (BCF) to which strings can be mapped. After strings is mapped
- to BCF they can be compared using binary string comparison.
- Implementors may implement the form-insensitive comparison without
- using BCF, as long as the results are the same.
-
- Mapping of a label to BCF is typically done by steps like: changing
- all upper case letters to lower case, mapping different forms to one
- form and changing different code points of one character into a
- single code point.
-
- For the UCS character code range 0-255 (ASCII and ISO 8859-1) the BCF
- MUST be done by mapping all upper case characters to lower case
- following the one to one mapping as defined in the Unicode 3.0
- Character Database [UDATA].
-
- The definition of the Binary Comparison Format (BCF) for the rest of
- UCS will be defined in a separate document. The nearest today is
- [NAMEPREP].
-
-2.1.3 Backward Compatibility Encoding (BCE)
-
- To support older software expecting only ASCII and to support
- downgrading from 8-bit to 7-bit ASCII in other protocols (like SMTP)
- a Backward Compatibility Encoding (BCE) is available. It is a
- transition mechanism and will no longer be supported at some future
- time when it is so decided.
-
- The Backward Compatibility Encoding (BCE) of a label is defined as
- the BCF of the label encoded using an ASCII Compatible Encoding
- (ACE).
-
- The definition of the ACE to be used, is defined in a separate
- document. Typical definitions that are suitable are [SACE] and
- [RACE].
-
-2.1.4 Long names
-
- The current DNS protocol limits a label to 63 octets. As UTF-8 take
- more than one octet for some characters, an UTF-8 name cannot have 63
- characters in a label like an ASCII name can. For example a name
- using Hangul would have a maximum of 21 characters.
-
- The limits imposed by RFC 1035 is 63 octets per label and 255 octets
- for the full name. The 255 limit is not a protocol limit but one to
- simplify implementations.
-
- To support longer names a long label type is defined using [RFC2671]
-
-
-
-Dan Oscarsson Expires: 24 August 2001 [Page 4]
-\f
-Internet Draft Universal DNS 24 February 2001
-
-
- as extended label 0b000011 (the label type will be assigned by IANA
- and may not be the number used here).
-
- 1 1 1 1 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- |0 1 0 0 0 0 1 1| length | label data ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- length: length of label in octets
- label data: the label
-
- The long label MUST be handled by all software following this
- specification. Also, they MUST support a UDP packet size of up to
- 1280 bytes.
-
- The limits for labels are updated since RFC 1025 as follows:
- A label is limited to a maximum of 63 character code points in UCS
- normalised using Unicode form C. The full name is limited to a
- maximum of 255 character code points normalised as for a label.
-
- A long label MUST always use the Standard Character Encoding (SCE).
-
- As long labels are not understood by older software, a response MUST
- not include a long label unless the query did. At a later date, IETF
- may change this.
-
-
-2.2 Rules for matching of domain names in UDNS aware DNS servers
-
- To be able to handle correct domain name matching in lookups, the
- following MUST be followed by DNS servers:
- - Do matching on authorative data using form-insensitive matching
- for the characters used in the data (for example a zone using only
- ASCII need only handle matching of ASCII characters).
- - On non-authorative data, either do binary matching or case-
- insensitive matching on ASCII letters and binary matching on all
- others.
-
- The effect of the above is:
- - only servers handling authorative data must implement form-
- insensitive matching of names. And they need only implement the
- subset needed for the subset of characters of UCS they support in
- their authorative zones.
- - it normally gives fast lookup because data is usually sent like:
- resolver <-> server <-> authorative server.
- While form-insensitive matching can be complex and CPU consuming,
- the server in the middle will do caching with only simple and fast
-
-
-
-Dan Oscarsson Expires: 24 August 2001 [Page 5]
-\f
-Internet Draft Universal DNS 24 February 2001
-
-
- binary matching. So the impact of complex matching rules should
- not slow down DNS very much.
-
-2.3 Mixing of UDNS aware and non-UDNS aware clients and servers
-
- To handle the mixing of UDNS aware and non-UDNS aware clients and
- servers the following MUST be followed for clients and servers.
-
-2.3.1 Native UDNS aware client
-
- A native UDNS aware client is a client supporting all in this
- document.
-
- When doing a query it MUST:
- - Use the long label in the QNAME.
- - If server rejected query due to long label, retry the query using
- the normal short label. If the QNAME contains non-ASCII it must be
- encoded using BCE.
- - Handle answers containg BCE.
-
- The client may skip trying a query using the long label if it knows
- the server does not understand it.
-
-2.3.2 Application based UDNS aware client
-
- An application based UDNS aware client is a client supporting UDNS
- through BCE handling in the application.
-
- It only understands BCE and need only a non-UDNS aware resolver to
- work. All encoding and decoding of BCE is handled in the
- application.
-
- Due to BCE being an ACE of BCF the names returned in an answer need
- not contain the real form of the name. Instead it may contains the
- simplified form used in name matching. As this is a transition
- mechanism to support non-ASCII in names before the DNS servers have
- been upgraded, it is acceptable and will give people a reason to
- upgrade.
-
-2.3.3 non-UDNS aware client
-
- A non-UDNS aware client will send ASCII or whatever is sent from an
- application. It can be BCE which will for the client just be ASCII
- text.
-
-2.3.4 UDNS aware server
-
- An UDNS aware server MUST handle all in this document and follow:
-
-
-
-Dan Oscarsson Expires: 24 August 2001 [Page 6]
-\f
-Internet Draft Universal DNS 24 February 2001
-
-
- - If an incoming query contains a long label the answer may contain
- a long label and the client is identified as being UDNS aware.
- - If the query comes from a non-UDNS aware client and the answer
- contains non-ASCII, the non-ASCII labels must be encoded using
- BCE.
- - If a short label is used in a query and the QNAME contains non-
- ASCII, an authorative server must handle the query if the
- character encoding can be recognised. If must recognise SCE and
- should recognise common encodings used for the labels in the
- domain it is authorative for. Answers will use BCE for all labels
- except the one matching QNAME. This will allow clients using the
- local character set to work in many cases before the resolver code
- is upgraded.
-
-2.3.5 non-UDNS aware server
-
- A non-UDNS server can only handle ASCII matching when comparing
- names. It can support the transition mechanism with BCE. The
- authorative zones will then have to be loaded with manually BCE
- encoded names.
-
-2.4 DNSSEC
-
- As labels now can have non-ASCII in them, DNSSEC [RFC2535] need to be
- revised so that it also can handle that.
-
-
-3. Effect on other protocols
-
- As now a domain name may include non-ASCII many other protocols that
- include domain names need to be updated. For example SMTP, HTTP and
- URIs. The BCE format can be used when interfacing with ASCII only
- software or protocols. Protocols like SMTP could be extended using
- ESMTP and a UTF8 option that defines that all headers are in UTF-8.
-
- It is recommended that protocols updated to handle i18n do this by
- encoding character data in the same standard format as defined for
- DNS in this document (UCS normalised form C). The use of encoding it
- in ASCII or by tagged character sets should be avoided.
-
- DNS do not only have domain names in them, for example e-mail
- addresses are also included. So an e-mail address would be expected
- to be changed to include non-ASCII both before and after the @-sign.
-
- Software need to be updated to follow the user interface
- recommendations given above, so that a human will see the characters
- in their local character set, if possible.
-
-
-
-
-Dan Oscarsson Expires: 24 August 2001 [Page 7]
-\f
-Internet Draft Universal DNS 24 February 2001
-
-
-4. Security Considerations
-
- 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.
-
-5. References
-
- [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1035] P. Mockapetris, "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, November 1987.
-
- [RFC2119] Scott Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", March 1997, RFC 2119.
-
- [RFC2181] R. Elz and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 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.
-
- [RFC2671] P. Vixie, "Extension Mechanisms for DNS (EDNS0)", RFC
- 2671, August 1999.
-
- [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
-
- [UTR15] M. Davis and M. Duerst, "Unicode Normalization Forms",
- Unicode Technical Report #15, Nov 1999,
- http://www.unicode.org/unicode/reports/tr15/.
-
- [UTR21] M. Davis, "Case Mappings", Unicode Technical Report #21,
- Dec 1999, http://www.unicode.org/unicode/reports/tr21/.
-
- [UDATA] The Unicode Character Database,
- ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData.txt.
-
-
-
-Dan Oscarsson Expires: 24 August 2001 [Page 8]
-\f
-Internet Draft Universal DNS 24 February 2001
-
-
- The database is described in
- ftp://ftp.unicode.org/Public/UNIDATA/
- UnicodeCharacterDatabase.html.
-
- [IDNREQ] James Seng, "Requirements of Internationalized Domain
- Names", draft-ietf-idn-requirement.
-
- [IANADNS] Donald Eastlake, Eric Brunner, Bill Manning, "Domain Name
- System (DNS) IANA Considerations",draft-ietf-dnsext-iana-dns.
-
- [IDNE] Marc Blanchet,Paul Hoffman, "Internationalized domain
- names using EDNS (IDNE)", draft-ietf-idn-idne.
-
- [CHNORM] M. Duerst, M. Davis, "Character Normalization in IETF
- Protocols", draft-duerst-i18n-norm.
-
- [IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
- Proposals", draft-ietf-idn-compare.
-
- [NAMEPREP] Paul Hoffman, "Comparison of Internationalized Domain Name
- Proposals", draft-ietf-idn-compare.
-
- [SACE] Dan Oscarsson, "Simple ASCII Compatible Encoding", draft-
- ietf-idn-sace.
-
- [RACE] Paul Hoffman, "RACE: Row-based ASCII Compatible Encoding
- for IDN", draft-ietf-idn-race.
-
-6. Acknowledgements
-
- Paul Hoffman giving many comments in our e-mail discussions.
-
- Ideas from drafts by Paul Hoffman, Stuart Kwan, James Gilroy and Kent
- Karlsson.
-
- Magnus Gustavsson, Mark Davis, Kent Karlsson and Andrew Draper for
- comments on my draft.
-
- Discussions and comments by the members of the IDN working group.
-
-
-
-Author's Address
-
- Dan Oscarsson
- Telia ProSoft AB
- Box 85
- 201 20 Malmo
-
-
-
-Dan Oscarsson Expires: 24 August 2001 [Page 9]
-\f
-Internet Draft Universal DNS 24 February 2001
-
-
- Sweden
-
- E-mail: Dan.Oscarsson@trab.se
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Dan Oscarsson Expires: 24 August 2001 [Page 10]
-\f
+++ /dev/null
-
-
-
-
-Network Working Group M. Duerst
-Internet-Draft W3C
-Expires: May 4, 2003 November 3, 2002
-
-
- Internationalized Domain Names in URIs
- draft-ietf-idn-uri-03
-
-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.
-
- This Internet-Draft will expire on May 4, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- This document proposes to upgrade the definition of URIs (RFC 2396)
- [RFC2396] to work consistently with internationalized domain names.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Duerst Expires May 4, 2003 [Page 1]
-Internet-Draft IDNs in URIs November 2002
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. URI syntax changes . . . . . . . . . . . . . . . . . . . . . . 3
- 3. Security considerations . . . . . . . . . . . . . . . . . . . 5
- 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
- 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 5.1 Changes from draft-ietf-idn-uri-02 to draft-ietf-idn-uri-03 . 5
- 5.2 Changes from draft-ietf-idn-uri-01 to draft-ietf-idn-uri-02 . 5
- 5.3 Changes from draft-ietf-idn-uri-00 to draft-ietf-idn-uri-01 . 5
- References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Duerst Expires May 4, 2003 [Page 2]
-Internet-Draft IDNs in URIs November 2002
-
-
-1. Introduction
-
- Internet domain names serve to identify hosts and services on the
- Internet in a convenient way. The IETF IDN working group [IDNWG] has
- been working on extending the character repertoire usable in domain
- names beyond a subset of US-ASCII.
-
- One of the most important places where domain names appear are
- Uniform Resource Identifiers (URIs, [RFC2396], as modified by
- [RFC2732]). However, in the current definition of the generic URI
- syntax, the restrictions on domain names are 'hard-coded'. In
- Section 2, this document relaxes these restrictions by updating the
- syntax, and defines how internationalized domain names are encoded in
- URIs.
-
- The syntax in this document has been chosen to further increase the
- uniformity of URI syntax, which is a very important principle of
- URIs.
-
- In practice, escaped domain names should be used as rarely as
- possible. Wherever possible, the actual characters in
- Internationalized Domain Names should be preserved as long as
- possible by using IRIs [IRI] rather than URIs, and only converting to
- URIs and then to ACE-encoded [IDNA] domain names (or ideally directly
- to ACE-encoding without even using URIs) when resolving the IRI.
- Also, this document does not exclude the use of ACE encoding directly
- in an URI domain name part. ACE encoding may be used directly in an
- URI domain name part if this is considered necessary for
- interoperability.
-
- Please note that even with the definition of URIs in [RFC2396], some
- URIs can already contain host names with escaped characters. For
- example, mailto:example@w%33.org is legal per [RFC2396] because the
- mailto: URI scheme does not follow the generic syntax of [RFC2396].
-
-2. URI syntax changes
-
- The syntax of URIs [RFC2396] currently contains the following rules
- relevant to domain names:
-
- hostname = *( domainlabel "." ) toplabel [ "." ]
- domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum
- toplabel = alpha | alpha *( alphanum | "-" ) alphanum
-
-
-
-
-
-
-
-
-Duerst Expires May 4, 2003 [Page 3]
-Internet-Draft IDNs in URIs November 2002
-
-
- The later two rules are changed as follows:
-
- domainlabel = anchar | anchar *( anchar | "-" ) anchar
- toplabel = achar | achar *( anchar | "-" ) anchar
-
- and the following rules are added:
-
- anchar = alphanum | escaped
- achar = alpha | escaped
-
- Characters outside the repertoire (alphanum) are encoded by first
- encoding the characters in UTF-8 [RFC 2279], resulting in a sequence
- of octets, and then escaping these octets according to the rules
- defined in [RFC2396].
-
- Using UTF-8 assures that this encoding interoperates with IRIs [IRI].
- It is also aligned with the recommendations in [RFC2277] and
- [RFC2718], and is consistent with the URN syntax [RFC2141] as well as
- recent URL scheme definitions that define encodings of non-ASCII
- characters based on UTF-8 (e.g., IMAP URLs [RFC2192] and POP URLs
- [RFC2384]).
-
- The above syntax rules permit for domain names that are neither
- permitted as US-ASCII only domain names nor as internationalized
- domain names. However, such domain names should never be used, and
- will never be resolved because no such domains will be registered.
- For US-ASCII only domain names, the syntax rules in [RFC2396] are
- relevant. For example, http://www.w%33.org is legal, because the
- corresponding 'w3' is a legal 'domainlabel' according to [RFC2396].
- However, http://%2a.example.org is illegal because the corresponding
- '*' is not a legal 'domainlabel' according to [RFC2396].
-
- For domain names containing non-ASCII characters, the legal domain
- names are those for which the ToASCII operation ([IDNA], [Nameprep];
- using the unescaped UTF-8 values as input), with the flags
- "UseSTD3ASCIIRules" and "AllowUnassigned" set, is successful. The
- URI resolver MUST apply any steps required as part of domain name
- resolution by [IDNA], in particular the ToASCII operation, with the
- above-mentioned flags set. URIs where the ToASCII operation results
- in an error should be treated as unresolvable.
-
- For domain names containing non-ASCII characters, the Nameprep
- specification ([Nameprep]) defines some mappings, which mainly
- include normalization to NFKC and folding to lower case. When
- encoding an internationalized domain name in an URI, these mappings
- SHOULD NOT be applied. It should be assumed that the domain name is
- already normalized as far as appropriate.
-
-
-
-
-Duerst Expires May 4, 2003 [Page 4]
-Internet-Draft IDNs in URIs November 2002
-
-
- For consistency in comparison operations and for interoperability
- with older software, the following should be noted: 1) US-ASCII
- characters in domain names should not be escaped. 2) Because of the
- principle of syntax uniformity for URIs, it is always more prudent to
- take into account the possibility that US-ASCII characters are
- escaped.
-
-3. Security considerations
-
- The security considerations of [RFC2396] and those applying to
- internationalized domain names apply. There may be an increased
- potential to smuggle escaped US-ASCII-based domain names across
- firewalls, although because of the uniform syntax principle for URIs,
- such a potential is already existing.
-
-4. Acknowledgements
-
- Erik Nordmark
-
-5. Change Log
-
-5.1 Changes from draft-ietf-idn-uri-02 to draft-ietf-idn-uri-03
-
- Clarified expectations on name checking.
-
-5.2 Changes from draft-ietf-idn-uri-01 to draft-ietf-idn-uri-02
-
- Moved change log to back
-
- Changed to only change URIs; IRI syntax updated directly in IRI
- draft.
-
- Removed syntax restriction on %hh in the US-ASCII part, but made
- clear that restrictions to domain names apply.
-
- Made clear that escaped domain names in URIs should only be an
- intermediate representation.
-
- Gave example of mailto: as already allowing escaped host names.
-
- Corrected some typos.
-
-5.3 Changes from draft-ietf-idn-uri-00 to draft-ietf-idn-uri-01
-
- Changed requirement for URI/IRI resolvers from MUST to SHOULD
-
- Changed IRI syntax slightly (ichar -> idchar, based on changes in
- [IRI])
-
-
-
-Duerst Expires May 4, 2003 [Page 5]
-Internet-Draft IDNs in URIs November 2002
-
-
- Various wording changes
-
-References
-
- [IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
- "Internationalizing Domain Names in Applications (IDNA)",
- draft-ietf-idn-idna-14.txt (work in progress), October
- 2002, <http://www.ietf.org/internet-drafts/draft-ietf-
- idn-idna-14.txt>.
-
- [IDNWG] "IETF Internationalized Domain Name (idn) Working Group".
-
- [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
- Identifiers (IRI)", draft-duerst-iri-02.txt (work in
- progress), November 2002, <http://www.ietf.org/internet-
- drafts/draft-duerst-iri-02.txt>.
-
- [ISO10646] International Organization for Standardization,
- "Information Technology - Universal Multiple-Octet Coded
- Character Set (UCS) - Part 1: Architecture and Basic
- Multilingual Plane", ISO Standard 10646-1, October 2000.
-
- [Nameprep] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
- Profile for Internationalized Domain Names", draft-ietf-
- idn-nameprep-11.txt (work in progress), June 2002,
- <http://www.ietf.org/internet-drafts/draft-ietf-idn-
- nameprep-11.txt>.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
-
- [RFC2192] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
-
- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
- Languages", BCP 18, RFC 2277, January 1998.
-
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
-
- [RFC2384] Gellens, R., "POP URL Scheme", RFC 2384, August 1998.
-
- [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
- Resource Identifiers (URI): Generic Syntax", RFC 2396,
- August 1998.
-
- [RFC2640] Curtin, B., "Internationalization of the File Transfer
-
-
-
-Duerst Expires May 4, 2003 [Page 6]
-Internet-Draft IDNs in URIs November 2002
-
-
- Protocol", RFC 2640, July 1999.
-
- [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
- "Guidelines for new URL Schemes", RFC 2718, November
- 1999.
-
- [RFC2732] Hinden, R., Carpenter, B. and L. Masinter, "Format for
- Literal IPv6 Addresses in URL's", RFC 2732, December
- 1999.
-
-
-Author's Address
-
- Martin Duerst
- World Wide Web Consortium
- 200 Technology Square
- Cambridge, MA 02139
- U.S.A.
-
- Phone: +1 617 253 5509
- Fax: +1 617 258 5999
- EMail: duerst@w3.org
- URI: http://www.w3.org/People/D%C3%BCrst/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Duerst Expires May 4, 2003 [Page 7]
-Internet-Draft IDNs in URIs November 2002
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Duerst Expires May 4, 2003 [Page 8]
+++ /dev/null
-Internet Engineering Task Force (IETF) Mark Welter
-INTERNET-DRAFT Brian W. Spolarich
-draft-ietf-idn-utf6-00 WALID, Inc.
-November 16, 2000 Expires May 16, 2001
-
-
- UTF-6 - Yet Another ASCII-Compatible Encoding for IDN
-
-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 is
-proposed as a potential candidate for an ASCII-Compatible Encoding (ACE)
-for supporting the deployment of an internationalized Domain Name System.
-The tranformation method, an extension of the UTF-5 encoding proposed by
-Duerst, provides both for more efficient representation of typical Unicode
-sequences while preserving simplicity and readability. This transformation
-method is deployed as part of the current WALID multilingual domain name
-system implementation, although that status should not necessarily influence
-the evaluation of its merits as a candidate encoding method.
-
-
-Table of Contents
-
-1. Introduction
-1.1 Terminology
-2. Hostname Part Transformation
-2.1 Post-Converted Name Prefix
-2.2 Hostname Prepartion
-2.3 Definitions
-2.4 UTF-6 Encoding
-2.4.1 Variable Length Hex Encoding
-2.4.2 UTF-6 Compression Algorithm
-2.4.3 Forward Transformation Algorithm
-2.5 UTF-6 Decoding
-2.5.1 Variable Length Hex Decoding
-2.5.2 UTF-6 Decompression Algorithm
-2.5.3 Reverse Transformation Algorithm
-3. Examples
-3.1 'www.walid.com' (in Arabic)
-4. Security Considerations
-5. References
-
-
-1. Introduction
-
-UTF-6 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".
-
-UTF-6 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 be case-insensitive, 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 'wq--' as a prefix to identify
-UTF-6-encoded sequences. For the purposes of comparison in the IDN
-Working Group activities, the 'wq--' prefix should be used solely to
-identify UTF-6 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 heirarchy. 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 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 UTF-6
-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 s
-separate, independent issues, which we will attempt to address in a
-separate document.
-
-2.3 Definitions
-
-For clarity:
-
- 'integer' is an unsigned binary quantity;
- 'byte' is an 8-bit integer quantity;
- 'nibble' is a 4-bit integer quantity.
-
-2.4 UTF-6 Encoding
-
-The idea behind this scheme was to improve on the UTF-5 transformation
-algorithm described in [IDNDUERST] by providing a straightforward
-compression mechanism. UTF-6 defines a compression mechanism by
-indentifying identical leading byte or nibble values in the pre-converted
-string, and using the length of this leading value to select a mask which
-can be applied to the pre-converted string. The resulting post-converted
-string is preserves the simplicity and readability of UTF-5 while
-enabling longer sequences to be encoded into a single host name part.
-
-2.4.1 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.
-
-The variable length nibble encoding of an integer, C, is defined
-as follows:
-
- 1. Skip over leading non-significant zero nibbles to find I,
- the first significant nibble of c;
-
- 2. Emit the Ith character of the set [ghijklmopqrstuv];
-
- 3. Continue from most to least significant, encoding each remaining
- nibble J by emitting the Jth character of the set [0123456789abcdef].
-
-Examples:
-
- 0x1f4c is encoded as "hf4c"
- 0x0624 is encoded as "m24"
- 0x0000 is encoded as "g"
- 'n' a single character in single quotes stands for the
- Unicode code point for that character.
-
-2.4.2 UTF-6 Compression Algorithm
-
-UTF-6 improves on the UTF-5 encoding by providing compression, which
-enables encoding of a larger number of characters in each hostname
-part. The compression algorithm is defined as follows:
-
- 1. Set the mask to 0xFFFF;
-
- 2. If the number of non '-' characters is less than 2, proceed to
- step 5;
-
- 3. If the most significant byte of every non '-' character is the
- same value:
-
- 3a. Set HB to this value;
- 3b. Emit 'Y';
- 3c. Emit the variable length hex encoding of HB;
- 3d. Set the mask to 0x00FF;
- 3e. Proceed to step 5.
-
- 4. If the most significant nibble of every non '-' character is the
- same value:
-
- 4a. Set HN to this value;
- 4b. Emit 'Z';
- 4c. Emit the variable length hex encoding of HN;
- 4d. Set the mask to 0x0FFF.
-
- 5. Foreach input character:
-
- 5a. Set HN to the result of the bitwise AND of the input
- character and the mask;
- 5b. Emit the variable length nibble encoding of HN.
-
-2.4.3 Forward Transformation Algorithm
-
-The UTF-6 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, perform steps 2 and 3 below;
-
- 2. Compress the component using the method described in section
- 2.4.2 above, and encode using the encoding described in section 2.4.1;
-
- 3. Prepend the post-converted name prefix 'wq--' (see section 2.1
- above) to the resulting string.
-
-
-2.5 UTF-6 Decoding
-
-2.5.1 Variable Length Hex Decoding
-
- 1. Let N be the lower case of the first input character;
-
- If N is not in set [ghijklmnopqrstuv] return error,
- else consume the input character;
-
- 2. Let R = N - 'g';
-
- 3. If another input character exists,
- then let N be the lower case of the next input character,
- else goto Step 9;
-
- 4. If N is not in the set [0123456789abcdef], go to Step 9;
-
- 5. Let N = the lower case of the next input character and consume
- the input character;
-
- 6. 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. Return decoded result R.
-
-2.5.2 UTF-6 Decompression Algorithm
-
- 1. Let N be the lower case of the first input character;
-
- 2. If N != 'y' and N != 'z',
-
- 2a. Let CPART be 0;
- 2b. Let VMAX be 0xFFFF;
-
- This is the no-compression case;
-
- 3. If N == 'y',
-
- 3a. Let M be the variable length hex decoding of the next
- character;
- 3b. Let CPART be the result of M * 0x0100;
- 3c. Let VMAX be 0x00FF;
- 3d. Continue to Step 5;
-
- 4. If N == 'z',
-
- 4a. Let M be the variable length hex decoding of the next
- character;
- 4b. Let CPART be the result of M * 0x1000;
- 4c. Let VMAX be 0x0FFF;
- 4d. Continue to Step 5;
-
- 5. While another input character exists, let N be the lower case of
- the next input character, and do the following:
-
- 5a. If N == '-' consume the character and
- then append '-' to the result string,
- else let VPART be the next variable hex decoded value;
- 5b. If VPART > VMAX, return error,
- else append CPART + VPART to the result string;
-
- 6. Return the result string.
-
-2.5.3 Reverse Transformation Algorithm
-
- 1. Break the string into dot-separated components and apply Steps
- 2 through 4 to each component:
-
- 2. Check for legality (in terms of RFC1035 permitted characters) and
- return error status if illegal,
-
- 3. Remove the post converted name prefix 'wq--' (see Section 2.1),
-
- 4. Decompress the component using the decompression algorithm
- described above.
-
- 5. 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
-
- 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
-
-
-3.2 Mixed Katakana and Hiragana (SOREZORENOBASHO)
-
- UTF-16: U+305D U+308C U+305E U+308C U+306E U+5834 U+6240
-
- UTF-6:
-
- UTF-5:
-
- RACE: bq--4ayf3memgbpdbdbqnzmdiysa
-
- LACE: bq--auyf4dc7rrxacwbuafrea
-
-
-3.3 Currently Disallowed ASCII Characters ($OneBillionDollars!):
-
- UTF-16: U+0024 U+004F U+006E U+0065 U+0042 U+0069 U+006C U+006C
- U+0069 U+006F U+006E U+0044 U+006F U+006C U+006C U+0061
- U+0072 U+0073 U+0021
-
- UTF-6:
-
- UTF-5:
-
- RACE: bq--aase74tfijuwy4djn6xei44mnrqxe5zb
-
- LACE: bq--cmacit4omvbgs4dmnfxw5rdpnrwgc5ttee
-
-4. 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 UTF-6 makes no changes to the DNS itself.
-
-UTF-6 is designed so that distinct Unicode sequences map to distinct
-domain name sequences (modulo the Unicode and DNS equivalence rules).
-Therefore use of UTF-6 with DNS will not negatively affect security.
-
-5. References
-
-[IDNCOMP] Paul Hoffman, "Comparison of Internationalized Domain Name
-Proposals", draft-ietf-idn-compare.
-
-[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)
-by Mark Davis and Paul Hoffman.
-
-The 'SOREZORENOBASHO' example was taken from draft-ietf-idn-brace draft
-by Adam Costello.
-
-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
-
-iD8DBQE6FaCt/DkPcNgtD/0RAtRmAJwISVeJGY6qmll71mL+Axc51o8iIwCgmNt/
-86RcQh1JQYWTux+8FS+XvMU=
-=bxiv
------END PGP SIGNATURE-----
-
+++ /dev/null
-Internet Draft Marc Blanchet
-
-draft-ietf-idn-version-00.txt Viagenie
-October 26, 2000
-Expires in six
-months
-
-
-
-
- Handling versions of internationalized domain names protocols
-
-
-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 some issues related to handling changes in the
-codepoints and other features in the chars space of an internationalized
-domain name as well as changes in the protocol that supports it (whatever
-that be). It also presents some solutions to these issues.
-
-
-1. Rationale
-
-The nameprep draft [NAMEPREP] is defining prohibited chars, normalization
-algorithms, etc.. The current concensus is to take the safer approach of
-not accepting new chars if they are not listed, since the new characters
-that can be included in the subsequent releases of the universal character
-set can have an impact on the domain name (for example, a new variation of
-the dot . will mostly be non-compatible and being excluded).
-
-The Unicode and ISO-10646 versioning is designed not for the same purpose
-as the idn work: for example, some chars or properties can be changed or
-added to those repertoires that cannot be taken as is by the idn
-protocol. In essence, the idn nameprep versions cannot be in sync with
-unicode/iso versions. idn need its own versioning of the accepted character
-set, which can or cannot be synchronized with the two others. While saying
-that, there is no intent at all to define new codepoints inside this work
-and any attempt to do that must be rejected.
-
-Since internationalization and specifically internationalization of the
-domain names is new, we don't really know if the chosen algorithm, protocol
-and codepoitns will not have any problem in the future. We need to handle
-versions of the protocol and to have a specific table for idn accepted chars.
-
-2. Versioning of the protocol
-
-Since the idn table of chars will be changed in the future, and possibly
-the algorithms and the processing, then there is a need to handle these
-situations in a controlled way. A version of the idn protocol should be
-defined and included as part of the exchange between the parties so that
-they can handle smoothly the new revisions.
-
-2.1 Implementing the version in the protocol
-Depending on which way the idn protocol will be, a different versioning
-will have to be defined. We will discuss the current proposals and identify
-where a versioning system can be handled.
-
-2.1.1 Proposals based on extensions of the DNS protocol
- Proposals based on extensions of the DNS protocol should include in the
-bits the version number and a way to exchange version numbers between the
-parties. [IDNE] already defined a version number as part of the use of
-EDNS. Similar versioning should be defined in the other proposed protocols.
-
-2.1.2 Proposals based on ACE and application
- Since ACEs (for example [RACE]) in applications [IDNA] do not change the
-DNS protocol but only encode the idn in a ascii compatible way, it looks
-more difficult to include a version number in the ACE encoding, since it
-will change the domain name. The proposal is to use a different
-prefix/suffix for each version, by using one of the chars used in the
-prefix as a version number, beginning with the lowest possible ascii char
-available and increase the ascii codepoint of the char by 1 for each
-version. For example, if the prefix is "ra--", then the first version of
-idn will be "ra--", the second version will be "rb--", the third "rc--".
-While this would be more elegant, one can handle versioning by having
-different prefixes for each version, while chosing prefixes randomly (i.e.
-1st version: rq--, 2nd version: wz--, ...). IANA should block all possible
-prefixes so that no pre-registration is permitted.
-
-2.2 Major and minor version numbers
-
- A <major>.<minor> version number is proposed (i.e. 1.0, 1.1, 2.0). A
-minor revision is defined to be as new chars or small changes in the table
-to be handled without any modification of algorithm. The idea here is to
-enable easy upgrading of idn processors when only new chars will be
-handled. In this case, the binary software do not have to be changed and
-only the table containing the chars has to be changed to enable a new
-version. A major revision means that the software has to be upgraded since
-it implies new ways of handling idn which are not identified in the table.
-
-2.3 Processing of the version numbers
-Any idn processor MUST verify the version number before processing. When a
-major version number is higher than what the processor currently handle is
-detected, processing MUST be stopped and rejected. When a minor version
-number is higher than what the processor currently handle, then any
-intermediate processors MUST forward the idn but the end processor (i.e.
-the dns server authoritative for that zone that is handling the request)
-MUST stop and reject the request. Specific handling of rejecting the
-request should be defined in the protocol document.
-
-2.4 Version numbers
- Version numbers of the idn protocol will be handled by IANA. A
-IESG-reviewed document should be used as the basis for IANA to define a new
-protocol version number.
-
-3. Idn table
- Since the unicode consortium and ISO will issue new versions not at the
-same time as the idn protocol versioning, the IETF need to have its own
-registered table of accepted idn chars. This will also enable specific data
-only useful for idn. The intent is not to duplicate the unicode/iso effort,
-it is to support the specific needs of the idn group. For example, it is
-possible that specific chars will have a different behavior than the normal
-Unicode way: the special casing for final or non-final letters in the
-Unicode SpecialCasing.txt file can be merged (ie not totally identical to
-the unicode processing) to only one casing since final and non-final
-letters have less meaning in a domain name. Simpler processing for idn is
-also useful: for example, the Lud property is probably not useful in the
-idn context and can be considered equivalent to Lu. Combining those
-properties together means much simple table and simpler processing and less
-errors in implementations. Added chars, codepoint, properties MUST NOT be
-done in this file, but must be done within the Unicode/ISO process.
-
-This document proposes a table contained in an ascii file handled by IANA
-and available in the IANA public directory. The source of the table will be
-the Unicode table, with a similar format, but a simpler, and perhaps
-different, content based on the needs of the idn protocol. Proposed
-filename is: idntab.txt.
-
-This file format will also help implementors to have the same input
-description and exhaustive list of which chars and processing to handle
-idn. This is easier for implementors to have a complete list of accepted
-chars instead a list of non-accepted chars. The hope is also to help
-decrease the different behaviors between the different implementations.
-This table can be considered as an implementation of [NAMEPREP].
-
-3.1 File format
-
-The file is divided in two parts. The first part contains variables. The
-second part contains all the chars accepted for idn. The two parts are
-separated by a empty line.
-
-The format of the first part is:
-tag=value<CR><LF>
-
-Currently, only the version tag is defined. The "version" tag defines the
-highest idn version number that can be found in this table. The intent is
-to have only one file that is kept current but where the beginning of the
-file can be used by parsers to identify the latest version of the file.
-
-The first idntab.txt file will define version=1.0:
-version=1.0<CR><LF>
-
-The format of the second part is:
- one codepoint per line
- lines separated by CR/LF
- each field in the line separated by ";"
-
-The fields are (in order, from left to right):
- 1. codepoint in hexadecimal (as in unicode table): HHHH
- 2. first version of idn table that this char is supported
-
-It is possible that new fields will be added in the future. Parsers should
-ignore the fields that they don't understand.
-
-Spaces (ascii 0x20) are ignored. Comments are identified by "#". All text
-following the comment char up to the end of line is ignored. Any codepoint
-not in the table is considered prohibited. Codepoints that are prohibited
-may be included in the table inside commented lines in order to help a
-reader to see explicitly which ones are prohibited.
-
-Example of the file idntab10.txt:
-version=1.0<CR><LF>
-<CR><LF>
-0041;1.0;
-
-4. Security Considerations
-
-Changing the way a software react about domain names is clearly something
-that have security impacts. While the actual table doesn't present any
-security threat by itself, if there is someways by a intruder to reload a
-new table into a idn processor software without the knowledge of the user,
-then it can completly disables name resolution or have other possible
-threats. In conclusion, care must be taken by software developers on how
-to manage the insertion of a new idn table in a idn processor software.
-
-5. IANA Considerations
- This document describes versions of the idn file called idntab.txt. The
-file should be kept in the IANA public directory for references purposes.
-New versions of the file should be made available after IESG review of a
-document. Old revisions of the file (idntab-xy.txt) should be kept for
-documentation purposes.
-
-6. Acknowledgements
- The author would like to acknowledge the comments and idea of the
-following people: Fran\87ois Yergeau and Paul Hoffman.
-
-7. Author
-
-Marc Blanchet
-Viagenie
-2875 boul. Laurier, bur. 300
-Ste-Foy, Quebec, Canada
-G1V 2M2
-Marc.Blanchet@viagenie.qc.ca
-tel: 418-656-9254
-
-8. References
-
-[NAMEPREP] Preparation of Internationalized Host Names, Paul Hoffman, Marc
-Blanchet. Work in progress.
-
-[RACE] RACE: Row-based ASCII Compatible Encoding for IDN, Paul Hoffman.
-Work in progress.
-
-[IDNA] Internationalizing Host Names In Applications (IDNA), Paul Hoffman,
-Patrick Falstrom. Work in progress.
-
-
-Marc Blanchet
-Viag\89nie inc.
-tel: 418-656-9254
-http://www.viagenie.qc.ca
-
-----------------------------------------------------------
-Normos (http://www.normos.org): Internet standards portal:
-IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place.
-
+++ /dev/null
-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, '\98\82' that means 'century' in English
-language, is transliterated into 'segi' in English scripts, and so, the entity
-whose name contains '\98\82' in Korean language may have an entity-defined portion
-of its domain name as 'segi' in English scripts. VIDN enables to use '\98\82' 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 '\98\82' in Korean scripts have the same sounds as the
-phonemes represented by the characters consisting of 'segi' in English scripts.
-In the local context, '\98\82' 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, '¾\9e®ý', is
-transliterated into 'yahoo' in English scripts, since the phonemes represented
-by the characters consisting of '¾\9e®ý' in Korean scripts have the same sounds as
-the phonemes represented by the characters consisting of 'yahoo' in English
-scripts. That is, '¾\9e®ý' in Korean scripts is pronounced as the same as 'yahoo'
-in English scripts, and so, it is easy for Korean-speaking people to deduce '¾\9e
-®ý' 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., '\98\82' in Korean scripts, as well as
-domain names whose originals are in English scripts, e.g., '¾\9e®ý' 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 'ýý', '
-Àí´\80', '\97\8d¦\8a', 'ÁðË«', ' Ï', 'þÚË«', 'ÀÁ\98Ú' 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 '\98\82¾\95'
-(meaning 'commercial' in Korean language), 'ÌÏ\98þ' (meaning 'education' in Korean
-language), 'Âñ¦ð' (meaning 'government' in Korean language), '\98 ª' (meaning
-'international' in Korean language), '\98¦À\8b' (meaning 'military' in Korean
-language), 'þÚË«' (meaning 'network' in Korean language), and '³\9bÈ' (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, 'Â\9e¾Ô.ýý', 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 'Â\9e¾Ô.ýý' 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 'Â\9e¾Ô.ýý' 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., 'Â\9e¾Ô.ýý' | | 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
-
+++ /dev/null
-
-
-IPng Working Group Richard Draves
-Internet Draft Microsoft Research
-Document: draft-ietf-ipngwg-default-addr-select-05.txt June 4, 2001
-Category: Standards Track
-
- Default Address Selection for IPv6
-Status of this Memo
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026 [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.
-Abstract
- This document describes two algorithms, for source address selection
- and for destination address selection. The algorithms specify
- default behavior for all IPv6 implementations. They do not override
- choices made by applications or upper-layer protocols, nor do they
- preclude the development of more advanced mechanisms for address
- selection. The two algorithms share a common framework, including an
- optional mechanism for allowing administrators to provide policy
- that can override the default behavior. In dual stack
- implementations, the framework allows the destination address
- selection algorithm to consider both IPv4 and IPv6 addresses -
- depending on the available source addresses, the algorithm might
- prefer IPv6 addresses over IPv4 addresses, or vice-versa.
- All IPv6 nodes, including both hosts and routers, must implement
- default address selection as defined in this specification.
-1. Introduction
- The IPv6 addressing architecture [2] allows multiple unicast
- addresses to be assigned to interfaces. These addresses may have
- different reachability scopes (link-local, site-local, or global).
- These addresses may also be "preferred" or "deprecated" [3]. Privacy
- considerations have introduced the concepts of "public addresses"
-
-Draves Standards Track - Expires January 2002 1 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- and "temporary addresses" [4]. The mobility architecture introduces
- "home addresses" and "care-of addresses" [5]. In addition, multi-
- homing situations will result in more addresses per node. For
- example, a node may have multiple interfaces, some of them tunnels
- or virtual interfaces, or a site may have multiple ISP attachments
- with a global prefix per ISP.
- The end result is that IPv6 implementations will very often be faced
- with multiple possible source and destination addresses when
- initiating communication. It is desirable to have default
- algorithms, common across all implementations, for selecting source
- and destination addresses so that developers and administrators can
- reason about and predict the behavior of their systems.
- Furthermore, dual or hybrid stack implementations, which support
- both IPv6 and IPv4, will very often need to choose between IPv6 and
- IPv4 when initiating communication. For example, when DNS name
- resolution yields both IPv6 and IPv4 addresses and the network
- protocol stack has available both IPv6 and IPv4 source addresses. In
- such cases, a simple policy to always prefer IPv6 or always prefer
- IPv4 can produce poor behavior. As one example, suppose a DNS name
- resolves to a global IPv6 address and a global IPv4 address. If the
- node has assigned a global IPv6 address and a 169.254/16 auto-
- configured IPv4 address [6], then IPv6 is the best choice for
- communication. But if the node has assigned only a link-local IPv6
- address and a global IPv4 address, then IPv4 is the best choice for
- communication. The destination address selection algorithm solves
- this with a unified procedure for choosing among both IPv6 and IPv4
- addresses.
- This document specifies source address selection and destination
- address selection separately, but using a common framework so that
- together the two algorithms yield useful results. The algorithms
- attempt to choose source and destination addresses of appropriate
- scope and configuration status (preferred or deprecated).
- Furthermore, this document suggests a preferred method, longest
- matching prefix, for choosing among otherwise equivalent addresses
- in the absence of better information.
- The framework also has policy hooks to allow administrative override
- of the default behavior. For example, using these hooks an
- administrator can specify a preferred source prefix for use with a
- destination prefix, or prefer destination addresses with one prefix
- over addresses with another prefix. These hooks give an
- administrator flexibility in dealing with some multi-homing and
- transition scenarios, but they are certainly not a panacea.
- The selection rules specified in this document MUST NOT be construed
- to override an application or upper-layer's explicit choice of a
- legal destination or source address.
-
-Draves Standards Track - Expires January 2002 2 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
-1.1. 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 [7].
-2. Framework
- Our framework for address selection derives from the most common
- implementation architecture, which separates the choice of
- destination address from the choice of source address. Consequently,
- the framework specifies two separate algorithms for these tasks. The
- algorithms are designed to work well together and they share a
- mechanism for administrative policy override.
- In this implementation architecture, applications use APIs [8] like
- getaddrinfo() that return a list of addresses to the application.
- This list might contain both IPv6 and IPv4 addresses (sometimes
- represented as IPv4-mapped addresses). The application then passes a
- destination address to the network stack with connect() or sendto().
- The application might use only the first address in the list, or it
- might loop over the list of addresses to find a working address. In
- any case, the network layer is never in a situation where it needs
- to choose a destination address from several alternatives. The
- application might also specify a source address with bind(), but
- often the source address is left unspecified. Therefore the network
- layer does often choose a source address from several alternatives.
- As a consequence, we intend that implementations of getaddrinfo()
- will use the destination address selection algorithm specified here
- to sort the list of IPv6 and IPv4 addresses that they return.
- Separately, the IPv6 network layer will use the source address
- selection algorithm when an application or upper-layer has not
- specified a source address. Application of this framework to source
- address selection in an IPv4 network layer may be possible but this
- is not explored further here.
- Well-behaved applications should iterate through the list of
- addresses returned from getaddrinfo() until they find a working
- addresses.
- The algorithms use several criteria in making their decisions. The
- combined effect is to prefer destination/source address pairs for
- which the two addresses are of equal scope or type, prefer smaller
- scopes over larger scopes for the destination address, prefer non-
- deprecated source addresses, avoid the use of transitional addresses
- when native addresses are available, and all else being equal prefer
- address pairs having the longest possible common prefix. For source
- address selection, public addresses [4] are preferred over temporary
- addresses. In mobile situations [5], home addresses are preferred
- 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
-
-Draves Standards Track - Expires January 2002 3 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- over addresses that are solely a home address or solely a care-of
- address.
- 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
- 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
- used.
-2.1. Scope Comparisons
- Multicast destination addresses have a 4-bit scope field that
- controls the propagation of the multicast packet. The IPv6
- addressing architecture defines scope field values for interface-
- local (0x1), link-local (0x2), subnet-local (0x3), admin-local
- (0x4), site-local (0x5), organization-local (0x8), and global (0xE)
- scopes [9].
- Use of the source address selection algorithm in the presence of
- multicast destination addresses requires the comparison of a unicast
- address scope with a multicast address scope. We map unicast link-
- local to multicast link-local, unicast site-local to multicast site-
- local, and unicast global scope to multicast global scope. For
- example, unicast site-local is equal to multicast site-local, which
- is smaller than multicast organization-local, which is smaller than
- unicast global, which is equal to multicast global.
- We write Scope(A) to mean the scope of address A. For example, if A
- is a link-local unicast address and B is a site-local multicast
- address, then Scope(A) < Scope(B).
- This mapping implicitly conflates unicast site boundaries and
- multicast site boundaries [9].
-2.2. IPv4 Addresses and IPv4-Mapped Addresses
- The destination address selection algorithm operates on both IPv6
- and IPv4 addresses. For this purpose, IPv4 addresses should be
- represented as IPv4-mapped addresses [2]. For example, to lookup the
- precedence or other attributes of an IPv4 address in the policy
- table, lookup the corresponding IPv4-mapped IPv6 address.
- IPv4 addresses are assigned scopes as follows. IPv4 auto-
- configuration addresses [6], which have the prefix 169.254/16, are
- assigned link-local scope. IPv4 private addresses [10], which have
- the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site-
- local scope. IPv4 loopback addresses [11, section 4.2.2.11], which
- have the prefix 127/8, are assigned link-local scope (analogously to
- the treatment of the IPv6 loopback address [9, section 4]). Other
- IPv4 addresses are assigned global scope.
-
-Draves Standards Track - Expires January 2002 4 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- IPv4 addresses should be treated as having "preferred" configuration
- status.
-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 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 [9, section 4] and "preferred" configuration status.
- 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 supersede 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 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
- has higher precedence than address B, meaning that our algorithm
- will prefer to sort destination address A before destination address
- B.
- 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
- here. If an implementation is not configurable or has not been
- configured, then it SHOULD operate according to the algorithms
- specified here in conjunction with the following default policy
- table:
- Prefix Precedence Label
- ::1/128 50 0
- ::/0 40 1
- 2002::/16 30 2
- ::/96 20 3
- ::ffff:0:0/96 10 4
-
-Draves Standards Track - Expires January 2002 5 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
-
- 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
- effect of the default policy table is to prefer communication using
- IPv6 addresses to communication using IPv4 addresses, if matching
- source addresses are available.
- Policy table entries for scoped address prefixes MAY be qualified
- with an optional zone index. If so, a prefix table entry only
- matches against an address during a lookup if the zone index also
- matches the address's zone index.
-2.6. Common Prefix Length
- We define the common prefix length CommonPrefixLen(A, B) of two
- addresses A and B as the length of the longest prefix (looking at
- the most significant, or leftmost, bits) that the two addresses have
- in common. It ranges from 0 to 128.
-3. Candidate Source Addresses
- The source address selection algorithm uses the concept of a
- "candidate set" of potential source addresses for a given
- destination address. We write CandidateSource(A) to denote the
- candidate set for the address A.
- It is RECOMMENDED that the candidate source addresses be the set of
- unicast addresses assigned to the interface that will be used to
- send to the destination. (The "outgoing" interface.) On routers, the
- candidate set MAY include unicast addresses assigned to any
- interface that forwards packets, subject to the restrictions
- described below.
- Discussion: The Neighbor Discovery Redirect mechanism [13]
- requires that routers verify that the source address of a packet
- identifies a neighbor before generating a Redirect, so it is
- advantageous for hosts to choose source addresses assigned to the
- outgoing interface. Implementations that wish to support the use
- of global source addresses assigned to a loopback interface should
- behave as if the loopback interface originates and forwards the
- packet.
- In some cases the destination address may be qualified with a zone
- index or other information that will constrain the candidate set.
- For multicast and link-local destination addresses, the set of
- candidate source addresses MUST only include addresses assigned to
- interfaces belonging to the same link as the outgoing interface.
-
-Draves Standards Track - Expires January 2002 6 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- Discussion: The restriction for multicast destination addresses is
- necessary because currently-deployed multicast forwarding
- algorithms use Reverse Path Forwarding (RPF) checks.
- For site-local destination addresses, the set of candidate source
- addresses MUST only include addresses assigned to interfaces
- belonging to the same site as the outgoing interface.
- In any case, anycast addresses, multicast addresses, and the
- unspecified address MUST NOT be included in a candidate set.
- If an application or upper-layer specifies a source address that is
- not in the candidate set for the destination, then the network layer
- MUST treat this is an error. The specified source address may
- influence the candidate set, by affecting the choice of outgoing
- interface. If the application or upper-layer 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 the network layer uses
- the source address selection algorithm specified in the next
- section.
- Discussion:
-4. Source Address Selection
- The source address selection algorithm chooses a source address for
- use with a destination address D. It is specified here in terms of
- the pair-wise comparison of addresses SA and SB. The pair-wise
- comparison can be used to select an address from the set
- CandidateSource(D).
- This source address selection algorithm only applies to IPv6
- destination addresses, not IPv4 addresses.
- The pair-wise comparison consists of eight rules, which should be
- applied in order. If a rule chooses an address, then the remaining
- rules are not relevant and should be ignored. Subsequent rules act
- as tie-breakers for earlier rules. If the eight rules fail to choose
- an address, some unspecified tie-breaker should be used.
- Rule 1: Prefer same address.
- 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
- and otherwise choose SA.
- Similarly, if Scope(SB) < Scope(SA): If Scope(SB) < Scope(D), then
- choose SA and otherwise choose SB.
-
-Draves Standards Track - Expires January 2002 7 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- Rule 3: Avoid deprecated addresses.
- The addresses SA and SB have the same scope. If one of the source
- addresses is "preferred" and one of them is "deprecated", choose the
- one that is preferred.
- Rule 4: Prefer home addresses.
- 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.
- Rule 5: Prefer outgoing interface.
- If SA is assigned to the interface that will be used to send to D
- and SB is assigned to a different interface, then prefer SA.
- Similarly, if SB is assigned to the interface that will be used to
- send to D and SA is assigned to a different interface, then prefer
- SB.
- 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 public addresses.
- If SA is a public address and SB is a temporary address, then prefer
- SA. Similarly, if SB is a public address and SA is a temporary
- 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 temporary addresses over public
- addresses.
- This rule avoids applications potentially failing due to the
- relatively short lifetime of temporary addresses or due to the
- possibility of the reverse lookup of a temporary address either
- failing or returning a randomized name. Implementations for which
- privacy considerations outweigh these application compatibility
- concerns MAY reverse the sense of this rule and by default prefer
- temporary addresses over public addresses.
- Rule 8: Use longest matching prefix.
- If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then choose SA.
- Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then
- choose SB.
- Rule 8 may be superseded if the implementation has other means of
- choosing among source addresses. For example, if the implementation
-
-Draves Standards Track - Expires January 2002 8 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- somehow knows which source address will result in the "best"
- communications performance.
- Rule 2 (prefer appropriate scope) MUST be implemented and given high
- priority because it can affect interoperability.
-5. Destination Address Selection
- The destination address selection algorithm takes a list of
- destination addresses and sorts the addresses to produce a new list.
- It is specified here in terms of the pair-wise comparison of
- addresses DA and DB, where DA appears before DB in the original
- list.
- The algorithm sorts together both IPv6 and IPv4 addresses. To find
- the attributes of an IPv4 address in the policy table, the IPv4
- address should be represented as an IPv4-mapped address.
- We write Source(D) to indicate the selected source address for a
- destination D. For IPv6 addresses, the previous section specifies
- the source address selection algorithm. Source address selection for
- IPv4 addresses is not specified in this document.
- We say that Source(D) is undefined if there is no source address
- available for destination D. For IPv6 addresses, this is only the
- case if CandidateSource(D) is the empty set.
- The pair-wise comparison of destination addresses consists of nine
- rules, which should be applied in order. If a rule determines a
- result, then the remaining rules are not relevant and should be
- ignored. Subsequent rules act as tie-breakers for earlier rules.
- Rule 1: Avoid unusable destinations.
- If there is no route to DB or the current next-hop neighbor for DB
- is known to be unreachable or if Source(DB) is undefined, then sort
- DA before DB. Similarly, if there is no route to DA or the current
- next-hop neighbor for DA is known to be unreachable or if Source(DA)
- is undefined, then sort DB before DA.
- For IPv6 destination addresses, the
- 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))
- and Scope(DB) = Scope(Source(DB)), then sort DB before DA.
- Rule 3: Avoid deprecated addresses.
- If Source(DA) is deprecated and Source(DB) is not, then sort DB
- before DA. Similarly, if Source(DA) is not deprecated and Source(DB)
- is deprecated, then sort DA before DB.
-
-Draves Standards Track - Expires January 2002 9 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- Rule 4: Prefer home addresses.
- 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 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.
- Similarly, if Precedence(DA) < Precedence(DB), then sort DB before
- DA.
- Rule 7: Prefer smaller scope.
- If Scope(DA) < Scope(DB), then sort DA before DB. Similarly, if
- Scope(DA) > Scope(DB), then sort DB before DA.
- Rule 8: Use longest matching prefix.
- If CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB,
- Source(DB)), then sort DA before DB. Similarly, if
- CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)),
- then sort DB before DA.
- Rule 9: Otherwise, leave the order unchanged.
- Sort DA before DB.
- Rules 8 and 9 may be superseded if the implementation has other
- means of sorting destination addresses. For example, if the
- implementation somehow knows which destination addresses will result
- in the "best" communications performance.
-6. Interactions with Routing
- This specification of source address selection assumes that routing
- (more precisely, selecting an outgoing interface on a node with
- multiple interfaces) is done before source address selection.
- However, implementations may use source address considerations as a
- tiebreaker when choosing among otherwise equivalent routes.
- 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
- destination address, if there's no routing reason to prefer one
- interface over the other, then an implementation may preferentially
- choose the outgoing interface that will allow it to use the source
- address that shares a longer common prefix with the destination.
-
-Draves Standards Track - Expires January 2002 10 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- Implementations may also use the choice of router to influence the
- choice of source address. For example, suppose a host is on a link
- with two routers. One router is advertising a global prefix A and
- the other route is advertising global prefix B. Then when sending
- via the first router, the host may prefer source addresses with
- prefix A and when sending via the second router, prefer source
- addresses with prefix B.
-7. Implementation Considerations
- The destination address selection algorithm needs information about
- potential source addresses. One possible implementation strategy is
- for getaddrinfo() to call down to the IPv6 network layer with a list
- of destination addresses, sort the list in the network layer with
- full current knowledge of available source addresses, and return the
- sorted list to getaddrinfo(). This is simple and gives the best
- results but it introduces the overhead of another system call. One
- way to reduce this overhead is to cache the sorted address list in
- the resolver, so that subsequent calls for the same name do not need
- to resort the list.
- Another implementation strategy is to call down to the network layer
- to retrieve source address information and then sort the list of
- addresses directly in the context of getaddrinfo(). To reduce
- overhead in this approach, the source address information can be
- cached, amortizing the overhead of retrieving it across multiple
- calls to getaddrinfo(). In this approach, the implementation may not
- have knowledge of the outgoing interface for each destination, so it
- MAY use a looser definition of the candidate set during destination
- address ordering.
- In any case, if the implementation uses cached and possibly stale
- 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
- 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. 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 potentially stale.
-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
-
-Draves Standards Track - Expires January 2002 11 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- 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.
-9. Examples
- This section contains a number of examples, first of default
- behavior and then demonstrating the utility of policy table
- configuration. These examples are provided for illustrative
- purposes; they should not be construed as normative.
-9.1. Default Source Address Selection
- The source address selection rules, in conjunction with the default
- policy table, produce the following behavior:
- Destination: 2001::1
- Sources: 3ffe::1 vs fe80::1
- Result: 3ffe::1 (prefer appropriate scope)
- Destination: 2001::1
- Sources: fe80::1 vs fec0::1
- Result: fec0::1 (prefer appropriate scope)
- Destination: fec0::1
- Sources: fe80::1 vs 2001::1
- Result: 2001::1 (prefer appropriate scope)
- Destination: ff05::1
- Sources: fe80::1 vs fec0::1 vs 2001::1
- Result: fec0::1 (prefer appropriate scope)
- Destination: 2001::1
- Sources: 2001::1 (deprecated) vs 2002::1
- Result: 2001::1 (prefer same address)
- Destination: fec0::1
- Sources: fec0::2 (deprecated) vs 2001::1
- Result: fec0::2 (prefer appropriate scope)
- Destination: 2001::1
- Sources: 2001::2 vs 3ffe::2
- Result: 2001::2 (longest-matching-prefix)
- Destination: 2001::1
- Sources: 2001::2 (care-of address) vs 3ffe::2 (home address)
- Result: 3ffe::2 (prefer home address)
-
-Draves Standards Track - Expires January 2002 12 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- Destination: 2002:836b:2179::1
- Sources: 2002:836b:2179::d5e3:7953:13eb:22e8 (temporary) vs 2001::2
- Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label)
- Destination: 2001::d5e3:0:0:1
- Sources: 2001::2 vs 2001::d5e3:7953:13eb:22e8 (temporary)
- Result: 2001::2 (prefer public address)
-9.2. Default Destination Address Selection
- The destination address selection rules, in conjunction with the
- default policy table and the source address selection rules, produce
- the following behavior:
- Sources: 2001::2 or fe80::1 or 169.254.13.78
- Destinations: 2001::1 vs 131.107.65.121
- Result: 2001::1 (src 2001::2) then 131.107.65.121 (src
- 169.254.13.78) (prefer matching scope)
- Sources: fe80::1 or 131.107.65.117
- Destinations: 2001::1 vs 131.107.65.121
- Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src
- fe80::1) (prefer matching scope)
- Sources: 2001::2 or fe80::1 or 10.1.2.4
- Destinations: 2001::1 vs 10.1.2.3
- Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer
- higher precedence)
- Sources: 2001::2 or fec0::2 or fe80::2
- 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)
- 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
- Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home
- address)
- Sources: 2001::2 or fec0::2 (deprecated) or fe80::2
- Destinations: 2001::1 vs fec0::1
- Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid
- deprecated addresses)
- Sources: 2001::2 or 3f44::2 or fe80::2
- Destinations: 2001::1 vs 3ffe::1
- Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest
- matching prefix)
- Sources: 2002:836b:4179::2 or fe80::2
- Destinations: 2002:836b:4179::1 vs 2001::1
-
-Draves Standards Track - Expires January 2002 13 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src
- 2002:836b:4179::2) (prefer matching label)
- Sources: 2002:836b:4179::2 or 2001::2 or fe80::2
- Destinations: 2002:836b:4179::1 vs 2001::1
- Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src
- 2002:836b:4179::2) (prefer higher precedence)
-9.3. Configuring Preference for IPv6 vs IPv4
- The default policy table gives IPv6 addresses higher precedence than
- IPv4 addresses. This means that applications will use IPv6 in
- preference to IPv4 when the two are equally suitable. An
- 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 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:
- Sources: 2001::2 or fe80::1 or 169.254.13.78
- Destinations: 2001::1 vs 131.107.65.121
- Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src
- 169.254.13.78) (prefer matching scope)
- Sources: fe80::1 or 131.107.65.117
- Destinations: 2001::1 vs 131.107.65.121
- Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1
- (src fe80::1) (prefer matching scope)
- Sources: 2001::2 or fe80::1 or 10.1.2.4
- Destinations: 2001::1 vs 10.1.2.3
- New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2)
- (prefer higher precedence)
-9.4. Configuring Preference for Scoped Addresses
- The destination address selection rules give preference to
- destinations of smaller scope. For example, a site-local destination
- will be sorted before a global scope destination when the two are
- otherwise equally suitable. An administrator can change the policy
- table to reverse this preference and sort global destinations before
- site-local destinations, and site-local destinations before link-
- local destinations:
-
-Draves Standards Track - Expires January 2002 14 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- 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:
- Sources: 2001::2 or fec0::2 or fe80::2
- Destinations: 2001::1 vs fec0::1 vs fe80::1
- New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then
- fe80::1 (src fe80::2) (prefer higher precedence)
- Sources: 2001::2 (deprecated) or fec0::2 or fe80::2
- Destinations: 2001::1 vs fec0::1
- Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2)
- (avoid deprecated addresses)
-9.5. Configuring a Multi-Homed Site
- Consider a site A that has a business-critical relationship with
- another site B. To support their business needs, the two sites have
- contracted for service with a special high-performance ISP. This is
- in addition to the normal Internet connection that both sites have
- with different ISPs. The high-performance ISP is expensive and the
- two sites wish to use it only for their business-critical traffic
- with each other.
- 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
- 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
- hosts in both sites register two addresses in the DNS.
- The routing within both sites directs most traffic to the egress to
- the normal ISP, but the routing directs traffic sent to the other
- site's 2001 prefix to the egress to the high-performance ISP. To
- prevent unintended use of their high-performance ISP connection, the
- two sites implement ingress filtering to discard traffic entering
- from the high-performance ISP that is not from the other site.
- The default policy table and address selection rules produce the
- following behavior:
- 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 January 2002 15 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b
- (src 2001:aaaa:aaaa::a) (longest matching prefix)
- In other words, when a host in site A initiates a connection to a
- host in site B, the traffic does not take advantage of their
- connections to the high-performance ISP. This is not their desired
- behavior.
- Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a
- Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c
- Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then
- 2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix)
- In other words, when a host in site A initiates a connection to a
- host in some other site C, the reverse traffic may come back through
- the high-performance ISP. Again, this is not their desired behavior.
- This situation demonstrates the limitations of the longest-matching-
- prefix heuristic in multi-homed situations.
- However, the administrators of sites A and B can achieve their
- desired behavior via policy table configuration. For example, they
- can use the following policy table:
- 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:
- 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
- 2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence)
- In other words, when a host in site A initiates a connection to a
- host in site B, the traffic uses the high-performance ISP as
- desired.
- Sources: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or fe80::a
- Destinations: 2001:cccc:cccc::c vs 2006:cccc:cccc::c
- New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then
- 2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix)
- In other words, when a host in site A initiates a connection to a
- host in some other site C, the traffic uses the normal ISP as
- desired.
-
-Draves Standards Track - Expires January 2002 16 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
-References
-
- 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP
- 9, RFC 2026, October 1996.
- 2 R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
- RFC 2373, July 1998.
- 3 S. Thompson, T. Narten, "IPv6 Stateless Address Autoconfig-
- uration", RFC 2462 , December 1998.
- 4 T. Narten, R. Draves, "Privacy Extensions for Stateless Address
- Autoconfiguration in IPv6", RFC 3041, January 2001.
- 5 D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-
- mobileip-ipv6-13.txt, November 2000.
- 6 S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local
- Addresses", draft-ietf-zeroconf-ipv4-linklocal-02.txt, March
- 2001.
- 7 S. Bradner, "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
- 8 R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic Socket
- Interface Extensions for IPv6", RFC 2553, March 1999.
- 9 S. Deering et. al, "IP Version 6 Scoped Address Architecture",
- draft-ietf-ipngwg-scoping-arch-02.txt, March 2001.
- 10 Y. Rekhter et. al, "Address Allocation for Private Internets",
- RFC 1918, February 1996.
- 11 F. Baker, Editor, "Requirements for IP Version 4 Routers", RFC
- 1812, June 1995.
- 12 B. Carpenter, K. Moore, "Connection of IPv6 Domains via IPv4
- Clouds", RFC 3056, February 2001.
- 13 T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for
- IP Version 6", RFC 2461, December 1998.
-Acknowledgments
- The author would like to acknowledge the contributions of the IPng
- Working Group, particularly Marc Blanchet, Brian Carpenter, Matt
- Crawford, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony
- Hain, M.T. Hollinger, JINMEI Tatuya, Erik Nordmark, Ken Powell,
- Markku Savela, Dave Thaler, Ole Troan, and Mauro Tortonesi. Please
- let the author know if you contributed to the development of this
- draft and are not mentioned here.
-
-Draves Standards Track - Expires January 2002 17 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
-Author's Address
- Richard Draves
- Microsoft Research
- One Microsoft Way
- Redmond, WA 98052
- Phone: 1-425-936-2268
- Email: richdr@microsoft.com
-Revision History
-Changes from draft-ietf-ipngwg-default-addr-select-04
- Clarified candidate set formation for routers.
- Added some explanatory discussion to the candidate set section.
- Replaced usages of scope id with zone index.
- Augmented the first destination-address selection rule, to avoid
- destination addresses for which the current next-hop neighbor is
- known to be unreachable.
-Changes from draft-ietf-ipngwg-default-addr-select-03
- Reversed the treatment of temporary addresses, so that unless an
- application specifies otherwise public addresses are preferred over
- temporary addresses.
- Added text clarifying our expectation that applications should
- iterate through the list of possible destination addresses until
- finding a working address.
- Removed references to getipnodebyname().
-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.
-
-Draves Standards Track - Expires January 2002 18 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
-Changes from draft-ietf-ipngwg-default-addr-select-01
- Added Examples section, demonstrating default behavior and some
- policy table configuration scenarios.
- Removed many uses of MUST. Remaining uses concern the candidate set
- of source addresses and the source address selection rule that
- prefers source addresses of appropriate scope.
- Simplified the default policy table. Reordered the source address
- selection rules to reduce the influence of policy labels. Added more
- destination address selection rules.
- Added scoping of v4-compatible and 6to4 addresses based on the
- embedded IPv4 address.
- Changed references to anonymous addresses to use the new term,
- temporary addresses.
- Clarified that a user-level implementation of destination address
- ordering, which does not have knowledge of the outgoing interface
- for each destination, may use a looser definition of the candidate
- set.
- Clarified that an implementation should prevent an application or
- upper-layer from choosing a source address that is not in the
- candidate set and not prevent an application or upper-layer from
- choosing a source address that is in the candidate set.
- Miscellaneous editorial changes, including adding some missing
- references.
-Changes from draft-ietf-ipngwg-default-addr-select-00
- Changed the candidate set definition so that the strong host model
- is recommended but not required. Added a rule to source address
- selection to prefer addresses assigned to the outgoing interface.
- Simplified the destination address selection algorithm, by having it
- use source address selection as a subroutine.
- Added a rule to source address selection to handle anonymous/public
- addresses.
- Added a rule to source address selection to handle home/care-of
- addresses.
- Changed to allow destination address selection to sort both IPv6 and
- IPv4 addresses. Added entries in the default policy table for IPv4-
- mapped addresses.
- Changed default precedences, so v4-compatible addresses have lower
- precedence than 6to4 addresses.
-
-Draves Standards Track - Expires January 2002 19 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
-Changes from draft-draves-ipngwg-simple-srcaddr-01
- Added framework discussion.
- Added algorithm for destination address ordering.
- Added mechanism to allow the specification of administrative policy
- that can override the default behavior.
- Added section on routing interactions and TBD section on mobility
- interactions.
- Changed the candidate set definition for source address selection,
- so that only addresses assigned to the outgoing interface are
- allowed.
- Changed the loopback address treatment to link-local scope.
-Changes from draft-draves-ipngwg-simple-srcaddr-00
- Minor wording changes because DHCPv6 also supports "preferred" and
- "deprecated" addresses.
- Specified treatment of other format prefixes; now they are
- considered global scope, "preferred" addresses.
- Reiterated that anycast and multicast addresses are not allowed as
- source addresses.
- Recommended that source addresses be taken from the outgoing
- interface. Required this for multicast destinations. Added analogous
- requirements for link-local and site-local destinations.
- Specified treatment of the loopback address.
- Changed the second selection rule so that if both candidate source
- addresses have scope greater or equal than the destination address
- and only of them is preferred, the preferred address is chosen.
-
-Draves Standards Track - Expires January 2002 20 \f
-draft-ietf-ipngwg-default-addr-select-05 June 4, 2001
-
-
- Full Copyright Statement
- Copyright (C) The Internet Society (1999). 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.
-
-Draves Standards Track - Expires January 2002 21 \f
\ No newline at end of file
+++ /dev/null
-
-IPng Working Group Matt Crawford
-Internet Draft Fermilab
- November 17, 2000
-
- Discovery of Resource Records Designating IPv6 Address prefixes
- <draft-ietf-ipngwg-prefix-rr-disc-00.txt>
-
-
-
-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 A6 resource record type [A6] was introduced to store IPv6
- addresses in a manner which facilitates prefix changes and
- assignment of addresses from multiple prefixes. In order to allow
- use of dynamic DNS updates while still respecting whatever prefix
- hierarchy may be in use in a site's "reverse" DNS zone, a method is
- needed for discovering the name(s) of the A6 record(s) which specify
- an address prefix.
-
- This memo specifies such a method of prefix name discovery.
-
-
-1. Introduction
-
- The A6 resource record type [A6] was introduced to store IPv6
- addresses in a manner which facilitates prefix changes and
- assignment of addresses from multiple prefixes. In order to allow
- use of dynamic DNS updates while still respecting whatever prefix
- hierarchy may be in use in a site's "reverse" DNS zone, a method is
- needed for discovering the name(s) of the A6 record(s) which specify
- an address prefix.
-
-
-
-Expires May 22, 2001 Crawford et al. [Page 1]
-\f
-Internet Draft IPv6 DNS November 17, 2000
-
-
- This memo specifies such a method. No new protocols or DNS record
- types are involved -- only a convention for storing the required
- information and a procedure for finding it.
-
- 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 [KWORD].
-
-
-2. Prefix Name Storage
-
- Recall from [A6] that address-to-name mapping information may be
- stored in a subzone of IP6.ARPA, or in another zone reached by a
- chain of one or more DNAME records. Nodenames are stored in PTR
- records in such a zone. Extending that custom, we specify that
- prefixes are to be named in PTR records in the same way. For a
- prefix "P" of length "L" bits there should be a PTR whose RDATA
- contains the owner name of an A6 record suitable for designating the
- prefix P/L, and this PTR record is to be stored so that it will be
- returned by a DNS query for the QNAME \[P/L].IP6.ARPA (possibly
- after resolving intervening DNAMEs [DNAME]).
-
- Since the purpose of prefix name discovery is to facilitate dynamic
- registration by hosts of their IPv6 addresses in DNS, only the names
- of "longest" prefixes need to be discoverable. Accordingly, this
- example will show just a prefix which is not subnetted further.
-
- Building on the example from [A6], section 5.2.3, the addition of
- the required PTR record is shown below.
-
- $ORIGIN X.EXAMPLE.
- N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
- SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
- PTR SUBNET-1.IP6 ; added record
- IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
- IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
- $ORIGIN IP6
- \[x0001/16] DNAME SUBNET-1
- \[x123456789ABCDEF0].SUBNET-1 PTR N.X.EXAMPLE.
-
- Notice that the owner and RDATA are the same. This is a consequence
- of a somewhat arbitrary choice. The new record could equally well
- have been
-
- \[x0001/16].IP6.X.EXAMPLE. PTR SUBNET-1.IP6.X.EXAMPLE.
-
-
- It cannot be determined by inspecting an A6 DNS record whether that
-
-
-
-Expires May 22, 2001 Crawford et al. [Page 2]
-\f
-Internet Draft IPv6 DNS November 17, 2000
-
-
- record is meant to specify all the trailing bits of a 128-bit IPv6
- address or merely a prefix. Inclusion of the trailing bits does not
- preclude its being pointed to as a prefix by some other A6 record.
- Nevertheless, a human or automated zone maintainer will generally
- know the intended purpose of each A6 record and which one should be
- named in a PTR for prefix name discovery.
-
-
-3. Prefix Name Discovery
-
- If a process wishing to do prefix name discovery has the prefix
- itself available (as opposed to a full address of which an unknown
- initial portion is the prefix), the prefix can be looked up
- directly. Otherwise, two heuristics are available.
-
- First, it is possible that looking up a PTR record based on the full
- IPv6 address, as would be done for ordinary address-to-name mapping,
- will yield a PTR record containing a hostname. That hostname will
- then be the owner of an A6 record. If its prefix length field is
- non-zero, its prefix name field will contain the desired name.
-
- Otherwise, looking up a PTR record will fail, returning an
- authoritative name error no no data of the requested type. There
- will be a set of DNAME records in the answer section of the reply.
- The last of these DNAMEs will indicate where to start looking for
- the required PTR record. First its target should be tried, then its
- owner. An especially persistent implementation can then prepend one
- bit at a time from the portion of the IPv6 address not mapped by the
- DNAME records to the target name, looking for a PTR record which was
- not at a DNAME cut point of its own. An authoritative name error is
- a stopping signal for this search.
-
-
-4. Security Considerations
-
- No security concerns are raised by this specification beyond those
- which apply to all uses of the DNS.
-
-
-5. References
-
-
- [A6] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6
- Address Aggregation and Renumbering", RFC 2874, July 2000.
-
- [KWORD] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels," RFC 2119.
-
-
-
-
-Expires May 22, 2001 Crawford et al. [Page 3]
-\f
-Internet Draft IPv6 DNS November 17, 2000
-
-
- [DNAME] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
- August 1999.
-
-6. Authors' Addresses
-
- Matt Crawford
- Fermilab
- MS 368
- PO Box 500
- Batavia, IL 60510
- USA
-
- +1 630 840-3461
- crawdad@fnal.gov
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May 22, 2001 Crawford et al. [Page 4]
-
+++ /dev/null
-INTERNET-DRAFT W. Richard Stevens (Consultant)
-Expires: May 7, 2001 Matt Thomas (Consultant)
-Obsoletes RFC 2292 Erik Nordmark (Sun)
- November 7, 2000
-
-
- Advanced Sockets API for IPv6
- <draft-ietf-ipngwg-rfc2292bis-02.txt>
-
-
-
-Abstract
-
- A separate specification [RFC-2553] contain changes to the sockets
- API to support IP version 6. Those changes are for TCP and UDP-based
- applications and will support most end-user applications in use
- today: Telnet and FTP clients and servers, HTTP clients and servers,
- and the like.
-
- But another class of applications exists that will also be run under
- IPv6. We call these "advanced" applications and today this includes
- programs such as Ping, Traceroute, routing daemons, multicast routing
- daemons, router discovery daemons, and the like. The API feature
- typically used by these programs that make them "advanced" is a raw
- socket to access ICMPv4, IGMPv4, or IPv4, along with some knowledge
- of the packet header formats used by these protocols. To provide
- portability for applications that use raw sockets under IPv6, some
- standardization is needed for the advanced API features.
-
- There are other features of IPv6 that some applications will need to
- access: interface identification (specifying the outgoing interface
- and determining the incoming interface) and IPv6 extension headers
- that are not addressed in [RFC-2553]: The Routing header (source
- routing), Hop-by-Hop options, and Destination options. This document
- provides API access to these features too.
-
-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
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 1]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- 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.
-
- This Internet Draft expires May 7, 2001.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 2]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-Table of Contents
-
- 1. Introduction ..................................................... 6
-
- 2. Common Structures and Definitions ................................ 7
- 2.1. The ip6_hdr Structure .......................................... 8
- 2.1.1. IPv6 Next Header Values ...................................... 8
- 2.1.2. IPv6 Extension Headers ....................................... 9
- 2.1.3. IPv6 Options ................................................. 10
- 2.2. The icmp6_hdr Structure ........................................ 13
- 2.2.1. ICMPv6 Type and Code Values .................................. 13
- 2.2.2. ICMPv6 Neighbor Discovery Definitions ........................ 14
- 2.2.3. Multicast Listener Discovery Definitions ..................... 17
- 2.2.4. ICMPv6 Router Renumbering Definitions ........................ 18
- 2.3. Address Testing Macros ......................................... 19
- 2.4. Protocols File ................................................. 20
-
- 3. IPv6 Raw Sockets ................................................. 20
- 3.1. Checksums ...................................................... 22
- 3.2. ICMPv6 Type Filtering .......................................... 22
- 3.3. ICMPv6 Verification of Received Packets ........................ 25
-
- 4. Access to IPv6 and Extension Headers ............................. 25
- 4.1. TCP Implications ............................................... 27
- 4.2. UDP and Raw Socket Implications ................................ 28
-
- 5. Extensions to Socket Ancillary Data .............................. 28
-
- 6. Packet Information ............................................... 29
- 6.1. Specifying/Receiving the Interface ............................. 30
- 6.2. Specifying/Receiving Source/Destination Address ................ 30
- 6.3. Specifying/Receiving the Hop Limit ............................. 31
- 6.4. Specifying the Next Hop Address ................................ 32
- 6.5. Additional Errors with sendmsg() and setsockopt() .............. 32
-
- 7. Routing Header Option ............................................ 33
- 7.1. inet6_rth_space ................................................ 34
- 7.2. inet6_rth_init ................................................. 35
- 7.3. inet6_rth_add .................................................. 35
- 7.4. inet6_rth_reverse .............................................. 35
- 7.5. inet6_rth_segments ............................................. 36
- 7.6. inet6_rth_getaddr .............................................. 36
-
- 8. Hop-By-Hop Options ............................................... 36
- 8.1. Receiving Hop-by-Hop Options ................................... 38
- 8.2. Sending Hop-by-Hop Options ..................................... 38
-
- 9. Destination Options .............................................. 38
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 3]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- 9.1. Receiving Destination Options .................................. 39
- 9.2. Sending Destination Options .................................... 39
-
- 10. Hop-by-Hop and Destination Options Processing ................... 40
- 10.1. inet6_opt_init ................................................ 40
- 10.2. inet6_opt_append .............................................. 41
- 10.3. inet6_opt_finish .............................................. 41
- 10.4. inet6_opt_set_val ............................................. 42
- 10.5. inet6_opt_next ................................................ 42
- 10.6. inet6_opt_find ................................................ 42
- 10.7. inet6_opt_get_val ............................................. 43
-
- 11. Additional Advanced API Functions ............................... 43
- 11.1. Sending with the Minimum MTU .................................. 43
- 11.2. Path MTU Discovery and UDP .................................... 44
- 11.3. Neighbor Reachability and UDP ................................. 44
-
- 12. Ordering of Ancillary Data and IPv6 Extension Headers ........... 45
-
- 13. IPv6-Specific Options with IPv4-Mapped IPv6 Addresses ........... 46
-
- 14. Extended interfaces for rresvport, rcmd and rexec ............... 46
- 14.1. rresvport_af .................................................. 46
- 14.2. rcmd_af ....................................................... 47
- 14.3. rexec_af ...................................................... 47
-
- 15. Summary of New Definitions ...................................... 47
-
- 16. Security Considerations ......................................... 52
-
- 17. Change History .................................................. 52
-
- 18. TODO and Open Issues ............................................ 54
-
- 19. References ...................................................... 56
-
- 20. Acknowledgments ................................................. 56
-
- 21. Authors' Addresses .............................................. 57
-
- 22. Appendix A: Ancillary Data Overview ............................. 57
- 22.1. The msghdr Structure .......................................... 58
- 22.2. The cmsghdr Structure ......................................... 59
- 22.3. Ancillary Data Object Macros .................................. 60
- 22.3.1. CMSG_FIRSTHDR ............................................... 61
- 22.3.2. CMSG_NXTHDR ................................................. 62
- 22.3.3. CMSG_DATA ................................................... 63
- 22.3.4. CMSG_SPACE .................................................. 63
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 4]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- 22.3.5. CMSG_LEN .................................................... 64
-
- 23. Appendix B: Examples using the inet6_rth_XXX() functions ........ 64
- 23.1. Sending a Routing Header ...................................... 64
- 23.2. Receiving Routing Headers ..................................... 69
-
- 24. Appendix C: Examples using the inet6_opt_XXX() functions ........ 71
- 24.1. Building options .............................................. 71
- 24.2. Parsing received options ...................................... 73
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 5]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-1. Introduction
-
- A separate specification [RFC-2553] contain changes to the sockets
- API to support IP version 6. Those changes are for TCP and UDP-based
- applications. This document defines some the "advanced" features of
- the sockets API that are required for applications to take advantage
- of additional features of IPv6.
-
- Today, the portability of applications using IPv4 raw sockets is
- quite high, but this is mainly because most IPv4 implementations
- started from a common base (the Berkeley source code) or at least
- started with the Berkeley header files. This allows programs such as
- Ping and Traceroute, for example, to compile with minimal effort on
- many hosts that support the sockets API. With IPv6, however, there
- is no common source code base that implementors are starting from,
- and the possibility for divergence at this level between different
- implementations is high. To avoid a complete lack of portability
- amongst applications that use raw IPv6 sockets, some standardization
- is necessary.
-
- There are also features from the basic IPv6 specification that are
- not addressed in [RFC-2553]: sending and receiving Routing headers,
- Hop-by-Hop options, and Destination options, specifying the outgoing
- interface, and being told of the receiving interface.
-
- This document can be divided into the following main sections.
-
- 1. Definitions of the basic constants and structures required for
- applications to use raw IPv6 sockets. This includes structure
- definitions for the IPv6 and ICMPv6 headers and all associated
- constants (e.g., values for the Next Header field).
-
- 2. Some basic semantic definitions for IPv6 raw sockets. For
- example, a raw ICMPv4 socket requires the application to
- calculate and store the ICMPv4 header checksum. But with IPv6
- this would require the application to choose the source IPv6
- address because the source address is part of the pseudo header
- that ICMPv6 now uses for its checksum computation. It should be
- defined that with a raw ICMPv6 socket the kernel always
- calculates and stores the ICMPv6 header checksum.
-
- 3. Packet information: how applications can obtain the received
- interface, destination address, and received hop limit, along
- with specifying these values on a per-packet basis. There are a
- class of applications that need this capability and the technique
- should be portable.
-
- 4. Access to the optional Routing header, Hop-by-Hop, and
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 6]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- Destination extension headers.
-
- 5. Additional features required for improved IPv6 application
- portability.
-
- The packet information along with access to the extension headers
- (Routing header, Hop-by-Hop options, and Destination options) are
- specified using the "ancillary data" fields that were added to the
- 4.3BSD Reno sockets API in 1990. The reason is that these ancillary
- data fields are part of the Posix.1g standard and should therefore be
- adopted by most vendors.
-
- This document does not address application access to either the
- authentication header or the encapsulating security payload header.
-
- All examples in this document omit error checking in favor of brevity
- and clarity.
-
- We note that many of the functions and socket options defined in this
- document may have error returns that are not defined in this
- document. Many of these possible error returns will be recognized
- only as implementations proceed.
-
- Datatypes in this document follow the Posix.1g format: intN_t means
- a signed integer of exactly N bits (e.g., int16_t) and uintN_t means
- an unsigned integer of exactly N bits (e.g., uint32_t).
-
- Note that we use the (unofficial) terminology ICMPv4, IGMPv4, and
- ARPv4 to avoid any confusion with the newer ICMPv6 protocol.
-
-
-2. Common Structures and Definitions
-
- Many advanced applications examine fields in the IPv6 header and set
- and examine fields in the various ICMPv6 headers. Common structure
- definitions for these protocol headers are required, along with
- common constant definitions for the structure members.
-
- This API assumes that the fields in the protocol headers are left in
- the network byte order, which is big-endian for the Internet
- protocols. If not, then either these constants or the fields being
- tested must be converted at run-time, using something like htons() or
- htonl().
-
- Two new header files are defined: <netinet/ip6.h> and
- <netinet/icmp6.h>.
-
- When an include file is specified, that include file is allowed to
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 7]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- include other files that do the actual declaration or definition.
-
-
-2.1. The ip6_hdr Structure
-
- The following structure is defined as a result of including
- <netinet/ip6.h>. Note that this is a new header.
-
- struct ip6_hdr {
- union {
- struct ip6_hdrctl {
- uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC, 20 bits flow-ID */
- uint16_t ip6_un1_plen; /* payload length */
- uint8_t ip6_un1_nxt; /* next header */
- uint8_t ip6_un1_hlim; /* hop limit */
- } ip6_un1;
- uint8_t ip6_un2_vfc; /* 4 bits version, top 4 bits tclass */
- } ip6_ctlun;
- struct in6_addr ip6_src; /* source address */
- struct in6_addr ip6_dst; /* destination address */
- };
-
- #define ip6_vfc ip6_ctlun.ip6_un2_vfc
- #define ip6_flow ip6_ctlun.ip6_un1.ip6_un1_flow
- #define ip6_plen ip6_ctlun.ip6_un1.ip6_un1_plen
- #define ip6_nxt ip6_ctlun.ip6_un1.ip6_un1_nxt
- #define ip6_hlim ip6_ctlun.ip6_un1.ip6_un1_hlim
- #define ip6_hops ip6_ctlun.ip6_un1.ip6_un1_hlim
-
-
-
-2.1.1. IPv6 Next Header Values
-
- IPv6 defines many new values for the Next Header field. The
- following constants are defined as a result of including
- <netinet/in.h>.
-
- #define IPPROTO_HOPOPTS 0 /* IPv6 Hop-by-Hop options */
- #define IPPROTO_IPV6 41 /* IPv6 header */
- #define IPPROTO_ROUTING 43 /* IPv6 Routing header */
- #define IPPROTO_FRAGMENT 44 /* IPv6 fragmentation header */
- #define IPPROTO_ESP 50 /* encapsulating security payload */
- #define IPPROTO_AH 51 /* authentication header */
- #define IPPROTO_ICMPV6 58 /* ICMPv6 */
- #define IPPROTO_NONE 59 /* IPv6 no next header */
- #define IPPROTO_DSTOPTS 60 /* IPv6 Destination options */
-
- Berkeley-derived IPv4 implementations also define IPPROTO_IP to be 0.
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 8]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- This should not be a problem since IPPROTO_IP is used only with IPv4
- sockets and IPPROTO_HOPOPTS only with IPv6 sockets.
-
-
-2.1.2. IPv6 Extension Headers
-
- Six extension headers are defined for IPv6. We define structures for
- all except the Authentication header and Encapsulating Security
- Payload header, both of which are beyond the scope of this document.
- The following structures are defined as a result of including
- <netinet/ip6.h>.
-
- /*
- * Generic extension header structure used by many extension headers.
- * Note that not all headers have this format. E.g. the fragmentation
- * header is different.
- */
- struct ip6_ext {
- uint8_t ip6e_nxt; /* next header */
- uint8_t ip6e_len; /* length in units of 8 octets */
- };
-
- /* Hop-by-Hop options header */
- struct ip6_hbh {
- uint8_t ip6h_nxt; /* next header */
- uint8_t ip6h_len; /* length in units of 8 octets */
- /* followed by options */
- };
-
- /* Destination options header */
- struct ip6_dest {
- uint8_t ip6d_nxt; /* next header */
- uint8_t ip6d_len; /* length in units of 8 octets */
- /* followed by options */
- };
-
- /* Routing header */
- struct ip6_rthdr {
- uint8_t ip6r_nxt; /* next header */
- uint8_t ip6r_len; /* length in units of 8 octets */
- uint8_t ip6r_type; /* routing type */
- uint8_t ip6r_segleft; /* segments left */
- /* followed by routing type specific data */
- };
-
- /* Type 0 Routing header */
- struct ip6_rthdr0 {
- uint8_t ip6r0_nxt; /* next header */
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 9]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- uint8_t ip6r0_len; /* length in units of 8 octets */
- uint8_t ip6r0_type; /* always zero */
- uint8_t ip6r0_segleft; /* segments left */
- uint32_t ip6r0_reserved; /* reserved field */
- /* followed by up to 127 struct in6_addr */
- };
-
- /* Fragment header */
- struct ip6_frag {
- uint8_t ip6f_nxt; /* next header */
- uint8_t ip6f_reserved; /* reserved field */
- uint16_t ip6f_offlg; /* offset, reserved, and flag */
- uint32_t ip6f_ident; /* identification */
- };
-
- #if BYTE_ORDER == BIG_ENDIAN
- #define IP6F_OFF_MASK 0xfff8 /* mask out offset from _offlg */
- #define IP6F_RESERVED_MASK 0x0006 /* reserved bits in ip6f_offlg */
- #define IP6F_MORE_FRAG 0x0001 /* more-fragments flag */
- #else /* BYTE_ORDER == LITTLE_ENDIAN */
- #define IP6F_OFF_MASK 0xf8ff /* mask out offset from _offlg */
- #define IP6F_RESERVED_MASK 0x0600 /* reserved bits in ip6f_offlg */
- #define IP6F_MORE_FRAG 0x0100 /* more-fragments flag */
- #endif
-
-
-
-2.1.3. IPv6 Options
-
- Eleven options are defined for IPv6 at the time of writing this
- document. We define structures for all except the unspecified EID
- option. The following structures are defined as a result of
- including <netinet/ip6.h>.
-
- /* IPv6 options */
- struct ip6_opt {
- uint8_t ip6o_type;
- uint8_t ip6o_len;
- };
-
- /*
- * The high-order 3 bits of the option type define the behavior
- * when processing an unknown option and whether or not the option
- * content changes in flight.
- */
- #define IP6OPT_TYPE(o) ((o) & 0xc0)
- #define IP6OPT_TYPE_SKIP 0x00
- #define IP6OPT_TYPE_DISCARD 0x40
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 10]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- #define IP6OPT_TYPE_FORCEICMP 0x80
- #define IP6OPT_TYPE_ICMP 0xc0
- #define IP6OPT_MUTABLE 0x20
-
- #define IP6OPT_PAD1 0x00 /* 00 0 00000 */
- #define IP6OPT_PADN 0x01 /* 00 0 00001 */
- #define IP6OPT_JUMBO 0xc2 /* 11 0 00010 = 194 */
- #define IP6OPT_NSAP_ADDR 0xc3 /* 11 0 00011 */
- #define IP6OPT_TUNNEL_LIMIT 0x04 /* 00 0 00100 */
- #define IP6OPT_ROUTER_ALERT 0x05 /* 00 0 00101 */
- #define IP6OPT_BINDING_UPDATE 0xc6 /* 11 0 00110 */
- #define IP6OPT_BINDING_ACK 0x07 /* 00 0 00111 */
- #define IP6OPT_BINDING_REQ 0x08 /* 00 0 01000 */
- #define IP6OPT_HOME_ADDRESS 0xc9 /* 11 0 01001 */
- #define IP6OPT_EID 0x8a /* 10 0 01010 */
-
- /* Jumbo Payload Option */
- struct ip6_opt_jumbo {
- uint8_t ip6oj_type;
- uint8_t ip6oj_len;
- uint8_t ip6oj_jumbo_len[4];
- };
- #define IP6OPT_JUMBO_LEN 6
-
- /* NSAP Address Option */
- struct ip6_opt_nsap {
- uint8_t ip6on_type;
- uint8_t ip6on_len;
- uint8_t ip6on_src_nsap_len;
- uint8_t ip6on_dst_nsap_len;
- /* followed by source NSAP */
- /* followed by destination NSAP */
- };
-
- /* Tunnel Limit Option */
- struct ip6_opt_tunnel {
- uint8_t ip6ot_type;
- uint8_t ip6ot_len;
- uint8_t ip6ot_encap_limit;
- };
-
- /* Router Alert Option */
- struct ip6_opt_router {
- uint8_t ip6or_type;
- uint8_t ip6or_len;
- uint8_t ip6or_value[2];
- };
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 11]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- /* Router alert values (in network byte order) */
- #ifdef _BIG_ENDIAN
- #define IP6_ALERT_MLD 0x0000
- #define IP6_ALERT_RSVP 0x0001
- #define IP6_ALERT_AN 0x0002
- #else
- #define IP6_ALERT_MLD 0x0000
- #define IP6_ALERT_RSVP 0x0100
- #define IP6_ALERT_AN 0x0200
- #endif
-
- /* Binding Update Option */
- struct ip6_opt_binding_update {
- uint8_t ip6ou_type;
- uint8_t ip6ou_len;
- uint8_t ip6ou_flags;
- uint8_t ip6ou_prefixlen;
- uint8_t ip6ou_seqno[2];
- uint8_t ip6ou_lifetime[4];
- uint8_t ip6ou_coa[16]; /* Optional based on flags */
- /* followed by sub-options */
- };
-
- /* Binding Update Flags */
- #define IP6_BUF_ACK 0x80 /* Request a binding ack */
- #define IP6_BUF_HOME 0x40 /* Home Registration */
- #define IP6_BUF_COA 0x20 /* Care-of-address present in option */
- #define IP6_BUF_ROUTER 0x10 /* Sending mobile node is a router */
-
- /* Binding Ack Option */
- struct ip6_opt_binding_ack {
- uint8_t ip6oa_type;
- uint8_t ip6oa_len;
- uint8_t ip6oa_status;
- uint8_t ip6oa_seqno[2];
- uint8_t ip6oa_lifetime[4];
- uint8_t ip6oa_refresh[4];
- /* followed by sub-options */
- };
-
- /* Binding Request Option */
- struct ip6_opt_binding_request {
- uint8_t ip6or_type;
- uint8_t ip6or_len;
- /* followed by sub-options */
- };
-
- /* Home Address Option */
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 12]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- struct ip6_opt_home_address {
- uint8_t ip6oh_type;
- uint8_t ip6oh_len;
- uint8_t ip6oh_addr[16]; /* Home Address */
- /* followed by sub-options */
- };
-
-
-
-2.2. The icmp6_hdr Structure
-
- The ICMPv6 header is needed by numerous IPv6 applications including
- Ping, Traceroute, router discovery daemons, and neighbor discovery
- daemons. The following structure is defined as a result of including
- <netinet/icmp6.h>. Note that this is a new header.
-
- struct icmp6_hdr {
- uint8_t icmp6_type; /* type field */
- uint8_t icmp6_code; /* code field */
- uint16_t icmp6_cksum; /* checksum field */
- union {
- uint32_t icmp6_un_data32[1]; /* type-specific field */
- uint16_t icmp6_un_data16[2]; /* type-specific field */
- uint8_t icmp6_un_data8[4]; /* type-specific field */
- } icmp6_dataun;
- };
-
- #define icmp6_data32 icmp6_dataun.icmp6_un_data32
- #define icmp6_data16 icmp6_dataun.icmp6_un_data16
- #define icmp6_data8 icmp6_dataun.icmp6_un_data8
- #define icmp6_pptr icmp6_data32[0] /* parameter prob */
- #define icmp6_mtu icmp6_data32[0] /* packet too big */
- #define icmp6_id icmp6_data16[0] /* echo request/reply */
- #define icmp6_seq icmp6_data16[1] /* echo request/reply */
- #define icmp6_maxdelay icmp6_data16[0] /* mcast group membership */
-
-
-
-2.2.1. ICMPv6 Type and Code Values
-
- In addition to a common structure for the ICMPv6 header, common
- definitions are required for the ICMPv6 type and code fields. The
- following constants are also defined as a result of including
- <netinet/icmp6.h>.
-
- #define ICMP6_DST_UNREACH 1
- #define ICMP6_PACKET_TOO_BIG 2
- #define ICMP6_TIME_EXCEEDED 3
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 13]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- #define ICMP6_PARAM_PROB 4
-
- #define ICMP6_INFOMSG_MASK 0x80 /* all informational messages */
-
- #define ICMP6_ECHO_REQUEST 128
- #define ICMP6_ECHO_REPLY 129
-
- #define ICMP6_DST_UNREACH_NOROUTE 0 /* no route to destination */
- #define ICMP6_DST_UNREACH_ADMIN 1 /* communication with */
- /* destination */
- /* admin. prohibited */
- #define ICMP6_DST_UNREACH_BEYONDSCOPE 2 /* beyond scope of source address */
- #define ICMP6_DST_UNREACH_ADDR 3 /* address unreachable */
- #define ICMP6_DST_UNREACH_NOPORT 4 /* bad port */
-
- #define ICMP6_TIME_EXCEED_TRANSIT 0 /* Hop Limit == 0 in transit */
- #define ICMP6_TIME_EXCEED_REASSEMBLY 1 /* Reassembly time out */
-
- #define ICMP6_PARAMPROB_HEADER 0 /* erroneous header field */
- #define ICMP6_PARAMPROB_NEXTHEADER 1 /* unrecognized Next Header */
- #define ICMP6_PARAMPROB_OPTION 2 /* unrecognized IPv6 option */
-
- The five ICMP message types defined by IPv6 neighbor discovery (133-
- 137) are defined in the next section.
-
-
-2.2.2. ICMPv6 Neighbor Discovery Definitions
-
- The following structures and definitions are defined as a result of
- including <netinet/icmp6.h>.
-
- #define ND_ROUTER_SOLICIT 133
- #define ND_ROUTER_ADVERT 134
- #define ND_NEIGHBOR_SOLICIT 135
- #define ND_NEIGHBOR_ADVERT 136
- #define ND_REDIRECT 137
-
- struct nd_router_solicit { /* router solicitation */
- struct icmp6_hdr nd_rs_hdr;
- /* could be followed by options */
- };
-
- #define nd_rs_type nd_rs_hdr.icmp6_type
- #define nd_rs_code nd_rs_hdr.icmp6_code
- #define nd_rs_cksum nd_rs_hdr.icmp6_cksum
- #define nd_rs_reserved nd_rs_hdr.icmp6_data32[0]
-
- struct nd_router_advert { /* router advertisement */
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 14]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- struct icmp6_hdr nd_ra_hdr;
- uint32_t nd_ra_reachable; /* reachable time */
- uint32_t nd_ra_retransmit; /* retransmit timer */
- /* could be followed by options */
- };
-
- #define nd_ra_type nd_ra_hdr.icmp6_type
- #define nd_ra_code nd_ra_hdr.icmp6_code
- #define nd_ra_cksum nd_ra_hdr.icmp6_cksum
- #define nd_ra_curhoplimit nd_ra_hdr.icmp6_data8[0]
- #define nd_ra_flags_reserved nd_ra_hdr.icmp6_data8[1]
- #define ND_RA_FLAG_MANAGED 0x80
- #define ND_RA_FLAG_OTHER 0x40
- #define ND_RA_FLAG_HOME_AGENT 0x20
- #define nd_ra_router_lifetime nd_ra_hdr.icmp6_data16[1]
-
- struct nd_neighbor_solicit { /* neighbor solicitation */
- struct icmp6_hdr nd_ns_hdr;
- struct in6_addr nd_ns_target; /* target address */
- /* could be followed by options */
- };
-
- #define nd_ns_type nd_ns_hdr.icmp6_type
- #define nd_ns_code nd_ns_hdr.icmp6_code
- #define nd_ns_cksum nd_ns_hdr.icmp6_cksum
- #define nd_ns_reserved nd_ns_hdr.icmp6_data32[0]
-
- struct nd_neighbor_advert { /* neighbor advertisement */
- struct icmp6_hdr nd_na_hdr;
- struct in6_addr nd_na_target; /* target address */
- /* could be followed by options */
- };
-
- #define nd_na_type nd_na_hdr.icmp6_type
- #define nd_na_code nd_na_hdr.icmp6_code
- #define nd_na_cksum nd_na_hdr.icmp6_cksum
- #define nd_na_flags_reserved nd_na_hdr.icmp6_data32[0]
- #if BYTE_ORDER == BIG_ENDIAN
- #define ND_NA_FLAG_ROUTER 0x80000000
- #define ND_NA_FLAG_SOLICITED 0x40000000
- #define ND_NA_FLAG_OVERRIDE 0x20000000
- #else /* BYTE_ORDER == LITTLE_ENDIAN */
- #define ND_NA_FLAG_ROUTER 0x00000080
- #define ND_NA_FLAG_SOLICITED 0x00000040
- #define ND_NA_FLAG_OVERRIDE 0x00000020
- #endif
-
- struct nd_redirect { /* redirect */
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 15]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- struct icmp6_hdr nd_rd_hdr;
- struct in6_addr nd_rd_target; /* target address */
- struct in6_addr nd_rd_dst; /* destination address */
- /* could be followed by options */
- };
-
- #define nd_rd_type nd_rd_hdr.icmp6_type
- #define nd_rd_code nd_rd_hdr.icmp6_code
- #define nd_rd_cksum nd_rd_hdr.icmp6_cksum
- #define nd_rd_reserved nd_rd_hdr.icmp6_data32[0]
-
- struct nd_opt_hdr { /* Neighbor discovery option header */
- uint8_t nd_opt_type;
- uint8_t nd_opt_len; /* in units of 8 octets */
- /* followed by option specific data */
- };
-
- #define ND_OPT_SOURCE_LINKADDR 1
- #define ND_OPT_TARGET_LINKADDR 2
- #define ND_OPT_PREFIX_INFORMATION 3
- #define ND_OPT_REDIRECTED_HEADER 4
- #define ND_OPT_MTU 5
- #define ND_OPT_ADVINTERVAL 7
- #define ND_OPT_HOMEAGENT_INFO 8
-
- struct nd_opt_prefix_info { /* prefix information */
- uint8_t nd_opt_pi_type;
- uint8_t nd_opt_pi_len;
- uint8_t nd_opt_pi_prefix_len;
- uint8_t nd_opt_pi_flags_reserved;
- uint32_t nd_opt_pi_valid_time;
- uint32_t nd_opt_pi_preferred_time;
- uint32_t nd_opt_pi_reserved2;
- /* XXX uint8_t nd_opt_pi_reserved2[3]; */
- /* XXX uint8_t nd_opt_pi_sitelen; */
- struct in6_addr nd_opt_pi_prefix;
- };
-
- #define ND_OPT_PI_FLAG_ONLINK 0x80
- #define ND_OPT_PI_FLAG_AUTO 0x40
- #define ND_OPT_PI_FLAG_ROUTER 0x20 /* Added my Mobile IPv6 */
- #define ND_OPT_PI_FLAG_SITEPREF 0x10 /* XXX sitelen is valid */
-
- struct nd_opt_rd_hdr { /* redirected header */
- uint8_t nd_opt_rh_type;
- uint8_t nd_opt_rh_len;
- uint16_t nd_opt_rh_reserved1;
- uint32_t nd_opt_rh_reserved2;
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 16]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- /* followed by IP header and data */
- };
-
- struct nd_opt_mtu { /* MTU option */
- uint8_t nd_opt_mtu_type;
- uint8_t nd_opt_mtu_len;
- uint16_t nd_opt_mtu_reserved;
- uint32_t nd_opt_mtu_mtu;
- };
-
- struct nd_opt_advinterval { /* Advertisement Interval */
- uint8_t nd_opt_adv_type;
- uint8_t nd_opt_adv_len;
- uint16_t nd_opt_adv_reserved;
- uint32_t nd_opt_adv_interval; /* In milliseconds */
- };
-
- struct nd_opt_homeagent_info { /* Home Agent info */
- uint8_t nd_opt_hai_type;
- uint8_t nd_opt_hai_len;
- uint16_t nd_opt_hai_reserved;
- int16_t nd_opt_hai_preference;
- uint16_t nd_opt_hai_lifetime;
- };
-
- We note that the nd_na_flags_reserved flags have the same byte
- ordering problems as we discussed with ip6f_offlg.
-
-
-2.2.3. Multicast Listener Discovery Definitions
-
- The following structures and definitions are defined as a result of
- including <netinet/icmp6.h>.
-
- #define MLD_LISTENER_QUERY 130
- #define MLD_LISTENER_REPORT 131
- #define MLD_LISTENER_REDUCTION 132
-
- struct mld_hdr {
- struct icmp6_hdr mld_hdr;
- struct in6_addr mld_addr; /* multicast address */
- };
- #define mld_type mld_hdr.icmp6_type
- #define mld_code mld_hdr.icmp6_code
- #define mld_cksum mld_hdr.icmp6_cksum
- #define mld_maxdelay mld_hdr.icmp6_data16[0]
- #define mld_reserved mld_hdr.icmp6_data16[1]
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 17]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-2.2.4. ICMPv6 Router Renumbering Definitions
-
- The following structures and definitions are defined as a result of
- including <netinet/icmp6.h>.
-
- #define ICMP6_ROUTER_RENUMBERING 138 /* router renumbering */
-
- struct icmp6_router_renum { /* router renumbering header */
- struct icmp6_hdr rr_hdr;
- u_int8_t rr_segnum;
- u_int8_t rr_flags;
- u_int16_t rr_maxdelay;
- u_int32_t rr_reserved;
- };
- #define rr_type rr_hdr.icmp6_type
- #define rr_code rr_hdr.icmp6_code
- #define rr_cksum rr_hdr.icmp6_cksum
- #define rr_seqnum rr_hdr.icmp6_data32[0]
-
- /* Router renumbering flags */
- #define ICMP6_RR_FLAGS_TEST 0x80
- #define ICMP6_RR_FLAGS_REQRESULT 0x40
- #define ICMP6_RR_FLAGS_FORCEAPPLY 0x20
- #define ICMP6_RR_FLAGS_SPECSITE 0x10
- #define ICMP6_RR_FLAGS_PREVDONE 0x08
-
-
- struct rr_pco_match { /* match prefix part */
- u_int8_t rpm_code;
- u_int8_t rpm_len;
- u_int8_t rpm_ordinal;
- u_int8_t rpm_matchlen;
- u_int8_t rpm_minlen;
- u_int8_t rpm_maxlen;
- u_int16_t rpm_reserved;
- struct in6_addr rpm_prefix;
- };
-
- /* PCO code values */
- #define RPM_PCO_ADD 1
- #define RPM_PCO_CHANGE 2
- #define RPM_PCO_SETGLOBAL 3
-
- struct rr_pco_use { /* use prefix part */
- u_int8_t rpu_uselen;
- u_int8_t rpu_keeplen;
- u_int8_t rpu_ramask;
- u_int8_t rpu_raflags;
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 18]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- u_int32_t rpu_vltime;
- u_int32_t rpu_pltime;
- u_int32_t rpu_flags;
- struct in6_addr rpu_prefix;
- };
- #define ICMP6_RR_PCOUSE_RAFLAGS_ONLINK 0x20
- #define ICMP6_RR_PCOUSE_RAFLAGS_AUTO 0x10
-
- #if BYTE_ORDER == BIG_ENDIAN
- #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80000000
- #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40000000
- #elif BYTE_ORDER == LITTLE_ENDIAN
- #define ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME 0x80
- #define ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME 0x40
- #endif
-
- struct rr_result { /* router renumbering result message */
- u_int16_t rrr_flags;
- u_int8_t rrr_ordinal;
- u_int8_t rrr_matchedlen;
- u_int32_t rrr_ifid;
- struct in6_addr rrr_prefix;
- };
-
- #if BYTE_ORDER == BIG_ENDIAN
- #define ICMP6_RR_RESULT_FLAGS_OOB 0x0002
- #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0001
- #elif BYTE_ORDER == LITTLE_ENDIAN
- #define ICMP6_RR_RESULT_FLAGS_OOB 0x0200
- #define ICMP6_RR_RESULT_FLAGS_FORBIDDEN 0x0100
- #endif
-
-
-
-2.3. Address Testing Macros
-
- The basic API ([RFC-2553]) defines some macros for testing an IPv6
- address for certain properties. This API extends those definitions
- with additional address testing macros, defined as a result of
- including <netinet/in.h>.
-
- int IN6_ARE_ADDR_EQUAL(const struct in6_addr *,
- const struct in6_addr *);
-
- This macro returns non-zero if the addresses are equal; otherwise it
-
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 19]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- returns zero.
-
-
-2.4. Protocols File
-
- Many hosts provide the file /etc/protocols that contains the names of
- the various IP protocols and their protocol number (e.g., the value
- of the protocol field in the IPv4 header for that protocol, such as 1
- for ICMP). Some programs then call the function getprotobyname() to
- obtain the protocol value that is then specified as the third
- argument to the socket() function. For example, the Ping program
- contains code of the form
-
- struct protoent *proto;
-
- proto = getprotobyname("icmp");
-
- s = socket(PF_INET, SOCK_RAW, proto->p_proto);
-
- Common names are required for the new IPv6 protocols in this file, to
- provide portability of applications that call the getprotoXXX()
- functions.
-
- We define the following protocol names with the values shown. These
- are taken from ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-
- numbers.
-
- hopopt 0 # hop-by-hop options for ipv6
- ipv6 41 # ipv6
- ipv6-route 43 # routing header for ipv6
- ipv6-frag 44 # fragment header for ipv6
- esp 50 # encapsulating security payload for ipv6
- ah 51 # authentication header for ipv6
- ipv6-icmp 58 # icmp for ipv6
- ipv6-nonxt 59 # no next header for ipv6
- ipv6-opts 60 # destination options for ipv6
-
-
-
-3. IPv6 Raw Sockets
-
- Raw sockets bypass the transport layer (TCP or UDP). With IPv4, raw
- sockets are used to access ICMPv4, IGMPv4, and to read and write IPv4
- datagrams containing a protocol field that the kernel does not
- process. An example of the latter is a routing daemon for OSPF,
- since it uses IPv4 protocol field 89. With IPv6 raw sockets will be
- used for ICMPv6 and to read and write IPv6 datagrams containing a
- Next Header field that the kernel does not process. Examples of the
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 20]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- latter are a routing daemon for OSPF for IPv6 and RSVP (protocol
- field 46).
-
- All data sent via raw sockets MUST be in network byte order and all
- data received via raw sockets will be in network byte order. This
- differs from the IPv4 raw sockets, which did not specify a byte
- ordering and used the host's byte order for certain IP header fields.
-
- Another difference from IPv4 raw sockets is that complete packets
- (that is, IPv6 packets with extension headers) cannot be sent or
- received using the IPv6 raw sockets API. Instead, ancillary data
- objects are used to transfer the extension headers and hoplimit
- information, as described in Section 6. Should an application need
- access to the complete IPv6 packet, some other technique, such as the
- datalink interfaces BPF or DLPI, must be used.
-
- All fields in the IPv6 header that an application might want to
- change (i.e., everything other than the version number) can be
- modified using ancillary data and/or socket options by the
- application for output. All fields in a received IPv6 header (other
- than the version number and Next Header fields) and all extension
- headers are also made available to the application as ancillary data
- on input. Hence there is no need for a socket option similar to the
- IPv4 IP_HDRINCL socket option and on receipt the application will
- only receive the payload i.e. the data after the IPv6 header and all
- the extension headers.
-
- When writing to a raw socket the kernel will automatically fragment
- the packet if its size exceeds the path MTU, inserting the required
- fragmentation headers. On input the kernel reassembles received
- fragments, so the reader of a raw socket never sees any fragment
- headers.
-
- When we say "an ICMPv6 raw socket" we mean a socket created by
- calling the socket function with the three arguments PF_INET6,
- SOCK_RAW, and IPPROTO_ICMPV6.
-
- Most IPv4 implementations give special treatment to a raw socket
- created with a third argument to socket() of IPPROTO_RAW, whose value
- is normally 255, to have it mean that the application will send down
- complete packets including the IPv4 header. (Note: This feature was
- added to IPv4 in 1988 by Van Jacobson to support traceroute, allowing
- a complete IP header to be passed by the application, before the
- IP_HDRINCL socket option was added.) We note that IPPROTO_RAW has no
- special meaning to an IPv6 raw socket (and the IANA currently
-
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 21]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- reserves the value of 255 when used as a next-header field).
-
-
-3.1. Checksums
-
- The kernel will calculate and insert the ICMPv6 checksum for ICMPv6
- raw sockets, since this checksum is mandatory.
-
- For other raw IPv6 sockets (that is, for raw IPv6 sockets created
- with a third argument other than IPPROTO_ICMPV6), the application
- must set the new IPV6_CHECKSUM socket option to have the kernel (1)
- compute and store a checksum for output, and (2) verify the received
- checksum on input, discarding the packet if the checksum is in error.
- This option prevents applications from having to perform source
- address selection on the packets they send. The checksum will
- incorporate the IPv6 pseudo-header, defined in Section 8.1 of [RFC-
- 2460]. This new socket option also specifies an integer offset into
- the user data of where the checksum is located.
-
- int offset = 2;
- setsockopt(fd, IPPROTO_IPV6, IPV6_CHECKSUM, &offset, sizeof(offset));
-
- By default, this socket option is disabled. Setting the offset to -1
- also disables the option. By disabled we mean (1) the kernel will
- not calculate and store a checksum for outgoing packets, and (2) the
- kernel will not verify a checksum for received packets.
-
- An attempt to set IPV6_CHECKSUM for an ICMPv6 socket will fail.
-
- (Note: Since the checksum is always calculated by the kernel for an
- ICMPv6 socket, applications are not able to generate ICMPv6 packets
- with incorrect checksums (presumably for testing purposes) using this
- API.)
-
-
-3.2. ICMPv6 Type Filtering
-
- ICMPv4 raw sockets receive most ICMPv4 messages received by the
- kernel. (We say "most" and not "all" because Berkeley-derived
- kernels never pass echo requests, timestamp requests, or address mask
- requests to a raw socket. Instead these three messages are processed
- entirely by the kernel.) But ICMPv6 is a superset of ICMPv4, also
- including the functionality of IGMPv4 and ARPv4. This means that an
- ICMPv6 raw socket can potentially receive many more messages than
- would be received with an ICMPv4 raw socket: ICMP messages similar
- to ICMPv4, along with neighbor solicitations, neighbor
- advertisements, and the three multicast listener discovery messages.
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 22]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- Most applications using an ICMPv6 raw socket care about only a small
- subset of the ICMPv6 message types. To transfer extraneous ICMPv6
- messages from the kernel to user can incur a significant overhead.
- Therefore this API includes a method of filtering ICMPv6 messages by
- the ICMPv6 type field.
-
- Each ICMPv6 raw socket has an associated filter whose datatype is
- defined as
-
- struct icmp6_filter;
-
- This structure, along with the macros and constants defined later in
- this section, are defined as a result of including the
- <netinet/icmp6.h>.
-
- The current filter is fetched and stored using getsockopt() and
- setsockopt() with a level of IPPROTO_ICMPV6 and an option name of
- ICMP6_FILTER.
-
- Six macros operate on an icmp6_filter structure:
-
- void ICMP6_FILTER_SETPASSALL (struct icmp6_filter *);
- void ICMP6_FILTER_SETBLOCKALL(struct icmp6_filter *);
-
- void ICMP6_FILTER_SETPASS ( int, struct icmp6_filter *);
- void ICMP6_FILTER_SETBLOCK( int, struct icmp6_filter *);
-
- int ICMP6_FILTER_WILLPASS (int,
- const struct icmp6_filter *);
- int ICMP6_FILTER_WILLBLOCK(int,
- const struct icmp6_filter *);
-
- The first argument to the last four macros (an integer) is an ICMPv6
- message type, between 0 and 255. The pointer argument to all six
- macros is a pointer to a filter that is modified by the first four
- macros examined by the last two macros.
-
- The first two macros, SETPASSALL and SETBLOCKALL, let us specify that
- all ICMPv6 messages are passed to the application or that all ICMPv6
- messages are blocked from being passed to the application.
-
- The next two macros, SETPASS and SETBLOCK, let us specify that
- messages of a given ICMPv6 type should be passed to the application
- or not passed to the application (blocked).
-
- The final two macros, WILLPASS and WILLBLOCK, return true or false
- depending whether the specified message type is passed to the
- application or blocked from being passed to the application by the
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 23]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- filter pointed to by the second argument.
-
- When an ICMPv6 raw socket is created, it will by default pass all
- ICMPv6 message types to the application.
-
- As an example, a program that wants to receive only router
- advertisements could execute the following:
-
- struct icmp6_filter myfilt;
-
- fd = socket(PF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
-
- ICMP6_FILTER_SETBLOCKALL(&myfilt);
- ICMP6_FILTER_SETPASS(ND_ROUTER_ADVERT, &myfilt);
- setsockopt(fd, IPPROTO_ICMPV6, ICMP6_FILTER, &myfilt, sizeof(myfilt));
-
- The filter structure is declared and then initialized to block all
- messages types. The filter structure is then changed to allow router
- advertisement messages to be passed to the application and the filter
- is installed using setsockopt().
-
- The icmp6_filter structure is similar to the fd_set datatype used
- with the select() function in the sockets API. The icmp6_filter
- structure is an opaque datatype and the application should not care
- how it is implemented. All the application does with this datatype
- is allocate a variable of this type, pass a pointer to a variable of
- this type to getsockopt() and setsockopt(), and operate on a variable
- of this type using the six macros that we just defined.
-
- Nevertheless, it is worth showing a simple implementation of this
- datatype and the six macros.
-
- struct icmp6_filter {
- uint32_t icmp6_filt[8]; /* 8*32 = 256 bits */
- };
-
- #define ICMP6_FILTER_WILLPASS(type, filterp) \
- ((((filterp)->icmp6_filt[(type) >> 5]) & (1 << ((type) & 31))) != 0)
- #define ICMP6_FILTER_WILLBLOCK(type, filterp) \
- ((((filterp)->icmp6_filt[(type) >> 5]) & (1 << ((type) & 31))) == 0)
- #define ICMP6_FILTER_SETPASS(type, filterp) \
- ((((filterp)->icmp6_filt[(type) >> 5]) |= (1 << ((type) & 31))))
- #define ICMP6_FILTER_SETBLOCK(type, filterp) \
- ((((filterp)->icmp6_filt[(type) >> 5]) &= ~(1 << ((type) & 31))))
- #define ICMP6_FILTER_SETPASSALL(filterp) \
- memset((filterp), 0xFF, sizeof(struct icmp6_filter))
- #define ICMP6_FILTER_SETBLOCKALL(filterp) \
- memset((filterp), 0, sizeof(struct icmp6_filter))
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 24]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- (Note: These sample definitions have two limitations that an
- implementation may want to change. The first four macros evaluate
- their first argument two times. The second two macros require the
- inclusion of the <string.h> header for the memset() function.)
-
-
-3.3. ICMPv6 Verification of Received Packets
-
- The protocol stack will verify the ICMPv6 checksum and discard any
- packets with invalid checksums.
-
- An implementation might perform additional validity checks on the
- ICMP message content and discard malformed packets. However, a
- portable application must not assume that such validity checks have
- been performed.
-
- The protocol stack should not automatically discard packets if the
- ICMP type is unknown to the stack. For extensibility reasons received
- ICMP packets with any type (informational or error) must be passed to
- the applications (subject to ICMP6_FILTER filtering on the type value
- and the checksum verification).
-
-
-4. Access to IPv6 and Extension Headers
-
- Applications need to be able to control IPv6 header and extension
- header content when sending as well as being able to receive the
- content of these headers. This is done by defining socket option
- types which can be used both with setsockopt and with ancillary data.
- Ancillary data is discussed in Appendix A. The following optional
- information can be exchanged between the application and the kernel:
-
- 1. The send/receive interface and source/destination address,
- 2. The hop limit,
- 3. Next hop address,
- 4. Routing header.
- 5. Hop-by-Hop options, and
- 6. Destination options (both before and after a Routing header).
-
- First, to receive any of this optional information (other than the
- next hop address, which can only be set), the application must call
- setsockopt() to turn on the corresponding flag:
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 25]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-
- int on = 1;
-
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on));
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on));
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on));
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDRDSTOPTS,
- &on, sizeof(on));
-
- When any of these options are enabled, the corresponding data is
- returned as control information by recvmsg(), as one or more
- ancillary data objects.
-
- Two different mechanisms exist for sending this optional information:
-
- 1. Using setsockopt to specify the option content for a socket.
- These are known an "sticky" options since they affect all
- transmitted packets on the socket until either the a new
- setsockopt is done or the options are overridden using ancillary
- data.
-
- 2. Using ancillary data to specify the option content for a single
- datagram. This only applies to datagram and raw sockets; not to
- TCP sockets.
-
-
- The three socket option parameters and the three cmsghdr fields that
- describe the options/ancillary data objects are summarized as:
-
- opt level/ optname/ optval/
- cmsg_level cmsg_type cmsg_data[]
- ------------ ------------ ------------------------
- IPPROTO_IPV6 IPV6_PKTINFO in6_pktinfo structure
- IPPROTO_IPV6 IPV6_HOPLIMIT int
- IPPROTO_IPV6 IPV6_NEXTHOP socket address structure
- IPPROTO_IPV6 IPV6_RTHDR ip6_rthdr structure
- IPPROTO_IPV6 IPV6_HOPOPTS ip6_hbh structure
- IPPROTO_IPV6 IPV6_DSTOPTS ip6_dest structure
- IPPROTO_IPV6 IPV6_RTHDRDSTOPTS ip6_dest structure
-
-
- All these options are described in detail in Section 6, 7, 8 and 9.
- All the constants beginning with IPV6_ are defined as a result of
- including the <netinet/in.h>.
-
- Issuing getsockopt() for the above options will return the sticky
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 26]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- option value i.e. the value set with setsockopt(). If no sticky
- option value has been set getsockopt() will return the default value.
-
- Note: We intentionally use the same constant for the cmsg_level
- member as is used as the second argument to getsockopt() and
- setsockopt() (what is called the "level"), and the same constant for
- the cmsg_type member as is used as the third argument to getsockopt()
- and setsockopt() (what is called the "option name").
-
- The application does not explicitly need to access the data
- structures for the Routing header option, Hop-by-Hop option, and
- Destination options, since the API to these features is through a set
- of inet6_rth_XXX() and inet6_opt_XXX() functions that we define in
- Section 8 and Section 10. Those functions simplify the interface to
- these features instead of requiring the application to know the
- intimate details of the extension header formats.
-
-
-4.1. TCP Implications
-
- It is not possible to use ancillary data to transmit the above
- options for TCP since there is not a one-to-one mapping between send
- operations and the TCP segments being transmitted. Instead an
- application can use setsockopt to specify them as sticky options.
- When the application uses setsockopt to specify the above options it
- is expected that TCP will start using the new information when
- sending segments. However, TCP may or may not use the new
- information when retransmitting segments that were originally sent
- when the old sticky options were in effect.
-
- Applications using TCP can use ancillary data (after enabling the
- desired IPV6_RECVxxx options) to receive the IPv6 and extension
- header information. However, since there is not a one-to-one mapping
- between received TCP segments and recv operations seen by the
- application, when different TCP segments have different IPv6 and
- extension headers the application might not be able to observe all
- received headers. For efficiency reasons it is recommended that a
- TCP implementation not send ancillary data items with every received
- segment but instead try to detect the points in the data stream when
- the requested IPv6 and extension header content changes and only send
- a single ancillary data item at the time of the change. Also, TCP
- should send ancillary data items at the start of the connection and
- when the application enables a new IPV6_RECVxxx option.
-
- For example, assume an application has enabled IPV6_RECVHOPLIMIT
- before a connection is established. Then the first recvmsg() would
- have an IPV6_HOPLIMIT item indicating the hop limit in the first data
- segment. Should the hoplimit in the received data segment change a
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 27]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- subsequent recvmsg() will also have an IPV6_HOPLIMIT item. However,
- the application must be prepared to handle ancillary data items even
- though the hop limit did not change. Note that should the hop limit
- in received ACK-only segments be different than the hop limit in data
- segments the application might only be able to observe the hop limit
- in the received data segments.
-
- The above example was for hop limit but the application should be
- prepared to handle the corresponding behavior for the other option
- information.
-
- The above recvmsg() behavior allows the application to detect changes
- in the received IPv6 and extension headers without resorting to
- periodic getsockopt() calls.
-
-
-4.2. UDP and Raw Socket Implications
-
- The receive behavior for UDP and raw sockets is quite
- straightforward. After the application has enabled an IPV6_RECVxxx
- socket option it will receive ancillary data items for every
- recvmsg() call containing the requested information. However, if the
- information is not present in the packet the ancillary data item will
- not be included. For example, if the application enables
- IPV6_RECVRTHDR and a received datagram does not contain a Routing
- header there will not be an IPV6_RTHDR ancillary data item. Note
- that due to buffering in the socket implementation there might be
- some packets queued when an IPV6_RECVxxx option is enabled and they
- might not have the ancillary data information.
-
- For sending the application has the choice between using sticky
- options and ancillary data. The application can also use both having
- the sticky options specify the "default" and using ancillary data to
- override the default options. Note that if any ancillary data is
- specified in a call to sendmsg(), all of the sticky options are
- overridden for that datagram. For example, if the application has
- set IPV6_RTHDR using a sticky option and later passes IPV6_HOPLIMIT
- as ancillary data this will override the IPV6_RTHDR sticky option and
- no Routing header will be sent with that datagram.
-
-
-5. Extensions to Socket Ancillary Data
-
- This specification uses ancillary data as defined in Posix.1g which
- the following compatible extensions:
-
- - CMSG_NXTHDR has been extended to handle a NULL 2nd argument to
- mean "get the first header". See Section 22.3.2.
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 28]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- - A new CMSG_SPACE macro is defined. It is used to determine how
- much space need to be allocated for an ancillary data item. See
- Section 22.3.4.
-
- - A new CMSG_LEN macro is defined. It returns the value to store
- in the cmsg_len member of the cmsghdr structure, taking into
- account any padding needed to satisfy alignment requirements.
- See Section 22.3.5.
-
-
-6. Packet Information
-
- There are four pieces of information that an application can specify
- for an outgoing packet using ancillary data:
-
- 1. the source IPv6 address,
- 2. the outgoing interface index,
- 3. the outgoing hop limit, and
- 4. the next hop address.
-
- Three similar pieces of information can be returned for a received
- packet as ancillary data:
-
- 1. the destination IPv6 address,
- 2. the arriving interface index, and
- 3. the arriving hop limit.
-
-
- The first two pieces of information are contained in an in6_pktinfo
- structure that is set with setsockopt() or sent as ancillary data
- with sendmsg() and received as ancillary data with recvmsg(). This
- structure is defined as a result of including the <netinet/in.h>.
-
- struct in6_pktinfo {
- struct in6_addr ipi6_addr; /* src/dst IPv6 address */
- unsigned int ipi6_ifindex; /* send/recv interface index */
- };
-
- In the socket option and cmsghdr level will be IPPROTO_IPV6, the type
- will be IPV6_PKTINFO, and the first byte of the option value and
- cmsg_data[] will be the first byte of the in6_pktinfo structure. An
- application can clear any sticky IPV6_PKTINFO option by either doing
- a setsockopt for option with optlen being zero, or by doing a
- "regular" setsockopt with ipi6_addr being in6addr_any and
- ipi6_ifindex being zero.
-
- This information is returned as ancillary data by recvmsg() only if
- the application has enabled the IPV6_RECVPKTINFO socket option:
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 29]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-
- int on = 1;
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPKTINFO, &on, sizeof(on));
-
-
- (Note: The hop limit is not contained in the in6_pktinfo structure
- for the following reason. Some UDP servers want to respond to client
- requests by sending their reply out the same interface on which the
- request was received and with the source IPv6 address of the reply
- equal to the destination IPv6 address of the request. To do this the
- application can enable just the IPV6_RECVPKTINFO socket option and
- then use the received control information from recvmsg() as the
- outgoing control information for sendmsg(). The application need not
- examine or modify the in6_pktinfo structure at all. But if the hop
- limit were contained in this structure, the application would have to
- parse the received control information and change the hop limit
- member, since the received hop limit is not the desired value for an
- outgoing packet.)
-
-
-6.1. Specifying/Receiving the Interface
-
- Interfaces on an IPv6 node are identified by a small positive
- integer, as described in Section 4 of [RFC-2553]. That document also
- describes a function to map an interface name to its interface index,
- a function to map an interface index to its interface name, and a
- function to return all the interface names and indexes. Notice from
- this document that no interface is ever assigned an index of 0.
-
- When specifying the outgoing interface, if the ipi6_ifindex value is
- 0, the kernel will choose the outgoing interface. If the application
- specifies an outgoing interface for a multicast packet, the interface
- specified by the ancillary data overrides any interface specified by
- the IPV6_MULTICAST_IF socket option (described in [RFC-2553]), for
- that call to sendmsg() only.
-
- When the IPV6_RECVPKTINFO socket option is enabled, the received
- interface index is always returned as the ipi6_ifindex member of the
- in6_pktinfo structure.
-
-
-6.2. Specifying/Receiving Source/Destination Address
-
- The source IPv6 address can be specified by calling bind() before
- each output operation, but supplying the source address together with
- the data requires less overhead (i.e., fewer system calls) and
- requires less state to be stored and protected in a multithreaded
- application.
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 30]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- When specifying the source IPv6 address as ancillary data, if the
- ipi6_addr member of the in6_pktinfo structure is the unspecified
- address (IN6ADDR_ANY_INIT or in6addr_any), then (a) if an address is
- currently bound to the socket, it is used as the source address, or
- (b) if no address is currently bound to the socket, the kernel will
- choose the source address. If the ipi6_addr member is not the
- unspecified address, but the socket has already bound a source
- address, then the ipi6_addr value overrides the already-bound source
- address for this output operation only.
-
- The kernel must verify that the requested source address is indeed a
- unicast address assigned to the node.
-
- When the in6_pktinfo structure is returned as ancillary data by
- recvmsg(), the ipi6_addr member contains the destination IPv6 address
- from the received packet.
-
-
-6.3. Specifying/Receiving the Hop Limit
-
- The outgoing hop limit is normally specified with either the
- IPV6_UNICAST_HOPS socket option or the IPV6_MULTICAST_HOPS socket
- option, both of which are described in [RFC-2553]. Specifying the
- hop limit as ancillary data lets the application override either the
- kernel's default or a previously specified value, for either a
- unicast destination or a multicast destination, for a single output
- operation. Returning the received hop limit is useful for programs
- such as Traceroute and for IPv6 applications that need to verify that
- the received hop limit is 255 (e.g., that the packet has not been
- forwarded).
-
- The received hop limit is returned as ancillary data by recvmsg()
- only if the application has enabled the IPV6_RECVHOPLIMIT socket
- option:
-
- int on = 1;
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &on, sizeof(on));
-
- In the cmsghdr structure containing this ancillary data, the
- cmsg_level member will be IPPROTO_IPV6, the cmsg_type member will be
- IPV6_HOPLIMIT, and the first byte of cmsg_data[] will be the first
- byte of the integer hop limit.
-
- Nothing special need be done to specify the outgoing hop limit: just
- specify the control information as ancillary data for sendmsg() or
- using setsockopt(). As specified in [RFC-2553], the interpretation
- of the integer hop limit value is
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 31]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-
- x < -1: return an error of EINVAL
- x == -1: use kernel default
- 0 <= x <= 255: use x
- x >= 256: return an error of EINVAL
-
-
- In order to clear a sticky IPV6_HOPLIMIT option the application can
- specify -1 as the value. Alternatively, the application can specify
- an IPV6_HOPLIMIT socket option with a zero length.
-
-
-6.4. Specifying the Next Hop Address
-
- The IPV6_NEXTHOP ancillary data object specifies the next hop for the
- datagram as a socket address structure. In the cmsghdr structure
- containing this ancillary data, the cmsg_level member will be
- IPPROTO_IPV6, the cmsg_type member will be IPV6_NEXTHOP, and the
- first byte of cmsg_data[] will be the first byte of the socket
- address structure.
-
- This is a privileged option. (Note: It is implementation defined and
- beyond the scope of this document to define what "privileged" means.
- Unix systems use this term to mean the process must have an effective
- user ID of 0.)
-
- If the socket address structure contains an IPv6 address (e.g., the
- sin6_family member is AF_INET6), then the node identified by that
- address must be a neighbor of the sending host. If that address
- equals the destination IPv6 address of the datagram, then this is
- equivalent to the existing SO_DONTROUTE socket option.
-
- In order to clear a sticky IPV6_NEXTHOP option the application must
- issue a setsockopt for IPv6_NEXTHOP with a zero length.
-
-
-
-6.5. Additional Errors with sendmsg() and setsockopt()
-
- With the IPV6_PKTINFO socket option there are no additional errors
- possible with the call to recvmsg(). But when specifying the
- outgoing interface or the source address, additional errors are
- possible from sendmsg() or setsockopt(). Note that some
- implementations might only be able to return this type of errors for
- setsockopt(). The following are examples, but some of these may not
- be provided by some implementations, and some implementations may
- define additional errors:
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 32]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- ENXIO The interface specified by ipi6_ifindex does not exist.
-
- ENETDOWN The interface specified by ipi6_ifindex is not enabled
- for IPv6 use.
-
- EADDRNOTAVAIL ipi6_ifindex specifies an interface but the address
- ipi6_addr is not available for use on that interface.
-
- EHOSTUNREACH No route to the destination exists over the interface
- specified by ifi6_ifindex.
-
-
-7. Routing Header Option
-
- Source routing in IPv6 is accomplished by specifying a Routing header
- as an extension header. There can be different types of Routing
- headers, but IPv6 currently defines only the Type 0 Routing header
- [RFC-2460]. This type supports up to 127 intermediate nodes (limited
- by the length field in the extension header). With this maximum
- number of intermediate nodes, a source, and a destination, there are
- 128 hops.
-
- Source routing with IPv4 sockets API (the IP_OPTIONS socket option)
- requires the application to build the source route in the format that
- appears as the IPv4 header option, requiring intimate knowledge of
- the IPv4 options format. This IPv6 API, however, defines six
- functions that the application calls to build and examine a Routing
- header, and the ability to use sticky options or ancillary data to
- communicate this information between the application and the kernel
- using the IPV6_RTHDR option.
-
- Three functions build a Routing header:
-
- inet6_rth_space() - return #bytes required for Routing header
- inet6_rth_init() - initialize buffer data for Routing header
- inet6_rth_add() - add one IPv6 address to the Routing header
-
- Three functions deal with a returned Routing header:
-
- inet6_rth_reverse() - reverse a Routing header
- inet6_rth_segments() - return #segments in a Routing header
- inet6_rth_getaddr() - fetch one address from a Routing header
-
- The function prototypes for these functions are defined as a result
- of including the <netinet/in.h>.
-
- To receive a Routing header the application must enable the
- IPV6_RECVRTHDR socket option:
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 33]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-
- int on = 1;
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on));
-
- To send a Routing header the application specifies it either as
- ancillary data in a call to sendmsg() or using setsockopt().
-
- The application can remove any sticky Routing header by calling
- setsockopt() for IPV6_RTHDR with a zero option length.
-
- When using ancillary data a Routing header is passed between the
- application and the kernel as follows: The cmsg_level member has a
- value of IPPROTO_IPV6 and the cmsg_type member has a value of
- IPV6_RTHDR. The contents of the cmsg_data[] member is implementation
- dependent and should not be accessed directly by the application, but
- should be accessed using the six functions that we are about to
- describe.
-
- The following constant is defined as a result of including the
- <netinet/in.h>:
-
- #define IPV6_RTHDR_TYPE_0 0 /* IPv6 Routing header type 0 */
-
- When a Routing header is specified, the destination address specified
- for connect(), sendto(), or sendmsg() is the final destination
- address of the datagram. The Routing header then contains the
- addresses of all the intermediate nodes.
-
-
-7.1. inet6_rth_space
-
-
- size_t inet6_rth_space(int type, int segments);
-
- This function returns the number of bytes required to hold a Routing
- header of the specified type containing the specified number of
- segments (addresses). For an IPv6 Type 0 Routing header, the number
- of segments must be between 0 and 127, inclusive. The return value
- is just the space for the Routing header. When the application uses
- ancillary data it must pass the returned length to CMSG_LEN() to
- determine how much memory is needed for the ancillary data object
- (including the cmsghdr structure).
-
- If the return value is 0, then either the type of the Routing header
- is not supported by this implementation or the number of segments is
- invalid for this type of Routing header.
-
- (Note: This function returns the size but does not allocate the space
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 34]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- required for the ancillary data. This allows an application to
- allocate a larger buffer, if other ancillary data objects are
- desired, since all the ancillary data objects must be specified to
- sendmsg() as a single msg_control buffer.)
-
-
-7.2. inet6_rth_init
-
-
- void *inet6_rth_init(void *bp, int bp_len, int type, int segments);
-
- This function initializes the buffer pointed to by bp to contain a
- Routing header of the specified type and sets ip6r_len based on the
- segments parameter. bp_len is only used to verify that the buffer is
- large enough. The ip6r_segleft field is set to zero; inet6_rth_add()
- will increment it.
-
- When the application uses ancillary data the application must
- initialize any cmsghdr fields.
-
- The caller must allocate the buffer and its size can be determined by
- calling inet6_rth_space().
-
- Upon success the return value is the pointer to the buffer (bp), and
- this is then used as the first argument to the inet6_rth_add()
- function. Upon an error the return value is NULL.
-
-
-7.3. inet6_rth_add
-
-
- int inet6_rth_add(void *bp, const struct in6_addr *addr);
-
- This function adds the IPv6 address pointed to by addr to the end of
- the Routing header being constructed.
-
- If successful, the segleft member of the Routing Header is updated to
- account for the new address in the Routing header and the return
- value of the function is 0. Upon an error the return value of the
- function is -1.
-
-
-7.4. inet6_rth_reverse
-
-
- int inet6_rth_reverse(const void *in, void *out);
-
- This function takes a Routing header extension header (pointed to by
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 35]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- the first argument) and writes a new Routing header that sends
- datagrams along the reverse of that route. The function reverses the
- order of the addresses and sets the segleft member in the new Routing
- header to the number of segments. Both arguments are allowed to
- point to the same buffer (that is, the reversal can occur in place).
-
- The return value of the function is 0 on success, or -1 upon an
- error.
-
-
-7.5. inet6_rth_segments
-
-
- int inet6_rth_segments(const void *bp);
-
- This function returns the number of segments (addresses) contained in
- the Routing header described by bp. On success the return value is
- zero or greater. The return value of the function is -1 upon an
- error.
-
-
-7.6. inet6_rth_getaddr
-
-
- struct in6_addr *inet6_rth_getaddr(const void *bp, int index);
-
- This function returns a pointer to the IPv6 address specified by
- index (which must have a value between 0 and one less than the value
- returned by inet6_rth_segments()) in the Routing header described by
- bp. An application should first call inet6_rth_segments() to obtain
- the number of segments in the Routing header.
-
- Upon an error the return value of the function is NULL.
-
-
-8. Hop-By-Hop Options
-
- A variable number of Hop-by-Hop options can appear in a single Hop-
- by-Hop options header. Each option in the header is TLV-encoded with
- a type, length, and value.
-
- Today only four Hop-by-Hop options are defined for IPv6 [RFC-2460]:
- Jumbo Payload, Pad1, PadN, and router-alert. The two pad options are
- for alignment purposes and are automatically inserted by the
- inet6_opt_XXX() routines and ignored by the inet6_opt_XXX() routines
- on the receive side.
-
- This section of the API is therefore defined for future Hop-by-Hop
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 36]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- options (as well as destination options) that an application may need
- to specify and receive. This IPv6 API defines seven functions that
- the application calls to build and examine a Hop-by_Hop options
- header, and the ability to use sticky options or ancillary data to
- communicate this information between the application and the kernel.
- This uses the IPV6_HOPOPTS for hob-by-hop options.
-
- Four functions build a options header:
-
- inet6_opt_init() - initialize buffer data for options header
- inet6_opt_append() - add one TLV option to the options header
- inet6_opt_finish() - finish adding TLV options to the options header
- inet6_opt_set_val() - add one component of the option content to the option
-
- Three functions deal with a returned options header:
-
- inet6_opt_next() - extract the next option from the options header
- inet6_opt_find() - extract an option of a specified type from the header
- inet6_opt_get_val() - retrieve one component of the option content
-
-
- Individual Hop-by-Hop options (and Destination options, which are
- described in Section 9 and are very similar to the Hop-by-Hop
- options) may have specific alignment requirements. For example, the
- 4-byte Jumbo Payload length should appear on a 4-byte boundary, and
- IPv6 addresses are normally aligned on an 8-byte boundary. These
- requirements and the terminology used with these options are
- discussed in Section 4.2 and Appendix B of [RFC-2460]. The alignment
- of first byte of each option is specified by two values, called x and
- y, written as "xn + y". This states that the option must appear at
- an integer multiple of x bytes from the beginning of the options
- header (x can have the values 1, 2, 4, or 8), plus y bytes (y can
- have a value between 0 and 7, inclusive). The Pad1 and PadN options
- are inserted as needed to maintain the required alignment. The
- functions below need to know the alignment of the end of the option
- (which is always in the form "xn," where x can have the values 1, 2,
- 4, or 8) and the total size of the data portion of the option. These
- are passed as the "align" and "len" arguments to inet6_opt_append().
-
- Multiple Hop-by-Hop options must be specified by the application by
- placing them in a single extension header.
-
- Finally, we note that use of some Hop-by-Hop options or some
- Destination options, might require special privilege. That is,
- normal applications (without special privilege) might be forbidden
- from setting certain options in outgoing packets, and might never see
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 37]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- certain options in received packets.
-
-
-8.1. Receiving Hop-by-Hop Options
-
- To receive Hop-by-Hop options the application must enable the
- IPV6_RECVHOPOPTS socket option:
-
- int on = 1;
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVHOPOPTS, &on, sizeof(on));
-
- When using ancillary data a Hop-by-hop options is passed between the
- application and the kernel as follows: The cmsg_level member will be
- IPPROTO_IPV6 and the cmsg_type member will be IPV6_HOPOPTS. These
- options are then processed by calling the inet6_opt_next(),
- inet6_opt_find(), and inet6_opt_get_val() functions, described in
- Section 10.6.
-
-
-8.2. Sending Hop-by-Hop Options
-
- To send a Hop-by-Hop options header, the application specifies the
- header either as ancillary data in a call to sendmsg() or using
- setsockopt().
-
- The application can remove any sticky Hop-by-Hop extension header by
- calling setsockopt() for IPV6_HOPOPTS with a zero option length.
-
- All the Hop-by-Hop options must specified by a single ancillary data
- object. The cmsg_level member is set to IPPROTO_IPV6 and the
- cmsg_type member is set to IPV6_HOPOPTS. The option is normally
- constructed using the inet6_opt_init(), inet6_opt_append(),
- inet6_opt_finish(), and inet6_set_val() functions, described in
- Section 10.
-
- Additional errors may be possible from sendmsg() and setsockopt() if
- the specified option is in error.
-
-
-9. Destination Options
-
- A variable number of Destination options can appear in one or more
- Destination option headers. As defined in [RFC-2460], a Destination
- options header appearing before a Routing header is processed by the
- first destination plus any subsequent destinations specified in the
- Routing header, while a Destination options header appearing after a
- Routing header is processed only by the final destination. As with
- the Hop-by-Hop options, each option in a Destination options header
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 38]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- is TLV-encoded with a type, length, and value.
-
- Today no Destination options are defined for IPv6 [RFC-2460],
- although proposals exist to use Destination options with Mobile IPv6.
-
-
-9.1. Receiving Destination Options
-
- To receive Destination options appearing after a Routing header (or
- in a packet without a Routing header) the application must enable the
- IPV6_RECVDSTOPTS socket option:
-
- int on = 1;
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVDSTOPTS, &on, sizeof(on));
-
- To receive Destination options appearing before a Routing header the
- application must enable the IPV6_RECVRTHDRDSTOPTS socket option:
-
- int on = 1;
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDRDSTOPTS,
- &on, sizeof(on));
-
- All the Destination options appearing before a Routing header are
- returned as one ancillary data object described by a cmsghdr
- structure (with cmsg_type set to IPV6_RTHDRDSTOPTS) and all the
- Destination options appearing after a Routing header (or in a packet
- without a Routing header) are returned as another ancillary data
- object described by a cmsghdr structure (with cmsg_type set to
- IPV6_DSTOPTS). For all these ancillary data objects, the cmsg_level
- member will be IPPROTO_IPV6.
-
- These options are then processed by calling the inet6_opt_next(),
- inet6_opt_find(), and inet6_opt_get_value() functions.
-
-
-9.2. Sending Destination Options
-
- To send a Destination options header, the application specifies it
- either as ancillary data in a call to sendmsg() or using
- setsockopt().
-
- The application can remove any sticky Destination extension header by
- calling setsockopt() for IPV6_RTHDRDSTOPTS/IPV6_DSTOPTS with a zero
- option length.
-
- As described in Section 6 one set of Destination options can appear
- before a Routing header, and one set can appear after a Routing
- header (or in a packet with no Routing header). Each set can consist
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 39]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- of one or more options but each set is a single extension header.
-
- When using ancillary data a Destination options header is passed
- between the application and the kernel as follows: The set preceding
- a Routing header are specified with the cmsg_level member is set to
- IPPROTO_IPV6 and the cmsg_type member is set to IPV6_RTHDRDSTOPTS.
- Any setsockopt or ancillary data for IPV6_RTHDRDSTOPTS is silently
- ignored when sending packets unless a Routing header is also
- specified.
-
- The set of Destination options after a Routing header, which are also
- used when no Routing header is present, are specified with the
- cmsg_level member is set to IPPROTO_IPV6 and the cmsg_type member is
- set to IPV6_DSTOPTS.
-
- The Destination options are normally constructed using the
- inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and
- inet6_set_val() functions, described in Section 10.
-
- Additional errors may be possible from sendmsg() and setsockopt() if
- the specified option is in error.
-
-
-10. Hop-by-Hop and Destination Options Processing
-
- Building and parsing the Hop-by-Hop and Destination options is
- complicated for the reasons given earlier. We therefore define a set
- of functions to help the application. These functions assume the
- formatting rules specified in Appendix B in [RFC-2460] i.e. that the
- largest field is placed last in the option.
-
- The function prototypes for these functions are defined as a result
- of including the <netinet/in.h>.
-
- The first 3 functions (init, append, and finish) are used both to
- calculate the needed buffer size for the options, and to actually
- encode the options once the application has allocated a buffer for
- the header. In order to only calculate the size the application must
- pass a NULL extbuf and a zero extlen to those functions.
-
-
-10.1. inet6_opt_init
-
-
- int inet6_opt_init(void *extbuf, size_t extlen);
-
- This function returns the number of bytes needed for the empty
- extension header i.e. without any options. If extbuf is not NULL it
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 40]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- also initializes the extension header to have the correct length
- field. In that case if the extlen value is not a positive (i.e.,
- non-zero) multiple of 8 the function fails and returns -1.
-
-
-10.2. inet6_opt_append
-
-
- int inet6_opt_append(void *extbuf, size_t extlen, int prevlen,
- uint8_t type, size_t len, uint_t align,
- void **databufp);
-
- Prevlen should be the length returned by inet6_opt_init() or a
- previous inet6_opt_append(). This function returns the updated total
- length taking into account adding an option with length 'len' and
- alignment 'align'. If extbuf is not NULL then, in addition to
- returning the length, the function inserts any needed pad option,
- initializes the option (setting the type and length fields) and
- returns a pointer to the location for the option content in databufp.
- If the option does not fit in the extension header buffer the
- function returns -1.
-
- Type is the 8-bit option type. Len is the length of the option data
- (i.e. excluding the option type and option length fields).
-
- Once inet6_opt_append() has been called the application can use the
- databuf directly, or use inet6_opt_set_val() to specify the content
- of the option.
-
- The option type must have a value from 2 to 255, inclusive. (0 and 1
- are reserved for the Pad1 and PadN options, respectively.)
-
- The option data length must have a value between 0 and 255,
- inclusive, and is the length of the option data that follows.
-
- The align parameter must have a value of 1, 2, 4, or 8. The align
- value can not exceed the value of len.
-
-
-10.3. inet6_opt_finish
-
-
- int inet6_opt_finish(void *extbuf, size_t extlen, int prevlen);
-
- Prevlen should be the length returned by inet6_opt_init() or
- inet6_opt_append(). This function returns the updated total length
- taking into account the final padding of the extension header to make
- it a multiple of 8 bytes. If extbuf is not NULL the function also
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 41]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- initializes the option by inserting a Pad1 or PadN option of the
- proper length.
-
- If the necessary pad does not fit in the extension header buffer the
- function returns -1.
-
-
-10.4. inet6_opt_set_val
-
-
- int inet6_opt_set_val(void *databuf, size_t offset, void *val,
- int vallen);
-
- Databuf should be a pointer returned by inet6_opt_append(). This
- function inserts data items of various sizes (1, 2, 4, or 8 bytes) in
- the data portion of the option. Val should point to the data to be
- inserted. Offset specifies where in the data portion of the option
- the value should be inserted; the first byte after the option type
- and length is accessed by specifying an offset of zero.
-
- The function returns the offset for the next field (i.e., offset +
- vallen) which can be used when composing option content with multiple
- fields.
-
-
-10.5. inet6_opt_next
-
-
- int inet6_opt_next(void *extbuf, size_t extlen, int prevlen,
- uint8_t *typep, size_t *lenp,
- void **databufp);
-
- This function parses received option extension headers returning the
- next option. Extbuf and extlen specifies the extension header.
- Prevlen should either be zero (for the first option) or the length
- returned by a previous call to inet6_opt_next() or inet6_opt_find().
- It specifies the position where to continue scanning the extension
- buffer. The next option is returned by updating typep, lenp, and
- databufp. This function returns the updated "previous" length
- computed by advancing past the option that was returned. This
- returned "previous" length can then be passed to subsequent calls to
- inet6_opt_next(). This function does not return any PAD1 or PADN
- options. When there are no more options or if the option extension
- header is malformed the return value is -1.
-
-
-10.6. inet6_opt_find
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 42]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-
- int inet6_opt_find(void *extbuf, size_t extlen, int prevlen,
- uint8_t type, size_t *lenp,
- void **databufp);
-
- This function is similar to the previously described inet6_opt_next()
- function, except this function lets the caller specify the option
- type to be searched for, instead of always returning the next option
- in the extension header.
-
- If an option of the specified type is located, the function returns
- the updated "previous" total length computed by advancing past the
- option that was returned and past any options that didn't match the
- type. This returned "previous" length can then be passed to
- subsequent calls to inet6_opt_find() for finding the next occurrence
- of the same option type.
-
- If an option of the specified type is not located, the return value
- is -1. If the option extension header is malformed, the return value
- is -1.
-
-
-10.7. inet6_opt_get_val
-
-
- int inet6_opt_get_val(void *databuf, size_t offset, void *val,
- int vallen);
-
- Databuf should be a pointer returned by inet6_opt_next() or
- inet6_opt_find(). This function extracts data items of various sizes
- (1, 2, 4, or 8 bytes) in the data portion of the option. Val should
- point to the destination for the extracted data. Offset specifies
- from where in the data portion of the option the value should be
- extracted; the first byte after the option type and length is
- accessed by specifying an offset of zero.
-
- The function returns the offset for the next field (i.e., offset +
- vallen) which can be used when extracting option content with
- multiple fields.
-
-
-11. Additional Advanced API Functions
-
-
-
-11.1. Sending with the Minimum MTU
-
- Some applications might not want to incur the overhead of path MTU
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 43]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- discovery, especially if the applications only send a single datagram
- to a destination. A potential example is a DNS server.
-
- This specification defines a mechanism to avoid path MTU discovery by
- sending at the minimum IPv6 MTU [RFC-2460]. If the packet is larger
- than the minimum MTU and this feature has been enabled the IP layer
- will fragment to the minimum MTU. This can be enabled using the
- IPV6_USE_MIN_MTU socket option.
-
- int on = 1;
- setsockopt(fd, IPPROTO_IPV6, IPV6_USE_MIN_MTU, &on, sizeof(on));
-
- By default, this socket option is disabled. Setting the value to 0
- also disables the option. This option can also be sent as ancillary
- data.
-
-
-
-11.2. Path MTU Discovery and UDP
-
- UDP and raw socket applications need to be able to determine the
- "maximum send transport-message size" (Section 5.1 of [RFC-1981]) to
- a given destination so that those applications can participate in
- path MTU discovery. This lets those applications send smaller
- datagrams to the destination, avoiding fragmentation.
-
- This is accomplished using a new ancillary data item (IPV6_PATHMTU)
- which is delivered to recvmsg() without any actual data. The
- application enable the receipt of IPV6_PATHMTU ancillary data items
- by enabing IPV6_RECVPATHMTU.
-
- int on = 1;
- setsockopt(fd, IPPROTO_IPV6, IPV6_RECVPATHMTU, &on, sizeof(on));
-
- By default, this socket option is disabled. Setting the value to 0
- also disables the option.
-
- When the application is sending packets too big for the path MTU
- recvmsg will return zero (indicating no data) but there will be a
- cmsghdr with cmsg_type set to IPV6_PATHMTU, and cmsg_len will
- indicate that cmsg_data is 4 bytes long. CMSG_DATA will point to an
- integer carrying the path MTU to use.
-
-
-11.3. Neighbor Reachability and UDP
-
- UDP and raw socket application might know that communication is
- making forward progress i.e. that the path from the node to the next
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 44]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- hop is working. In such a case the applications, similarly to TCP as
- specified in [RFC-2461], has the option indicate to the internet
- layer that the neighbor is reachable. See section 7.3.1 of [RFC-
- 2461]. This could save unneeded neighbor solicitation and neighbor
- advertisement messages.
-
- This is done by including an ancilary data item with cmsg_type being
- IPV6_REACHCONF and with no attached CMSG_DATA.
-
- If implementations honor the IPV6_REACHCONF from any application
- there is a possibility that, when there is an unreachability
- situation, one application can cause a denial of service attack on
- anogther application running on the same node by periodically issuing
- sendmsg() with an IPV6_REACHCONF ancillary data item to prevent the
- Neighbor Unreachability Detection algoritm to send probe messages and
- declare the neighbor unreachable. It is unclear whether
- implementations need to mitigate this very minor threat by e.g.
- restricting IPV6_REACHCONF to priviledged applications.
-
-
-12. Ordering of Ancillary Data and IPv6 Extension Headers
-
- Three IPv6 extension headers can be specified by the application and
- returned to the application using ancillary data with sendmsg() and
- recvmsg(): the Routing header, Hop-by-Hop options, and Destination
- options. When multiple ancillary data objects are transferred via
- recvmsg() and these objects represent any of these three extension
- headers, their placement in the control buffer is directly tied to
- their location in the corresponding IPv6 datagram. This API imposes
- some ordering constraints for using these ancillary data objects with
- sendmsg().
-
- All Hop-by-Hop options must be specified in a single ancillary data
- object. Should multiple hop-by-hop ancillary data objects be
- specified the implementation might choose an arbitrary one or drop
- the packet.
-
- All Destination options that precede a Routing header must be
- specified in a single ancillary data object. If there is no Routing
- header ancillary data object the IPV6_RTHDRDSTOPTS object will be
- silently ignored.
-
- All Destination options that follow a Routing header (or are used
- without a Routing header) must be specified in a single ancillary
- data object.
-
- If Destination options are specified in the control buffer after a
- Routing header, or if Destination options are specified without a
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 45]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- Routing header, the kernel will place those Destination options after
- an authentication header and/or an encapsulating security payload
- header, if present.
-
-
-13. IPv6-Specific Options with IPv4-Mapped IPv6 Addresses
-
- The various socket options and ancillary data specifications defined
- in this document apply only to true IPv6 sockets. It is possible to
- create an IPv6 socket that actually sends and receives IPv4 packets,
- using IPv4-mapped IPv6 addresses, but the mapping of the options
- defined in this document to an IPv4 datagram is beyond the scope of
- this document.
-
- In general, attempting to specify an IPv6-only option, such as the
- Hop-by-Hop options, Destination options, or Routing header on an IPv6
- socket that is using IPv4-mapped IPv6 addresses, will probably result
- in an error. Some implementations, however, may provide access to
- the packet information (source/destination address, send/receive
- interface, and hop limit) on an IPv6 socket that is using IPv4-mapped
- IPv6 addresses.
-
-
-14. Extended interfaces for rresvport, rcmd and rexec
-
- TBD
-
-
-14.1. rresvport_af
-
- The rresvport() function is used by the rcmd() function, and this
- function is in turn called by many of the "r" commands such as
- rlogin. While new applications are not being written to use the
- rcmd() function, legacy applications such as rlogin will continue to
- use it and these will be ported to IPv6.
-
- rresvport() creates an IPv4/TCP socket and binds a "reserved port" to
- the socket. Instead of defining an IPv6 version of this function we
- define a new function that takes an address family as its argument.
-
- #include <unistd.h>
-
- int rresvport_af(int *port, int family);
-
- This function behaves the same as the existing rresvport() function,
- but instead of creating an AF_INET TCP socket, it can also create an
- AF_INET6 TCP socket. The family argument is either AF_INET or
- AF_INET6, and a new error return is EAFNOSUPPORT if the address
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 46]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- family is not supported.
-
- (Note: There is little consensus on which header defines the
- rresvport() and rcmd() function prototypes. 4.4BSD defines it in
- <unistd.h>, others in <netdb.h>, and others don't define the function
- prototypes at all.)
-
-
-14.2. rcmd_af
-
- The existing rcmd() function can not transparently use AF_INET6
- sockets since the an application would not be prepared to handle
- AF_INET6 addresses returned by e.g. getpeername on the file
- descriptor created by rcmd. Thus a new function is needed.
-
- int rcmd_af(char **ahost, unsigned short rport, const char *locuser,
- const char *remuser, const char *cmd, int *fd2p, int af)
-
- This function behaves the same as the existing rcmd() function, but
- instead of creating an AF_INET TCP socket, it can also create an
- AF_INET6 TCP socket. The family argument is either AF_INET or
- AF_INET6, and a new error return is EAFNOSUPPORT if the address
- family is not supported.
-
-
-14.3. rexec_af
-
- The existing rexec() function can not transparently use AF_INET6
- sockets since the an application would not be prepared to handle
- AF_INET6 addresses returned by e.g. getpeername on the file
- descriptor created by rexec. Thus a new function is needed.
-
- int rexec_af(char **ahost, unsigned short rport, const char *name,
- const char *pass, const char *cmd, int *fd2p, int af)
-
- This function behaves the same as the existing rexec() function, but
- instead of creating an AF_INET TCP socket, it can also create an
- AF_INET6 TCP socket. The family argument is either AF_INET or
- AF_INET6, and a new error return is EAFNOSUPPORT if the address
- family is not supported.
-
-
-15. Summary of New Definitions
-
- The following list summarizes the constants and structure,
- definitions discussed in this memo, sorted by header.
-
- <netinet/icmp6.h> ICMP6_DST_UNREACH
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 47]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- <netinet/icmp6.h> ICMP6_DST_UNREACH_ADDR
- <netinet/icmp6.h> ICMP6_DST_UNREACH_ADMIN
- <netinet/icmp6.h> ICMP6_DST_UNREACH_BEYONDSCOPE
- <netinet/icmp6.h> ICMP6_DST_UNREACH_NOPORT
- <netinet/icmp6.h> ICMP6_DST_UNREACH_NOROUTE
- <netinet/icmp6.h> ICMP6_ECHO_REPLY
- <netinet/icmp6.h> ICMP6_ECHO_REQUEST
- <netinet/icmp6.h> ICMP6_INFOMSG_MASK
- <netinet/icmp6.h> ICMP6_PACKET_TOO_BIG
- <netinet/icmp6.h> ICMP6_PARAMPROB_HEADER
- <netinet/icmp6.h> ICMP6_PARAMPROB_NEXTHEADER
- <netinet/icmp6.h> ICMP6_PARAMPROB_OPTION
- <netinet/icmp6.h> ICMP6_PARAM_PROB
- <netinet/icmp6.h> ICMP6_ROUTER_RENUMBERING
- <netinet/icmp6.h> ICMP6_RR_FLAGS_FORCEAPPLY
- <netinet/icmp6.h> ICMP6_RR_FLAGS_PREVDONE
- <netinet/icmp6.h> ICMP6_RR_FLAGS_REQRESULT
- <netinet/icmp6.h> ICMP6_RR_FLAGS_SPECSITE
- <netinet/icmp6.h> ICMP6_RR_FLAGS_TEST
- <netinet/icmp6.h> ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME
- <netinet/icmp6.h> ICMP6_RR_PCOUSE_FLAGS_DECRPLTIME
- <netinet/icmp6.h> ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME
- <netinet/icmp6.h> ICMP6_RR_PCOUSE_FLAGS_DECRVLTIME
- <netinet/icmp6.h> ICMP6_RR_PCOUSE_RAFLAGS_AUTO
- <netinet/icmp6.h> ICMP6_RR_PCOUSE_RAFLAGS_ONLINK
- <netinet/icmp6.h> ICMP6_RR_RESULT_FLAGS_FORBIDDEN
- <netinet/icmp6.h> ICMP6_RR_RESULT_FLAGS_FORBIDDEN
- <netinet/icmp6.h> ICMP6_RR_RESULT_FLAGS_OOB
- <netinet/icmp6.h> ICMP6_RR_RESULT_FLAGS_OOB
- <netinet/icmp6.h> ICMP6_TIME_EXCEEDED
- <netinet/icmp6.h> ICMP6_TIME_EXCEED_REASSEMBLY
- <netinet/icmp6.h> ICMP6_TIME_EXCEED_TRANSIT
- <netinet/icmp6.h> MLD_LISTENER_QUERY
- <netinet/icmp6.h> MLD_LISTENER_REDUCTION
- <netinet/icmp6.h> MLD_LISTENER_REPORT
- <netinet/icmp6.h> ND_NA_FLAG_OVERRIDE
- <netinet/icmp6.h> ND_NA_FLAG_ROUTER
- <netinet/icmp6.h> ND_NA_FLAG_SOLICITED
- <netinet/icmp6.h> ND_NEIGHBOR_ADVERT
- <netinet/icmp6.h> ND_NEIGHBOR_SOLICIT
- <netinet/icmp6.h> ND_OPT_MTU
- <netinet/icmp6.h> ND_OPT_PI_FLAG_AUTO
- <netinet/icmp6.h> ND_OPT_PI_FLAG_ONLINK
- <netinet/icmp6.h> ND_OPT_PI_FLAG_ROUTER
- <netinet/icmp6.h> ND_OPT_PI_FLAG_SITEPREF
- <netinet/icmp6.h> ND_OPT_PREFIX_INFORMATION
- <netinet/icmp6.h> ND_OPT_REDIRECTED_HEADER
- <netinet/icmp6.h> ND_OPT_SOURCE_LINKADDR
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 48]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- <netinet/icmp6.h> ND_OPT_TARGET_LINKADDR
- <netinet/icmp6.h> ND_RA_FLAG_HOME_AGENT
- <netinet/icmp6.h> ND_RA_FLAG_MANAGED
- <netinet/icmp6.h> ND_RA_FLAG_OTHER
- <netinet/icmp6.h> ND_REDIRECT
- <netinet/icmp6.h> ND_ROUTER_ADVERT
- <netinet/icmp6.h> ND_ROUTER_SOLICIT
-
- <netinet/icmp6.h> struct icmp6_filter{};
- <netinet/icmp6.h> struct icmp6_hdr{};
- <netinet/icmp6.h> struct icmp6_router_renum{};
- <netinet/icmp6.h> struct mld_hdr{};
- <netinet/icmp6.h> struct nd_neighbor_advert{};
- <netinet/icmp6.h> struct nd_neighbor_solicit{};
- <netinet/icmp6.h> struct nd_opt_hdr{};
- <netinet/icmp6.h> struct nd_opt_mtu{};
- <netinet/icmp6.h> struct nd_opt_prefix_info{};
- <netinet/icmp6.h> struct nd_opt_rd_hdr{};
- <netinet/icmp6.h> struct nd_redirect{};
- <netinet/icmp6.h> struct nd_router_advert{};
- <netinet/icmp6.h> struct nd_router_solicit{};
- <netinet/icmp6.h> struct rr_pco_match{};
- <netinet/icmp6.h> struct rr_pco_use{};
- <netinet/icmp6.h> struct rr_result{};
-
- <netinet/in.h> IPPROTO_AH
- <netinet/in.h> IPPROTO_DSTOPTS
- <netinet/in.h> IPPROTO_ESP
- <netinet/in.h> IPPROTO_FRAGMENT
- <netinet/in.h> IPPROTO_HOPOPTS
- <netinet/in.h> IPPROTO_ICMPV6
- <netinet/in.h> IPPROTO_IPV6
- <netinet/in.h> IPPROTO_NONE
- <netinet/in.h> IPPROTO_ROUTING
- <netinet/in.h> IPV6_CHECKSUM
- <netinet/in.h> IPV6_DSTOPTS
- <netinet/in.h> IPV6_HOPLIMIT
- <netinet/in.h> IPV6_HOPOPTS
- <netinet/in.h> IPV6_NEXTHOP
- <netinet/in.h> IPV6_PATHMTU
- <netinet/in.h> IPV6_PKTINFO
- <netinet/in.h> IPV6_RECVDSTOPTS
- <netinet/in.h> IPV6_RECVHOPLIMIT
- <netinet/in.h> IPV6_RECVHOPOPTS
- <netinet/in.h> IPV6_RECVPKTINFO
- <netinet/in.h> IPV6_RECVRTHDR
- <netinet/in.h> IPV6_RECVRTHDRDSTOPTS
- <netinet/in.h> IPV6_RTHDR
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 49]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- <netinet/in.h> IPV6_RTHDRDSTOPTS
- <netinet/in.h> IPV6_RTHDR_TYPE_0
- <netinet/in.h> IPV6_RECVPATHMTU
- <netinet/in.h> IPV6_REACHCONF
- <netinet/in.h> IPV6_USE_MIN_MTU
- <netinet/in.h> struct in6_pktinfo{};
-
- <netinet/ip6.h> IP6F_MORE_FRAG
- <netinet/ip6.h> IP6F_OFF_MASK
- <netinet/ip6.h> IP6F_RESERVED_MASK
- <netinet/ip6.h> IP6OPT_BINDING_ACK
- <netinet/ip6.h> IP6OPT_BINDING_REQ
- <netinet/ip6.h> IP6OPT_BINDING_UPDATE
- <netinet/ip6.h> IP6OPT_EID
- <netinet/ip6.h> IP6OPT_HOME_ADDRESS
- <netinet/ip6.h> IP6OPT_JUMBO
- <netinet/ip6.h> IP6OPT_JUMBO_LEN
- <netinet/ip6.h> IP6OPT_MUTABLE
- <netinet/ip6.h> IP6OPT_NSAP_ADDR
- <netinet/ip6.h> IP6OPT_PAD1
- <netinet/ip6.h> IP6OPT_PADN
- <netinet/ip6.h> IP6OPT_ROUTER_ALERT
- <netinet/ip6.h> IP6OPT_TUNNEL_LIMIT
- <netinet/ip6.h> IP6OPT_TYPE_DISCARD
- <netinet/ip6.h> IP6OPT_TYPE_FORCEICMP
- <netinet/ip6.h> IP6OPT_TYPE_ICMP
- <netinet/ip6.h> IP6OPT_TYPE_SKIP
- <netinet/ip6.h> IP6_ALERT_AN
- <netinet/ip6.h> IP6_ALERT_AN
- <netinet/ip6.h> IP6_ALERT_MLD
- <netinet/ip6.h> IP6_ALERT_MLD
- <netinet/ip6.h> IP6_ALERT_RSVP
- <netinet/ip6.h> IP6_ALERT_RSVP
- <netinet/ip6.h> IP6_BUF_ACK
- <netinet/ip6.h> IP6_BUF_COA
- <netinet/ip6.h> IP6_BUF_HOME
- <netinet/ip6.h> IP6_BUF_ROUTER
- <netinet/ip6.h> struct ip6_dest{};
- <netinet/ip6.h> struct ip6_ext{};
- <netinet/ip6.h> struct ip6_frag{};
- <netinet/ip6.h> struct ip6_hbh{};
- <netinet/ip6.h> struct ip6_hdr{};
- <netinet/ip6.h> struct ip6_opt{};
- <netinet/ip6.h> struct ip6_opt_binding_ack{};
- <netinet/ip6.h> struct ip6_opt_binding_request{};
- <netinet/ip6.h> struct ip6_opt_binding_update{};
- <netinet/ip6.h> struct ip6_opt_home_address{};
- <netinet/ip6.h> struct ip6_opt_jumbo{};
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 50]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- <netinet/ip6.h> struct ip6_opt_nsap{};
- <netinet/ip6.h> struct ip6_opt_router{};
- <netinet/ip6.h> struct ip6_opt_tunnel{};
- <netinet/ip6.h> struct ip6_rthdr{};
- <netinet/ip6.h> struct ip6_rthdr0{};
-
-
- The following list summarizes the function and macro prototypes
- discussed in this memo, sorted by header.
-
- <netinet/icmp6.h> void ICMP6_FILTER_SETBLOCK(int, struct icmp6_filter *);
- <netinet/icmp6.h> void ICMP6_FILTER_SETBLOCKALL(struct icmp6_filter *);
- <netinet/icmp6.h> void ICMP6_FILTER_SETPASS(int, struct icmp6_filter *);
- <netinet/icmp6.h> void ICMP6_FILTER_SETPASSALL(struct icmp6_filter *);
- <netinet/icmp6.h> int ICMP6_FILTER_WILLBLOCK(int,
- const struct icmp6_filter *);
- <netinet/icmp6.h> int ICMP6_FILTER_WILLPASS(int,
- const struct icmp6_filter *);
-
- <netinet/in.h> int IN6_ARE_ADDR_EQUAL(const struct in6_addr *,
- const struct in6_addr *);
-
- <netinet/in.h> int inet6_opt_append(void *, size_t, int,
- uint8_t, size_t, uint_t, void **);
- <netinet/in.h> int inet6_opt_get_val(void *, size_t, void *, int);
- <netinet/in.h> int inet6_opt_find(void *, size_t, int, uint8_t ,
- size_t *, void **);
- <netinet/in.h> int inet6_opt_finish(void *, size_t, int);
- <netinet/in.h> int inet6_opt_init(void *, size_t);
- <netinet/in.h> int inet6_opt_next(void *, size_t, int, uint8_t *,
- size_t *, void **);
- <netinet/in.h> int inet6_opt_set_val(void *, size_t, void *, int);
-
- <netinet/in.h> int inet6_rth_add(void *,
- const struct in6_addr *);
- <netinet/in.h> struct in6_addr inet6_rth_getaddr(const void *,
- int);
- <netinet/in.h> void *inet6_rth_init(void *, int, int, int);
- <netinet/in.h> int inet6_rth_reverse(const void *, void *);
- <netinet/in.h> int inet6_rth_segments(const void *);
- <netinet/in.h> size_t inet6_rth_space(int, int);
-
- <netinet/ip6.h> int IP6OPT_TYPE(uint8_t);
-
- <sys/socket.h> unsigned int CMSG_LEN(unsigned int);
- <sys/socket.h> unsigned int CMSG_SPACE(unsigned int);
-
- <unistd.h> int rresvport_af(int *, int);
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 51]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- <unistd.h> int rcmd_af(char **, unsigned short, const char *,
- const char *, const char *, int *, int);
- <unistd.h> int rexec_af(char **, unsigned short , const char *,
- const char *, const char *, int *, int);
-
-
-
-16. Security Considerations
-
- The setting of certain Hop-by-Hop options and Destination options may
- be restricted to privileged processes. Similarly some Hop-by-Hop
- options and Destination options may not be returned to nonprivileged
- applications.
-
- The ability to specify an arbitrary source address using IPV6_PKTINFO
- must be prevented; at least for non-privileged processes.
-
-
-17. Change History
-
- Changes from RFC 2292:
-
- - Removed the IPV6_PKTOPTIONS socket option by allowing sticky
- options to be set with individual setsockopt calls. This
- simplifies the protocol stack implementation by not having to
- handle options within options and also clarifies the failure
- semantics when some option is incorrectly formatted.
-
- - Added the IPV6_RTHDRDSTOPTS for a Destination header before the
- Routing header. This is necessary to allow setting these
- Destination headers without IPV6_PKTOPTIONS.
-
- - Removed the ability to be able to specify Hop-by-Hop and
- Destination options using multiple ancillary data items. The
- application, using the inet6_option_*() routines, is responsible
- for formatting the whole extension header. This removes the need
- for the protocol stack to somehow guess the alignment
- restrictions on options when concatenating them together.
-
- - Added separate IPV6_RECVxxx options to enable the receipt of the
- corresponding ancillary data items. This makes the API cleaner
- since it allows the application to retrieve with getsockopt the
- sticky options it has set with setsockopt.
-
- - Clarified how sticky options are turned off.
-
- - Clarified how and when TCP returns ancillary data.
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 52]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- - Removed the support for the loose/strict Routing header since
- that has been removed from the IPv6 specification.
-
- - Modified the inet6_rthdr_XXX() functions to not assume a cmsghdr
- structure in order to work with both sticky options and ancillary
- data. Renamed the functions to inet6_rth_XXX() to allow
- implementations to provide both the old and new functions.
-
- - Modified the inet6_option_XXX() functions to not assume a cmsghdr
- structure in order to work with both sticky options and ancillary
- data. Renamed the functions to inet6_opt_XXX() to allow
- implementations to provide both the old and new functions.
-
- - The new inet6_opt_XXX() functions were made different that the
- old as to not require structure declarations but instead use
- functions to add the individual fields to the option.
-
- - Changed inet6_rthdr_getaddr() to operate on index O through N-1
- (used to be 1 through N).
-
- - Changed the comments in the struct ip6_hdr from "priority" to
- "traffic class".
-
- - Clarified the alignment issues involving ancillary data to allow
- for separate alignment of cmsghdr structures and the data. Made
- CMSG_SPACE() return an upper bound on the needed space.
-
- - Added rcmd_af() and rexec_af().
-
- Changes since -00:
-
- - Changed ICMP unreachable code 2 name to be "beyond scope of
- source address".
-
- - Added motivation for rcmd_af() and rexec_af().
-
- - Added option definitions (IP6OPT_PAD1 etc) to ip6.h.
-
- - Added MLD and router renumbering definitions to icmp6.h
-
- - Removed ip6r0_addr field - replaced by a comment.
-
- - Made the content of IPV6_RTHDR, IPV6_HOPOPTS etc be specified as
- the extension header format (struct ip6_rthdr etc) instead of the
- previous "implementation dependent".
-
- - Removed attempt at RFC 2292 compatibility.
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 53]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- - Excluded pad options from inet6_opt_next().
-
- - Added IPV6_USE_MIN_MTU socket option for applications to avoid
- fragmentation by sending at the minimum IPv6 MTU.
-
- - Added MTU notification so that UDP and raw socket applications
- can participate in path MTU discovery.
-
- - Added Reachability confirmation for UDP and raw socket
- applications.
-
- - Clarified that if the application asks for e.g., IPV6_RTHDR and a
- received datagram does not contain a Routing header an
- implementation will exclude the IPV6_RTHDR ancillary data item.
-
- - Removed the constraints for jumbo option.
-
- - Moved the new CMSG macros and changes from the appendix.
-
- - Add text about inet6_opt_ depending on 2260 appendix B formatting
- rules i.e. largest field last in the option.
-
- - Specified that getsockopt() of a sticky option returns what was
- set with setsockopt().
-
- - Updated the summary of new definitions to make it current.
-
- Changes since -01:
-
- - Added a note about the minor threat for DoS attacks using
- IPV6_REACHCONF
-
- - Clarified checksum and other receive side verification for RAW
- ICMP sockets.
-
- - Editorial clarifications.
-
-
-
-18. TODO and Open Issues
-
- Items left to do:
-
- - Add macros for ip6_hdr to access the traffic class and flow label
- fields.
-
- - Should we remove the 1, 2, 4, 8 byte restriction for
- inet6_opt_set_val and inet6_opt_get_val? Option values can be
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 54]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- any size even though there alignment must be a power of two.
- Issue of how natural alignment is defined for sizes that are not
- a power of two.
-
- - Perhaps we should add a note to point out that robust receivers
- should verify alignment before calling inet6_opt_get_val(). Or
- require that inet6_opt_get_val() should check the alignment and
- fail by returning -1?
-
- - Should we change IPV6_USE_MIN_MTU to IPV6_USEMTU taking a
- uint32_t Should we add IPV6_DONTFRAG option for traceroute??
-
- - Add credits for UDP MTU stuff
-
- - Move information about mapping from inet6_opt to setsockopt and
- cmsg.
-
- - Clarify IPV6_RTHDRDSTOPTS's interaction with IPV6_RTHDR.
-
- - Make the new inet6_opt_set_val() and inet6_opt_get_val() check
- the length of the data item.
-
- - Add sending and receiving sections for routing header text just
- like destination options?
-
- - Include sample implementation of inet6_opt_XXX.
-
- - Fix Authors address wrt Rich.
-
- Open issues:
-
- - Add ICMP name lookups definitions?
-
- - Add site-prefixes definitions?
-
- - Add flow label allocation API as requested in draft-berson-rsvp-
- ipv6-fl-00.txt? Draft has expired!
-
- - Anything special for mobility options? Restrict setting at API?
- Filter out on receipt? If received what does the home address
- option contain?
-
- - Specify "change" for TCP especially when there are multiple HBH
- option headers etc.
-
- - Specify binding to scope-id => implies filtering of addresses
- with that scope if the address you are bound to is link-local
- etc. What about conflicts with bound scope-id and sendto/connect
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 55]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- scope-id?
-
- - Specify order for ifindex selection. Put in separate section.
- Different cases for sending to link-local (scope_id including
- nexthop scope_id) and global. Is multicast different?
-
- - bind() and sin6_scope_id. Should have been in Basic API. Error
- checks when bind/sendto sin6_scope_id does not match?
-
- - Specify notion of default multicast interface? In Basic API?
-
- - What about site names and site ids? Need for interfaces to map?
- Requires that site-prefixes pass name - does name need to use DNS
- format to handle character sets?
-
- - If the home address option passed out in IPV6_RECVDSTOPTS? If so
- what address value does it contain?
-
-
-19. References
-
-
- [RFC-2460] Deering, S., Hinden, R., "Internet Protocol, Version 6
- (IPv6), Specification", RFC 2460, Dec. 1998.
-
- [RFC-2553] Gilligan, R. E., Thomson, S., Bound, J., Stevens, W.,
- "Basic Socket Interface Extensions for IPv6", RFC 2553,
- March 1999.
-
- [RFC-1981] McCann, J., Deering, S., Mogul, J, "Path MTU Discovery
- for IP version 6", RFC 1981, Aug. 1996.
-
- [RFC-2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor
- Discovery for IP Version 6 (IPv6)", RFC 2461, Dec. 1998.
-
-
-20. Acknowledgments
-
- Matt Thomas and Jim Bound have been working on the technical details
- in this draft for over a year. Keith Sklower is the original
- implementor of ancillary data in the BSD networking code. Craig Metz
- provided lots of feedback, suggestions, and comments based on his
- implementing many of these features as the document was being
- written.
-
- The following provided comments on earlier drafts: Pascal Anelli,
- Hamid Asayesh, Ran Atkinson, Karl Auerbach, Hamid Asayesh, Jim Bound,
- Don Coolidge, Matt Crawford, Sam T. Denton, Richard Draves, Francis
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 56]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- Dupont, Bob Gilligan, Jun-ichiro Hagino, Gerri Harter, Tim Hartrick,
- Bob Halley, Masaki Hirabaru, Yoshinobu Inoue, Mukesh Kacker, A. N.
- Kuznetsov, Sam Manthorpe, Pedro Marques, Jack McCann, der Mouse, John
- Moy, Thomas Narten, Steve Parker, Charles Perkins, Ken Powell, Tom
- Pusateri, Pedro Roque, Sameer Shah, Peter Sjodin, Stephen P.
- Spackman, Jinmei Tatuya, Karen Tracey, Sowmini Varadhan, Quaizar
- Vohra, Carl Williams, Steve Wise, Eric Wong, Farrell Woods, Kazu
- Yamamoto, and Vlad Yasevich.
-
-
-21. Authors' Addresses
-
- W. Richard Stevens
- 1202 E. Paseo del Zorro
- Tucson, AZ 85718
- Email: rstevens@kohala.com
-
-
- Matt Thomas
- 3am Software Foundry
- 8053 Park Villa Circle
- Cupertino, CA 95014
- Email: matt@3am-software.com
-
-
- Erik Nordmark
- Sun Microsystems, Inc.
- 901 San Antonio Road
- Palo Alto, CA 94303, USA
- Email: erik.nordmark@eng.sun.com
-
-
-
-22. Appendix A: Ancillary Data Overview
-
- 4.2BSD allowed file descriptors to be transferred between separate
- processes across a UNIX domain socket using the sendmsg() and
- recvmsg() functions. Two members of the msghdr structure,
- msg_accrights and msg_accrightslen, were used to send and receive the
- descriptors. When the OSI protocols were added to 4.3BSD Reno in
- 1990 the names of these two fields in the msghdr structure were
- changed to msg_control and msg_controllen, because they were used by
- the OSI protocols for "control information", although the comments in
- the source code call this "ancillary data".
-
- Other than the OSI protocols, the use of ancillary data has been
- rare. In 4.4BSD, for example, the only use of ancillary data with
- IPv4 is to return the destination address of a received UDP datagram
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 57]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- if the IP_RECVDSTADDR socket option is set. With Unix domain sockets
- ancillary data is still used to send and receive descriptors.
-
- Nevertheless the ancillary data fields of the msghdr structure
- provide a clean way to pass information in addition to the data that
- is being read or written. The inclusion of the msg_control and
- msg_controllen members of the msghdr structure along with the cmsghdr
- structure that is pointed to by the msg_control member is required by
- the Posix.1g sockets API standard.
-
-
-
-22.1. The msghdr Structure
-
- The msghdr structure is used by the recvmsg() and sendmsg()
- functions. Its Posix.1g definition is:
-
- struct msghdr {
- void *msg_name; /* ptr to socket address structure */
- socklen_t msg_namelen; /* size of socket address structure */
- struct iovec *msg_iov; /* scatter/gather array */
- size_t msg_iovlen; /* # elements in msg_iov */
- void *msg_control; /* ancillary data */
- socklen_t msg_controllen; /* ancillary data buffer length */
- int msg_flags; /* flags on received message */
- };
-
- The structure is declared as a result of including <sys/socket.h>.
-
- (Note: Before Posix.1g the two "void *" pointers were typically "char
- *", and the two socklen_t members and the size_t member were
- typically integers. Earlier drafts of Posix.1g had the two socklen_t
- members as size_t, but Draft 6.6 of Posix.1g, apparently the final
- draft, changed these to socklen_t to simplify binary portability for
- 64-bit implementations and to align Posix.1g with X/Open's Networking
- Services, Issue 5. The change in msg_control to a "void *" pointer
- affects any code that increments this pointer.)
-
- (Note: Before Posix.1g the cmsg_len member was an integer, and not a
- socklen_t. See the Note in the previous section for why socklen_t is
- used here.)
-
- Most Berkeley-derived implementations limit the amount of ancillary
- data in a call to sendmsg() to no more than 108 bytes (an mbuf).
- This API requires a minimum of 10240 bytes of ancillary data, but it
- is recommended that the amount be limited only by the buffer space
- reserved by the socket (which can be modified by the SO_SNDBUF socket
- option). (Note: This magic number 10240 was picked as a value that
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 58]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- should always be large enough. 108 bytes is clearly too small as the
- maximum size of a Routing header is 2048 bytes.)
-
-
-22.2. The cmsghdr Structure
-
- The cmsghdr structure describes ancillary data objects transferred by
- recvmsg() and sendmsg(). Its Posix.1g definition is:
-
- struct cmsghdr {
- socklen_t cmsg_len; /* #bytes, including this header */
- int cmsg_level; /* originating protocol */
- int cmsg_type; /* protocol-specific type */
- /* followed by unsigned char cmsg_data[]; */
- };
-
- This structure is declared as a result of including <sys/socket.h>.
-
- As shown in this definition, normally there is no member with the
- name cmsg_data[]. Instead, the data portion is accessed using the
- CMSG_xxx() macros, as described in Section 22.3. Nevertheless, it is
- common to refer to the cmsg_data[] member.
-
- When ancillary data is sent or received, any number of ancillary data
- objects can be specified by the msg_control and msg_controllen
- members of the msghdr structure, because each object is preceded by a
- cmsghdr structure defining the object's length (the cmsg_len member).
- Historically Berkeley-derived implementations have passed only one
- object at a time, but this API allows multiple objects to be passed
- in a single call to sendmsg() or recvmsg(). The following example
- shows two ancillary data objects in a control buffer.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 59]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-
- |<--------------------------- msg_controllen -------------------------->|
- | OR |
- |<--------------------------- msg_controllen ----------------------->|
- | |
- |<----- ancillary data object ----->|<----- ancillary data object ----->|
- |<------ min CMSG_SPACE() --------->|<------ min CMSG_SPACE() --------->|
- | | |
- |<---------- cmsg_len ---------->| |<--------- cmsg_len ----------->| |
- |<--------- CMSG_LEN() --------->| |<-------- CMSG_LEN() ---------->| |
- | | | | |
- +-----+-----+-----+--+-----------+--+-----+-----+-----+--+-----------+--+
- |cmsg_|cmsg_|cmsg_|XX| |XX|cmsg_|cmsg_|cmsg_|XX| |XX|
- |len |level|type |XX|cmsg_data[]|XX|len |level|type |XX|cmsg_data[]|XX|
- +-----+-----+-----+--+-----------+--+-----+-----+-----+--+-----------+--+
- ^
- |
- msg_control
- points here
-
-
- The fields shown as "XX" are possible padding, between the cmsghdr
- structure and the data, and between the data and the next cmsghdr
- structure, if required by the implementation. While sending an
- application may or may not include padding at the end of last
- ancillary data in msg_controllen and implementations must accept both
- as valid. On receiving a portable application must provide space for
- padding at the end of the last ancillary data as implementations may
- copy out the padding at the end of the control message buffer and
- include it in the received msg_controllen. When recvmsg() is called
- if msg_controllen is too small for all the ancillary data items
- including any trailing padding after the last item an implementation
- may set MSG_CTRUNC.
-
-
-22.3. Ancillary Data Object Macros
-
- To aid in the manipulation of ancillary data objects, three macros
- from 4.4BSD are defined by Posix.1g: CMSG_DATA(), CMSG_NXTHDR(), and
- CMSG_FIRSTHDR(). Before describing these macros, we show the
- following example of how they might be used with a call to recvmsg().
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 60]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-
- struct msghdr msg;
- struct cmsghdr *cmsgptr;
-
- /* fill in msg */
-
- /* call recvmsg() */
-
- for (cmsgptr = CMSG_FIRSTHDR(&msg); cmsgptr != NULL;
- cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) {
- if (cmsgptr->cmsg_len == 0) {
- /* Error handling */
- break;
- }
- if (cmsgptr->cmsg_level == ... && cmsgptr->cmsg_type == ... ) {
- u_char *ptr;
-
- ptr = CMSG_DATA(cmsgptr);
- /* process data pointed to by ptr */
- }
- }
-
- We now describe the three Posix.1g macros, followed by two more that
- are new with this API: CMSG_SPACE() and CMSG_LEN(). All these
- macros are defined as a result of including <sys/socket.h>.
-
-
-22.3.1. CMSG_FIRSTHDR
-
-
- struct cmsghdr *CMSG_FIRSTHDR(const struct msghdr *mhdr);
-
- CMSG_FIRSTHDR() returns a pointer to the first cmsghdr structure in
- the msghdr structure pointed to by mhdr. The macro returns NULL if
- there is no ancillary data pointed to by the msghdr structure (that
- is, if either msg_control is NULL or if msg_controllen is less than
- the size of a cmsghdr structure).
-
- One possible implementation could be
-
- #define CMSG_FIRSTHDR(mhdr) \
- ( (mhdr)->msg_controllen >= sizeof(struct cmsghdr) ? \
- (struct cmsghdr *)(mhdr)->msg_control : \
- (struct cmsghdr *)NULL )
-
- (Note: Most existing implementations do not test the value of
- msg_controllen, and just return the value of msg_control. The value
- of msg_controllen must be tested, because if the application asks
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 61]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- recvmsg() to return ancillary data, by setting msg_control to point
- to the application's buffer and setting msg_controllen to the length
- of this buffer, the kernel indicates that no ancillary data is
- available by setting msg_controllen to 0 on return. It is also
- easier to put this test into this macro, than making the application
- perform the test.)
-
-
-22.3.2. CMSG_NXTHDR
-
-
- struct cmsghdr *CMSG_NXTHDR(const struct msghdr *mhdr,
- const struct cmsghdr *cmsg);
-
- CMSG_NXTHDR() returns a pointer to the cmsghdr structure describing
- the next ancillary data object. mhdr is a pointer to a msghdr
- structure and cmsg is a pointer to a cmsghdr structure. If there is
- not another ancillary data object, the return value is NULL.
-
- The following behavior of this macro is new to this API: if the
- value of the cmsg pointer is NULL, a pointer to the cmsghdr structure
- describing the first ancillary data object is returned. That is,
- CMSG_NXTHDR(mhdr, NULL) is equivalent to CMSG_FIRSTHDR(mhdr). If
- there are no ancillary data objects, the return value is NULL. This
- provides an alternative way of coding the processing loop shown
- earlier:
-
- struct msghdr msg;
- struct cmsghdr *cmsgptr = NULL;
-
- /* fill in msg */
-
- /* call recvmsg() */
-
- while ((cmsgptr = CMSG_NXTHDR(&msg, cmsgptr)) != NULL) {
- if (cmsgptr->cmsg_len == 0) {
- /* Error handling */
- break;
- }
- if (cmsgptr->cmsg_level == ... && cmsgptr->cmsg_type == ... ) {
- u_char *ptr;
-
- ptr = CMSG_DATA(cmsgptr);
- /* process data pointed to by ptr */
- }
- }
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 62]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- One possible implementation could be:
-
- #define CMSG_NXTHDR(mhdr, cmsg) \
- (((cmsg) == NULL) ? CMSG_FIRSTHDR(mhdr) : \
- (((u_char *)(cmsg) + ALIGN_H((cmsg)->cmsg_len) \
- + ALIGN_D(sizeof(struct cmsghdr)) > \
- (u_char *)((mhdr)->msg_control) + (mhdr)->msg_controllen) ? \
- (struct cmsghdr *)NULL : \
- (struct cmsghdr *)((u_char *)(cmsg) + ALIGN_H((cmsg)->cmsg_len))))
-
- The macros ALIGN_H() and ALIGN_D(), which are implementation
- dependent, round their arguments up to the next even multiple of
- whatever alignment is required for the start of the cmsghdr structure
- and the data, respectively. (This is probably a multiple of 4 or 8
- bytes.) They are often the same macro in implementations platforms
- where alignment requirement for header and data is chosen to be
- identical.
-
-
-22.3.3. CMSG_DATA
-
-
- unsigned char *CMSG_DATA(const struct cmsghdr *cmsg);
-
- CMSG_DATA() returns a pointer to the data (what is called the
- cmsg_data[] member, even though such a member is not defined in the
- structure) following a cmsghdr structure.
-
- One possible implementation could be:
-
- #define CMSG_DATA(cmsg) ( (u_char *)(cmsg) + \
- ALIGN_D(sizeof(struct cmsghdr)) )
-
-
-
-22.3.4. CMSG_SPACE
-
-
- unsigned int CMSG_SPACE(unsigned int length);
-
- This macro is new with this API. Given the length of an ancillary
- data object, CMSG_SPACE() returns an upper bound on the space
- required by the object and its cmsghdr structure, including any
- padding needed to satisfy alignment requirements. This macro can be
- used, for example, when allocating space dynamically for the
- ancillary data. This macro should not be used to initialize the
- cmsg_len member of a cmsghdr structure; instead use the CMSG_LEN()
- macro.
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 63]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- One possible implementation could be:
-
- #define CMSG_SPACE(length) ( ALIGN_D(sizeof(struct cmsghdr)) + \
- ALIGN_H(length) )
-
-
-
-22.3.5. CMSG_LEN
-
-
- unsigned int CMSG_LEN(unsigned int length);
-
- This macro is new with this API. Given the length of an ancillary
- data object, CMSG_LEN() returns the value to store in the cmsg_len
- member of the cmsghdr structure, taking into account any padding
- needed to satisfy alignment requirements.
-
- One possible implementation could be:
-
- #define CMSG_LEN(length) ( ALIGN_D(sizeof(struct cmsghdr)) + length )
-
- Note the difference between CMSG_SPACE() and CMSG_LEN(), shown also
- in the figure in Section 4.2: the former accounts for any required
- padding at the end of the ancillary data object and the latter is the
- actual length to store in the cmsg_len member of the ancillary data
- object.
-
-
-23. Appendix B: Examples using the inet6_rth_XXX() functions
-
- Here we show an example for both sending Routing headers and
- processing and reversing a received Routing header.
-
-
-23.1. Sending a Routing Header
-
- As an example of these Routing header functions defined in this
- document, we go through the function calls for the example on p. 17
- of [RFC-2460]. The source is S, the destination is D, and the three
- intermediate nodes are I1, I2, and I3.
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 64]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-
- S -----> I1 -----> I2 -----> I3 -----> D
-
- src: * S S S S S
- dst: D I1 I2 I3 D D
- A[1]: I1 I2 I1 I1 I1 I1
- A[2]: I2 I3 I3 I2 I2 I2
- A[3]: I3 D D D I3 I3
- #seg: 3 3 2 1 0 3
-
- src and dst are the source and destination IPv6 addresses in the IPv6
- header. A[1], A[2], and A[3] are the three addresses in the Routing
- header. #seg is the Segments Left field in the Routing header.
-
- The six values in the column beneath node S are the values in the
- Routing header specified by the sending application using sendmsg()
- of setsockopt(). The function calls by the sender would look like:
-
- void *extptr;
- int extlen;
- struct msghdr msg;
- struct cmsghdr *cmsgptr;
- int cmsglen;
- struct sockaddr_in6 I1, I2, I3, D;
-
- extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, 3);
- cmsglen = CMSG_SPACE(extlen);
- cmsgptr = malloc(cmsglen);
- cmsgptr->cmsg_len = CMSG_LEN(extlen);
- cmsgptr->cmsg_level = IPPROTO_IPV6;
- cmsgptr->cmsg_type = IPV6_RTHDR;
-
- extptr = CMSG_DATA(cmsgptr);
- extptr = inet6_rth_init(extptr, extlen, IPV6_RTHDR_TYPE_0, 3);
-
- inet6_rth_add(extptr, &I1.sin6_addr);
- inet6_rth_add(extptr, &I2.sin6_addr);
- inet6_rth_add(extptr, &I3.sin6_addr);
-
- msg.msg_control = cmsgptr;
- msg.msg_controllen = cmsglen;
-
- /* finish filling in msg{}, msg_name = D */
- /* call sendmsg() */
-
- We also assume that the source address for the socket is not
- specified (i.e., the asterisk in the figure).
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 65]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- The four columns of six values that are then shown between the five
- nodes are the values of the fields in the packet while the packet is
- in transit between the two nodes. Notice that before the packet is
- sent by the source node S, the source address is chosen (replacing
- the asterisk), I1 becomes the destination address of the datagram,
- the two addresses A[2] and A[3] are "shifted up", and D is moved to
- A[3].
-
- The columns of values that are shown beneath the destination node are
- the values returned by recvmsg(), assuming the application has
- enabled both the IPV6_RECVPKTINFO and IPV6_RECVRTHDR socket options.
- The source address is S (contained in the sockaddr_in6 structure
- pointed to by the msg_name member), the destination address is D
- (returned as an ancillary data object in an in6_pktinfo structure),
- and the ancillary data object specifying the Routing header will
- contain three addresses (I1, I2, and I3). The number of segments in
- the Routing header is known from the Hdr Ext Len field in the Routing
- header (a value of 6, indicating 3 addresses).
-
- The return value from inet6_rth_segments() will be 3 and
- inet6_rth_getaddr(0) will return I1, inet6_rth_getaddr(1) will return
- I2, and inet6_rth_getaddr(2) will return I3,
-
- If the receiving application then calls inet6_rth_reverse(), the
- order of the three addresses will become I3, I2, and I1.
-
- We can also show what an implementation might store in the ancillary
- data object as the Routing header is being built by the sending
- process. If we assume a 32-bit architecture where sizeof(struct
- cmsghdr) equals 12, with a desired alignment of 4-byte boundaries,
- then the call to inet6_rth_space(3) returns 68: 12 bytes for the
- cmsghdr structure and 56 bytes for the Routing header (8 + 3*16).
-
- The call to inet6_rth_init() initializes the ancillary data object to
- contain a Type 0 Routing header:
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | cmsg_len = 20 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | cmsg_level = IPPROTO_IPV6 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | cmsg_type = IPV6_RTHDR |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=0 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 66]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- The first call to inet6_rth_add() adds I1 to the list.
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | cmsg_len = 36 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | cmsg_level = IPPROTO_IPV6 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | cmsg_type = IPV6_RTHDR |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=1 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + +
- | |
- + Address[1] = I1 +
- | |
- + +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- cmsg_len is incremented by 16, and the Segments Left field is
- incremented by 1.
-
- The next call to inet6_rth_add() adds I2 to the list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 67]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | cmsg_len = 52 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | cmsg_level = IPPROTO_IPV6 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | cmsg_type = IPV6_RTHDR |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + +
- | |
- + Address[1] = I1 +
- | |
- + +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + +
- | |
- + Address[2] = I2 +
- | |
- + +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- cmsg_len is incremented by 16, and the Segments Left field is
- incremented by 1.
-
- The last call to inet6_rth_add() adds I3 to the list.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 68]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
-
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | cmsg_len = 68 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | cmsg_level = IPPROTO_IPV6 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | cmsg_type = IPV6_RTHDR |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Next Header | Hdr Ext Len=6 | Routing Type=0| Seg Left=3 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + +
- | |
- + Address[1] = I1 +
- | |
- + +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + +
- | |
- + Address[2] = I2 +
- | |
- + +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + +
- | |
- + Address[3] = I3 +
- | |
- + +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- cmsg_len is incremented by 16, and the Segments Left field is
- incremented by 1.
-
-
-23.2. Receiving Routing Headers
-
- This example assumes that the application has enabled IPV6_RECVRTHDR
- socket option. The application prints and reverses a source route
- and uses that to echo the received data.
-
- struct sockaddr_in6 addr;
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 69]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- struct msghdr msg;
- struct iovec iov;
- struct cmsghdr *cmsgptr;
- size_t cmsgspace;
- void *extptr;
- int extlen;
-
- int segments;
- int i;
- char databuf[8192];
-
- segments = 100; /* Enough */
- extlen = inet6_rth_space(IPV6_RTHDR_TYPE_0, segments);
- cmsgspace = CMSG_SPACE(extlen);
- cmsgptr = malloc(cmsgspace);
- if (cmsgptr == NULL) {
- perror("malloc");
- exit(1);
- }
- extptr = CMSG_DATA(cmsgptr);
-
- msg.msg_control = (char *)cmsgptr;
- msg.msg_controllen = cmsgspace;
- msg.msg_name = (struct sockaddr *)&addr;
- msg.msg_namelen = sizeof (addr);
- msg.msg_iov = &iov;
- msg.msg_iovlen = 1;
- iov.iov_base = databuf;
- iov.iov_len = sizeof (databuf);
- msg.msg_flags = 0;
- if (recvmsg(s, &msg, 0) == -1) {
- perror("recvmsg");
- return;
- }
- if (msg.msg_controllen != 0 &&
- cmsgptr->cmsg_level == IPPROTO_IPV6 &&
- cmsgptr->cmsg_type == IPV6_RTHDR) {
- struct in6_addr *in6;
- char asciiname[INET6_ADDRSTRLEN];
- struct ip6_rthdr *rthdr;
-
- rthdr = (struct ip6_rthdr *)extptr;
- segments = inet6_rth_segments(extptr);
- printf("route (%d segments, %d left): ",
- segments, rthdr->ip6r_segleft);
- for (i = 0; i < segments; i++) {
- in6 = inet6_rth_getaddr(extptr, i);
- if (in6 == NULL)
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 70]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- printf("<NULL> ");
- else
- printf("%s ", inet_ntop(AF_INET6,
- (void *)in6->s6_addr,
- asciiname, INET6_ADDRSTRLEN));
- }
- if (inet6_rth_reverse(extptr, extptr) == -1) {
- printf("reverse failed");
- return;
- }
- }
- iov.iov_base = databuf;
- iov.iov_len = strlen(databuf);
- if (sendmsg(s, &msg, 0) == -1)
- perror("sendmsg");
- if (cmsgptr != NULL)
- free(cmsgptr);
-
- Note: The above example is a simple illustration. It skips some
- error checks involving the MSG_TRUNC and MSG_CTRUNC flags.
-
-
-24. Appendix C: Examples using the inet6_opt_XXX() functions
-
- This shows how Hop-by-Hop and Destination options can be both built
- as well as parsed using the inet6_opt_XXX() functions. This examples
- assume that there are defined values for OPT_X and OPT_Y.
-
-
-24.1. Building options
-
- We now provide an example that builds two Hop-by-Hop options using
- the example in Appendix B of [RFC-2460].
-
- void *extbuf;
- size_t extlen;
- int currentlen;
- void *databuf;
- size_t offset;
- uint8_t value1;
- uint16_t value2;
- uint32_t value4;
- uint64_t value8;
-
- /* Estimate the length */
- currentlen = inet6_opt_init(NULL, 0);
- if (currentlen == -1)
- return (-1);
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 71]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- currentlen = inet6_opt_append(NULL, 0, currentlen, OPT_X, 12, 8, NULL);
- if (currentlen == -1)
- return (-1);
- currentlen = inet6_opt_append(NULL, 0, currentlen, OPT_Y, 7, 4, NULL);
- if (currentlen == -1)
- return (-1);
- currentlen = inet6_opt_finish(NULL, 0, currentlen);
- if (currentlen == -1)
- return (-1);
- extlen = currentlen;
-
- extbuf = malloc(extlen);
- if (extbuf == NULL) {
- perror("malloc");
- return (-1);
- }
- currentlen = inet6_opt_init(extbuf, extlen);
- if (currentlen == -1)
- return (-1);
-
- currentlen = inet6_opt_append(extbuf, extlen, currentlen,
- OPT_X, 12, 8, &databuf);
- if (currentlen == -1)
- return (-1);
- /* Insert value 0x12345678 for 4-octet field */
- offset = 0;
- value4 = 0x12345678;
- offset = inet6_opt_set_val(databuf, offset, &value4, sizeof (value4));
- /* Insert value 0x0102030405060708 for 8-octet field */
- value8 = 0x0102030405060708;
- offset = inet6_opt_set_val(databuf, offset, &value8, sizeof (value8));
-
- currentlen = inet6_opt_append(extbuf, extlen, currentlen,
- OPT_Y, 7, 4, &databuf);
- if (currentlen == -1)
- return (-1);
- /* Insert value 0x01 for 1-octet field */
- offset = 0;
- value1 = 0x01;
- offset = inet6_opt_set_val(databuf, offset, &value1, sizeof (value1));
- /* Insert value 0x1331 for 2-octet field */
- value2 = 0x1331;
- offset = inet6_opt_set_val(databuf, offset, &value2, sizeof (value2));
- /* Insert value 0x01020304 for 4-octet field */
- value4 = 0x01020304;
- offset = inet6_opt_set_val(databuf, offset, &value4, sizeof (value4));
-
- currentlen = inet6_opt_finish(extbuf, extlen, currentlen);
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 72]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- if (currentlen == -1)
- return (-1);
- /* extbuf and extlen are now completely formatted */
-
-
-
-24.2. Parsing received options
-
- This example parses and prints the content of the two options in the
- previous example.
-
- int
- print_opt(void *extbuf, size_t extlen)
- {
- struct ip6_dest *ext;
- int currentlen;
- uint8_t type;
- size_t len;
- void *databuf;
- size_t offset;
- uint8_t value1;
- uint16_t value2;
- uint32_t value4;
- uint64_t value8;
-
- ext = (struct ip6_dest *)extbuf;
- printf("nxt %u, len %u (bytes %d)\n", ext->ip6d_nxt,
- ext->ip6d_len, (ext->ip6d_len + 1) * 8);
-
- currentlen = 0;
- while (1) {
- currentlen = inet6_opt_next(extbuf, extlen, currentlen,
- &type, &len, &databuf);
- if (currentlen == -1)
- break;
- printf("Received opt %u len %u\n",
- type, len);
- switch (type) {
- case OPT_X:
- offset = 0;
- offset = inet6_opt_get_val(databuf, offset,
- &value4, sizeof (value4));
- printf("X 4-byte field %x\n", value4);
- offset = inet6_opt_get_val(databuf, offset,
- &value8, sizeof (value8));
- printf("X 8-byte field %llx\n", value8);
- break;
- case OPT_Y:
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 73]
-\f
-INTERNET-DRAFT Advanced Sockets API for IPv6 Nov. 7, 2000
-
-
- offset = 0;
- offset = inet6_opt_get_val(databuf, offset,
- &value1, sizeof (value1));
- printf("Y 1-byte field %x\n", value1);
- offset = inet6_opt_get_val(databuf, offset,
- &value2, sizeof (value2));
- printf("Y 2-byte field %x\n", value2);
- offset = inet6_opt_get_val(databuf, offset,
- &value4, sizeof (value4));
- printf("Y 4-byte field %x\n", value4);
- break;
- default:
- printf("Unknown option %u\n", type);
- break;
- }
- }
- return (0);
- }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-draft-ietf-ipngwg-2292bis-02.txt [Page 74]
-\f
+++ /dev/null
-A new Request for Comments is now available in online RFC libraries.
-
-
- RFC 3493
-
- Title: Basic Socket Interface Extensions for IPv6
- Author(s): R. Gilligan, S. Thomson, J. Bound, J. McCann,
- W. Stevens
- Status: Informational
- Date: March 2003
- Mailbox: gilligan@intransa.com, sethomso@cisco.com,
- Jim.Bound@hp.com, Jack.McCann@hp.com
- Pages: 39
- Characters: 82570
- Obsoletes: 2553
-
- I-D Tag: draft-ietf-ipngwg-rfc2553bis-10.txt
-
- URL: ftp://ftp.rfc-editor.org/in-notes/rfc3493.txt
-
-
-The de facto standard Application Program Interface (API) for TCP/IP
-applications is the "sockets" interface. Although this API was
-developed for Unix in the early 1980s it has also been implemented on
-a wide variety of non-Unix systems. TCP/IP applications written
-using the sockets API have in the past enjoyed a high degree of
-portability and we would like the same portability with IPv6
-applications. But changes are required to the sockets API to support
-IPv6 and this memo describes these changes. These include a new
-socket address structure to carry IPv6 addresses, new address
-conversion functions, and some new socket options. These extensions
-are designed to provide access to the basic IPv6 features required by
-TCP and UDP applications, including multicasting, while introducing a
-minimum of change into the system and providing complete
-compatibility for existing IPv4 applications. Additional extensions
-for advanced IPv6 features (raw sockets and access to the IPv6
-extension headers) are defined in another document.
-
-This document is a product of the IP Version 6 Working Group of the
-IETF.
-
-This memo provides information for the Internet community. It does
-not specify an Internet standard of any kind. Distribution of this
-memo is unlimited.
-
-This announcement is sent to the IETF list and the RFC-DIST list.
-Requests to be added to or deleted from the IETF distribution list
-should be sent to IETF-REQUEST@IETF.ORG. Requests to be
-added to or deleted from the RFC-DIST distribution list should
-be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.
-
-Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
-an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
-help: ways_to_get_rfcs. For example:
-
- To: rfc-info@RFC-EDITOR.ORG
- Subject: getting rfcs
-
- help: ways_to_get_rfcs
-
-Requests for special distribution should be addressed to either the
-author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless
-specifically noted otherwise on the RFC itself, all RFCs are for
-unlimited distribution.echo
-Submissions for Requests for Comments should be sent to
-RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC
-Authors, for further information.
-
+++ /dev/null
-Network Working Group Alain Durand
-INTERNET-DRAFT SUN Microsystems, inc.
-October 25, 2002 Jun-ichiro itojun Hagino
-Expires April 2002 IIJ Research Laboratory
- Dave Thaler
- Microsoft
-
-
-
-
- Well known site local unicast addresses
- to communicate with recursive DNS servers
- <draft-ietf-ipv6-dns-discovery-07.txt>
-
-
-
- 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 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 a "work in progress".
-
- To view the list Internet-Draft Shadow Directories, see
- http://www.ietf.org/shadow.html.
-
-
-
-Abstract
-
- This documents specifies 3 well known addresses to configure stub
- resolvers on IPv6 nodes to enable them to communicate with recursive
- DNS server with minimum configuration in the network and without
- running a discovery protocol on the end nodes. This method may be
- used when no other information about the addresses of recursive DNS
- servers is available. Implementation of stub resolvers using this as
- default configuration must provide a way to override this.
-
-
-
-Copyright notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-
-1. Introduction
-
- RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or
- more IPv6 address and default routes.
-
- However, for a node to be fully operational on a network, many other
- parameters are needed, such as the address of a name server that
- offer recursive service (a.k.a. recursive DNS server), mail relays,
- web proxies, etc. Except for name resolution, all the other services
- are usually described using names, not addresses, such as
- smtp.myisp.net or webcache.myisp.net. For obvious bootstrapping
- reasons, a node needs to be configured with the IP address (and not
- the name) of a recursive DNS server. As IPv6 addresses look much
- more complex than IPv4 ones, there is some incentive to make this
- configuration as automatic and simple as possible.
-
- Although it would be desirable to have all configuration parameters
- configured/discovered automatically, it is common practice in IPv4
- today to ask the user to do manual configuration for some of them by
- entering server names in a configuration form. So, a solution that
- will allow for automatic configuration of the recursive DNS server is
- seen as an important step forward in the autoconfiguration story.
-
- The intended usage scenario for this proposal is a home or enterprise
- network where IPv6 nodes are plugged/unplugged with minimum
- management and use local resources available on the network to
- autoconfigure. This proposal is also useful in cellular networks
- where all mobile devices are included within the same site.
-
- 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 [KEYWORDS].
-
-
-
-
-2. Well known addresses vs discovery
-
- Some of the discussions in the past around DNS server discovery have
- been trying to characterize the solution space into stateless versus
- stateful or server oriented versus severless. It is not absolutely
- clear how much state if any needs to be kept to perform DNS server
- discovery, and, although the semantic differences between a router
- and a server are well understood from a conceptual perspective, the
- current implementations tend to blur the picture. In another attempt
- to characterize different approaches, one can look at how much
- intelligence a client needs to have in order to use the service.
-
- One avenue is to ask the IPv6 node to participate in a discovery
- protocol, such as SLP or DHCP, learn the address of the server and
- send packets to this server. Another one is to configure the IPv6
- node with well known addresses and let the local routing system
- forward packets to the right place. This document explores this
- later avenue of configuration using well known addresses that does
- not require participation of the end node in any discovery mechanism.
-
-
-
-
-
-3. Reserved prefix and addresses
-
- The mechanism described here is:
- - intended for ongoing use and not not just for bootstrapping
- - intended to populate a stub resolver's list of available
- recursive servers only if that list is otherwise unpopulated
- - providing reliability through redundancy using three unicast
- addresses.
-
-
-3.1 Stub resolver configuration
-
- This memo reserved three well known IPv6 site local addresses.
-
- In the absence of any other information about the addresses of
- recursive DNS servers, IPv6 stub-resolvers MAY use any of those three
- IPv6 addresses in their list of candidate recursive DNS servers.
-
-
-3.2 Recursive DNS servers configuration
-
- Within sites, one or more recursive DNS server SHOULD be configured
- with any of those three addresses. It is RECOMMENDED that large sites
- deploy 3 recursive DNS servers, one for each reserved address. Small
- site could use only one recursive DNS server and assign the 3
- addresses to it.
-
-
-3.3 Rationale for the choice of three addresses
-
- Three was chosen based on common practice in many places in the
- industry. While it's true that if the first one fails, that it's
- unlikely the second one will succeed (due to there really being no
- DNS server at all), using multiple addresses is important so that
- when ones do exist, the host can fail over to a second server more
- quickly than routing converges. Three servers is a compromise between
- extra reliability and increased complexity (maintaining additional
- servers, having multiple entries in the routing system, additional
- delays before the stub resolver returns an error,...).
-
- Another reason to have multiple addresses is to avoid the need to use
- of anycast addresses to achieve reliability through redundancy. On
- top of the classic problems (TCP sessions, ICMP messages,...) using
- an anycast address would hide the real locations of the recursive DNS
- servers to the stub resolver, prohibiting it to keep track of which
- servers are performing correctly. For this particular matter, using
- well known addresses is no different than configuring the stub
- resolver with regular addresses taken from the local site.
-
-
-3.4 Implementation considerations
-
- Stub resolver implementation MAY be configured by default using those
- addresses. However, implementing only the mechanism described in this
- memo may end up causing some interoperability problems when operating
- in networks where no recursive DNS server is configured with any of
- the well known addresses. Thus, stub resolvers MUST implement
- mechanisms for overriding this default, for example: manual
- configuration, L2 mechanisms and/or DHCPv6.
-
-
-
-
-4. Routing
-
- A solution to enable the stub resolvers to reach the recursive DNS
- servers is to inject host routes in the local routing system.
- Examples of methods for injecting host routes and a brief discussion
- of their fate sharing properties are presented here:
-
- a) Manual injection of routes by a router on the same subnet.
- If the node running the recursive DNS server goes down, the router
- may or may not be notified and keep announcing the route.
-
- b) Running a routing protocol on the same node running the DNS
- resolver.
- If the process running the recursive DNS server dies, the routing
- protocol may or may not be notified and keep announcing the route.
-
- c) Running a routing protocol within the same process running the
- recursive DNS server.
- If the recursive DNS server and the routing protocol run in
- separated threads, similar concerns as above are true.
-
- d) Developing an "announcement" protocol that the recursive DNS
- server could use to advertize the host route to the nearby router.
- Details of such a protocol are out of scope of this document, but
- something similar to [MLD] is possible. However, the three first
- mechanisms should cover most cases.
-
- An alternate solution is to configure a link with the well known
- prefix and position the three recursive DNS servers on that link.
- The advantage of this method is that host routes are not necessary ,
- the well known prefix is advertised to the routing system by the
- routers on the link. However, in the event of a problem on the
- physical link, all resolvers will become unreachable.
-
- IANA considerations for this prefix are covered in Section 6.
-
-
-
-5. Site local versus global scope considerations
-
- The rationales for having a site local prefix are:
-
- -a) Using a site local prefix will ensure that the traffic to the
- recursive DNS servers stays local to the site. This will prevent
- the DNS requests from accidentally leaking out of the site.
- However, the local resolver can implement a policy to forward DNS
- resolution of non-local addresses to an external DNS resolver.
-
- -b) Reverse DNS resolution of site local addresses is only
- meaningful within the site. Thus, making sure that such queries
- are first sent to a recursive DNS server located within the site
- perimeter increase their likelihood of success.
-
-
-
-
-6. Examples of use
-
- This section presents example scenarios showing how the mechanism
- described in this memo can co-exist with other techniques, namely
- manual configuration and DHCPv6 discovery.
-
- Note: those examples are just there to illustrate some usage
- scenarios and in no way do they suggest any recommended practices.
-
-
-6.1 Simple case, general purpose recursive DNS server
-
- This example shows the case of a network that manages one recursive
- DNS server and a large number of nodes running DNS stub resolvers.
- The recursive DNS server is performing (and caching) all the
- recursive queries on behalf of the stub resolvers. The recursive DNS
- server is configured with an IPv6 address taken from the prefix
- delegated to the site and with the 3 well known addresses defined in
- this memo. The stub resolvers are either configured with the "real"
- IPv6 address of the recursive DNS server or with the well known site
- local unicast addresses defined in this memo.
-
- --------------------------------------------
- | |
- | --------------------- |
- | |DNS stub resolver | |
- | |configured with the| |
- | |"real" address of | |
- | |the recursive DNS | |
- | |server | |
- | --------------------- |
- | ----------- | |
- | |recursive| | |
- | |DNS |<---------- |
- | |server |<---------------- |
- | ----------- | |
- | ---------------------- |
- | |DNS stub resolver | |
- | |configured with 3 | |
- | |well known addresses| |
- | ---------------------- |
- | |
- --------------------------------------------
-
- (The recursive DNS server is configured to listen both on
- its IPv6 address and on the well known address)
-
-
-6.2 Three recursive DNS servers
-
- This is a similar example as above, except that three recursive DNS
- resolvers are configured instead of just one.
-
- -------------------------------------------
- | |
- | --------------------- |
- | |DNS stub resolver | |
- | |configured with the| |
- | |"real" address of | |
- | |the recursive DNS | |
- | |server | |
- | --------------------- |
- | | |
- | ----------- | |
- | |recursive| | |
- | |DNS |<---------| |
- | |server 1 |<---------|------ |
- | ----------- | | |
- | | | |
- | ----------- | | |
- | |recursive| | | |
- | |DNS |<---------| | |
- | |server 2 |<---------|-----| |
- | ----------- | | |
- | | | |
- | ----------- | | |
- | |recursive| | | |
- | |DNS |<---------- | |
- | |server 3 |<---------------| |
- | ----------- | |
- | ---------------------- |
- | |DNS stub resolver | |
- | |configured with 3 | |
- | |well known addresses| |
- | ---------------------- |
- | |
- -------------------------------------------
-
- (The recursive DNS server is configured to listen both on
- its IPv6 address and on the well known address)
-
-
-6.3 DNS forwarder
-
- A drawback of the choice of site local scope for the reserved
- addresses for recursive DNS server is that, in the case of a
- home/small office network connected to an ISP, DNS traffic cannot be
- sent directly to the ISP recursive DNS server without having the ISP
- and all its customers share the same definition of site.
-
- In this scenario, the home/small office network is connected to the
- ISP router (PE) via an edge router (CPE).
-
- -------------
- / |
- -------- ----- / |
- |ISP PE| |CPE| / Customer |
- | |===========| |====< site |
- | | | | \ |
- -------- ----- \ |
- \ |
- -------------
-
-
- The customer router CPE could be configured on its internal interface
- with one of the reserved site local addresses and listen for DNS
- queries. It would be configured to use one (or several) of the well
- known site local unicast addresses within the ISP's site to send its
- own queries to. It would act as a DNS forwarder, forwarding queries
- received on its internal interface to the ISP's recursive DNS server.
-
- -------------
- / |
- ---------- -------------- / |
- |ISP | | CPE| / Customer |
- |DNS |===========| DNS|====< site |
- |server | <------|---forwarder|-----\---- |
- ---------- -------------- \ |
- \ |
- -------------
-
- In this configuration, the CPE is acting as a multi-sited router.
-
-
-6.4 DNS forwarder with DHCPv6 interactions
-
- In this variant scenario, DHCPv6 is be used between the PE and CPE to
- do prefix delegation [DELEG] and recursive DNS server discovery.
-
- -------------
- / |
- -------- -------------- / |
- |ISP | |customer CPE| / Customer |
- |DHCPv6|===========| DHCPv6|====< site |
- |server| <------|------client| \ |
- -------- -------------- \ |
- \ |
- -------------
-
- This example will show how DHCPv6 and well known site local unicast
- addresses cooperate to enable the internal nodes to access DNS.
-
- The customer router CPE is configured on its internal interface with
- one of the reserved site local addresses and listen for DNS queries.
- It would act as a DNS forwarder, as in 5.2, forwarding those queries
- to the recursive DNS server pointed out by the ISP in the DHCPv6
- exchange.
-
- -------------
- / |
- ---------- -------------- / |
- |ISP | |customer CPE| / Customer |
- |DNS |===========| DNS|====< site |
- |resolver| <------|---forwarder|-----\---- |
- ---------- -------------- \ |
- \ |
- -------------
-
-
- The same CPE router could also implement a local DHCPv6 server and
- advertizes itself as DNS forwarder.
-
- -------------
- / |
- -------- -------------- / Customer |
- |ISP PE| |customer CPE| / site |
- | |===========|DHCPv6 |====< |
- | | |server------|-----\---> |
- -------- -------------- \ |
- \ |
- -------------
-
-
-
- Within the site:
-
- a) DHCPv6 aware clients use DHCPv6 to obtain the address of the
- DNS forwarder...
-
- -------------
- / |
- ---------- -------------- / Customer |
- |ISP | |customer CPE| / site |
- |DNS |===========| DNS|====< |
- |resolver| <------|---forwarder|-----\----DHCPv6 |
- ---------- -------------- \ client |
- \ |
- -------------
- (The address of the DNS forwarder is acquired via DHCPv6.)
-
-
- b) other nodes simply send their DNS request to the reserved site
- local addresses.
-
- -------------
- / |
- ---------- -------------- / customer |
- |ISP | |customer CPE| / site |
- |DNS |===========| DNS|====< |
- |resolver| <------|---forwarder|-----\----non DHCPv6|
- ---------- -------------- \ node |
- \ |
- -------------
- (Internal nodes use the reserved site local unicast address.)
-
-
- A variant of this scenario is the CPE can decide to pass the global
- address of the ISP recursive DNS server in the DHCPv6 exchange with
- the internal nodes.
-
-
-
-7. IANA considerations
-
- The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out
- of the site local fec0::/10 prefix.
-
- The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2
- and fec0:000:0000:ffff::3 are to be reserved for recursive DNS server
- configuration.
-
- All other addresses within the fec0:0000:0000:ffff::/64 are reserved
- for future use and are expected to be assigned only with IESG
- approval.
-
-
-
-
-8. Security Considerations
-
- Ensuring that queries reach a legitimate DNS server relies on the
- security of the IPv6 routing infrastructure. The issues here are the
- same as those for protecting basic IPv6 connectivity.
-
- IPsec/IKE can be used as the well known addresses are used as unicast
- addresses.
-
- The payload can be protected using standard DNS security techniques.
- If the client can preconfigure a well known private or public key
- then TSIG [TSIG] can be used with the same packets presented for the
- query. If this is not the case, then TSIG keys will have to be
- negotiated using [TKEY]. After the client has the proper key then
- the query can be performed.
-
- The use of site local addresses instead of global addresses will
- ensure the DNS queries issued by host using this mechanism will not
- leak out of the site.
-
-
-
-
-9. References
-
- [KEYWORDS]
- Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [ADDRCONF]
- Thomson, S., and T. Narten, "IPv6 Stateless Address
- Autoconfiguration", RFC 2462, December 1998.
-
- [MLD]
- Deering, S., Fenner, W., Haberman, B.,
- "Multicast Listener Discovery (MLD) for IPv6",
- RFC2710, October 1999.
-
- [TSIG]
- Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)",
- RFC2845, May 2000.
-
- [TKEY]
- D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)",
- RFC2930, September 2000.
-
- [DHCPv6]
- Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and
- Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6
- (DHCPv6)", draft-ietf-dhc-dhcpv6-27 (work in progress),
- Februray 2002.
-
- [DELEG]
- Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6",
- draft-troan-dhcpv6-opt-prefix-delegation-01.txt (work in progress),
- February 2002.
-
-
-
-
-10. Authors' Addresses
-
- Alain Durand
- SUN microsystems, inc.
- 17 Network Circle, UMPK 17-202
- Menlo Park, CA 94025
- Email: Alain.Durand@sun.com
-
- Jun-ichiro itojun HAGINO
- Research Laboratory, Internet Initiative Japan Inc.
- Takebashi Yasuda Bldg.,
- 3-13 Kanda Nishiki-cho,
- Chiyoda-ku, Tokyo 101-0054, JAPAN
- Email: itojun@iijlab.net
-
- Dave Thaler
- Microsoft
- One Microsoft Way
- Redmond, CA 98052, USA
- Email: dthaler@microsoft.com
-
-
-
-
-11. Full Copyright Statement
-
-Copyright (C) The Internet Society (2002). 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 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+++ /dev/null
-
-
-Secure Shell Working Group J. Schlyter
-Internet-Draft Carlstedt Research &
-Expires: October 1, 2003 Technology
- W. Griffin
- Network Associates Laboratories
- April 2, 2003
-
-
- Using DNS to securely publish SSH key fingerprints
- draft-ietf-secsh-dns-04.txt
-
-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.
-
- This Internet-Draft will expire on October 1, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document describes a method to verify SSH host keys using
- DNSSEC. The document defines a new DNS resource record that contains
- a standard SSH key fingerprint.
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin Expires October 1, 2003 [Page 1]
-
-Internet-Draft DNS and SSH fingerprints April 2003
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3
- 2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2.2 Implementation Notes . . . . . . . . . . . . . . . . . . . . 3
- 2.3 Fingerprint Matching . . . . . . . . . . . . . . . . . . . . 4
- 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. The SSHFP Resource Record . . . . . . . . . . . . . . . . . 4
- 3.1 The SSHFP RDATA Format . . . . . . . . . . . . . . . . . . . 4
- 3.1.1 Algorithm Number Specification . . . . . . . . . . . . . . . 5
- 3.1.2 Fingerprint Type Specification . . . . . . . . . . . . . . . 5
- 3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.2 Presentation Format of the SSHFP RR . . . . . . . . . . . . 6
- 4. Security Considerations . . . . . . . . . . . . . . . . . . 6
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
- Normative References . . . . . . . . . . . . . . . . . . . . 8
- Informational References . . . . . . . . . . . . . . . . . . 8
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
- A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
- Intellectual Property and Copyright Statements . . . . . . . 10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin Expires October 1, 2003 [Page 2]
-
-Internet-Draft DNS and SSH fingerprints April 2003
-
-
-1. Introduction
-
- The SSH [5] protocol provides secure remote login and other secure
- network services over an insecure network. The security of the
- connection relies on the server authenticating itself to the client.
-
- Server authentication is normally done by presenting the fingerprint
- of an unknown public key to the user for verification. If the user
- decides the fingerprint is correct and accepts the key, the key is
- saved locally and used for verification for all following
- connections. While some security-conscious users verify the
- fingerprint out-of-band before accepting the key, many users blindly
- accepts the presented key.
-
- The method described here can provide out-of-band verification by
- looking up a fingerprint of the server public key in the DNS [1][2]
- and using DNSSEC [4] to verify the lookup.
-
- In order to distribute the fingerprint using DNS, this document
- defines a new DNS resource record to carry the fingerprint.
-
- Basic understanding of the DNS system [1][2] and the DNS security
- extensions [4] is assumed by 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 [3].
-
-2. SSH Host Key Verification
-
-2.1 Method
-
- Upon connection to a SSH server, the SSH client MAY look up the SSHFP
- resource record(s) for the host it is connecting to. If the
- algorithm and fingerprint of the key received from the SSH server
- matches the algorithm and fingerprint of one of the SSHFP resource
- record(s) returned from DNS, the client MAY accept the identity of
- the server.
-
-2.2 Implementation Notes
-
- Client implementors SHOULD provide a configurable policy used to
- select the order of methods used to verify a host key. This document
- defines one method: Fingerprint storage in DNS. Another method
- defined in the SSH Architecture [5] uses local files to store keys
- for comparison. Other methods that could be defined in the future
- might include storing fingerprints in LDAP or other databases. A
- configurable policy will allow administrators to determine which
-
-
-
-Schlyter & Griffin Expires October 1, 2003 [Page 3]
-
-Internet-Draft DNS and SSH fingerprints April 2003
-
-
- methods they want to use and in what order the methods should be
- prioritized. This will allow administrators to determine how much
- trust they want to place in the different methods.
-
- One specific scenario for having a configurable policy is where
- clients do not use fully qualified host names to connect to servers.
- In this scenario, the implementation SHOULD verify the host key
- against a local database before verifying the key via the fingerprint
- returned from DNS. This would help prevent an attacker from injecting
- a DNS search path into the local resolver and forcing the client to
- connect to a different host.
-
-2.3 Fingerprint Matching
-
- The public key and the SSHFP resource record are matched together by
- comparing algorithm number and fingerprint.
-
- The public key algorithm and the SSHFP algorithm number MUST
- match.
-
- A message digest of the public key, using the message digest
- algorithm specified in the SSHFP fingerprint type, MUST match the
- SSH FP fingerprint.
-
-
-2.4 Authentication
-
- A public key verified using this method MUST only be trusted if the
- SSHFP resource record (RR) used for verification was authenticated by
- a trusted SIG RR.
-
- Clients that do not validate the DNSSEC signatures themselves MUST
- use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7],
- between themselves and the entity performing the signature
- validation.
-
-3. The SSHFP Resource Record
-
- The SSHFP resource record (RR) is used to store a fingerprint of a
- SSH public host key that is associated with a Domain Name System
- (DNS) name.
-
- The RR type code for the SSHFP RR is TBA.
-
-3.1 The SSHFP RDATA Format
-
- The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
- type and the fingerprint of the public host key.
-
-
-
-Schlyter & Griffin Expires October 1, 2003 [Page 4]
-
-Internet-Draft DNS and SSH fingerprints April 2003
-
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | algorithm | fp type | /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
- / /
- / fingerprint /
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-3.1.1 Algorithm Number Specification
-
- This algorithm number octet describes the algorithm of the public
- key. The following values are assigned:
-
- Value Algorithm name
- ----- --------------
- 0 reserved
- 1 RSA
- 2 DSS
-
- Reserving other types requires IETF consensus.
-
-3.1.2 Fingerprint Type Specification
-
- The fingerprint type octet describes the message-digest algorithm
- used to calculate the fingerprint of the public key. The following
- values are assigned:
-
- Value Fingerprint type
- ----- ----------------
- 0 reserved
- 1 SHA-1
-
- Reserving other types requires IETF consensus. For interoperability
- reasons, as few fingerprint types as possible should be reserved.
- The only reason to reserve additional types is to increase security.
-
-3.1.3 Fingerprint
-
- The fingerprint is calculated over the public key blob as described
- in [6].
-
- The message-digest algorithm is presumed to produce an opaque octet
- string output which is placed as-is in the RDATA fingerprint field.
-
-
-
-
-
-Schlyter & Griffin Expires October 1, 2003 [Page 5]
-
-Internet-Draft DNS and SSH fingerprints April 2003
-
-
-3.2 Presentation Format of the SSHFP RR
-
- The presentation format of the SSHFP resource record consists of two
- numbers (algorithm and fingerprint type) followed by the fingerprint
- itself presented in hex, e.g:
-
- host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890
-
-
-4. Security Considerations
-
- Currently, the amount of trust a user can realistically place in a
- server key is proportional to the amount of attention paid to
- verifying that the public key presented actually corresponds to the
- private key of the server. If a user accepts a key without verifying
- the fingerprint with something learned through a secured channel, the
- connection is vulnerable to a man-in-the-middle attack.
-
- The approach suggested here shifts the burden of key checking from
- each user of a machine to the key checking performed by the
- administrator of the DNS recursive server used to resolve the host
- information. Hopefully, by reducing the number of times that keys
- need to be verified by hand, each verification is performed more
- completely. Furthermore, by requiring an administrator do the
- checking, the result may be more reliable than placing this task in
- the hands of an application user.
-
- The overall security of using SSHFP for SSH host key verification is
- dependent on detailed aspects of how verification is done in SSH
- implementations. One such aspect is in which order fingerprints are
- looked up (e.g. first checking local file and then SSHFP). We note
- that in addition to protecting the first-time transfer of host keys,
- SSHFP can optionally be used for stronger host key protection.
-
- If SSHFP is checked first, new SSH host keys may be distributed by
- replacing the corresponding SSHFP in DNS.
-
- If SSH host key verification can be configured to require SSHFP,
- we can implement SSH host key revocation by removing the
- corresponding SSHFP from DNS.
-
- As stated in Section 2.2, we recommend that SSH implementors provide
- a policy mechanism to control the order of methods used for host key
- verification. One specific scenario for having a configurable policy
- is where clients use unqualified host names to connect to servers. In
- this case, we recommend that SSH implementations check the host key
- against a local database before verifying the key via the fingerprint
- returned from DNS. This would help prevent an attacker from injecting
-
-
-
-Schlyter & Griffin Expires October 1, 2003 [Page 6]
-
-Internet-Draft DNS and SSH fingerprints April 2003
-
-
- a DNS search path into the local resolver and forcing the client to
- connect to a different host.
-
- A different approach to solve the DNS search path issue would be for
- clients to use a trusted DNS search path, i.e., one not acquired
- through DHCP or other autoconfiguration mechanisms. Since there is no
- way with current DNS lookup APIs to tell whether a search path is
- from a trusted source, the entire client system would need to be
- configured with this trusted DNS search path.
-
- Another dependency is on the implementation of DNSSEC itself. As
- stated in Section 2.4, we mandate the use of secure methods for
- lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This
- is especially important if SSHFP is to be used as a basis for host
- key rollover and/or revocation, as described above.
-
- Since DNSSEC only protects the integrity of the host key fingerprint
- after it is signed by the DNS zone administrator, the fingerprint
- must be transferred securely from the SSH host administrator to the
- DNS zone administrator. This could be done manually between the
- administrators or automatically using secure DNS dynamic update [10]
- between the SSH server and the nameserver. We note that this is no
- different from other key enrollment situations, e.g. a client sending
- a certificate request to a certificate authority for signing.
-
-5. IANA Considerations
-
- IANA needs to allocate a RR type code for SSHFP from the standard RR
- type space (type 44 requested).
-
- IANA needs to open a new registry for the SSHFP RR type for public
- key algorithms. Defined types are:
-
- 0 is reserved
- 1 is RSA
- 2 is DSA
-
- Adding new reservations requires IETF consensus.
-
- IANA needs to open a new registry for the SSHFP RR type for
- fingerprint types. Defined types are:
-
- 0 is reserved
- 1 is SHA-1
-
- Adding new reservations requires IETF consensus.
-
-Normative References
-
-
-
-Schlyter & Griffin Expires October 1, 2003 [Page 7]
-
-Internet-Draft DNS and SSH fingerprints April 2003
-
-
- [1] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [2] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [4] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [5] Rinne, T., Ylonen, T., Kivinen, T. and S. Lehtinen, "SSH
- Protocol Architecture", draft-ietf-secsh-architecture-13 (work
- in progress), September 2002.
-
- [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.
- Lehtinen, "SSH Transport Layer Protocol",
- draft-ietf-secsh-transport-15 (work in progress), September
- 2002.
-
-Informational References
-
- [7] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
- Roadmap", RFC 2411, November 1998.
-
- [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
- "Secret Key Transaction Authentication for DNS (TSIG)", RFC
- 2845, May 2000.
-
- [9] Eastlake, D., "DNS Request and Transaction Signatures (
- SIG(0)s)", RFC 2931, September 2000.
-
- [10] Wellington, B., "Secure Domain Name System (DNS) Dynamic
- Update", RFC 3007, November 2000.
-
-
-Authors' Addresses
-
- Jakob Schlyter
- Carlstedt Research & Technology
- Stora Badhusgatan 18-20
- Goteborg SE-411 21
- Sweden
-
- EMail: jakob@crt.se
- URI: http://www.crt.se/~jakob/
-
-
-
-
-Schlyter & Griffin Expires October 1, 2003 [Page 8]
-
-Internet-Draft DNS and SSH fingerprints April 2003
-
-
- Wesley Griffin
- Network Associates Laboratories
- 15204 Omega Drive Suite 300
- Rockville, MD 20850
- USA
-
- EMail: wgriffin@tislabs.com
- URI: http://www.nailabs.com/
-
-Appendix A. Acknowledgements
-
- The authors gratefully acknowledges, in no particular order, the
- contributions of the following persons:
-
- Martin Fredriksson
-
- Olafur Gudmundsson
-
- Edward Lewis
-
- Bill Sommerfeld
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin Expires October 1, 2003 [Page 9]
-
-Internet-Draft DNS and SSH fingerprints April 2003
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). 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 assignees.
-
- 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
-
-
-
-Schlyter & Griffin Expires October 1, 2003 [Page 10]
-
-Internet-Draft DNS and SSH fingerprints April 2003
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Schlyter & Griffin Expires October 1, 2003 [Page 11]
-
+++ /dev/null
-
-
- Individual Submission
- Internet Draft
- Jae-Hoon Jeong
- Jung-Soo Park
- Kyeong-Jin Lee
- Hyoung-Jun Kim
- <draft-jeong-hmipv6-dns-optimization-00.txt> ETRI
- Expires: August 2003 February 2003
-
-
- The Autoconfiguration of Recursive DNS Server and the Optimization of
- DNS Name Resolution in Hierarchical Mobile IPv6
-
-
- 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 [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.
-
- Abstract
-
- This document provides the mechanism for the autoconfiguration of
- recursive DNS server in mobile node and the optimization of DNS name
- resolution in the hierarchical mobile IPv6 networks. Whenever the
- mobile node moves into a new MAP domain, the region managed by
- another MAP, in the hierarchical mobile IPv6 networks, it detects the
- addresses of recursive DNS servers which are placed in the region and
- replaces the old ones with the new ones for DNS name resolution. This
- allows the time for DNS name resolution much reduced by using the
- nearest DNS recursive server which exists in the region. Therefore,
- the mechanism of this document can optimize the DNS name resolution.
-
-
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 1]
-\f DNS Autoconfiguration and Optimization in HMIPv6 February 2003
-
-
- 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].
-
- Table of Contents
-
- 1. Terminology....................................................2
- 2. Introduction...................................................2
- 3. Overview.......................................................3
- 4. HMIPv6 extension - Advertisement of Recursive DNS Server.......4
- 5. Neighbor Discovery extension - RDNSS option message format.....4
- 6. RDNSS selection by the Mobile Node.............................5
- 7. Detection of RDNSS failure.....................................6
- 8. Security Considerations........................................6
- 9. References.....................................................6
- 10. Author's Addresses............................................7
-
- 1. Terminology
-
- This memo uses the terminology described in [3]. In addition, a new
- term is defined below:
-
- Recursive DNS Server (RDNSS) A Recursive DNS Server is a name server
- that offers the recursive service of
- DNS name resolution.
-
- 2. Introduction
-
- RFC 2462 [4] provides a way to autoconfigure either fixed or mobile
- nodes with one or more IPv6 addresses and default routes.
-
- For the support of the various services in the Internet, not only the
- configuration of IP address in network interface, but also that of
- the recursive DNS server for DNS name resolution are necessary.
-
- Up to now, many mechanisms to autoconfigure recursive DNS server in
- nodes have been proposed [5][6].
-
- This document suggests not only the autoconfiguration of recursive
- DNS server in mobile node that moves within the hierarchical mobile
- IPv6 networks [3], but also the optimization of the DNS name
- resolution in such networks. Whenever the mobile node moves into a
- new MAP (Mobility Anchor Point) domain, the region managed by another
- MAP, in the hierarchical mobile IPv6 networks, it detects the
- addresses of recursive DNS servers which are placed in the region and
- replaces the old ones with the new ones for DNS name resolution. This
- allows the time for DNS name resolution much reduced by using the
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 2]
-\f DNS Autoconfiguration and Optimization in HMIPv6 February 2003
-
-
- nearest DNS recursive server which exists in the region. Like this,
- because the mobile nodes use the recursive DNS server in the same
- domain instead of the fixed recursive DNS server, the DNS name
- resolution of the mobile nodes can be optimized.
-
- 3. Overview
-
- +-------+ +--------+
- | HA |---| RDNSS1 |
- +-------+ +--------+
- |
- | +----+
- | | CN |
- | +----+
- +-----+ |
- | |
- | +---+
- | |
- +-------+
- | MAP | RCoA
- +-------+
- | |
- | +--------+
- | |
- | |
- +-----+ +-----+ +--------+
- | AR1 | | AR2 |---| RDNSS2 |
- +-----+ +-----+ +--------+
-
- +----+
- | MN |
- +----+ ------------>
- Movement
-
- Figure 1: Optimization of DNS Name Resolution in HMIPv6 domain
-
- Whenever a mobile node enters into a new MAP domain of the visited
- network, it receives the RA message including MAP option from Access
- Router (AR) and performs the local binding update with the new MAP.
- If the list of the addresses of the recursive DNS server (RDNSS) is
- included in the RA message with the MAP option, the mobile node can
- detect the new RDNSSs and select one of them for the DNS name
- resolution. Like Figure 1, this scheme can reduce considerably the
- time of the name resolution between the mobile node and the RDNSS.
- Because the mobile node uses the nearest RDNSS in the same MAP domain,
- RDNSS2, instead of the RDNSS in its home network, RDNSS1. When the
- mobile node moves into another MAP domain, it replaces the old RDNSS
- with the new RDNSS for the succeeding name resolutions.
-
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 3]
-\f DNS Autoconfiguration and Optimization in HMIPv6 February 2003
-
-
- 4. HMIPv6 extension - Advertisement of Recursive DNS Server
-
- Because this document considers only router advertisement for MAP
- discovery, all ARs belonging to the MAP domain MUST advertise the
- MAP's IP address.
-
- The information of the RDNSS in the MAP domain is stored in the MAP
- by the network administrator and advertised as a new option through
- the RA message with MAP option. There MAY be more than one RDNSS in a
- MAP domain. A MAP advertises the RA message including the list of
- RDNSSs in the same domain with MAP option. The RA message with MAP
- and RDNSS options is propagated from the MAP to the mobile node
- through certain (configured) router interfaces within the hierarchy
- of routers. This would require manual configuration of the MAP and
- RDNSS options in the MAP and also the routers receiving the MAN and
- RDNSS options to allow them to propagate the options on certain
- interfaces.
-
- Finally, the mobile node listening to RA messages receives the new RA
- message and checks if the MAP is new or not. If the MAP is a new one,
- the mobile node perceives it has moved into another MAP domain and
- performs both the local binding update with the new MAP and the
- update of the list of RDNSSs in the configuration of name resolution
- with the new ones. From the next name resolution, the mobile node
- uses the new RDNSSs.
-
-
- 5. Neighbor Discovery extension - RDNSS option message format
-
- The mechanism of this document needs a new option in Neighbor
- Discovery [7].
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length( = 3) | Pref | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- + +
- | |
- + IPv6 Address for RDNSS +
- | |
- + +
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 4]
-\f DNS Autoconfiguration and Optimization in HMIPv6 February 2003
-
-
- Fields:
-
- Type Message type. TBA.
-
- Length 8-bit unsigned integer. The length of the
- option (including the type and length fields)
- in units of 8 octets. The default value is 3.
- The value 0 is invalid. Nodes MUST silently
- discard an ND packet that contains an option with
- length zero.
-
- Pref The preference of an RDNSS. A 4 bit unsigned
- integer. A decimal value of 15 indicates the
- highest preference. A decimal value of 0
- indicates that the RDNSS can not be used.
-
- IPv6 Address for RDNSS
- The RDNSS IPv6 address. The scope of the address
- can be any scope.
- i.e., link-local, site-local and global.
- The prefix of the address is be /64.
-
- When advertising more than one RDNSS, as many RDNSS options as the
- number of RDNSSs are included in an RA message.
-
- 6. RDNSS selection by the Mobile Node
-
- When a mobile node perceives multiple RDNSSs through RA message, it
- stores the RDNSSs in order into the configuration the resolver on the
- node uses for DNS name resolution on the basis of the value of "Pref"
- field and the prefix of "IPv6 Address for RDNSS" field in the RDNSS
- option. The following algorithm is simply based on the rule of
- selecting the nearest possible RDNSS, providing that its preference
- value did not reach the maximum value of 15. When the distances are
- the same, this algorithm uses the preference value to order the
- RDNSSs. The mobile node operation is shown below:
-
- 1) Receive and parse all RDNSS options
-
- 2) Arrange RDNSSs in an ascending order, starting with the nearest
- RDNSS and store them in the configuration for DNS name resolution
- used by resolver. (i.e., the longest prefix matching between the
- "IPv6 Address for RDNSS" field and mobile node's On-link CoA
- (LCoA) MAY be used to decide the distance between mobile node and
- RDNSS, how far away the mobile node is from the RDNSS.)
-
- 3) For each RDNSS entry, check the following;
- - If the value of "Pref" field is set to zero, exclude the RDNSS
- entry from the list of RDNSSs of the configuration for DNS name
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 5]
-\f DNS Autoconfiguration and Optimization in HMIPv6 February 2003
-
-
- resolution.
-
- Whenever the resolver on the mobile node performs the name resolution,
- it refers to the address(es) of RDNSS in the configuration for name
- resolution according to the current rule of selecting an RDNSS,
- namely from the 1st RDNSS.
-
- 7. Detection of RDNSS failure
-
- A MAP placed in a MAP domain checks periodically if the RDNSSs
- registered in the MAP are alive. Whenever the MAP detects the failure
- of any RDNSS, it advertises the failure down to the hierarchy with a
- new RA message including an RDNSS option of which "Pref" field has
- zero for the RDNSS. When a mobile node receives the RA message, it
- perceives that the RDNSS is out of work or the path to the RDNSS is
- broken and excludes the RDNSS from the configuration for name
- resolution.
-
- The dynamic detection of RDNSS failure in a MAP can be done by simply
- pinging the RDNSS periodically (e.g., every ten seconds). If no
- response is received, the MAP MAY try to aggressively ping the RDNSS
- for a short period of time (e.g., once every 5 seconds for 15
- seconds); if no response is received, an RDNSS option MAY be sent
- with a preference value of zero.
-
- 8. Security Considerations
-
- In order to guarantee the secure communication between routers, the
- router advertisements sent between routers SHOULD be authenticated by
- AH or ESP [3]. This security is essentially related to Neighbor
- Discovery protocol security [7].
-
- 9. 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
-
- [3] H. Soliman, C. Castelluccia, K. El-Malki and L. Bellier,
- "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-
- ietf-mobileip-hmipv6-07.txt, October 2002.
-
- [4] S. Thomson and T. Narten, "IPv6 Stateless Address
- Autoconfiguration", RFC2462.
-
-
-
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 6]
-\f DNS Autoconfiguration and Optimization in HMIPv6 February 2003
-
-
- [5] A. Durand, J. itojun and D. Thaler, "Well known site local
- unicast addresses to communicate with recursive DNS servers",
- draft-ietf-ipv6-dns-discovery-07.txt, October 25 2002.
-
- [6] Luc Beloeil, "IPv6 Router Advertisement DNS resolver Option",
- draft-beloeil-ipv6-dns-resolver-option-01.txt, January 2003.
-
- [7] T. Narten, E. Nordmark and W. Simpson, "Neighbour Discovery for
- IP version 6", RFC 2461.
-
- 10. Author's Addresses
-
- Jae-Hoon Jeong
- ETRI / PEC
- 161 Gajong-Dong, Yusong-Gu
- Daejon 305-350
- Korea
-
- Phone: +82 42 860 1664
- EMail: paul@etri.re.kr
-
- Jung-Soo Park
- ETRI / PEC
- 161 Gajong-Dong, Yusong-Gu
- Daejon 305-350
- Korea
-
- Phone: +82 42 860 6514
- EMail: pjs@etri.re.kr
-
- Kyeong-Jin Lee
- ETRI / PEC
- 161 Gajong-Dong, Yusong-Gu
- Daejon 305-350
- Korea
-
- Phone: +82 42 860 6484
- EMail: leekj@etri.re.kr
-
- Hyoung-Jun Kim
- ETRI / PEC
- 161 Gajong-Dong, Yusong-Gu
- Daejon 305-350
- Korea
-
- Phone: +82 42 860 6576
- EMail: khj@etri.re.kr
-
-
-
-
- Jeong, Park, Lee, Kim Expires - August 2003 [Page 7]
-\f
\ No newline at end of file
+++ /dev/null
-INTERNET-DRAFT John C. Klensin
-December 13, 2000
-Expires June 2000
-
- Reflections on the DNS, RFC 1591, and Categories of Domains
- draft-klensin-1591-reflections-02.txt
-
-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.
-
-This document is purely informational, for comment, and to stimulate
-other discussions: it is not expected to be, or evolve into, a
-standard of any form.
-
-
-0. Abstract
-
-RFC 1591, "Domain Name System Structure and Delegation" [1] laid out
-the basic administrative design and principles for the allocation and
-administration of domains, from the top level down. It was written
-before the introduction of the world wide web and rapid growth of the
-Internet put significant market, social, and political pressure on
-domain name allocations. In recent years, 1591 has been cited by all
-sides in various debates, and attempts have been made by various
-bodies to update it or adjust its provisions, sometimes under
-pressures that have arguably produced policies that are less well
-thought out than the original. Some of those efforts have begun from
-misconceptions about the provisions of 1591 or the motivation for
-those provisions. The current directions of ICANN and other groups
-who now determine DNS policy directions appear to be drifting away
-from policies and philosophy of 1591. This document is being
-published primarily for historical context and comparative purposes,
-essentially to document some thoughts about how 1591 might have been
-interpreted and adjusted by the IANA and ICANN to better reflect
-today's world while retaining characteristics and policies that have
-proven to be effective in supporting Internet growth and stability.
-An earlier variation of this memo was submitted to ICANN as a comment
-on its evolving TLD policies.
-
-
-1. Introduction
-
-RFC1591 has been heavily discussed and referenced in the last year or
-two, especially in discussions within ICANN and its predecessors
-about the creation, delegation, and management of top-level domains.
-In particular, the ICANN Domain Name Supporting Organization (DNSO),
-and especially its ccTLD constituency, have been the home of many
-discussions in which 1591 and interpretations of it have been cited
-in support of a variety of sometimes-contradictory positions. During
-that period, other discussions have gone on to try to reconstruct the
-thinking that went into RFC 1591. Those in turn have led me and
-others to muse on how that original thinking might relate to some of
-the issues being raised. 1591 is, I believe, one of Jon Postel's
-masterpieces, drawing together very different philosophies (e.g., his
-traditional view that people are basically reasonable and will do the
-right thing if told what it is with some stronger mechanisms when
-that model is not successful) into a single whole.
-
-RFC 1591 was written in the context of the assumption that what it
-described as generic TLDs would be bound to policies and categories
-of registration (see the "This domain is intended..." text in
-section 2) while ccTLDs were expected to be used primarily to support
-users and uses within and for a country and its residents. The
-notion that different domains would be run in different ways --albeit
-within the broad contexts of "public service on behalf of the
-Internet community" and "trustee... for the global Internet
-community"-- was considered a design feature and a safeguard against
-a variety of potential abuses. Obviously the world has changed in
-many ways in the six or seven years since 1591 was written. In
-particular, the Internet has become more heavily used and, because
-the design of the world wide web has put domain names in front of
-users, top-level domain names and registrations in them have been
-heavily in demand: not only has the number of hosts increased
-dramatically during that time, but the ratio between registered
-domain names and physical hosts has increased very significantly.
-
-The issues 1591 attempted to address when it was written and those we
-face today have not changed significantly in principle. But one
-alternative to present trends would be to take a step back to refine
-it into a model that can function effectively today. Therefore, it
-may be useful to try to reconstruct 1591's principles and think about
-their applicability today as a model that could continue to be
-applied: not because it is historically significant, but because many
-of its elements have proven to work reasonably well, even in
-difficult situations. In particular, for many domains (some in
-1591's "generic" list and others in its "country code" category) the
-notion of "public service" --expected then to imply being carried out
-at no or minimal cost to the users, not merely on a non-profit
-basis-- has yielded to profitability calculations. And, in most of
-the rest, considerations of at least calculating and recovering costs
-have crept in. While many of us feel some nostalgia for the old
-system, it is clear that its days are waning if not gone: perhaps the
-public service notions as understood when 1591 was written just don't
-scale to rapid internet growth and very large numbers of
-registrations.
-
-In particular, some ccTLDs have advertised for registrations outside
-the designated countries (or other entities), while others have made
-clear decisions to allow registrations by non-nationals. These
-decisions and others have produced protests from many sides,
-suggesting, in turn, that a recategorization is in order. For
-example, we have heard concerns by governments and managers of
-traditional, "public service", in-country, ccTLDs about excessive
-ICANN interference and fears of being forced to conform to
-internationally-set policies for dispute resolution when their
-domestic ones are considered more appropriate. We have also heard
-concerns from registrars and operators of externally-marketed ccTLDs
-about unreasonable government interference and from gTLD registrars
-and registries about unreasonable competition from aggressively
-marketed ccTLDs. The appropriate distinction is no longer between
-what RFC 1591 described as "generic" TLDs (but which were really
-intended to be "purpose-specific", a term I will use again below) and
-ccTLDs but among:
-
- (i) true "generic" TLDs, in which any registration is acceptable
- and, ordinarily, registrations from all sources are actively
- promoted. This list currently includes (the formerly
- purpose-specific) COM, NET, and ORG, and some ccTLDs. There have
- been proposals from time to time for additional TLDs of this
- variety in which, as with COM (and, more recently, NET and ORG)
- anyone (generally subject only to name conflicts and national
- law) could register who could pay the fees.
-
- (ii) purpose-specific TLDs, in which registration is accepted
- only from organizations or individuals meeting particular
- qualifications, but where those qualifications are not tied to
- national boundaries. This list currently includes INT, EDU, the
- infrastructure domain ARPA, and, arguably, the specialized US
- Government TLDs MIL and GOV. There have been proposals from
- time to time for other international TLDs of this variety, e.g.,
- for medical entities such as physicians and hospitals and for
- museums. ICANN has recently approved several TLDs of this type
- and describes them as "sponsored" TLDs.
-
- (iii) Country domains, operated according to the original
- underlying assumptions of 1591, i.e., registrants are largely
- expected to be people or other entities within the country.
- While external registrations might be accepted by some of these,
- the country does not aggressively advertise for such
- registrations, nor does anyone expect to derive significant fee
- revenue from them. All current domains in this category are
- ccTLDs, but not all ccTLDs are in this category.
-
-These categories are clearly orthogonal to the association between
-the use of the IS 3166-1 registered code list [2] and two-letter
-"country" domain names. If that relationship is to be maintained
-(and I believe it is desirable), the only inherent requirement is
-that no two-letter TLDs be created except from that list (in order to
-avoid future conflicts). ICANN should control the allocation and
-delegation of TLDs using these, and other, criteria, but only
-registered 3166-1 two letter codes should be used as two-letter TLDs.
-
-
-2. Implications of the Categories
-
-If we had adopted this type of three-way categorization and could
-make it work, I believe it would have presented several opportunities
-for ICANN and the community more generally to reduce controversies
-and move forward. Of course, there will be cases where the
-categorization of a particular domain and its operating style will
-not be completely clear-cut (see section 3, below). But having ICANN
-work out procedures for dealing with those (probably few) situations
-appears preferable to strategies that would tend to propel ICANN into
-areas that are beyond its competence or that might require
-significant expansion of its mandate.
-
-First, the internally-operated ccTLDs (category iii above) should not
-be required to have much interaction with ICANN or vice versa. Once
-a domain of this sort is established and delegated, and assuming that
-the "admin contact in the country" rule is strictly observed, the
-domain should be able to function effectively without ICANN
-intervention or oversight. In particular, while a country might
-choose to adopt the general ICANN policies about dispute resolution
-or name management, issues that arise in these areas might equally
-well be dealt with exclusively under applicable national laws. If a
-domain chooses to use ICANN services that cost resources to provide,
-it should contribute to ICANN's support, but, if it does not, ICANN
-should not presume to charge it for other than a reasonable fraction
-of the costs to ICANN of operating the root, root servers, and any
-directory systems that are generally agreed upon to be necessary and
-in which the domain participates.
-
-By contrast, ccTLDs operated as generic domains ought to be treated
-as generic domains. ICANN dispute resolution and name management
-policies and any special rules developed to protect the Internet
-public in multiple registrar or registry situations should reasonably
-apply.
-
-3. Telling TLD types apart
-
-If appropriate policies are adopted, ccTLDs operated as generic
-domains (category (i) above) and those operated as country domains
-(category (iii) above) ought to be able to be self-identified. There
-are several criteria that could be applied to make this
-determination. For example, either a domain is aggressively seeking
-outside registrations or it is not and either the vast majority of
-registrants in a domain are in-country or they are not. One could
-also think of this as the issue of having some tangible level of
-presence in the jurisdiction - e.g., is the administrative contact
-subject, in practical terms, to the in-country laws, or are the
-registration rules such that it is reasonably likely that a court in
-the jurisdiction of the country associated with the domain can
-exercise jurisdiction and enforce a judgment against the registrant.
-
-One (fairly non-intrusive) rule ICANN might well impose on all
-top-level domains is that they identify and publish the policies they
-intend to use. E.g., registrants in a domain that will use the laws
-of one particular country to resolve disputes should have a
-reasonable opportunity to understand those policies prior to
-registration and to make other arrangements (e.g., to register
-elsewhere) if that mechanism for dispute resolution is not
-acceptable. Giving IANA (as the root registrar) incorrect
-information about the purpose and use of a domain should be subject
-to challenge, and should be grounds for reviewing the appropriateness
-of the domain delegation, just as not acting consistently and
-equitably provides such grounds under the original provisions of RFC
-1591.
-
-In order to ensure the availability of accurate and up-to-date
-registration information the criteria must be consistent, and
-consistent with more traditional gTLDs, for all nominally country
-code domains operating as generic TLDs.
-
-
-4. The role of ICANN in country domains
-
-ICANN (and IANA) should, as described above, have as little
-involvement as possible in the direction of true country [code]
-domains (i.e., category (iii)). There is no particular reason why
-these domains should be subject to ICANN regulation beyond the basic
-principles of 1591 and associated arrangements needed to ensure
-Internet interoperability and stability.
-
-ICANN's avoiding such involvement strengthens it: the desirability of
-avoiding collisions with national sovereignty, determinations about
-government legitimacy, and the authority of someone purportedly
-writing on behalf of a government, is as important today as it was
-when 1591 was written. The alternatives take us quickly from
-"administration" into "internet governance" or, in the case of
-determining which claimant is the legitimate government of a country,
-"international relations", and the reasons for not moving in that
-particular direction are legion.
-
-5. The role of governments
-
-The history of IANA strategy in handling ccTLDs included three major
-"things to avoid" considerations:
-
- * Never get involved in determining which entities were countries
- and which ones were not.
-
- * Never get involved in determining who was, or was not, the
- legitimate government of a country. And, more generally, avoid
- deciding what entity --government, religion, commercial,
- academic, etc.-- has what legitimacy or rights.
-
- * If possible, never become involved in in-country disputes.
- Instead, very strongly encourage internal parties to work
- problems out among themselves. At most, adopt a role as
- mediator and educator, rather than judge, unless abuses are very
- clear and clearly will not be settled by any internal mechanism.
-
-All three considerations were obviously intended to avoid IANA's
-being dragged into a political morass in which it had (and, I
-suggest, has) no competence to resolve the issues and could only get
-bogged down. The first consideration was the most visible (and the
-easiest) and was implemented by strict adherence to the ISO 3166
-registered Country Code list. If an entity had a code, it was
-eligible to be registered with a TLD (although IANA was free to apply
-other criteria-most of them stated in 1591). If it did not, there
-were no exceptions: the applicant's only recourse was a discussion
-with the 3166 Registration Authority (now Maintenance Agency, often
-known just as "3166/MA") or the UN Statistical Office (now Statistics
-Bureau), not with IANA.
-This, obviously, is also the argument against use of the "reserved"
-list, at least without explicit agreement with 3166/MA: since IANA
-(or ICANN) can ask that a name be placed on that list, there is no
-rule of an absolute determination by an external organization.
-Purported countries can come to ICANN, insist on having delegations
-made and persuade ICANN to ask that the names be reserved. Then,
-since the reserved name would exist, they could insist that the
-domain be delegated. Worse, someone could use another organization
-to request reservation of the name by 3166/MA; once it was reserved,
-ICANN might be hard-pressed not to do the delegation. Of course,
-ICANN could (and probably would be forced to) adopt additional
-criteria other than appearance on the "reserved list" in order to
-delegate such domains. But those criteria would almost certainly be
-nearly equivalent to determining which applicants were legitimate and
-stable enough to be considered a country, the exact decision process
-that 1591 strove to avoid.
-
-The other two considerations were more subtle and not always
-successful: from time to time, both before and after the formal
-policy shifted toward "governments could have their way", IANA
-received letters from people purporting to be competent government
-authorities asking for changes. Some of them turned out later to not
-have that authority or appropriate qualifications. The assumption of
-1591 itself was that, if the "administrative contact in country" rule
-was strictly observed, as was the rule that delegation changes
-requested by the administrative contact would be honored, then, if a
-government _really_ wanted to assert itself, it could pressure the
-administrative contact into requesting the changes it wanted, using
-whatever would pass for due process in that country. And the ability
-to apply that process and pressure would effectively determine who
-was the government and who wasn't, and would do so far more
-effectively than any IANA evaluation of, e.g., whether the letterhead
-on a request looked authentic (and far more safely for ICANN than
-asking the opinion of any particular other government or selection of
-governments).
-
-Specific language in 1591 permitted IANA to adopt a "work it out
-yourselves; if we have to decide, we will strive for a solution that
-is not satisfactory to any party" stance. That approach was used
-successfully, along with large doses of education, on many occasions
-over the years, to avoid IANA's having to assume the role of judge
-between conflicting parties.
-
-Similar principles could be applied to the boundary between country-
-code-based generic TLDs and country domains. Different countries,
-under different circumstances, might prefer to operate the ccTLD
-either as a national service or as a profit center where the
-"customers" were largely external. Whatever decisions were made
-historically, general Internet stability argues that changes should
-not be made lightly. At the same time, if a government wishes to
-make a change, the best mechanism for doing so is not to involve
-ICANN in a potential determination of legitimacy (or even to have the
-GAC try to formally make that decision for individual countries) but
-for the relevant government to use its own procedures to persuade the
-administrative contact to request the change and for IANA to promptly
-and efficiently carry out requests made by administrative contacts.
-
-
-6. Implications for the current DNSO structure.
-
-The arguments by some of the ccTLD administrators that they are
-different from the rest of the ICANN and DNSO structures are (in this
-model) correct: they are different. The ccTLDs that are operating as
-generic TLDs should be separated from the ccTLD constituency and
-joined to the gTLD constituency. The country ccTLDs should be
-separated from ICANN's immediate Supporting Organization structure,
-and operate in a parallel and advisory capacity to ICANN, similar to
-the arrangements used with the GAC. The DNSO and country TLDs should
-not be required to interact with each other except on a mutually
-voluntary basis and, if ICANN needs interaction or advice from some
-of all of those TLDs, it would be more appropriate to get it in the
-form of an advisory body like the GAC rather than as DNSO
-constituency.
-
-7. References
-
-[1] Postel, Jon. Domain Name System Structure and Delegation,
- RFC 1591. USC Information Sciences Institute: March 1994.
-
-[2] ISO 3166. Codes for the identification of names of countries (??)
-
-8. Acknowledgements and disclaimer
-
-These reflections have been prepared in my individual capacity and do
-not necessarily reflect the views of my past or present employers.
-Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel,
-Geoff Huston, Havard Eidnes, and several anonymous reviewers, made
-suggestions or offered editorial comments about earlier versions of
-this document. Those comments contributed significantly to whatever
-clarity the document has, but the author bears responsibility for the
-selection of comments which were ultimately incorporated and the way
-in which the conclusions were presented.
-
-9. Security Considerations
-
-This memo addresses the context for a set of administrative decisions
-and procedures, and does not raise or address security issues.
-
-
-10. Author's address
-
-John C Klensin
-1770 Massachusetts Ave, Suite 322
-Cambridge, MA 02140, USA
-klensin@jck.com
+++ /dev/null
-INTERNET-DRAFT John C. Klensin
-May 28, 2001
-Expires November 2001
-
-
- Role of the Domain Name System
- draft-klensin-dns-role-01.txt
-
-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.
-
-This document represents a summary of the personal opinions of the
-author on the subject covered and is not intended to evolve into a
-standard of any kind.
-
-Copyright Notice
-
-Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-
-
-0. Abstract
-
-The original function and purpose of the DNS is reviewed, and
-contrasted with some of the functions into which it is being forced
-today and some of the newer demands being placed upon it or suggested
-for it. A framework for an alternative to placing these additional
-stresses on the DNS is then outlined. This document and that
-framework are not a proposed solution, only a strong suggestion that
-the time has come to begin thinking more broadly about the problems
-we are encountering and possible approaches to solving them.
-
-A mailing list has been initiated for discussion of this draft,
-its successors, and closely-related issues at
-ietf-i18n-dns-directory@imc.org. See
-http://www.imc.org/ietf-i18n-dns-directory/ for subscription
-and archival information.
-
-
-1. History
-
-Several of the comments that follow are somewhat revisionist. Good
-design and engineering often requires a level of intuition by the
-designers about things that will be necessary in the future; the
-reasons for some of these design decisions are not made explicit at
-the time because no one is able to articulate them. The discussion
-below reconstructs some of the decisions about the Internet's primary
-namespace (the "Class=IN" DNS) in the light of subsequent development
-and experience. In addition, the historical reasons for particular
-decisions about the Internet were often severely underdocumented
-contemporaneously and, not surprisingly, different participants have
-different recollections about what happened and what was considered
-important. Consequently, the quasi-historical story below is just
-one story. There may be (indeed, almost certainly are) other stories
-about how we got to where we are today, but they probably don't, of
-themselves, invalidate the inferences and conclusions.
-
-1.1 Context for DNS development
-
-During the entire life of the ARPANET and nearly the first decade or
-so of operation of the Internet, the list of host names and their
-mapping to and from addresses was maintained in a frequently-updated
-"host table" [RFC625, 811, 952]. This table was just a list in an
-agreed-upon format; sites were expected to frequently obtain copies
-of, and install, new versions. The host tables themselves were
-introduced to
-
- * Eliminate the requirement for people to remember host numbers
- (addresses). Despite apparent experience to the contrary in the
- conventional telephone system, numeric numbering systems, including
- the numeric host number strategy, did not (and do not) work well for
- more than a (large) handful of hosts.
-
- * Provide stability when addresses changed. Since addresses --to
- some degree in the ARPANET and more importantly in the contemporary
- Internet-- are a function of network topology and routing, they
- often had to be changed when connectivity or topology changed. The
- names could be kept stable even as addresses changed.
-
- * Some hosts (so-called "multihomed" ones) needed multiple
- addresses to reflect different types of connectivity and topology.
- Again, the names were very useful for avoiding the requirement that
- would otherwise exist for users and other hosts to track these
- multiple host numbers and addresses.
-
-Toward the end of that long (in network time) period, the community
-concluded that the host table model did not scale adequately and that
-it would not adequately support new service variations. A working
-group was created, and the DNS was the result of that effort. The
-role of the DNS was to preserve the capabilities of the host table
-arrangements (especially unique, unambiguous, host names), provide
-for addition of additional services (e.g., the special record types
-for electronic mail routing which rather quickly followed
-introduction of the DNS), and to do so on the base of a robust,
-hierarchical, distributed, name lookup system. That system also
-permitted distribution of name administration, rather than requiring
-that each host be entered into a single, central, table by a central
-administration.
-
-1.2 Review of the DNS
-
-The DNS was designed primarily to identify network resources.
-Although there was speculation about including, e.g., personal names
-and email addresses, it was not designed primarily to identify
-people, brands, etc. At the same time, the system was designed with
-the flexibility to accomodate new data types and structures through
-the addition of new record types to the initial "INternet" class.
-Since the appropriate identifiers and content of those future
-extensions could not be anticipated, the design provided that these
-fields could contain any (binary) information, not just the
-restricted text forms of the host table.
-
-However, the DNS as-used is intimately tied to the applications and
-application protocols that utilize it, often at a fairly low level.
-
-In particular, despite the ability of the protocols and data
-structures themselves to accomodate any binary representation, DNS
-names as used are historically not [even] ASCII, but a very
-restricted subset of it, a subset that derives primarily from the
-original host table naming rules. Selection of that subset was
-driven in part by human factors considerations, including a desire to
-eliminate possible ambiguities in an international context. Hence
-character codes that had international variations in interpretation
-were excluded, the underscore character and case distinctions were
-eliminated as being confusing (in the underscore's case, with the
-hyphen character) when written or read by people, and so on. These
-considerations appear to be very similar to those that resulted in
-similarly restricted character sets being used as protocol elements
-in many ITU and ISO protocols (cf. X.9, X.29).
-
-Another assumption was that there would be a high ratio of physical
-hosts to second level domains and, more generally, that the system
-would be deeply hierarchical, with most systems (and names) at the
-third level or below and a large ratio of names representing physical
-hosts to total names. There are domains that follow this model: many
-university and corporate domains use fairly deep hierarchies, as do a
-few country code TLDs (".US" is an excellent example). However, the
-RIPE hostcount list is now showing a count of SOA records that is
-approaching (and may have passed) the number of distinct hosts.
-While recent experience has shown that the DNS is robust enough
---given contemporary machines as servers and current bandwidth
-norms-- to be able to continue to operate reasonably well when those
-historical assumptions are not met (e.g., with a huge, flat,
-structure under ".COM"), it is still useful to remember that the
-system could have been designed to work optimally with a flat
-structure (and very large zones) rather than a deeply hierarchical
-one, and was not.
-
-Similarly, despite some early speculation about entering people's
-names and email addresses into the DNS directly, with the sole
-exception (at least in the "IN" class) of one field of the SOA
-record, electronic mail addresses in the Internet have preserved the
-original, pre-DNS, "user at location" conceptual format rather than a
-flatter or strictly faceted one. Location, in that instance, is a
-reference to a host.
-
-Both the DNS architecture itself and the two-level provisions for
-email and similar functions (e.g., see the finger protocol), also
-anticipated a relatively high ratio of users to actual hosts. It was
-never clear that the DNS was intended to, or could, scale to the
-order of magnitude of number of users (or, more recently, products or
-document objects), rather than that of physical hosts.
-
-Like the host table before it, the DNS has provided criticial
-uniqueness for names and universal accessibility to them as part of
-overall "single internet" and "end to end" models (cf [RFC2826]).
-However, there are many signs that, as new uses evolve and original
-assmumptions are abused, the system is being stretched to, or beyond,
-its practical limits.
-
-The original design effort that led to the DNS included examination
-of the directory technologies available at the time. The working
-group concluded that the DNS design, with its simplifying assumptions
-and restricted capabilities, would be feasible to deploy and make
-adequately robust, which the more comprehensive directory approaches
-were not. At the same time, some of the participants feared that the
-limitations might cause future problems; this document essentially
-takes the position that they were probably correct. On the other
-hand, directory technology and implementations have evolved
-significantly in the ensuing years: it may be time to revisit the
-assumptions, either in the context of the two- (or more) level
-mechanism contemplated by the rest of this document or, even more
-radically, as a path toward a DNS replacement.
-
-
-1.3 The web and user-visible domain names
-
-From the standpoint of the integrity of the domain name system --and
-scaling of the Internet, including optimal accessibility to content--
-the web design decision to use "A record" domain names, rather than
-some system of indirection, has proven to be a serious mistake in
-several respects. Convenience of typing, and the desire to make
-domain names out of easily-remembered product names, has led to a
-flattening of the DNS, with many people now perceiving that
-second-level names under COM (or in some countries, second- or
-third-level names under the relevant ccTLD) are all that is
-meaningful (this perception has been reinforced by some domain name
-registrars who have been anxious to "sell" additional names). And,
-of course, the perception that one needs a top-level domain per
-product, rather than a (usually organizational) collection of network
-resources has led to a rapid acceleration in the number of names
-being registered, a phenonenum that has clearly benefited registrars
-charging on a per-name basis, "cybersquatters", and others in the
-business of "selling" names, but has not obviously benefitted the
-Internet as a whole.
-
-The emphasis on second-level domain names has also created a problem
-for the trademark community. Since the Internet is international,
-and names are being populated in a flat and unqualified space,
-similarly-named entities are in conflict even if there would
-ordinarily be no chance of confusing them in the marketplace. The
-problem appears to be unsolvable except by a choice between draconian
-measures --possibly including significant changes to the underlying
-legislation and conventions-- and a situation in which the "rights"
-to a name are typically not settled using the subtle and traditional
-product (or industry) type and geopolitical scope rules of the
-trademark system but by depending largely on main force, e.g., the
-organization with the greatest resources to invest in defending (or
-attacking) names will ultimately win out. The latter raises not only
-important issues of equity, but the risk of backlash as the numerous
-small players are forced to relinquish names they find attractive and
-to adopt less-desirable naming conventions.
-
-Independent of these sociopolitical problems, content distribution
-issues have made it clear that it should be possible for an
-organization to have copies of data it wishes to make available
-distributed around the network, with a user who asks for the
-information by name getting the topologically-closest copy. This is
-not possible with simple, as-designed, use of the DNS: DNS names
-identify target resources or, in the case of email "MX" records, a
-preferentially-ordered list of resources "closest" to a target (not
-to the source/user). Several technologies (and, in some cases,
-corresponding business models) have arisen to work around these
-problems, including intercepting and altering DNS requests so as to
-point to other locations,
-
-While additional implications are still being discovered and
-seriously evaluated, it appears, not surprisingly, that rewriting DNS
-names in the middle of the network, or trying to give them different
-values or interpretations depending on the topological location of
-the user trying to resolve the name interferes, in the general case,
-with end-to-end applications. These problems occur even if the
-rewriting machinery is accompanied by additional workarounds for
-particular applications: security associations and applications that
-need to identify "the same host" as the applications for which these
-tools have been designed often run into one problem or another.
-
-
-1.4 A pessimistic history of the evolution of Internet applications
-protocols.
-
-At the applications level, few of the protocols in active, widespread
-use on the Internet reflect the either contemporary knowledge in
-computer science or human factors or experience accumulated through
-deployment and use. Instead, protocols tend to be deployed at a
-just-past-prototype level, typically including the types of expedient
-compromises typical with prototypes. If they prove useful, the
-nature of the network permit very rapid dissemination (i.e., they
-fill a vacuum, even if a vacuum that no one previously knew existed).
-But, once the vacuum is filled, the installed base provides its own
-inertia: unless the design is so seriously faulty as to prevent
-effective use (or there is a widely-perceived sense of impending
-disaster unless the protocol is replaced), future developments must
-maintain backward compatibility and workarounds for problematic
-characteristics rather than benefiting from redesign in the light of
-experience. Applications that are "almost good enough" prevent
-development and deployment of high-quality replacements.
-
-
-2. Signs of DNS overloading
-
-Parts of the historical discussion above identify areas in which it
-is becoming clear that the DNS is becoming overloaded (semantically
-if not in the mechanical ability to resolve names). While we seem to
-still be well within the "just about good enough" range -- current
-mechanisms and proposals to deal with these problems are all focused
-on patching or working around limitations within the DNS rather than
-dramatic rethinking -- the number of these issues that are arising
-at the same time may argue for rethinging mechanisms and
-relationships, not just more patches and kludges. For example:
-
-o While technical approaches such as larger and higher-powered
-servers and more bandwidth, and legal/political mechanisms such as
-dispute resolution policies, have arguably kept the problems from
-becoming critical, the DNS has not proven adequately responsive to
-business and individual needs to describe or identify things (such as
-product names and names of individuals) other than strict network
-resources.
-
-o While stacks have been modified to better handle multiple addresses
-on a physical interface and some protocols have been extended to
-include DNS names for determining context, the DNS doesn't deal
-especially well with high-multiple names per host (needed for web
-hosting facilities with multiple domains on a server).
-
-o Efforts to add names deriving from languages or character sets
-based on other than simple ASCII and English-like names (see below),
-or even to utilize complex company or product names without the use
-of hierarchy have created apparent requirements for names (labels)
-that are over 63 octets long. This requirement will undoubtedly
-increase over time; while there are workarounds to accomodate longer
-names, they impose their own restrictions and cause their own
-problems.
-
-o Increasing commercialization of the Internet, and visibility of
-domain names that are assumed to match names of companies or
-products, has turned the DNS and DNS names into a trademark
-battleground. The traditional trademark system in (at least) most
-countries makes careful distinctions about fields of applicability.
-When the space is flattened, without differentiators by either
-geography or industry sector, not only are there likely conflicts
-between "Joe's Pizza" (of Boston) and "Joe's Pizza" (of San
-Francisco) but between both and "Joe's Auto Repair" (of Los Angeles):
-all three would like to control "Joes.com" and may claim trademark
-rights to do so, even though conflict or confusion would not occcur
-with traditional trademark principles.
-
-o Many organizations wish to have different web sites under the same
-URL and domain name. Sometimes this is to create local variations
---the Widget Company might want to present different material to a UK
-user relative to a US one-- and sometimes it is to provide higher
-performance by supplying information from the server topologically
-closest to the user. Arguably, the name resolution mechanism should
-provide information about multiple sites that can provide information
-associated with the same name and sufficient attributes associated
-with each of those sites to permit applications to make sensible
-choices, or should accept client-site attributes and utilize them in
-the search process.
-
-o Many existing and proposed systems for "finding things on the
-Internet" require a true search capability in which near matches can
-be reported to the user and queries may be slightly ambiguous or
-fuzzy. The DNS can accomodate only one set of (quite rigid) matching
-rules. Current proposals to permit different rules in different
-localities help to identify the problem, but, if applied directly to
-the DNS, either don't provide the level of flexibility that would be
-desirable or tend to isolate different parts of the Internet from
-each other (or both). Fuzzy or ambiguous searches are desirable for
-(at least) resolution of business names that might have spelling
-variations and for names that can be resolved into different sets of
-glyphs depending on context. This goes beyond "mere"
-canonicalization differences (different ways of representing the same
-character or ordering the same string) and into such relationships as
-the use of different alphabets for the same language, Kanji-Hiragana
-relationships, Simplified and Traditional Chinese, etc.
-
-o The historical DNS and applications that make assumptions about how
-it works impose significant risk (or forces technical kludges and
-consequent odd restrictions), when one considers adding mechanisms
-for use with various multi-character-set and multilingual
-"internationalization" systems. Cf RFC 2825.
-
-o In order to provide proper functionality to the Internet, the DNS
-must have a single unique root (see RFC 2826 for a discussion of this
-issue). There are many desires for local treatment of names or
-character sets that cannot be accomodated without either multiple
-roots (e.g., a separate root for multilingual names) or mechanisms
-that would have similar effects in terms of Internet fragmentation
-and isolation.
-
-o For some purposes, it is desirable to be able to search targets
-(i.e., by value, not just by name (label)). One might, for example,
-want to locate all of the host (and virtual host) names which cause
-mail to be directed to a given server via MX records. The DNS does
-not support this capability and it can be simulated only by
-extracting all of the relevant records (perhaps by zone transfer if
-the source doesn't prohibit that through access lists) and then
-searching a file built from those records.
-
-o Finally, as additional types of personal or identifying information
-are added to the DNS, issues of protection of that information and
-making different information available based on the credentials and
-authorization of the source of the inquiry. As with site locational
-and proximity information (as discussed above), the DNS protocols
-make the mechanisms needed to do this quite difficult if not
-impossible.
-
-In each of these cases, it is, or might be, possible to devise ways
-to trick the DNS system into supporting mechanisms that were not
-designed into it. Several ingenious solutions have been proposed in
-many of these areas already, and some have been deployed into the
-marketplace with some success.
-
-Several of the above problems are addressed well by a good directory
-system (supported by the LDAP protocol or otherwise) or searching
-environment (such as common web search engines) although not by the
-DNS. Given the difficulty of deploying new applications discussed
-above, an important question is whether the kludges are bad enough,
-or will scale up to bad enough, that new solutions are needed and can
-be deployed.
-
-
-
-3. The directory story.
-
-3.1 Overview
-
-The constraints of the DNS argue for introducing an intermediate
-protocol mechanism, referred to here as a "directory layer". The
-terms "directory" and "directory system" are used interchangably with
-"searchable system" in this document although the latter is far more
-precise. Directory layer proposals would use a two (or more) -stage
-lookup, not unlike several of the proposals for internationalized
-names in the DNS (see section 4), but all operations but the final
-one would involving searching other systems, rather than looking up
-identifiers in the DNS itself. This would permit us to relax several
-constraints and produce a more comprehensive system.
-
-Ultimately, many of the issues with domain names arise as the result
-of people attempting to use the DNS as a directory. While there has
-not been enough pressure/demand to justify a change to date, it has
-already been quite clear that, as a directory system, the DNS is a
-good deal less than ideal. This document suggests that there
-actually is a requirement for a directory system, and that the right
-solution to a searchable system requirement is a searchable system,
-not a series of DNS patches, kludges, or workarounds.
-
-In particular...
-
-o A directory system would not require imposition of particular
-length limits on names.
-
-o A directory system could permit explicit association of attributes
-of, e.g., language and country, with a name, without having to
-utilize trick encodings to incorporate that information in DNS labels
-(or creating artificial hierarchy for doing so).
-
-o There is considerable experience (albeit not much of it very
-successful) in doing fuzzy and "sonex" (similar-sounding) matching in
-directory systems. Moreover, it is plausible to think about
-different matching rules for different areas and sets of names so
-that these can be adapted to local cultural requirements.
-Specifically, it might be possible to have a single form of a name in
-a directory, but to have great flexibility about what queries matched
-that name (and even have different variations in different areas).
-Of course, the more flexibility one provides, the greater the
-possibility of real or imagined trademark conflicts, but we would
-have the opportunity to design a directory structure that dealt with
-those issues in an intelligent way, while DNS constraints arguably
-make a general and equitable DNS-only solution impossible.
-
-o If a directory system is used to translate to DNS names, and then
-DNS names are looked up in the normal fashion, it may be possible to
-relax several of the constraints that have been traditional (and
-perhaps necessary) with the DNS. For example, reverse-mapping of
-addresses to directory names may not be a requirement, since the DNS
-name(s) would (continue to) uniquely identify the host.
-
-o Solutions to multilingual transcription problems that are common in
-"normal life" (e.g., two-sided business cards to be sure that a
-recipient trying to contact a person can access romanized spellings
-and numbers when the original language may not be comprehensible to
-that recipient) can be easily handled in a directory system by
-inserting both sets of entries.
-
-o One can easily imagine a directory system that would return, not a
-single name, but a set of names paired with network-locational
-information or other context-establishing attributes. This type of
-information might be of considerable use in resolving the "nearest
-(or best) server for a particular named resource" problems that are a
-significant concern for organizations hosting web and other sites
-that are accessed from a wide range of locations and subnets.
-
-o Names bound to countries and languages might help to manage
-trademark realities, while use of the DNS in trademark-significant
-areas tends to require worldwide "flattening" of the trademark
-system.
-
-3.2 Some details and comments.
-
-As several proposals have noted, almost any internationalization
-(i18n) proposal for names that are in, or map into, the DNS will
-require changing DNS resolver API calls ("gethostbyname" or
-equivalent or adding some pre-resolution preparation mechanism) in
-almost all Internet applications -- whether to cause the API to take
-a different character set, to accept or return more arguments with
-qualifying or identifying information, or otherwise. Once
-applications must be opened to make such changes, it is a relatively
-small matter to switch from calling into the DNS to calling a
-directory service and then the DNS (in many situations, both actions
-could be accomplished in a single API call).
-
-A directory approach can be consistent both with "flat" stories and
-multi-attribute ones. The DNS requires strict hierarchies, limiting
-its ability to handle differentiation among names by their
-properties. By contrast, modern directories can utilize
-independently-searched attributes and other structured schema to
-provide flexibilities not present in a strictly hierarchical system.
-
-There is a strong argument for a single directory structure (implying
-a need for mechanisms for registration, delegation, etc.). But it is
-not a strict requirement, especially if in-depth case analysis and
-design work leads to the conclusion that reverse-mapping to directory
-names is not a requirement (see section 4).
-
-While the discussion above includes very general comments about
-attributes, it appears that only a very small number of attributes
-would be needed. The list would almost certainly include country and
-language for IDN purposes and might require "charset" if we cannot
-agree on a character set and encoding. Trademark issues might
-motivate "commercial" and "non-commercial" (or other) attributes if
-they would be helpful in bypassing trademark problems. And
-applications to resource location might argue for a few other
-attributes (as outlined above).
-
-
-4. Examining internationalization
-
-Much of the thinking underlying this document has been driven by
-considerations of internationalizing the DNS or, more specifically,
-providing access to the functions of the DNS from languages and
-naming systems that cannot be accurately expressed in ASCII (or in
-the traditional DNS subset of ASCII). Much of this work has been
-done in the "IETF Internationalized Access to Domain Names" (IDN)
-Working Group. This section contains an evaluation of what that
-group has learned and how that learning might reasonably impact
-IETF's next steps. It assumes familiarity with the work and
-terminology of that working group.
-
-When the IDN effort started, several of us made the observation that
-the first important task for the WG was an undocumented one: to
-increase the understanding of the complexities of the problem
-sufficiently that naive solutions could be rejected and people could
-go to work on the harder problems. That has clearly been
-accomplished. With the exception of some continuing background
-noise, the simplistic stuff, with promises of one-year deployment,
-has just disappeared and almost no one thinks this is simple any more.
-
-But some of the lessons learned are quite painful and should give us
-pause, both generally and in the context of the remarks above:
-
-4.1. ASCII isn't just because of English
-
-The hostname rules chosen in the mid-70s weren't just "ASCII
-because English uses ASCII", although that was a starting
-point. We have discovered that almost every other script
-(and, I think, even ASCII if we let the rest of the ISO 646
-non-BV characters in) is more complex than hostname-
-restricted-ASCII. In some cases, case mapping works from one
-case to the other, but is not reversible. In others, there
-are conventions about alternate ways to represent characters
-(in the language, not [just] in character coding) that work
-most of the time, but not always. And there are issues in
-coding, with Unicode/10646 providing different ways to
-represent the same character (I am using that word, rather
-than "glyph", deliberately here). And, in others, there are
-questions as to whether two glphs "match", which may be a
-distance-function question, not one with a binary answer. We
-have tried to solve this set of problems with "nameprep" (see
-below).
-
-4.2. "Nameprep" and its complexities
-
-The model for getting around the various problems described above and
-elsewhere has evolved into a notion that all strings are to be placed
-into the DNS only after being passed through a string preparation
-function that eliminates or rejects spurious character codes, maps
-some characters onto others, performs some sequence canonicalization,
-and generally creates forms that can be accurately compared. The
-impact of this process on host-table-subset ASCII is trivial and
-essentially adds only overhead. For other scripts, the impact is, of
-necessity, quite significant.
-
-Defining that process was quite complex. Although the general notion
-was simple, the devil is often in the details, and there are many
-details. A design team worked on it for months, with considerable
-effort placed into clarifying and fine-tuning the protocol. Despite
-general agreement that the IETF would avoid getting into the business
-of defining character sets, character codings, and the associated
-conventions, the group has several times taken excursions into
-special treatment of code positions to more nearly match the
-distinctions of Unicode with user-perceptions about similarities and
-differences between characters. The IETF-specific code position work
-has been removed from the protocol draft, but the fact that the
-temptation has been strong may indicate problems we haven't solved to
-everyone's satisfaction.
-
-At the same time, the nameprep work has been extremely useful, both
-in identifying many of the problem code points and issues and
-providing a reasonable set of rules. The problem is arguably not
-with nameprep, but with the DNS-imposed requirement that nameprep, as
-with all other parts of the matching and comparison process, yield a
-binary "match or no match" answer, rather than, e.g., a value on a
-similarity scale that can be evaluated by the user or by user-driven
-heuristic functions.
-
-
-4.3 The UCS Stability Problem
-
-ISO 10646 basically defines only code points, and not rules for using
-or comparing the characters. This is a long- standing issue with
-standards coming out of ISO/IEC JTC1/SC2; internationalization
-issues, as contrasted with character-listing and code point
-assignment issues, are just not dealt with effectively in that group.
-The Unicode Technical Committee has defined some rules for
-canonicalization and comparision, many of which have been factored
-into the "nameprep" work, but we are still in progress on figuring
-out how to make or define those rules in a sufficiently precise and
-permanent fashion that the DNS can depend on them. Perhaps more
-important, our nameprep efforts have identified several areas in
-which the UTC rules do not adequately define things to make matching
-precise and unambiguous. That raises two issues: whether trying to
-do precise matching at the character set level is actually possible
-(addressed below) and whether driving toward more precision could
-create issues that cause instability in the implementation and
-resolution models.
-
-In addition, JTC1 has recently assigned some (most?) of these issues
-to JTC1/SC22/WG20 (the Internationalization WG within the
-subcommittee that deals with programming languages, systems, and
-environments). WG20 is historically strong and deals with
-internationalization issues thoughtfully and in depth. Whether or
-not they get it right, assignment of these matters to WG20
-significantly increases the risk of an eventual ISO standard that
-specifies different behavior from the UTC specification.
-
-4.4 Audiences, end users, and the UI problem
-
-Part of what has "caused" the DNS i18n problem, as well as the DNS
-trademark problem and several others is that we have stopped thinking
-about "identifiers for objects", which normal people are not expected
-to see, and started thinking about "names" -- strings that are
-expected not only to be readable, but to have culturally-dependent
-meaning to non-specialist users.
-
-The WG, and others, have attempted to avoid addressing the
-implications of that transition by taking "someone else's problem"
-approaches or by suggesting that we can adopt conventions and people
-will just get used to them. I suggest that neither will work:
-
- * If we want to make it a problem in a different part of the
- UI structure, we need to figure out where it goes in order
- to have proof of concept of our solution. Unlike those
- whose sole [business] model is the selling or registering of
- names, any solution IETF produces actually needs to work, in
- applications context, for the end user.
-
- * The "they will get used to our conventions and adapt"
- principle is fine if we are writing rules for programming
- languages or an API. But the conventions we are talking
- about aren't part of a semi-mathematical system, they are
- deeply ingrained in culture. No matter how often we tell an
- English-speaking American that the Internet requires that the
- correct spelling of "colour" be used, he or she isn't going to be
- convinced. Getting a French-speaker in Lyon to use exactly
- the same lexical conventions as a French-speaker in Quebec
- in order to accomodate the decisions of the IETF or of a
- registrar or registry is just not likely. "Montreal" is
- either a misspelling or an anglicization (anglicisation?) of
- Montr\89al (with an acute accent mark over the "e"), but we
- are as unlikely to get global agreement on a rule that will
- determine whether the two forms should match --and that
- won't astonish end users and speakers of one language or the
- other-- as we are to get agreement on whether "misspelling"
- or "anglicization" is the greater travesty.
-
-More generally, it is not clear that the outcome of any conceivable
-nameprep-like process is going to be good enough. In the use of
-human languages by humans, we have many cases in which things that do
-not match are nonetheless interpreted as matching. The
-Norwegian/Danish glyph "°" (lower case 'o' with forward slash) and
-the German glyph "\15" (lower case 'o' with umlaut) are clearly
-different and no matching program should yield an "equal" comparison.
-But they are more similar than either of them is to, e.g., "e", and
-humans are able to mentally make the correction in context and can be
-surprised if computers can't do so.
-
-This text uses examples in Roman scripts because it is being written
-in English and those examples are relatively easy to render. But one
-of the important lessons of the IDN discussions of the last year or
-so is that problems like this exist in almost every language and
-script. Each one has its idiosyncracies, and each set of
-idiosyncracies is tied to common usage and cultural issues that are
-deeply embedded. As long as a schoolchild in the US can get a bad
-grade on a spelling test for using a perfectly valid British
-spelling, or one in France or Germany can get a poor grade for
-leaving off a diacritical mark, or one in Egypt or Israel will find
-it acceptable to write a word with or without vowels or stress marks,
-but, if they are included, that they must be the correct ones, there
-are issues with the relevant language. We are dealing with culture,
-not identifier symbol-strings for geeks or computers, and the efforts
-of the last year have made it ever more clear that, if we ignore that
-distinction, we are solving an insufficient problem.
-
-
-4.5 Business cards and other natural uses of natural languages
-
-We have some established local conventions in the world for dealing
-with multilingual situations. Looking at them may be helpful. If
-one visits a country where the language is different from ones own,
-business cards are often printed on two sides, one side in each
-language. This is usually a high-tolerance situation: exact
-translations are often not possible, and people typically smile at
-errors, appreciate the effort, and move on. The DNS situation
-differs from this in at least two ways: since we need a global
-solution, the business card would need a number of sides
-approximating the number of languages in the world, which is probably
-impossible without violating laws of physics. And the opportunities
-for tolerance don't exist: the DNS requires a exact match or the
-lookup fails.
-
-4.6 ASCII encodings and the Roman keyboard assumption
-
-Part of the argument for ACE-based solutions is that they provide an
-escape for multilingual environments when applications have not been
-upgraded. When an older application encounters an ACE-based name,
-the assumption is that the (admittedly ugly) ASCII string will be
-displayed and can be typed in. This argument is reasonable from the
-standpoint of mixtures of Latin-based alphabets, but may not be
-relevant if user-level systems and devices are involved that do not
-support the entry of Roman-based characters or which cannot
-conveniently render such characters.
-
-4.7 A pessimistic summary of IDN WG directions
-
-It appears, from the cases above and others, that none of the
-intra-DNS-based solutions for "multilingual names" are workable.
-They just rest on too many assumptions that do not appear to be
-feasible -- that people will adapt deeply-entrenched language habits
-to conventions laid down to make the lives of computers easy; that we
-can make "freeze it now, no need for changes in these areas"
-decisions about Unicode and nameprep; that ACE will smooth over
-applications problems, even in environments without the ability to
-key or render roman-based glyphs (or where user experience is such
-that they cannot easily be told apart); that we can either deploy
-EDNS or that long names aren't really important; that the Chinese
-Government (and others) will either give up their IS 2022-based
-solutions (for which UTC adding large fractions of a million new code
-points is almost certainly a necessary, but probably not sufficient
-condition) or build leakproof boundary conversion mechanisms; that
-out of band or contextual information will always be sufficient for
-the "map glyph onto script" problem; and so on. In each case, we can
-get about 80% or 90%, but it is not clear that is going to be good
-enough. For example, suppose someone can spell her name 90%
-correctly: is that likely to be considered adequate?
-
-
-6. The Key Controversies
-
-6.1. One directory or many
-
-As suggested in some of the text above, it is an open question as to
-whether the needs of the community would be best served by a single
-directory with universal applicability, a single directory but
-locally-tailored search (and, most important, matching) functions, or
-multiple, locally-determined, directories. Each has its attractions.
-Any but the first would essentially prevent reverse-mapping
-(determination of the user-visible name of the host or resource from
-target information such as an address or DNS name). But reverse
-mapping has become less useful over the years --at least to users--
-as we have assigned more and more names per host address.
-
-Locally-tailored search and mappings would permit national variations
-on interpretation of which strings matched which other ones, an
-arrangement that is especially important when different localities
-apply different rules to, e.g., matching of characters with and
-without diacriticals. But, of course, this implies that a URL may
-evaluate properly or not depending on either settings on a client
-machine or the network connectivity of the user, which is not, in
-general, a desirable situation.
-
-And, of course, completely separate directories would permit
-translation and transliteration functions to be embedded in the
-directory, given much of the Internet a different appearance
-depending on which directory was chosen. The attractions of this are
-obvious, but, unless things were very carefully designed to preserve
-uniqueness and precise identities at the right points (which may or
-may not be possible), such a system would have many of the
-difficulties associated with multiple roots.
-
-6.2 Why not a proposal?
-
-As this document has gone through various preliminary drafts and
-reviews, the question has been raised as to whether it should contain
-a specific proposal: a specific directory mechanism, schema, and so
-on. It deliberately does not take that step. It has been difficult
-to get directory systems deployed in significant ways in the Internet
-infrastructure, partially because we have a surplus of options.
-There are also some approaches that could be used to implement the
-general concepts described here, such as the Common Name Resolution
-Protocol [RFC2972], which some would not consider directory protocols
-at all. Consequently, it appeared better to present the general
-concepts and arguments here and leave the specifics to other sources,
-documents, and proposals.
-
-
-7. Security Considerations
-
-The set of proposals implied by this document suggests an interesting
-set of security issues (i.e., nothing important is ever easy). A
-directory system used for this purpose would presumably need to be as
-carefully protected against unauthorized changes as the DNS itself.
-There also might be new opportunities for problems in the two-layer
-arrangement; but those problems are not more severe than a two-stage
-lookup in the DNS.
-
-
-8. References
-
-RFC 625 On-line hostnames service. M.D. Kudlick, E.J. Feinler.
-Mar-07-1974.
-
-RFC 811 Hostnames Server. K. Harrenstien, V. White, E.J. Feinler.
-Mar-01-1982.
-
-RFC 952 DoD Internet host table specification. K. Harrenstien, M.K.
-Stahl, E.J. Feinler. Oct-01-1985.
-
-RFC 882 Domain names: Concepts and facilities. P.V. Mockapetris.
-Nov-01-1983.
-
-RFC 883 Domain names: Implementation specification. P.V. Mockapetris.
-Nov-01-1983.
-
-RFC 1035 Domain names - implementation and specification. P.V.
-Mockapetris. Nov-01-1987.
-
-RFC 1591 Domain Name System Structure and Delegation. J. Postel.
-March 1994.
-
-RFC 2825 A Tangled Web: Issues of I18N, Domain Names, and the Other
-Internet protocols. IAB, L. Daigle, ed.. May 2000.
-
-RFC 2826 IAB Technical Comment on the Unique DNS Root. IAB. May 2000.
-
-RFC 2972 Context and Goals for Common Name Resolution. N. Popp, M.
-Mealling, L. Masinter, K. Sollins. October 2000.
-
-ITU Recommendation X.9
-
-ITU Recommendation X.25
-
-9. Acknowledgements
-
-Many people have contributed to versions of this document or the
-thinking that went into it. The author would particularly like to
-thank Harald Alvestrand, Leslie Daigle, Patrik Faltstrom, Eric A.
-Hall, and Paul Hoffman for challenging the assumptions of earlier
-versions and suggesting ways to improve them.
-
-
-10. Culprit address
-
-John Klensin
-AT&T Labs
-99 Bedford Street
-Boston, MA 02111
-klensin@att.com
-
-Expires November 2001
+++ /dev/null
-INTERNET-DRAFT John C Klensin
-21 October 2002
-Expires April 2003
-
- National and Local Characters in DNS TLD Names
- draft-klensin-idn-tld-00.txt
-
-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.
- 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.
-
-
-Abstract
-
- In the context of work on internationalizing the Domain Name System
- (DNS), there have been extensive discussions about "multilingual" or
- "internationalized" top level domain names (TLDs), especially for
- countries whose predominant language is not written in a Roman-based
- script. This document reviews some of the motivations for such
- domains and the constraints that the DNS imposes. It then suggests
- an alternative, local translation, that may solve a superset of the
- problem while avoiding protocol changes, serious deployment delays,
- and other difficulties.
-
-Table of Contents
-
-1 Introduction
-1.1 Background on the "Multilingual Name" Problem
-1.2 Domain Name System Constraints
-1.3 Internationalization and Localization
-2. Client-side solutions
-2.1 IDNA and the client
-2.2 Local translation tables for TLD names
-3. Advantages and disadvantages of local translation
-3.1 Every TLD in the local language and character set
-\f
-3.2 Unification of country code domains
-3.3 User understanding of local and global reference
-3.4 Limits on TLD propagation
-4. Security Considerations
-5. References
-6. Acknowledgements
-7. Author's Address
-
-
-1. Introduction
-
-1.1 Background on the "Multilingual Name" Problem
-
-People who share a language prefer to communicate in it, using whatever
-characters are normally used to write that language, rather than in some
-"foreign" one. There have been standards for using mutually-agreed
-characters and languages in electronic mail message bodies and selected
-headers since the introduction of MIME in 1992 [MIME] and the Web has
-permitted multilingual text since its inception. However, since domain
-names are exposed to users in email addresses and URLs, and
-corresponding arrangements in other protocols, demand rapidly arose to
-permit domain names in applications that used characters other than
-those of the very restrictive, ASCII-subset, "LDH" conventions [LDH].
-The effort to do this rapidly became known as "multilingual domain
-names", although that is a misnomer, since the DNS deals only with
-characters and identifier strings, and not, except by accident, what
-people usually think of as "names". And there has been little actual
-interest in what would actually be a "multilingual name" -- i.e., a name
-that contains components from more than one language -- but only the use
-of strings conforming to different languages in the context of the DNS.
-
-1.1.1 Approaches to the requirement
-
-If the requirement is seen, not as "modifying the DNS", but as
-"providing users with access to the DNS from a variety of languages and
-character sets", three sets of proposals have emerged in the IETF and
-elsewhere. They are:
-
- (1) Perform processing in client software that recodes a user-visible
- string into an ASCII-compatible form that can safely be passed
- through the DNS protocols and stored in the DNS. This is the
- approach used, for example, in the IETF's "IDNA" protocol [IDNA].
-
- (2) Modify the DNS to be more hospitable to non-ASCII names and
- strings. There have been a variety of proposals to do this in almost
- as many ways, some of which have been implemented on a proprietary
- basis by various vendors. None of them have gained acceptance in the
- IETF community, primarily because they would take a long time to
- deploy and would leave many problems unsolved.
-
- (3) Move the problem out of the DNS entirely, relying instead on a
- "directory" or "presentation" layer to handle internationalization.
- The rationale for this approach is discussed in [DNSROLE].
-
-This document proposes a fourth approach, applicable to the top level
-domains (TLDs) only (see section 1.2.1 for a discussion of the special
-issues that make TLDs problematic). That approach could be used as an
-alternate or supplement to the strategies summarized above.
-\f
-
-1.1.2 Writing the name of one's country in its own characters
-
-An early focus of the "multilingual domain name" efforts was expressed
-in statements such as "users in my country, in which ASCII is rarely
-used, should be able to write an entire domain name in their own
-character set. In particular, since all top-level domain names, at
-present, follow the LDH rules, the somewhat more restrictive naming
-rules discussed in [STD3], and the coding conventions specified in
-[RFC1591], all fully-qualified DNS names were effectively required to
-contain at least one ASCII label (the TLD name), and that was considered
-inappropriate. One should, instead, be able to write the name of the
-ccTLD for China in Chinese, the name of the ccTLD for Saudi Arabia in
-Arabic, and so on.
-
-1.1.3 Countries with multiple languages and countries with multiple
- names
-
->From a user interface standpoint, writing ccTLD names in local
-characters is a problem. As discussed in section 1.2.2, the DNS itself
-does not easily permit a domain to be referred to by more than one name
-(or spelling or translation of a name). Countries with more than one
-official language would require that the country name be represented in
-each of those languages. And, just as it is important that a user in
-China be able to represent the name of the Chinese ccTLD in Chinese
-characters, she should be able to access a Chinese-language site in
-France using Chinese characters, requiring that she be able to write the
-name of the French ccTLD in those characters rather than in a form based
-on a Roman character set.
-
-
-1.2 Domain Name System Constraints
-
-1.2.1 Administrative hierarchy
-
-The domain name system is designed around the idea of an "administrative
-hierarchy", with the entity responsible for a given node of the
-hierarchy responsible for policies applicable to its subhierarchies (Cf.
-[STD13]). The model works quite well for the domain and subdomains of a
-particular enterprise, where the hierarchy can be organized to match the
-organizational structure, there are established ways to set policies and
-there is, at least presumably, shared assumptions about overall goals
-and objectives among all registrants in the domain. It is more
-problematic when a domain is shared by unrelated entities which lack
-common policy assumptions. It is difficult to reach agreement on rules
-that should apply to all of them. That situation always prevails for
-the labels registered in a TLD (second-level names) except in those TLDs
-for which the second level is structural (e.g., the .CO, .AC, .GOV
-conventions in many ccTLD) in which case, it exists for the labels
-within that structural level.
-
-TLDs may, but need not, have consistent registration policies for those
-second (or third) level names. Countries (or ccTLD administrators) have
-often adopted rules about what entities may register in those ccTLDs,
-and the forms the names may take. RFC 1591 outlined registration norms
-for most of the gTLDs, even though those norms have been largely ignored
-in recent years. And some recent "sponsored" domains are based on quite
-specific rules about appropriate registrations. Homogeneous
-\f
-registration rules for the root are, by contrast, impossible: almost by
-definition, the subdomains registered in it are diverse and no single
-policy applying to all root subdomains (TLDs) is feasible.
-
-1.2.2 Aliases
-
-In an environment different from the DNS, a rational way to permit
-assigning local-language names to a country code (or other) domain would
-be to set up an alias for the name, or to use some sort of "see instead"
-reference. But the DNS does not have quite the right facilities for
-either. Instead, it supports a "CNAME" record, whose label can refer
-onto to a particular label and not to a subtree. For example, if A.B.C
-is a fully-qualified name, then a CNAME reference from X to A would make
-X.B.C appear to have the same values as A.B.C. However, a CNAME
-reference from Y to C would not make A.B.Y referenceable (or even
-defined) at all. A second record type, DNAME [RFC2672], can provide an
-alias for a portion of the tree. But it is problematic technically, and
-its use is strongly discouraged except for transition uses from one
-domain to another.
-
-
-1.3 Internationalization and Localization
-
-It has often been observed that while many people talk about
-"internationalization" (a term we typically use for making something
-globally accessible while incorporating a broad-range "universal"
-character set and conventions appropriate to all languages), they often really
-mean, and want, "localization" (making things work well in a particular
-locality, or well, but potentially differently, for a broad range of
-localities). Anything that actually involves the DNS must be global and
-hence internationalized since the DNS cannot meaningfully support
-different responses based, e.g., on the location of the user making a
-query. While the DNS cannot support localization internally, many of
-the features discussed earlier in this section are much more easily
-thought about in local terms --whether localized to a geographical area,
-users of a language, or using some other criteria -- than in global ones.
-
-2. Client-side solutions
-
-Traditionally, the IETF has avoided becoming involved in standardization
-for actions that take place strictly on individual hosts on the network,
-assuming that it should confine itself to behavior that is observable
-"on the wire", i.e., in protocols between network hosts. Exceptions to
-this general principle have been made when different clients were
-required to utilize data or interpret values in compatible ways to
-preserve interoperability: the standards for email and web body formats,
-and IDNA itself, are examples of these exceptions. Regardless of what
-is required to be standardized, it is almost never required, and often
-unwise, that a user interface, by default, present on-the-wire formats
-to the user. However, in most cases when the presentation format and
-the wire format differ, the client program must take precautions that
-the wire format can be reconstructed from user input, or to keep the
-wire format, while hidden, bound to the presentation mechanism so that
-it can be reconstructed. And, while it is rarely a goal in itself, it
-is often necessary that the user be at least vaguely aware that the wire
-("real") format is different from the presentation one and that the wire
-format be available for debugging.
-
-\f
-2.1 IDNA and the client
-
-As mentioned above, IDNA itself is entirely a client-side protocol. It
-works by providing labels to the DNS in a special format (so-called
-"ACE"). When labels in that format are encountered, they are
-transformed, by the client, back into internationalized (normally
-Unicode) characters. In the context of this document, the important
-obvservation about IDNA is that any application program that supports it
-is already doing considerable transformation work on the client; it is
-not simply presenting the on-the-wire formats to the user.
-
-
-2.2 Local translation tables for TLD names
-
-We suggest that, in addition to maintaining the code and tables required
-to support IDNA, clients may want to maintain a table that contains a
-list of TLDs and that maps between them and locally-desirable names.
-For ccTLDs, these might be the names (or locally-standard abbreviations)
-by which the relevant countries are known locally (whether in ASCII
-characters or others). With some care on the part of the application
-designer (e.g., to ensure that local forms do not conflict with the
-actual TLD names), a particular TLD name input from the user could be
-either in local or standard form without special tagging or problems.
-When DNS names are received by these client programs, the TLD labels
-would be mapped to local form before IDNA is applied to the rest of the
-name; when names are received from users, local TLD names would be
-mapped to the global ones before being passed into IDNA or for other DNS
-processing.
-
-
-3. Advantages and disadvantages of local translation
-
-3.1 Every TLD in the local language and character set
-
-The notion of a top-level domain whose name matches, e.g., the name that
-is used for a country in that country or the name of a language in that
-language as, as mentioned above, immediately appealing. But most of the
-reasons for it argue equally strongly for other TLDs being accessible
-from that language. A user in Korea who can access the national ccTLD
-in the Korean language and character set has every reason to expect that
-both generic top level domains and and domains associated with other
-countries would be similarly accessible, especially if the second-level
-domains bear Korean names. A user in Spain or Portugal, or in Latin
-America, would presumably have similar expectations, but would expect to
-use Spanish names, not Korean ones.
-
-That level of local optimization is not realistic --some would argue not
-possible-- with the DNS since it would ultimately require that every top
-level domain be replicated for each of the world's languages. That
-replication process would involve not just the top level domain itself:
-in principle, all of its subtrees would need to be completely replicated
-as well (or at least all of the subtrees for which a the language
-associated with the a given replicant was relevant). The administrative
-hierarchy characteristics of the DNS (see section 1.2.1) turn the
-replication process into an administrative nightmare: every
-administrator of a second-level domain in the world would be forced to
-maintain dozens, probably hundreds, of similar zone files for the the
-replicates of the domain. Even if only the zones relevant to a
-\f
-particular country or language were replicated, the administrative and
-tracking problems to bind these to the appropriate top-level domain and
-keep all of the replicas synchronized would be extremely difficulty at
-best. And many administrators of third- and fourth-level domains, and
-beyond, would be faced with similar problems.
-
-By contrast, dealing with the names of TLDs as a localization problem,
-using local translation, is fairly simple. Each function represented by
-a TLD -- a country, generic registrations, or purpose-specific
-registrations -- could be represented in the local language and
-character set as needed. And, for countries with many languages, or
-users living, working, or visiting countries where their language was
-not dominant, "local" could be defined in terms of the needs or wishes
-of each particular user.
-
-3.2 Unification of country code domains
-
-It follows from some of the comments above that, while there appears to
-be some immediate appeal from having (at least) two domains for each
-country, one using the ISO 3166-1 code and another one using a name
-based on the national name in the national language, such a situation
-would create considerable problems for registrants in the multiple
-domains. For registrants maintaining enterprise or organizational
-subdomains, ease of administration in a single family of zone files will
-usually make a registration in a single top-level domain preferable to
-replicated sets of them, at least as long as their functional
-requirements (such a local-language access) are met by the unified
-structure.
-
-Of course, having replicated domains might be popular with registries
-and registrars, since replication would almost inevitably increase the
-total number of domains to be registered.
-
-3.3 User understanding of local and global references
-
-While the IDNA tables (actually Nameprep and Stringprep -- see the IDNA
-specification) must be identical globally for IDNA to work reliably, the
-tables for mapping between local names and TLD names could be locally
-determined, and differ from one locale to another, as long as users
-understood that international interchange of names required using the
-standard forms. That understanding could be assisted by software. It
-is likely that, at least for the foreseeable future, DNS names being
-passed among users in different countries, or using different languages,
-will be forced to be in ACE form to guarantee compatibility in any
-event, so the marginal knowledge or effort needed to put TLD names into
-standard form and transmit them that way would be very small.
-
-3.4 Limits on TLD propagation
-
-The concept of using local translation does have one side-effect, which
-some portions of the Internet community might consider undesirable.
-The size and complexity of translation tables, and maintaining those
-tables, will be, to a considerable extent, a function of the number of
-top-level domains, the frequency with which new domains are added, and
-the number of domains that are added at a time. A country or other
-locale that wished to maintain a few set of translations (i.e., so that
-every TLD had a representation in the local language) would presumably
-find setting up a table for the current collection of a few hundred
-\f
-domains to be a task that would take some days. If the number of TLDs
-was relatively stable, with a relatively small number being added at
-infrequent intervals, the updates could probably be dealt with on an ad
-hoc basis. But, if large numbers of domains were added frequently, or
-if the total number of TLDs became very large, maintaining the table
-might require dedicated staff. Worse, updating the tables stored on
-client machines might require update and synchronization protocols and
-all of the related complexities.
-
-4. Security Considerations
-
-IDNA provides a client-based mechanism for presenting Unicode names in
-applications while passing only ASCII-based names on the wire. As such,
-it constitutes a major step along the path of introducing a client-based
-presentation layer into the Internet. Client-based presentation layer
-transformations introduce risks from variant tables that can change
-meaning without external protection. For example, if a mapping table
-normally maps A onto C and that table is altered by an attacker so that
-A maps onto D instead, much mischief can be committed. On the other
-hand, these are not the usual sort of network attacks: they may be
-thought of as falling into the "users can always cause harm to
-themselves" category. The local translation model outlined here does
-not significantly increase the risks over those associated with IDNA,
-but may provide some new avenues for exploiting them.
-
-Both this approach and IDNA rely on having updated programs present
-information to the user in a very different form than the one in which
-it is transmitted on the wire. Unless the internal (wire) form is
-always used in interchange, there are possibilities for ambiguity and
-confusion about references.
-
-5. References
-
-[DNSROLE] Klensin, J.C., "Role of the Domain Name System", work in
- progress (draft-klensin-dns-role-04.txt).
-
-[IDNA] Faltstorm, F., P. Hoffman, A. M. Costello, "Internationalizing
- Domain Names in Applications (IDNA)", work in progress
- (draft-ietf-idn-idna-13.txt)
-
-[LDH] STD13 and comments
-
-[MIME] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
- Extensions): Mechanisms for Specifying and Describing the Format of
- Internet Message Bodies", RFC 1341, June 1992. Updated and replaced
- by Freed, N. and N. Borenstein, "Multipurpose Internet Mail
- Extensions (MIME) Part One: Format of Internet Message Bodies",
- RFC2045, November 1996. Also, Moore, K., "Representation of
- Non-ASCII Text in Internet Message Headers", RFC 1342, June 1992.
- Updated and replaced by Moore, K., "MIME (Multipurpose Internet
- Mail Extensions) Part Three: Message Header Extensions for
- Non-ASCII Text", RFC 2047, November 1996.
-
-[RFC1591] Postel, J., "Domain Name System Structure and Delegation",
- RFC1591, March 1994.
-
-[RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672,
- August 1999.
-\f
-
-[STD3] Braden, R., Ed., "Requirements for Internet Hosts - Application and
- Support", RFC1123, October 1989.
-
-[STD13] Mockapetris, P.V., 1034 "Domain names - concepts and
- facilities", RFC 1034, and "Domain names - implementation and
- specification", RFC 1035, November 1987.
-
-6. Acknowledgements
-
-This document was inspired by a number of conversations in ICANN, IETF,
-MINC, and private contexts about the future evolution and
-internationalization of top level domains. Discussions within, and
-about, the ICANN IDN Committee have been particularly helpful, although
-several of the members of that committee may be surprised about where
-those discussions led.
-
-7. Author's Address
-
-John C Klensin
-1770 Massachusetts Ave, #322
-Cambridge, MA 02140 USA
-email: john+ietf@jck.com
-\f
+++ /dev/null
-
-
-Network Working Group M. Kosters
-Internet-Draft Network Solutions, Inc.
-Expires: August 31, 2001 March 2, 2001
-
-
- DNSSEC Opt-in for Large Zones
- draft-kosters-dnsext-dnssec-opt-in-01.txt
-
-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.
-
- This Internet-Draft will expire on August 31, 2001.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
-Abstract
-
- In order for DNSSEC to be deployed operationally with large zones
- and little operational impact, there needs to be included a
- mechanism that allows for the separation of secure versus unsecure
- views of zones. This needs to be done in a transparent fashion that
- allows DNSSEC to be deployed in an incremental manner. This
- document proposes the use of an extended RCODE to signify that a
- DNSSEC-aware requestor may have to re-query for the information, if
- and only if, the delegation is not yet secure. Thus, one can
- maintain two views of the zone and expand the DNSSEC zone as demand
- warrants.
-
-
-
-
-
-Kosters Expires August 31, 2001 [Page 1]
-\f
-Internet-Draft DNSSEC Opt In March 2001
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. Protocol Additions . . . . . . . . . . . . . . . . . . . . . . . 4
- 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
- References . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 9
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kosters Expires August 31, 2001 [Page 2]
-\f
-Internet-Draft DNSSEC Opt In March 2001
-
-
-1. Introduction
-
- DNS is an unsecure system. The key features that gives DNS its power
- can also be its chief weaknesses. One feature is the facility to
- delegate branches of information from one set of servers to another.
- Currently, this is done in a non-cryptographically verified way that
- allows spoofing attacks. For example, an alternative domain registry
- called AlterNIC exploited this vulnerability to redirect
- www.netsol.com and www.internic.net websites to their own website in
- July 1997 that gained widespread exposure. If this delegated
- information had been cryptographically verified, this attack would
- not have been able to occur.
-
- In recent years, there has been much work within the IETF regarding
- DNS security. There are a number of RFCs that integrate public key
- technology within DNS to enable cryptographically-verified answers.
- To this end, three new resource record types (RR's) have been
- defined:
-
- o KEY -- a public key of the zone
- o SIG - a signature of an accompanying RR
- o NXT - a negative response record
-
- Within the zone, each authoritative RR will have accompanying SIG
- RR's that can be verified with the KEY RR of the zone. Each KEY RR
- can be verified hierarchically with a SIG RR from the direct parent
- zone. For unsecure delegations, a null-KEY RR is inserted in the
- parent zone. Finally, NXT RR's and their accompanying SIG RR's are
- issued in the case of a negative reply.
-
- As a zone maintainer, transitioning to a secure zone has a high
- overhead in the following areas:
-
- KEY RR
- At a delegation point, the zone maintainer needs to place a NULL
- key and accompanying SIG RR's when the child zone is not known to
- be secure.
- NXT RR
- Each delegation needs to be lexigraphically ordered so that a NXT
- RR can be generated and signed with SIG RR's. For large zone
- operators, generating the zone file is a very time consuming
- process. In the resolution process, NXT lookups require that the
- server replace efficient hash structures with a lexigraphically
- ordered search structure that degrades lookup performance. This
- lookup performance is a critical element for a high-query rate
- DNS server.
-
- Thus, the net effect is when one initially secures a zone as defined
- in RFC2535[4], the net overhead is massive because of the following
-
-
-Kosters Expires August 31, 2001 [Page 3]
-\f
-Internet-Draft DNSSEC Opt In March 2001
-
-
- factors:
-
- 1. Zone ordering and maintenance for large zones is difficult and
- expensive.
- 2. Adding null-KEY RR's, NXT RR's and their accompanying SIG RR's
- for unsecure delegations will consume large amounts of memory
- (6x the current memory requirements).
- 3. Having a less efficient look-up algorithm to provide answers to
- queries will degrade overall performance.
- 4. Very little initial payoff (anticipate only a small fraction of
- delegations to be signed. This equates to less than 1% over the
- first six months).
- 5. Unsecured delegations are more expensive at the parent than
- secure delegations (NULL KEY).
-
-2. Rationale
-
- As DNSSEC is initially deployed, it is anticipated that DNSSEC
- adoption will be slow to materialize. It is also anticipated that
- DNSSEC security resolution will be top down. Thus for DNSSEC to be
- widely adopted, the root zone and GTLD zones will need to be signed.
- Based on the implications previously listed, a large zone maintainer
- such as the administrator of COM, needs to create an infrastructure
- that is an order of magnitude larger than its current state with
- very little initial benefit.
-
- This document proposes an alternative opt-in approach that minimizes
- the expense and complexity to ease adoption of DNSSEC for large
- zones by allowing for an alternate view of secured only delegations.
-
-3. Protocol Additions
-
- The opt-in proposal allows for a zone operator to maintain two views
- of its delegations - one being non-DNSSEC and the other being
- DNSSSEC aware. The non-DNSSEC view will have all delegations - both
- secured and non-secured. The DNSSEC aware view will only have
- secured delegations. It is assumed that neither view will have any
- innate knowledge of the other's delegations. Thus, the cost of
- securing a zone is proportional to the demand of its delegations
- with the added benefit of no longer having to maintain NULL KEY RRs
- for unsecure delegations.
-
- On the server side, identification of the zone being opt-in will be
- identified by using one of the reserved bits of the flags section
- within the KEY RR for that particular zone [note - the actual bit
- needs yet to be selected out of reserved bits 4-5 or 8-11].
-
- On the client side, the client MUST be identified by sending a
- option-code of RETRY-NO-SEC-AWARE within the OPT RR RDATA to ensure
-
-
-Kosters Expires August 31, 2001 [Page 4]
-\f
-Internet-Draft DNSSEC Opt In March 2001
-
-
- that it can accept and understand the RETRY-NO-SEC RCODE. The
- RETRY-NO-SEC-AWARE option-code MUST have an option-length value of
- zero with no option-data. The RETRY-NO-SEC-AWARE option-code will be
- determined by IANA.
-
- To determine which view each DNS query packet is to be queried
- against, there is a simple algorithm to be followed:
-
- 1. The DNSSEC view is to be queried when the DO bit is set within
- the EDNS0 OPT meta RR as indicated in [6] Additionally,
- 2. The DNSSEC view is to be queried when the query type is SIG,
- KEY, or NXT and the RRs added match the query name and query
- type.
-
- If the query does not follow either case (1) or (2), the non-DNSSEC
- view MUST be consulted by default.
-
- Since the DNSSEC view will have a subset of the actual delegations
- of that zone, it will not be able to respond to an unsecured
- delegation. To that end, one of two things will happen:
-
- 1) If the client has been identified as RETRY-NO-SEC-AWARE, a new
- extended RCODE MUST be set within the EDNS OPT RR for the resolver
- to retry again with the DO bit not set. This RCODE is referred to
- as "RETRY-NO-SEC" (RS). In the context of the EDNS0 OPT meta-RR,
- the RS value will be determined by IANA.
-
- Setting the RS RCODE in a response indicates to the resolver that
- the resolver is retrying the query again without the DO bit set. The
- behavior of the authority and additional records section being
- populated should be the same using the RS RCODE as the RCODE being
- set to NXDOMAIN. Therefore, the resolver will be able to verify that
- the answer does not exist within the secure zone since the NXT RR
- will be sent in the Authority section. To avoid caching, the server
- SHOULD set the TTL on the NXT RR to 0.
-
- 2) If the client has been identified as not being
- RETRY-NO-SEC-AWARE, the server itself MUST consult the non-secure
- view to compile the answer and respond back to the client. If the
- RR exists, the answer will show up normally with in the Answer and
- Additional sections and the NXT RR's within the Authority section
- along with the KEY RR and its SIG in the Additional section. If the
- RR does not exist, RCODE will be set to NXDOMAIN with the NXT RR
- will be sent in the Authority section along with the KEY RR and its
- SIG in the Additional section . Again, to avoid caching, the server
- SHOULD set the TTL on the NXT RR to 0.
-
- Note that latter case should be used during the transition of moving
- to clients that understand the RS RCODE only. It should not be
-
-
-Kosters Expires August 31, 2001 [Page 5]
-\f
-Internet-Draft DNSSEC Opt In March 2001
-
-
- viewed as a permanent solution and may deprecated in a short period
- of time.
-
- Example:
-
- Consider a zone with the secure names 3, 6, and 9, and unsecure
- names 2, 4, 5, 7, and 8.
-
- Unsecured zone Contents:
-
- @ SOA
- 2 NS
- 3 NS
- 4 NS
- 5 NS
- 6 NS
- 7 NS
- 8 NS
- 9 NS
-
- Secured zone Contents:
- @ SOA, SIG SOA, NXT(3), SIG NXT
- 3 NS, SIG NS, NXT(6), SIG NXT
- 6 NS, SIG NS, NXT(9), SIG NXT
- 9 NS, SIG NS, NXT(@), SIG NXT
-
- 1. Query for 5 RR type A with EDNS0 DO bit set along with the
- RETRY-NO-SEC-AWARE option code, the response would return with
- the extended RCODE RS bit set:
-
-
- RCODE=RS
- Authority Section:
- SOA, SIG SOA, 3 NXT(6), SIG NXT
- Additional Section:
- KEY, SIG KEY
-
-
- The source would then retry without the EDNS0 DO bit set which
- would return an answer as defined in RFC1035[2].
-
- 2. Query for 5 RR type A with EDNS0 DO bit only, the response would
- return with the following:
-
-
- RCODE=NOERROR
- Answer Section:
- 5 NS
- Authority Section:
-
-
-Kosters Expires August 31, 2001 [Page 6]
-\f
-Internet-Draft DNSSEC Opt In March 2001
-
-
- 3 NXT(6), SIG NXT
- Additional Section:
- KEY, SIG KEY
-
-
-
- 3. Query for 55 RR type A with EDNS0 DO bit set along with the
- RETRY-NO-SEC-AWARE option code, the response would return with
- the extended RCODE RS bit set:
-
-
- RCODE=RS
- Authority Section:
- SOA, SIG SOA, 3 NXT(6), SIG NXT
- Additional Section:
- KEY, SIG KEY
-
-
- The source would then retry without the EDNS0 DO bit set which
- would return an answer as defined in RFC1035[2]. The subsequent
- 1035 answer would contain a RCODE of NXDOMAIN since the domain
- 55 does not exist.
-
- 4. Query for 3 RR type KEY without EDNS DO bit set. The response
- would return with an answer as defined in RFC2535[4].
-
- 5. Query for 3 RR type A, with EDNS0 DO bit set, the response would
- be the same as defined in RFC2535[4].
-
-
-4. Security Considerations
-
- This draft is different and separate from RFC2535[4] in that it
- allows for secured delegation paths to exist but does not allow for
- secure answers to unsecured delegations at the parent level.
- Increased exposure will be marginal given that the children are
- unsecure.
-
-5. IANA Considerations
-
- 1) Allocation of a bit within the reserved portion of the KEY RR to
- indicate that the zone is an opt-in zone.
-
- 2) Allocation of the most significant bit of the RCODE field in the
- EDNS0 OPT meta-RR is required.
-
- 3) Allocation of an option-code within the OPT RR to indicate that
- the client can understand the new RCODE.
-
-
-
-Kosters Expires August 31, 2001 [Page 7]
-\f
-Internet-Draft DNSSEC Opt In March 2001
-
-
-6. Acknowledgements
-
- This document is based on a rough draft by Brian Wellington, and
- input from Olafur Gudmundsson.
-
-References
-
- [1] Mockapetris, P.V., "Domain names - concepts and facilities",
- RFC 1034, STD 13, Nov 1987.
-
- [2] Mockapetris, P.V., "Domain names - implementation and
- specification", RFC 1035, STD 13, Nov 1987.
-
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, BCP 14, March 1997.
-
- [4] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [5] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671,
- August 1999.
-
- [6] Conrad, D. R., "Indicating Resolver Support of DNSSEC (work in
- progress)", August 2000.
-
-
-Author's Address
-
- Mark Kosters
- Network Solutions, Inc.
- 505 Huntmar Park Drive
- Herndon, VA 22070
- US
-
- Phone: +1 703 948-3362
- EMail: markk@netsol.com
- URI: http://www.netsol.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kosters Expires August 31, 2001 [Page 8]
-\f
-Internet-Draft DNSSEC Opt In March 2001
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2001). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph
- are included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kosters Expires August 31, 2001 [Page 9]
-\f
+++ /dev/null
-
-Internet Engineering Task Force E. Lewis
-Internet-Draft ARIN
-February 4, 2003 Expires: August 4, 2003
-
- Clarifying the Role of Wild Card Domains
- in the Domain Name System
- <draft-lewis-dns-wildcard-clarify-00.txt>
-
-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 definition of wild cards is recast from the original in RFC 1034,
-in words that are more specific and in line with RFC 2119. This document
-is meant to supplement the definition in RFC 1034 and to alter neither
-the spirit nor intent of that definition.
-
-1 Introduction
-
-The first section of this document will give a crisp overview of what
-is begin defined, as well as the motivation for what amounts to a
-simple rewording of an original document. An example is included to
-help orient the reader.
-
-Wild card domain names are defined in Section 4.3.3. of RFC 1034 as
-"instructions for synthesizing RRs." [RFC1034] The meaning of this is
-that a specific, special domain name is used to construct responses in
-instances in which the query name is not otherwise represented in a zone.
-
-A wild card domain name has a specific range of influence on query names
-(QNAMEs) within a given class, which is rooted at the domain name
-containing the wild card label, and is limited by explicit entries, zone
-cuts and empty non-terminal domains (see section 1.3 of this document).
-
-Note that a wild card domain name has no special impact on the search
-for a query type (QTYPE). If a domain name is found that matches the
-QNAME (exact or a wild card) but the QTYPE is not found at that point,
-the proper response is that there is no data available. The search
-does not continue on to seek other wild cards that might match the QTYPE.
-To illustrate, a wild card owning an MX RR does not 'cover' other names
-in the zone that own an A RR.
-
-Why is this document needed? Empirical evidence suggests that the
-words in RFC 1034 are not clear enough. There exist a number of
-implementations that have strayed from the definition. There also
-exists a misconception of operators that the wild card can be used to
-add a specific RR type to all names, such as the MX RR example listed
-above. This document is also needed as input to efforts to extend
-DNS, such as the DNS Security Extensions [RFC 2535]. Lack of a clear
-base specification has proven to result in extension documents that
-have unpredictable consequences. (This is true in general, not just
-for DNS.)
-
-1.1 Existence
-
-The notion that a domain name 'exists' will arise numerous times in this
-discussion. RFC 1034 raises the issue of existence in a number of places,
-usually in reference to non-existence and often in reference to processing
-involving wild card domain names. RFC 1034 does contain algorithms that
-describe how domain names impact the preparation of an answer and does
-define wild cards as a means of synthesizing answers.
-
-To help clarify the topic of wild cards, a positive definition of existence
-is needed. To complicate matters, though, there needs to be a recognition
-that existence is relative. To an authoritative server, a domain name
-exists if the domain name plays a role following the algorithms of
-preparing a response. To a resolver, a domain name exists if there is
-any data available corresponding to the name. The difference between the
-two is the synthesis of records according to a wild card.
-
-For the purposes of this document, the point of view of an authoritative
-server is adopted. A domain name is said to exist if it plays a role in
-the execution of the algorithms in RFC 1034.
-
-1.2 An Example
-
-For example, consider this wild card domain name: *.example. Any query
-name under example. is a candidate to be matched (answered) by this wild
-card. Although any name is a candidate, not all queries will match.
-
-To further illustrate this, consider this example:
-
- $ORIGIN example.
- @ IN SOA
- NS
- NS
- * TXT "this is a wild card"
- MX 10 mailhost.example.
- host1 A 10.0.0.1
- _ssh._tcp.host1 SRV
- _ssh._tcp.host2 SRV
- subdel NS
-
-The following queries would be synthesized from the wild card:
- QNAME=host3.example. QTYPE=MX, QCLASS=IN
- the answer will be a "host.example. IN MX ..."
- QNAME=host3.example. QTYPE=A, QCLASS=IN
- the answer will be a "host.example. IN NXT ..."
- because there is no A RR set at '*'
-
-The following queries would not be synthesized from the wild card:
- QNAME=host1.example., QTYPE=MX, QCLASS=IN
- because host1.example. exists
- QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
- because _tcp.host1.example. exists (without data)
- QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN
- because host2.example. exists (without data)
- QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
- because subdel.example. exists and is a zone cut
-
-To the server, the following domains are considered to exist in the zone:
-*, host1, _tcp.host1, _ssh._tcp.host1, host2, _tcp.host2, _ssh._tcp.host2,
-and subdel. To a resolver, many more domains appear to exist via the
-synthesis of the wild card.
-
-1.3 Empty Non-terminals
-
-Empty non-terminals are domain names that have no data but have
-subdomains. This is defined in section 3.1 of RFC 1034:
-
-# The domain name space is a tree structure. Each node and leaf on the
-# tree corresponds to a resource set (which may be empty). The domain
-# system makes no distinctions between the uses of the interior nodes and
-# leaves, and this memo uses the term "node" to refer to both.
-
-The parenthesized "which may be empty" specifies that empty non-terminals
-are explicitly recognized. According to the definition of existence in
-this document, empty non-terminals do exist at the server.
-
-Carefully reading the above paragraph can lead to an interpretation that
-all possible domains exist - up to the suggested limit of 255 octets for
-a domain name [RFC 1035]. For example, www.example. may have an A RR, and
-as far as is practically concerned, is a leaf of the domain tree. But the
-definition can be taken to mean that sub.www.example. also exists, albeit
-with no data. By extension, all possible domains exist, from the root
-down. As RFC 1034 also defines "an authoritative name error indicating
-that the name does not exist" in section 4.3.1, this is not the intent
-of the original document.
-
-RFC1034's wording is to be clarified by adding the following paragraph:
-
- A node is considered to have an impact on the algorithms of 4.3.2
- if it is a leaf node with any resource sets or an interior node,
- with or without a resource set, that has a subdomain that is a leaf
- node with a resource set. A QNAME and QCLASS matching an existing
- node never results in a response return code of authoritative name
- error.
-
-As an aside, an "authoritative name error" has been called NXDOMAIN in
-some RFCs, such as RFC 2136 [RFC 2136]. NXDOMAIN is the mnemonic assigned
-to such an error by at least one implementation of DNS.
-
-1.3 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 the document entitled
-"Key words for use in RFCs to Indicate Requirement Levels." [RFC2119]
-
-Requirements are denoted by paragraphs that begin with with the following
-convention: 'R'<sect>.<count>.
-
-2 Defining the Wild Card Domain Name
-
-A wild card domain name is defined by having the initial label be:
-
- 0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
-
-This defines domain names that may play a role in being a wild card, that
-is, being a source for synthesized answers. Domain names conforming to
-this definition that appear in queries and RDATA sections do not have
-any special role. These cases will be described in more detail in
-following sections.
-
-R2.1 A domain name that is to be interpreted as a wild card MUST begin
- with a label of '0000 0001 0010 1010' in binary.
-
-The first octet is the normal label type and length for a 1 octet long
-label, the second octet is the ASCII representation [RFC 20] for the
-'*' character. In RFC 1034, ASCII encoding is assumed to be the character
-encoding.
-
-In the master file formats used in RFCs, a "*" is a legal representation
-for the wild card label. Even if the "*" is escaped, it is still
-interpreted as the wild card when it is the only character in the label.
-
-R2.2. A server MUST treat a wild card domain name as the basis of
- synthesized answers regardless of any "escape" sequences in
- the input format.
-
-RFC 1034 and RFC 1035 ignore the case in which a domain name might be
-"the*.example.com." The interpretation is that this domain name in a
-zone would only match queries for "the*.example.com" and not have any
-other role.
-
-Note: By virtue of this definition, a wild card domain name may have a
-subdomain. The subdomain (or sub-subdomain) itself may also be a wild
-card. E.g., *.*.example. is a wild card, so is *.sub.*.example.
-More discussion on this is given in Appendix A.
-
-3 Defining Existence
-
-As described in the Introduction, a precise definition of existence is
-needed.
-
-R3.1 An authoritative server MUST treat a domain name as existing during
- the execution of the algorithms in RFC 1034 when the domain name
- conforms to the following definition. A domain name is defined
- to exist if the domain name owns data and/or has a subdomain that
- exists.
-
-Note that at a zone boundary, the domain name owns data, including the
-NS RR set. At the delegating server, the NS RR set is not authoritative,
-but that is of no consequence here. The domain name owns data, therefore,
-it exists.
-
-R3.2 An authoritative server MUST treat a domain name that has neither
- a resource record set nor a subdomain as nonexistent when executing
- the algorithm in section 4.3.2. of RFC 1034.
-
-4 Impact of a Wild Card Domain In a Query Message
-
-When a wild card domain name appears in a question, e.g., the query name
-is "*.example.", the response in no way differs from any other query.
-In other words, the wild card label in a QNAME has no special meaning,
-and query processing will proceed using '*' as a literal query name.
-
-R4.1 A wild card domain name acting as a QNAME MUST be treated as any
- other QNAME, there MUST be no special processing accorded it.
-
-If a wild card domain name appears in the RDATA of a CNAME RR or any
-other RR that has a domain name in it, the same rule applies. In the
-instance of a CNAME RR, the wild card domain name is used in the same
-manner of as being the original QNAME. For other RR's, rules vary
-regarding what is done with the domain name(s) appearing in them,
-in no case does the wild card hold special meaning.
-
-R4.2 A wild card domain name appearing in any RR's RDATA MUST be treated
- as any other domain name in that situation, there MUST be no special
- processing accorded it.
-
-5 Impact of a Wild Card Domain On a Response
-
-The description of how wild cards impact response generation is in RFC
-1034, section 4.3.2. That passage contains the algorithm followed by a
-server in constructing a response. Within that algorithm step 3, part
-'c' defines the behavior of the wild card. The algorithm is directly
-quoted in lines that begin with a '#' sign. Commentary is interleaved.
-
-[Note that are no requirements specifically listed in this section. The
-text here is explanatory and interpretative. There is no change to
-the algorithm specified in RFC 1034.]
-
-The context of part 'c' is that the search is progressing label by label
-through the QNAME. (Note that the data being searched is the authoritative
-data in the server, the cache is searched in step 4.) Step 3's part 'a'
-covers the case that the QNAME has been matched in full, regardless of the
-presence of a CNAME RR. Step 'b' covers crossing a cut point, resulting
-in a referral. All that is left is to look for the wild card.
-
-Step 3 of the algorithm also assumes that the search is looking in the
-zone closest to the answer, i.e., in the same class as QCLASS and as
-close to the authority as possible on this server. If the zone is not
-the authority, then a referral is given, possibly one indicating lameness.
-
-# c. If at some label, a match is impossible (i.e., the
-# corresponding label does not exist), look to see if a
-# the "*" label exists.
-
-The above paragraph refers to finding the domain name that exists in the
-zone and that most encloses the QNAME. Such a domain name will mark the
-boundary of candidate wild card domain names that might be used to
-synthesize an answer. (Remember that at this point, if the most enclosing
-name is the same as the QNAME, part 'a' would have recorded an exact
-match.) The existence of the enclosing name means that no wild card name
-higher in the tree is a candidate to answer the query.
-
-Once the closest enclosing node is identified, there's the matter of what
-exists below it. It may have subdomains, but none will be closer to the
-QNAME. One of the subdomains just might be a wild card. If it exists,
-this is the only wild card eligible to be used to synthesize an answer
-for the query. Even if the closest enclosing node conforms to the syntax
-rule in section 2 for being a wild card domain name, the closest enclosing
-node is not eligible to be a source of a synthesized answer.
-
-The only wild card domain name that is a candidate to synthesize an answer
-will be the "*" subdomain of the closest enclosing domain name. Three
-possibilities can happen. The "*" subdomain does not exist, the "*"
-subdomain does but does not have an RR set of the same type as the QTYPE,
-or it exists and has the desired RR set.
-
-For the sake of brevity, the closest enclosing node can be referred to as
-the "closest encloser."
-
-To illustrate, using the example in section 1.2 of this document, the
-following chart shows QNAMEs and the closest enclosers. In Appendix A
-there is another chart showing unusual cases.
-
- QNAME Closest Encloser Wild Card Source
- host3.example. example. *.example.
- _telnet._tcp.host1.example. _tcp.host1.example. no wild card
- _telnet._tcp.host2.example. host2.example. no wild card
- _telnet._tcp.host3.example. example. *.example.
- _chat._udp.host3.example. example. *.example.
-
-Note that host1.subdel.example. is in a subzone, so the search for it ends
-in a referral in part 'b', thus does not enter into finding a closest
-encloser.
-
-The fact that a closest encloser will be the only superdomain that
-can have a candidate wild card will have an impact when it comes to
-designing authenticated denial of existence proofs. (This concept
-is not introduced until DNS Security Extensions are considered in
-upcoming sections.)
-
-# If the "*" label does not exist, check whether the name
-# we are looking for is the original QNAME in the query
-# or a name we have followed due to a CNAME. If the name
-# is original, set an authoritative name error in the
-# response and exit. Otherwise just exit.
-
-The above passage says that if there is not even a wild card domain name
-to match at this point (failing to find an explicit answer elsewhere),
-we are to return an authoritative name error at this point. If we were
-following a CNAME, the specification is unclear, but seems to imply that
-a no error return code is appropriate, with just the CNAME RR (or sequence
-of CNAME RRs) in the answer section.
-
-# If the "*" label does exist, match RRs at that node
-# against QTYPE. If any match, copy them into the answer
-# section, but set the owner of the RR to be QNAME, and
-# not the node with the "*" label. Go to step 6.
-
-This final paragraph covers the role of the QTYPE in the process. Note
-that if no resource record set matches the QTYPE the result is that no data
-is copied, but the search still ceases ("Go to step 6.").
-
-6 Authenticated Denial and Wild Cards
-
-In unsecured DNS, the only concern when there is no data to return to
-a query is whether the domain name from which the answer comes exists or
-not, whether or not a name error is indicated in the return code. In
-either case the answer section is empty or contained just a sequence of
-CNAME RR sets.
-
-In securing DNS, authenticated denial of existence is a service that is
-provided. The chosen solution to provide this service is to generate
-resource records indicating what is protected in a zone and to digitally
-sign these.
-
-The resource records that do this, as defined in RFC 2535, are NXT RRs.
-
-There are three points to consider when clarifying the topic of wild card
-domain names. One is the construction of the records. The second is
-the inclusion of records in responses. The third is the interpretation
-of the records in a response by the resolver.
-
-6.1 Preparing Wild Card Domain Name Owned Non-existence Proofs
-
-During the creation of the authenticated denial records, the wild card
-domain name plays no special role, in the same manner as the wild card
-domain name playing no special role in a query.
-
-There is one consideration with regards to preparing non-existence
-proofs.
-
-R6.1 Any mechanism used to provide authenticated denial MUST reveal the
- closest enclosing existing domain for the query. If this is not
- provided, the resolver will not be able to ascertain the identity
- of an appropriate wild card domain name.
-
-6.2 Role of Wild Cards in Answers
-
-There are three cases to address. The first is synthesizing from wild card
-domain name with data, the second is negatively synthesizing from an
-existing wild card, and the third is denying that neither an exact match,
-referral, nor wild card exist to answer the query.
-
-6.2.1 Synthesizing From a Wild Card
-
-When preparing an answer from a wild card domain name, the answer needs
-to include proof that the exact match of the QNAME and QCLASS does not
-exist. This is needed because synthesis of the answer replaces the "*"
-label with the QNAME without securing the result. The resolver will
-realize that the answer was derived from a wild card, but cannot
-detect whether an exact match was maliciously omitted.
-
-R6.2 When synthesizing a positive answer from a wild card domain name, the
- answer MUST include proof that the exact match for the QNAME and
- QCLASS does not exist.
-
-6.2.2. Synthesizing Negatively From a Wild Card
-
-When synthesizing a negative answer that is derived from a wild card,
-meaning that a wild card matched the QNAME (no exact match happened for
-QNAME) but that there is no match for QTYPE there, two negative answers
-are needed, possibly one. As in 6.2.1, a proof that the exact match
-failed is needed. A second proof is needed to show that the wild card
-domain name does not have the QTYPE. Depending on the method of
-authenticated denial, these this could be possible with one statement.
-
-R6.3 When synthesizing a negative answer from a wild card domain name,
- the answer MUST include proof that the exact match of the QNAME
- and QCLASS does not exist and that the QTYPE matches no RR set at
- the wild card. If this answer can be optimized, an implementation
- SHOULD reduce the number of records included in the response.
-
-6.2.3. Answering With an Authoritative Name Error
-
-When answering with a result code of a name error, the answer needs to
-provide proof that neither the exact match for QNAME and QCLASS exists
-nor that a wild card domain name exists as a subdomain of the closest
-enclosing domain name.
-
-R6.4 When preparing a reply with an authoritative name error, the answer
- MUST include proof that the exact match for the QNAME and QCLASS
- does not exist and that no wild card is available to provide a match.
-
-6.2.4. The Remaining Case
-
-When answering negatively because there is a match for QNAME and QCLASS
-but no match for the QTYPE, only a proof for that is needed. Just as
-the search does not proceed onto a search for the wild card in this
-case, neither does the construction of the negative answer proof.
-
-R6.5 When preparing a reply in which there is an exact match of the
- QNAME and QCLASS, but there is no RR set matching the QTYPE,
- the reply SHOULD NOT contain any proof regarding the wild card
- domain name.
-
-6.3 Interpreting Negative Answers Involving Wild Cards
-
-There are two requirements for resolvers when it comes to handling
-negative answers generated as described in section 6.2.
-
-R6.6 A resolver MUST be able to identify negative answer data that
- indicate when a match for QNAME and QCLASS does not exist.
-
-R6.7 From a negative answer, a resolver MUST be able to determine
- the closest enclosing domain name in a negative answer and
- MUST be able to process a negative answer involving the one
- wild card domain name that is a candidate to provide a
- synthesized answer.
-
-6.4 Authenticated Denial, Wild Card Domain Names, and Opt-In
-
-When considering the Opt-In proposal [WIP], it is wise to not combine
-a zone that adheres to both opt-in and that has a wild card domain
-name. The reason is rooted in that the synthesis of an answer is done
-by substituting the QNAME for the wild card domain name in the answer.
-Because this is unsecured, and the is ambiguity regarding whether a
-negative proof can be provided for the exact match (when it is outside
-the opt-in secured area), a definitive proof of authenticated denial
-is not possible.
-
-7 Security Considerations
-
-This document is refining the specifications to make it more likely that
-security can be added to DNS. No functional additions are being made,
-just refining what is considered proper to allow the system, security
-of the system, and extending the system more predictable.
-
-8 References
-
-Normative References
-
-[RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969
-[RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris,
- Nov-01-1987
-[RFC 1035] Domain Names - Implementation and Specification, P.V
- Mockapetris, Nov-01-1987
-[RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S
- Bradner, March 1997
-
-Non-normative References
-
-[RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P. Vixie,
- Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997
-[RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999
-[WIP] DNSSEC Opt-In, Internet Draft, R. Arends, M. Kosters, D. Blacka, 2002
-
-9 Other Contributing to This Document
-
-Others who have directly caused text to appear in the document: Paul Vixie
-and Olaf Kolkman. Many others have indirect influences on the content.
-
-10 Editor
-
-Name: Edward Lewis
-Title: Research Engineer
-Affiliation: ARIN
-Email: edlewis@arin.net
-Phone: +1-703-227-9854
-
-Appendix A: Subdomains of Wild Card Domain Names
-
-In reading the definition of section 2 carefully, it is possible to
-rationalize unusual names as legal. In the example given, *.example.
-could have subdomains of *.sub.*.example. and even the more direct
-*.*.example. (The implication here is that these domain names own
-explicit resource records sets.) Although defining these names is not
-easy to justify, it is important that implementations account for the
-possibility. This section will give some further guidance on handling
-these names.
-
-The first thing to realize is that by all definitions, subdomains of
-wild card domain names are legal. In analyzing them, one realizes
-that they cause no harm by their existence. Because of this, they are
-allowed to exist, i.e., there are no special case rules made to disallow
-them. The reason for not preventing these names is that the prevention
-would just introduce more code paths to put into implementations.
-
-The concept of "closest enclosing" existing names is important to keep in
-mind. It is also important to realize that a wild card domain name can
-be a closest encloser of a query name. For example, if *.*.example. is
-defined in a zone, and the query name is a.*.example., then the closest
-enclosing domain name is *.example. Keep in mind that the closest
-encloser is not eligible to be a source of synthesized answers, just the
-subdomain of it that has the first label "*".
-
-To illustrate this, the following chart shows some matches. Assume that
-the names *.example., *.*.example., and *.sub.*.example. are defined
-in the zone.
-
- QNAME Closest Encloser Wild Card Source
- a.example. example. *.example.
- b.a.example. example. *.example.
- a.*.example. *.example. *.*.example.
- b.a.*.example. *.example. *.*.example.
- b.a.*.*.example. *.*.example. no wild card
- a.sub.*.example. sub.*.example. *.sub.*.example.
- b.a.sub.*.example. sub.*.example. *.sub.*.example.
- a.*.sub.*.example. *.sub.*.example. no wild card
- *.a.example. example. *.example.
- a.sub.b.example. example. *.example.
-
-Recall that the closest encloser itself cannot be the wild card. Therefore
-the match for b.a.*.*.example. has no applicable wild card.
-
-Finally, if a query name is sub.*.example., any answer available will come
-from an exact name match for sub.*.example. No wild card synthesis is
-performed in this case.
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society 2003. All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of developing
- Internet standards in which case the procedures for copyrights defined
- in the Internet Standards process must be followed, or as required to
- translate it into languages other than English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
- NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
- WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
---
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
-Edward Lewis +1-703-227-9854
-ARIN Research Engineer
-
+++ /dev/null
-INTERNET-DRAFT DNS Label Intelligence and Management System\r
-UPDATES RFC 1034 February 2001\r
- Expires August 2001\r
-\r
-\r
-\r
-\r
-Domain Name System (DNS) DNS Label Intelligence and Management System\r
- draft-macgowan-dnsext-label-intel-manage-00.txt\r
-\r
-\r
-\r
-Michael L. Macgowan Jr.\r
-\r
-\r
-Status of This Document\r
-\r
-This draft is intended to become a Proposed Standard RFC. Distribution \r
-of this document is unlimited. Comments should be sent to the Domain \r
-Name Server Extensions working group mailing \r
-list<namedroppers@ops.ietf.org> or to the author.\r
-\r
-This document is an Internet-Draft and is in full conformance with all \r
-provisions of Section 10 of RFC 2026. Internet-Drafts are working \r
-documents of the Internet Engineering Task Force (IETF), its areas, and \r
-its working groups. Note that other groups may also distribute working \r
-documents as Internet-Drafts.\r
-\r
-Internet-Drafts are draft documents valid for a maximum of six months \r
-and may be updated, replaced, or obsoleted by other documents at any \r
-time. It is inappropriate to use Internet- Drafts as reference \r
-material or to cite them other than as "work in progress."\r
-\r
-The list of current Internet-Drafts can be accessed at \r
-http://www.ietf.org/ietf/1id-abstracts.txt\r
-\r
-The list of Internet-Draft Shadow Directories can be accessed at \r
-http://www.ietf.org/shadow.html.\r
-\r
-\r
-\r
-Abstract\r
-\r
-\r
-A multidimensional array of domain label analysis and extensions are \r
-offered to overcome a number of issues with the DNS and its use to \r
-locate resources on the Internet. These goals are accomplished by \r
-proposing a naming convention to add labels to domain strings. The \r
-result will be a rational relationship to the content that will provide \r
-a method for meeting the ever-increasing need to expand the namespace, \r
-while providing an efficient search system to access content in a user-\r
-friendly manner.\r
-\r
-A fundamental problem exists in the design of DNS. A user must know the \r
-domain name including the Top Level Domain, TLD, and type the Uniform \r
-Resource Locator, URL, accurately to connect to resources on the \r
-Internet. The current lookup organization of the DNS uses domain labels \r
-separated by periods to provide hierarchical levels for a resolver to \r
-seek in finding a path to an authority. A new masking technique within \r
-labels is proposed to accommodate lookups based on the request. \r
-Multiple processing trees are proposed to redistribute the requests \r
-based on the known pieces of the domain name. Rather than knowing the \r
-fully qualified domain name, FQDN, the user can search for content \r
-based upon known pieces of the string like group (business), country, \r
-area code, phone number, type of organization, street address, zip code \r
-and/or GPS location, etc.. Intelligence is added for determining the \r
-fastest route to resolution based on user weighting, number of \r
-requests, and traffic within the system.\r
-\r
-A result of the masking technique is an opportunity to provide a \r
-completely hidden label(s) for maintenance of the system. A TTL (Time \r
-to Live), version, and type of request could be keyed into a label to \r
-provide information, which remains with the client but is normally lost \r
-after a request is processed. This system could be implemented to \r
-create automatically updated records and content. Or hidden labels \r
-could be used to distinguish between version 4 and version 6 requests \r
-in the TCP/IP, Transmission Control Protocol/ Internet Protocol, \r
-rollover.\r
-\r
-Implementation of the new name system is facilitated by the addition of \r
-a client interface for building requests. Longer domain names are \r
-enhanced by smart AutoCompletes and group edit boxes.\r
-\r
-Table of Contents\r
-\r
- Status of This Document 1\r
- Abstract 1\r
-\r
- Table of Contents 3\r
-\r
- 1. Introduction 4\r
- 2. Inputting Request for Resolution 4\r
- 3. Resolution Processing 7\r
- 4. Processing Forest 13\r
- 5. Extended Label Uses 14\r
- 6. IANA Considerations 16\r
- 6. Security Considerations 16\r
-\r
- References 16\r
-\r
- Authors Address 16\r
- Expiration and File Name 17\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-1. Introduction\r
-\r
-The Domain Name System (DNS) [RFC 1034, 1035] is the global \r
-hierarchical replicated distributed database system for Internet \r
-addressing, mail proxy, and other information. The DNS has been \r
-extended to phone numbers as described in [RFC 2535]. It is designed to \r
-accommodate a user-friendly name as an abstraction level over an IP \r
-address, which provides a path to the physical connection to resources \r
-and/or content on the Internet. This abstraction allows for changing \r
-the physical location of the content without an update by the client. \r
-The design, however, lacks a user-friendly method for assigning TLDs \r
-and determining which TLD a content provider will be registered under.\r
-\r
-According to COMPUTERGRAM INTERNATIONAL: January 08, 2001, over 100 \r
-million hosts are connected to the Internet with over 350 million \r
-users. ICANN has submitted plans to increase the number of TLDs to \r
-accommodate the lack of namespace, but the problem of organization and \r
-extensibility continues to exist. As the number of TLDs grows, it \r
-becomes harder for a user to input a user friendly domain name. In \r
-essence, the user must know what derivations and which TLDs were \r
-available to a provider at the time the organization chose a domain \r
-name. The method of one response, in an all or nothing request, forces \r
-precision on the part of the user that is a distraction to the original \r
-goal of a user-friendly name. Consider a user that wants to find a new \r
-theoretical health related company called Healthy Foods. Will the \r
-company be called Healthyfoods.com? Or will it have an extension like \r
-healthfoods.net, healthfoods.org, or healthfoods.health? Maybe it will \r
-be forced to be a derivation like healthf.com, healthf.net, etc. There \r
-is no user-friendly method to determine what the associated domain name \r
-might be. This is a central problem of focus and organization. The \r
-number of iterations a user must try increases with each new TLD that \r
-is added. If a user forms multiple guesses for the TLD, excess traffic \r
-is generated and the search is slowed by the inefficient nature of \r
-human typing. Further, if a system were proposed under the current root \r
-structure to allow for a search of all possible TLDs, the number of \r
-requests would grow exponentially with the addition of each new TLD.\r
-\r
-2. Inputting Request for Resolution\r
- \r
-\r
-\r
-The key to making a New Name System, NNS, is to provide a user \r
-interface, which will accommodate a friendly method of building name \r
-requests. AutoComplete and multiple-selection drop-down, group list \r
-boxes (some editable, some not) will make more complicated names easier \r
-to input. Consider the previous example of Healthy Foods. Additional \r
-extensions could be added as labels to make the namespace exponentially \r
-larger. The web content might be reached at \r
-www.healthy.food.US2081234567.Fairview101. In this example, www is the \r
-Device label or content desired by the user. Health is the domain or \r
-Subgroup/Group name label. Food is the item under the Type label. \r
-US2081234567 is the item country/area code/number for the Global label. \r
-Sfairview101 is the street/address of the Local label.\r
-\r
-Derivations of this example provide a limitless expansion of the \r
-namespace within the physical limits of the protocol. A competitor down \r
-the block might have the same FQDN, except for the street number and \r
-phone number e.g. www.healthy.food.US2088901234.SFairview990. A second \r
-type of business could also be run from the same location by changing \r
-the type e.g. www.healthy.entertainment.US2081234567.SFairview101. A \r
-parody of the site might be offered at \r
-www.healthy.parody.us2086669999.SState103.\r
-\r
-A method of using less descriptive labels could also be used to \r
-generalize the content. For example, the site for the regional office \r
-might use only the country and area code designation e.g. .US208. A \r
-corporate address might be located at www.healthy.food.US.corporate. \r
-This way the Global and Local labels are not tied to physical \r
-locations. Or there may be an 800 or 888 number that could be used for \r
-multiple sites that are tied to multiple registrations at different \r
-street addresses in the Local label.\r
-\r
-The task of building these longer names with labels can be accomplished \r
-by updating list items from the NNS and by designing a better \r
-interface. Instead of waiting for ICANN to vote on the relative merits \r
-of a proposal for a new TLD, items could be automatically updated and \r
-added to the system by a list of requirements. This would force a \r
-relationship between labels but provide a nonbiased method without \r
-prejudice. For example, a .Bus(iness) item for the Type label would \r
-require a copy of a business license to be granted by the governing \r
-authorities for the area specified in the Global label or the address \r
-specified in the Local label. A \93TM\94 item could separate the \r
-Intellectual Property of Trademarks and Copyrights from other \r
-registered listings issued from the government specified by the country \r
-code in the Global label. Additionally, the Academy of Motion Pictures \r
-might request an Oscar item, which would restrict membership to \r
-nominees or recipients of the coveted award. \r
-\r
-Just as the resolver gets an updated list of root servers upon first \r
-connection, the resolver could also receive an updated list of items in \r
-the Type label and return them to the client. The list could be updated \r
-by a TTL trigger and should not be editable from the user\92s standpoint. \r
-The user interface should allow for multiple selections, which could be \r
-used to form separate requests for resolution. Finally, the \r
-implementation should begin with at least a list that is equal to a \r
-subject list found in the yellow pages of the phone book. This will \r
-provide a well-known classification that will greatly reduce \r
-competition for names of organizations, which are similar but provide \r
-for very different products/services. Delta.airline is readily \r
-distinguished from Delta.homeimprovement.\r
-\r
-The device label would remain largely unaffected. A list of previously \r
-connected items such as www, toasters, lock, refrigerator, etc. would \r
-facilitate input. The list would be editable. As the number of devices \r
-connected to the Internet grows, this method will be invaluable. \r
-Consider mail and faxes being sent directly to \r
-printer.mybusiness.computer.us2081234567.sfairview101. A user that \r
-needs to send a fax to a satellite office might also be able to try \r
-searching for mybusiness at its other street address or telephone \r
-number eg., printer.mybusiness.computer.us714*.sPensylvaiaave2345. \r
-Wildcards and searching are discussed in the next section. \r
-\r
-The items under the Groups/Subgroups labels would also be a list of \r
-previously connected to domains (less the TLD) such as sales.business \r
-or kitchen.home. The list would contain a history of previous \r
-connections and be editable.\r
-\r
-The Global label would have two characters to represent the country \r
-code followed optionally by all or part of a representative telephone \r
-number or mask for identifying the voice number(s) associated as items \r
-in the domain. An international code would require a rational \r
-relationship with world organizations. The interface would contain the \r
-country codes and/or area codes, but the numbers would have to be \r
-added.\r
-\r
-The Local label would require a single character to represent the type \r
-of information presented, followed by the information in a standardized \r
-form. The following codes are proposed for the Local label, \93P\94 for \r
-Postal code, \93G\94 for Global Satellite Positioning and \93S\94 for street \r
-address. For example, P83706 would represent the author\92s postal code, \r
-GP0445004N1162498 (since the \93+\94 key is not valid, \93p\94 and \93n\94 \r
-represent positive and negative) would represent the GPS position of \r
-the author with padding to standardize degrees/min/sec or SOrchard15541 \r
-would represent the Street address (house number at the end). Note each \r
-of these would require a separate name registration. The editable list \r
-box could be a fly out list box with one of the designators specified, \r
-while the remainder would be user input.\r
-\r
-+------------------+\r
-|Street |\r
-| Fairview101 |\r
- State101 |\r
-|Postal |\r
-|GPS |\r
-+------------------+\r
-\r
-The added labels would exponentially expand the name space. This may \r
-cause an undesired relation to a Global or Local designation. This \r
-could hamper changes to an organization or business in the future. \r
-Hence a business might want to use a CNAME entry to reference users to \r
-a non-distinct item in a label. For instance, a corporation might want \r
-to register mybusiness.bus.In(ternational).corporate so that the \r
-corporate office could be used for email addresses and bookmarking. \r
-Content might be located at each mybusiness.bus.country.location where \r
-the company does business. This way a corporation does not have to be \r
-penalized for moving to a new physical location. The goal of the DNS \r
-was to remove a physical relationship to the network, but the need of \r
-the users is for some content to have a physical relationship to the \r
-content; which is why, in part, the NNS is proposed. The concept of an \r
-update is also discussed in section 5.\r
-\r
-The system would need to distinguish between the need for a request for \r
-a connection to single IP address versus multiple requests. In an \r
-application like a browser, traditional requests for IP resolution are \r
-all or none. Either an IP address is connected to or not. If wildcards \r
-are added to the request, multiple entries could be returned as a \93hit\94 \r
-list. An option on the browser could determine the number of requests \r
-specified by the user. The \93hits\94 should also be weighted. For \r
-instance, if a user wanted to find all the movie theatres in the local \r
-area he/she might submit a request for www.*.movies.US8370*.*. She/he \r
-would be more inclined to desire additional theatres at different \r
-nearby area codes than derivations of different domain names or Local \r
-label derivations for a single theatre. A simple listing of each label \r
-with an associated numerical value in an advanced option field could \r
-determine how the responses are weighted against one another. The NNS \r
-could also take into account the number of requests on the system and \r
-further limit the number of responses based upon traffic.\r
-\r
-For registration, the content provider might want to register a more \r
-global entry to be displayed on a restrictive search e.g. loans.US*.*. \r
-A business content provider might want to register mybusiness.com.US* \r
-so that requests for www.mybusiness.com.US208.* and \r
-www.mybusiness.com.us714.* both resolve to mybusiness. A process would \r
-have to be in place to copy an entry with wildcards to each of the \r
-associated branches of the processing trees as discussed in section 4. \r
-Similarly wildcard registrations should meet the rational requirements \r
-required for the known item with the generalized scope. In the previous \r
-example the provider would have to be licensed as a financial \r
-institution in each of the states of the United States.\r
-\r
-3. Resolution Processing\r
-\r
-The key to expanding the DNS is to provide for a name space, which can \r
-be accessed quickly and efficiently. Organization is key to this \r
-process. The current DNS has one root organized by TLDs of the Type \r
-label combined with Country TLDs. If a user does not know the extension \r
-for the name, requests must be created for each one until a match is \r
-found. The NNS creates separate roots for each label that can be used \r
-for a search (see graphic on next page, description of TLDs is in \r
-section 5). Instead of one tree, a forest is created, connected by a \r
-common list of authorities for devices in the zones requested. Requests \r
-can be organized by the known piece(s) of information. For instance, if \r
-a user is trying to find Hewlett Packard and does not know that content \r
-is provided at HP, a search of www.H*.*.US*.* should be returned \r
-alphabetically from the Group label, not the Type label. However, if \r
-the type item is known to be \93computer\94, a search of the Type tree \r
-would be fastest. If a user wants to find a local voice number for \r
-Microsoft he/she could submit a request generalized request within the \r
-local area code for www.Microsoft.software.US208*.*. The authority \r
-would best be located by the Global processor, which might list \r
-www.Microsoft.software.US5041234567.SState123 and \r
-www.Microsoft.software.US5044567890.SredmondAve123. If the request for \r
-www.Microsoft.software.US504*.* were sent to the Local processor, every \r
-TLD would have to be queried. The result might be one phone number with \r
-separate Local label listings for the street address, GPS, and postal \r
-code. This would create unwanted traffic on the system.\r
-\r
-\r
-Root \93.\94 Group Root \93.\94Type\r
- | |\r
- | |\r
- \93H\94 TLD TLD \93Computer\94\r
- | |\r
- | |\r
- --- Authority for..HP.computer.US2081234567.SChinden12----\r
- | |\r
- | |\r
- \93US208\94 TLD TLD \93SChi\94\r
- | |\r
- | |\r
-Root \93.\94 Global Root \93.\94Local\r
-\r
-\r
-In addition to determining which label(s) to process the request, the \r
-system would also have to take into account the weighting by the user \r
-and the traffic on the system as discussed in the previous section. \r
-When the FQDN is specified, the resolver would query the processor with \r
-the fastest expected response time. A FQDN can be resolved from any of \r
-the search processor trees. In the example \r
-oven.macgowan.private.US2081234567.SOrchard15541, it does not matter \r
-whether the request is sent to the Group, Type, Global, or Local \r
-processing tree. Each leads to the authority, \r
-macgowan.private.us2081234567.SOrchard15541.\r
-\r
-If wildcards or null characters exist in the request, the system should \r
-take into account the number of requests that might be generated. \r
-Currently the DNS does not account for the \93?\94 and reserves the \93\94 for \r
-the root. The \93*\94 could replace the singe character wildcard \93?\94 and \r
-the word \93null\94 could be used in lieu of \93\94. The following table could \r
-be used to determine which processing tree should be the most desirable \r
-under such conditions:\r
-\r
-any = any combination of characters displayed in request\r
-reject= no preferred processor\r
-*= match any combination of characters for response\r
-?= match any single character for response\r
-null= no character specified\r
-\r
-\r
-Device Sub Group T G L Result\r
-* * * * * * reject\r
-* any any any any any reject\r
-* * any any any any reject\r
-* * * any any any submit to T, G, or L \r
-* * * * any any submit to G, or L \r
-* * * * * any submit to L \r
-any * * * * * reject\r
-any any * * * * reject\r
-any any any * * * submit to group \r
-any any any any * * submit to group, or T \r
-any any any any any * submit to group, T, or G \r
-any any any any any any submit to any \r
-any * any any any any submit to any \r
-any * * any any any submit to T, G, or L \r
-any * * * any any submit to any G, or L \r
-any * * * * any submit to any L \r
-any any * any any any submit to any T, G, or L \r
-any any * * any any submit to any G, or L \r
-any any * * * any submit to any L \r
-any any any * any any submit to any group, G, or L \r
-any any any * * any submit to any group, or L \r
-any any any any * any submit to any group, T, or L \r
-any any any any * * submit to any group, or T \r
- \r
-* * * * * * reject\r
-* any*any any*any any*any any*any any*any reject\r
-* * any*any any*any any*any any*any reject\r
-* * * any*any any*any any*any submit to T, G, or L \r
-* * * * any*any any*any submit to G, or L \r
-* * * * * any*any submit to L \r
-any*any * * * * * reject\r
-any*any any*any * * * * reject\r
-any*any any*any any*any * * * submit to group \r
-any*any any*any any*any any*any * * submit to group, or T \r
-any*any any*any any*any any*any any*any * submit to group, T, or G \r
-any*any any*any any*any any*any any*any any*any reject\r
-any*any * any*any any*any any*any any*any reject\r
-any*any * * any*any any*any any*any submit to T, G, or L \r
-any*any * * * any*any any*any submit to any G, or L \r
-any*any * * * * any*any submit to any L \r
-any*any any*any * any*any any*any any*any reject\r
-any*any any*any * * any*any any*any submit to any G, or L \r
-any*any any*any * * * any*any submit to any L \r
-any*any any*any any*any * any*any any*any reject\r
-any*any any*any any*any * * any*any submit to any group, or L \r
-any*any any*any any*any any*any * any*any submit to any group, T, or L \r
-any*any any*any any*any any*any * * submit to any group, or T \r
- \r
-* * * * * * reject\r
-* any* any* any* any* any* reject\r
-* * any* any* any* any* reject\r
-* * * any* any* any* reject\r
-* * * * any* any* submit to G, or L \r
-* * * * * any* submit to L \r
-any* * * * * * reject\r
-any* any* * * * * reject\r
-any* any* any* * * * reject\r
-any* any* any* any* * * reject\r
-any* any* any* any* any* * reject\r
-any* any* any* any* any* any* reject\r
-any* * any* any* any* any* reject\r
-any* * * any* any* any* submit to T, G, or L \r
-any* * * * any* any* submit to any G, or L \r
-any* * * * * any* submit to any L \r
-any* any* * any* any* any* reject\r
-any* any* * * any* any* submit to any G, or L \r
-any* any* * * * any* submit to any L \r
-any* any* any* * any* any* reject\r
-any* any* any* * * any* submit to any group, or L \r
-any* any* any* any* * any* reject\r
-any* any* any* any* * * submit to any group, or T \r
- \r
-?any ?any ?any ?any ?any ?any reject\r
-?any any any any any any reject\r
-?any ?any any any any any reject\r
-?any ?any ?any any any any submit to T, G, or L \r
-?any ?any ?any ?any any any submit to G, or L \r
-?any ?any ?any ?any ?any any submit to L \r
-any ?any ?any ?any ?any ?any reject\r
-any any ?any ?any ?any ?any reject\r
-any any any ?any ?any ?any submit to group \r
-any any any any ?any ?any submit to group, or T \r
-any any any any any ?any submit to group, T, or G \r
-any any any any any any submit to any \r
-any ?any any any any any submit to any \r
-any ?any ?any any any any submit to T, G, or L \r
-any ?any ?any ?any any any submit to any G, or L \r
-any ?any ?any ?any ?any any submit to any L \r
-any any ?any any any any submit to any T, G, or L \r
-any any ?any ?any any any submit to any G, or L \r
-any any ?any ?any ?any any submit to any L \r
-any any any ?any any any submit to any group, G, or L \r
-any any any ?any ?any any submit to any group, or L \r
-any any any any ?any any submit to any group, T, or L \r
-any any any any ?any ?any submit to any group, or T \r
- \r
-any?any any?any any?any any?any any?any any?any reject\r
-any?any any any any any any submit to any \r
-any?any any?any any any any any submit to any \r
-any?any any?any any?any any any any submit to any \r
-any?any any?any any?any any?any any any submit to G, or L \r
-any?any any?any any?any any?any any?any any submit to L \r
-any any?any any?any any?any any?any any?any reject\r
-any any any?any any?any any?any any?any reject\r
-any any any any?any any?any any?any submit to group \r
-any any any any any?any any?any submit to group, or T \r
-any any any any any any?any submit to any \r
-any any any any any any submit to any \r
-any any?any any any any any submit to any \r
-any any?any any?any any any any submit to any \r
-any any?any any?any any?any any any submit to any G, or L \r
-any any?any any?any any?any any?any any submit to any L \r
-any any any?any any any any submit to any \r
-any any any?any any?any any any submit to any G, or L \r
-any any any?any any?any any?any any submit to any L \r
-any any any any?any any any submit to any \r
-any any any any?any any?any any submit to any group, or L \r
-any any any any any?any any submit to any \r
-any any any any any?any any?any submit to any group, or T \r
- \r
-any? any? any? any? any? any? reject\r
-any? any any any any any submit to any \r
-any? any? any any any any submit to any \r
-any? any? any? any any any submit to any \r
-any? any? any? any? any any submit to any \r
-any? any? any? any? any? any submit to any \r
-any any? any? any? any? any? submit to any \r
-any any any? any? any? any? submit to any \r
-any any any any? any? any? submit to any \r
-any any any any any? any? submit to any \r
-any any any any any any? submit to any \r
-any any any any any any submit to any \r
-any any? any any any any submit to any \r
-any any? any? any any any submit to any \r
-any any? any? any? any any submit to any \r
-any any? any? any? any? any submit to any \r
-any any any? any any any submit to any \r
-any any any? any? any any submit to any \r
-any any any? any? any? any submit to any \r
-any any any any? any any submit to any \r
-any any any any? any? any submit to any \r
-any any any any any? any submit to any \r
-any any any any any? any? submit to any \r
- \r
-Null any any any any any not valid\r
-any Null any any any any submit to any \r
-any any Null any any any reject\r
-any any any Null any any submit to group, G, L \r
-any any any any Null any submit to group, T, L \r
-any any any any any Null submit to group, T, G \r
-Null Null any any any any not valid\r
-any Null Null any any any reject\r
-any any Null Null any any submit to G, L \r
-any any any Null Null any submit to group, L \r
-any any any any Null Null submit to group, T \r
-Null Null Null any any any not valid\r
-any Null Null Null any any submit to G, L \r
-any any Null Null Null any submit to L \r
-any any any Null Null Null submit to group \r
-Null Null Null Null any any not valid\r
-any Null Null Null Null any submit to L \r
-any any Null Null Null Null not valid\r
-Null Null Null Null Null any not valid\r
-any Null Null Null Null Null not valid\r
-Null Null Null Null Null Null not valid\r
-\r
-\r
-\r
-4. Processing Forest\r
-\r
-\r
-\r
- |--Group Root---|\r
- | |\r
- |---Type Root---|\r
- | |\r
-client->------Resolver ->------| |----Authority->---\r
-return\r
- | |\r
- |--Global Root--|\r
- | |\r
- |--Local Root---|\r
-\r
-Once the resolver has determined which root to send the resolution \r
-request to, each tree should be organized according to an exhaustive \r
-replication of each name string on the route to an authority. For \r
-instance, the Group tree would be organized alphabetically with TLDs \r
-\93A\94 through \93Z\94 initially. Since there are a lot of organizations with \r
-business name derivations using the word \93micron\94, there might be a \r
-need to reorganize the \93M\94 TLD to accommodate a \93Mic\94 and a \93Mid\94 TLD. \r
-Although it would be more efficient to break down each letter according \r
-to the demands of the system, it would be easier to specify one mask \r
-for the entire tree. The number of TLDs becomes a function of the \r
-permutations of the number of masked characters in the available set of \r
-usable characters rather than a select few that are added over time. \r
-The resolver can cache the TLDs and know when to use them based upon \r
-the mask for the tree. If a larger mask is needed to further distribute \r
-the load, the resolvers would have to be updated.\r
-\r
-To replicate the current DNS entries under the additional labels \r
-specified in this proposal a number of applications and uses would have \r
-to be accounted for. The ARPA listings would remain unchanged or they \r
-could be replicated under each root by recombining telephone numbers in \r
-a single label under the e164 or padding IP addresses under the inverse \r
-lookup tables without the periods separating the octets.\r
-\r
-Since the NNS uses a forest of processing trees and the current system \r
-uses only one tree, a conversion process would have to be developed to \r
-distinguish between DNS requests and NNS requests. This could be \r
-handled using a number of different methods.\r
-\r
-A version flag in the request could accomplish this. This way the \r
-resolver would be able to determine which searchable labels were used \r
-and the order of presentation by standardization. The resolver \r
-intelligence would know which labels to use for lookup or in the \r
-preferred embodiment. The resolver could also reorganize the labels to \r
-be presented under the correct processor so that the Global label is \r
-presented at the right of the name string for processing through the \r
-Global tree. Legacy requests without a version would be sent to the \r
-Type tree. \r
-\r
-Another method could accomplish the goal by combining the labels the \r
-request for the processing tree. In the previous example, the request \r
-oven.macgowan.private.US2081234567.SOrchard15541 could be recombined by \r
-the submitting processor as \r
-oven.macgowanUS2081234567SOrchard15541.private to be searched under the \r
-Type tree. Similarly it could be recombined as \r
-oven.macgowanprivateUS2081234567.SOrchard15541 to be searched under the \r
-Local tree. If a legacy DNS based system submitted a request for \r
-www.yahoo.com, it might be appended as www.yahoo.com..... The first \93.\94 \r
-after com is to end the Type label. The second \93.\94 Represents the null \r
-character at the end of the Global label. The third \93.\94 is for the \r
-Local label. The fourth \93.\94 is for the root. The last \93.\94 is for the \r
-end of the sentence. If applications are affected by the reservation of \r
-the \93.\94 for the root, the request could be recreated as \r
-www.yahoo.com.null.null..\r
-\r
-A final method is to create a hidden label. Hidden labels are discussed \r
-further in extended label uses.\r
-\r
-Once the authority for a label is found within the label, the system \r
-must also determine if there are Subgroups. Subgroups can be used for a \r
-number of internal functions and/or divisions within the authority for \r
-an organization. At this point the system would continue to resolve \r
-using subgroup labels as levels as it does under the current system \r
-toward the device at the left of the name string.\r
-\r
-The remaining searchable labels would be serviced using a similar \r
-method. The Type tree would be organized as it is in the DNS with TLDs \r
-representing each item in the list. Since the items in the list are \r
-limited by the system, the mask could be set to none. The Global label \r
-should be organized by a mask, which would accommodate at least the \r
-country and area codes. The Local label would mask the PGS items until \r
-enough TLDs are derived to equal processing traffic under the other \r
-trees. Provisions should be made for the non-distinct items like \r
-\93corporate\94 that may use characters not reserved for physical \r
-locations. In addition, a null TLD could be used to organize the \r
-remainder of name strings that have omitted labels. The null \93\94 \r
-character or the word \93null\94 could be used to represent legacy DNS \r
-strings under the new labels until the name strings are updated with \r
-the longer requirements.\r
-\r
-The NNS allows a FQDN to be resolved from each searchable label. Please \r
-refer to the previous example, \r
-oven.macgowan.private.US2081234567.SOrchard15541. The authority, \r
-\93Macgowan.private.US2081234567.SOrchard15541\94 is found using the \r
-traditional method of the DNS using a Type item of \93private\94 (mask of \r
-zero). The authority, \93Macgowan.private.US2081234567.SOrchard15541\94 is \r
-found through the Group processor under the \93Mac\94 branch using a mask \r
-of three characters. The \93Macgowan.private.US2081234567.SOrchard15541\94 \r
-authority is found under \93US208\94 using a mask of four characters within \r
-the Global processing tree. The \r
-\93Macgowan.private.US2081234567.SOrchard15541\94 authority is also found \r
-under \93SOr\94 of the branch masked under the Local tree.\r
-\r
-5. Extended Label Uses\r
-\r
-The NNS is a simple design which can accommodate the future of Internet \r
-name strings by incorporating additional processing trees and a large \r
-name space organized by labels with a user friendly interface. A search \r
-engine is automatically derived from the organization within labels as \r
-opposed to across labels. In other words, you send the known pieces of \r
-the request to the processing tree that will yield the quickest results \r
-with the least amount of traffic. Once names are bookmarked or selected \r
-from a list of AutoCompletes, requests can be sent to any processing \r
-tree to balance the load on the system.\r
-\r
-The present proposal also provides an extensible path for future labels \r
-that may or may not have associated processors. A \93Contact\94 label \r
-might always be masked during the request for resolution, but provide \r
-additional value to the user with a description about the connection or \r
-a webmaster\92s email address. This has extreme value in the event a name \r
-can be resolved, but not reached by connection to the IP address. In \r
-addition to adding new labels, a group or association might request a \r
-new item under the Type label or a new area code might be added under \r
-the Group label. Therefore, one result of this system is a combination \r
-of devices and labels which expands exponentially to meet the demand \r
-for namespace with an inherent capability to adjust to future needs.\r
-\r
-An additional hidden label (mask of all) adjacent to the root could be \r
-hidden and give information for maintenance of the system and/or the \r
-listing. The most important consideration is keying the order and \r
-number of labels in the string. Or using this method, a hidden security \r
-label could help create a firewall between valid requests from users in \r
-the domain versus outsiders or tie to a public key for the destination. \r
-The hidden label could also be used to pass a request for content \r
-delivered in a specific language. With the addition of the Local and \r
-Global labels it might also be necessary to add a TTL label which could \r
-serve as a timer for the registration or the life of a bookmark or \r
-connection. The client could use this value in a history of valid \r
-connections to make a request for an updated TTL, a new IP address, \r
-and/or a trigger for replacing the name with a new string. This would \r
-allow for a change in address, phone number, new area code, etc. on the \r
-part of the provider. Just as the domain name was an abstraction layer \r
-over the IP address, the current domain string is an abstraction for a \r
-future domain string. A routine could prompt a user to change an entry \r
-in a contact/bookmark list. Services such as WWW could also \r
-automatically update links in the content or reflect changes to related \r
-destinations within the content. In use, the client could compare its \r
-value to the value at the authority. If the authority has a value of \r
-zero, the client would update its name and IP address to the new \r
-pointer returned by the resolver. An electronically updating NNS with \r
-updating links in content is a product of this system.\r
-\r
-An example of using this procedure could be applied to finding the best \r
-cell phone plan. A user buys a cell plan. The user emails contact links \r
-to friends and associates. The recipients use their link to dial the \r
-user. The user determines a new provider would be more advantageous and \r
-purchases a new plan with a new number. The user sets their old TTL to \r
-zero in the NNS and creates a new FQDN with the new cell number. Now \r
-when the recipients use the old string, they are pointed to the new \r
-string. The string with the new number is updated in the recipient\92s \r
-contact list. The user is not tied to their telephone number and the \r
-recipients do not need to manually adjust their entries.\r
-\r
-Hidden labels and masking would also have to be present at the client. \r
-A business might have a lot of phone numbers or locations listed on the \r
-name servers but use a shorter version of the string for making local \r
-connections. This way all the devices under a group could be combined \r
-as a single domain name. The future direction of label intelligence and \r
-the ideas expressed here suggest that there may be numerous ways to \r
-provide abstraction levels within the label string. Even the IP address \r
-might be used as an identifier to search for the rest of the domain \r
-string or an item like the telephone number.\r
-\r
-6. IANA Considerations\r
-\r
-The focus of the IANA will change considerably. The need to regulate \r
-name hoarders, TM infringement considerations, and the decision to \r
-implement new TLDs will be greatly reduced. The IANA might be used to \r
-determine the relationships between labels as new items are added under \r
-the requirements that provide for fair and equal addition to the Type \r
-label.\r
-\r
-7. Security Consideration\r
-\r
-Name resolution is an inherent problem for spoofing content, but is \r
-beyond the scope of this proposal. The suggested ability to update name \r
-strings at the client also increases the need to provide secure \r
-communications between the system and the client.\r
-\r
-\r
-References\r
-\r
-\r
-\r
- [RFC 1034] - "Domain names - concepts and facilities", P.\r
-\r
- Mockapetris, 11/01/1987.\r
-\r
- [RFC 1035] - "Domain names - implementation and specification", P.\r
-\r
- Mockapetris, 11/01/1987.\r
-\r
- [RFC 2535] \96 \93E.164 number and DNS\94 , P.\r
-\r
- P. Faltstrom, 9/1/2000.\r
-\r
-Authors Address\r
-\r
- Michael L. Macgowan Jr.\r
- 15541 Orchard Ave.\r
- Caldwell, ID 83607 USA\r
-\r
-\r
- Telephone: +1 208.454.1177 (h)\r
- FAX: +1 208.455.0439\r
- EMail: mmacgowa@yahoo.com\r
-\r
-\r
-Expiration and File Name\r
-\r
- This draft expires in August 2001\r
-\r
- Its file name is labelmanage.txt\r
-\r
-Full Copyright Statement\r
-\r
-Copyright (C) The Internet Society (February 2001). All Rights \r
-Reserved.\r
-\r
-This document and translations of it may be copied and furnished to\r
-others, and derivative works that comment on or otherwise explain it or \r
-assist in its implementation may be prepared, copied, published and \r
-distributed, in whole or in part, without restriction of any kind, \r
-provided that the above copyright notice and this paragraph are \r
-included on all such copies and derivative works. However, this \r
-document itself may not be modified in any way, such as by removing the \r
-copyright notice or references to the Internet Society or other \r
-Internet organizations, except as needed for the purpose of developing \r
-Internet standards in which case the procedures for copyrights defined \r
-in the Internet Standards process must be followed, or as required to \r
-translate it into languages other than English.\r
-\r
-The limited permissions granted above are perpetual and will not be \r
-revoked by the Internet Society or its successors or assigns. This \r
-document and the information contained herein is provided on an "AS IS" \r
-basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE \r
-DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED \r
-TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT \r
-INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR \r
-FITNESS FOR A PARTICULAR PURPOSE."\r
-Michael L. Macgowan Jr. February 2001 [Page 17]\r
-\r
-Internet Draft DNS Label Intelligence and Management System\r
-\r
-\r
-\r
+++ /dev/null
-Network Working Group B. Woodcock
-Request for Comments: nnnn Zocalo
-Category: Experimental B. Manning
- ISI
- August 2000
-
-
- Multicast Discovery of DNS Services
- draft-manning-multicast-dns-02.txt
-
-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."
-
- To view the list Internet-Draft Shadow Directories, see
- http://www.ietf.org/shadow.html.
-
- This memo defines an Experimental Protocol for the Internet
- community. This memo does not specify an Internet standard of any
- kind. Discussion and suggestions for improvement are requested.
- Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-1. Introduction
-
- This document describes a minimal extension to the method of a DNS
- query which allows unconfigured hosts to locate a local DNS server,
- or in the absence of a DNS server to nonetheless identify some
- local network services.
-
-2. Acknowledgments
-
- Vital contributions to this document were made by Paul Vixie, Dave
- Meyer, Stuart Cheshire, Richard Ford, Tony McGregor, Erik Guttman,
- Benard Aboba, and Peter Ford. Thanks also to Alex Hoppman for
- discussion of text-encoding methods.
-
-3. Overview and rationale
-
- This experimental extension to DNS is intended to provide a bootstrap
- mechanism whereby unconfigured devices may find a local DNS server
- and begin using it to perform the usual name resolution and service
- lookup functions. This need is particularly acute in the absence of
- a DHCP server.
-
- Secondarily, it is anticipated that device vendors may implement the
- server (query-receiving) portion of this extension, in order to
- render unconfigured devices which may lack an out-of-band
- configuration interface such as a screen or keyboard discoverable on
- the local network. For example, if a newly-purchased laser printer
- or router were connected to a network, this extension would allow a
- system administrator to use the DNS to discover the IP address which
- the device had selected or been DHCP-assigned, and begin
- communicating with it through the network.
-
- A tertiary objective of this extension is to make possible the
- deprecation of the AppleTalk protocol, which has been prolonged as a
- means of providing support for "network browsing."
-
-4. Discussion
-
- This extension to the DNS protocol consists of a single change to the
- method of use, and no change whatsoever to the current format of DNS
- packets. Specifically, this extension allows UDP DNS queries, as
- documented in RFC 1035, sections 4.1.1, 4.1.2 and 4.2.1, to be
- addressed to port 53 of statically-assigned relative offset -2 within
- the range of multicast addresses defined as "administratively scoped"
- by RFC 2365, section 9. Within the full /8 of administratively
- scoped addresses, this corresponds to the destination address
- 239.255.255.253. Until MZAP or a similar protocol is implemented to
- allow hosts to discover the extent of the local multicast scopes
- which enclose them, it is anticipated that implementations will
- simply utilize the destination address 239.255.255.253.
-
- In order to receive multicasted queries, DNS server implementations
- MUST listen on the -2 offset to their local scope (as above, in the
- absence of a method of determining the scope, this will be assumed to
- be relative to the full /8 allocated for administratively-scoped
- multicast use, or 239.255.255.253), and respond via ordinary unicast
- UDP to ONLY those queries for which they have or can find a positive
- non-null answer. Multicast-enabled DNS servers MUST answer
- multicasted queries non-authoritatively. That is, when responding to
- a query which was received via multicast, they MAY NOT include an NS
- record which contains data which resolves back to their own IP
- address.
-
- Resolvers SHOULD be liberal in their acceptance of wildcard queries.
- That is, resolvers should anticipate receiving queries which will
- contain the asterisk character in any position within the query's
- data field. For example, a query for SRV RRs with data
- "afp.tcp.*.domain.com." would match "afp.tcp.server.domain.com." but
- not match "afp.tcp.". A query for "afp.tcp.*" would match both,
- since the asterisk should be interpreted as matching zero or more
- characters within the RR data.
-
- Resolvers MUST anticipate receiving no replies to some multicasted
- queries, in the event that no multicast-enabled DNS server
- implementations are active within the local scope, or in the event
- that no positive non-null responses exist to the transmitted query.
- That is, a query for the MX record for host.domain.com would go
- unanswered if no local server was able to resolve that request, if no
- MX record exists for host.domain.com, or if no local servers were
- capable of receiving multicast queries. The resolver which initiated
- the query MUST treat such non-response as a non-cacheable negative
- response. Since this multicast transmission does not provide
- reliable delivery, resolvers MAY repeat the transmission of a query
- in order to assure themselves that is has been reveived by any hosts
- capable of answering, however any resolvers which repeat a query MUST
- increase the interval between such repetitions exponentially over
- time.
-
- Resolvers MUST also anticipate receiving multiple replies to the same
- multicasted query, in the event that several multicast-enabled DNS
- servers receive the query and respond with valid answers. When this
- occurs, the responses MAY first be concatenated, and then treated in
- the same manner that multiple RRs received from the same server
- would, ordinarily.
-
-
-5. Implementation Notes Appendix
-
- It is anticipated that a major use of this extension to DNS will be
- for the replacement of the AppleTalk Name Binding Protocol (NBP)
- "distributed database," and the implementation of a similar service
- within other operating systems and on other platforms. Such use
- implies the existence of "stub DNS servers" on each participating
- host, each containing only local information in its served zones, but
- not to the exclusion of data which other servers may assert within
- the same zones.
-
- The following rather complex example shows the format by which an
- implementor could assert the local information possessed by any
- Macintosh in zones served by a stub DNS server on that host:
-
- $ORIGIN .
- @ SOA . . 1998082701 0 0 0 0
- 0 IN NS dns.udp.
- Jasons-Mac 0 IN A 169.254.101.218
- 0 IN HINFO Macintosh-G3-400 MacOS-8.6
- 0 IN LOC 37 52 N 122 20 W
- 0 IN RP . owner-name.Jasons-Mac.
- Jasons-Hard-Disk 0 IN A 169.254.101.218
- 0 IN TXT "UTF8-encoded service-name"
- Print-Spooler 0 IN A 169.254.101.218
- 0 IN TXT "UTF8-encoded service-name"
- dns.udp 0 IN SRV 0 0 53 Jasons-Mac.
- afp.tcp 0 IN SRV 0 0 548 Jasons-Hard-Disk.
- lpr.tcp 0 IN SRV 0 0 515 Print-Spooler.
- http.tcp 0 IN SRV 0 0 80 www.jasonco.com.
- https.tcp 0 IN SRV 0 0 443 secure.jasonco.com.
-
- $ORIGIN jasonco.com.
- www 0 IN A 169.254.101.218
- 0 IN TXT "UTF8-encoded service-name"
- secure 0 IN A 169.254.101.218
- 0 IN TXT "UTF8-encoded service-name"
-
- $ORIGIN Jasons-Mac.
- dns.udp 0 IN SRV 0 0 53 Jasons-Mac.
- owner-name 0 IN TXT "Jason A. Luser"
- * 0 IN PTR afp.tcp.Jasons-Mac.
- 0 IN PTR lpr.tcp.Jasons-Mac.
- 0 IN PTR http.tcp.Jasons-Mac.
- afp.tcp 0 IN SRV 0 0 548 Jasons-Hard-Disk.
- lpr.tcp 0 IN SRV 0 0 515 Print-Spooler.
- http.tcp 0 IN SRV 0 0 80 www.jasonco.com.
-
- $ORIGIN 101.254.169.in-addr.arpa.
- 218 0 IN PTR Jasons-Mac.
-
- Windows and Unix hosts are possessed of many of the same, or
- analogous, types of local information, and similar examples could be
- constructed around hypothetical hosts of those types. A much
- simpler example featuring a laser printer follows, in section 6 of
- this document.
-
- Note that in translating service and device names from high-bit-depth
- character sets such as Unicode to DNS-compliant hostnames, a
- character-mapping must occur, whereby spaces are mapped to hyphens,
- punctuation other than periods is removed, and plain characters are
- substituted for their accented equivalents. Implementors MUST perform
- a uniqueness check, in order to guarantee that no other device within
- the local multicast scope has already asserted a claim to the DNS
- name which their device wishes to employ. Uniqueness checks at
- service-registration time must be somewhat more strict than their
- historical AppleTalk equivalents, comparing names which have already
- been converted to their DNS-compliant state (containing only a-z,
- A-Z, 0-9, and the hyphen character, and starting with a letter rather
- than a hyphen or number), and must treat upper and lower-case as
- equivalent. Note that periods in device and service names shall be
- preserved and used to establish subdomains within the stub DNS
- server's dataset. The high-bit-depth names are made available to
- queriants in the form of UTF8-encoded RDATA in TXT RRs included as
- Additional Information (as described in RFC 1035, sections 4.1
- through 4.1.3) appended to any A RR response.
-
- Implementors of multicast-enabled resolvers may expect the following
- results of the following query-types:
-
- Data Type Result
-
- *.in-addr.arpa PTR All hostnames in the local scope
- *.host.domain.com SRV All services on host.domain.com
- lpr.tcp. SRV All printers/spoolers in the local scope
-
- Duplicate identical records received in different responses to a
- query may be treated as a single record in the concatenation of
- responses. It is beyond the scope of this document to suggest
- disposition of different responses which contain disagreeing pairs of
- name NAME and RDATA.
-
- Implementors should note that "virtual hosts" (that is, the support
- of multiple IP addresses on a single host, and the binding of
- different services to different addresses) are easily supported in
- responses to multicast queries, but should also note that one of the
- benefits afforded by the use of SRV RR-types is a reduction in the
- need for virtual hosts, since multiple named services may be bound to
- different (non-well-known) ports of the same IP address, and still be
- individually identified and differentiated. For example, a single
- host might support one HTTP server on port 80, a second on port 8001,
- and an HTTPS server on port 443, and each could be reached via
- different name.
-
- Another major use of this extension to DNS is to allow bootstrapping
- machines to find local DNS servers. It is anticipated that larger
- enterprises may in the future possess one or more fully-featured DNS
- servers which are also multicast-enabled. Once a bootstrapping host
- has located such a server, that host need no longer use multicast at
- all. That host may instead employ ordinary unicast DNS exactly as
- any other host would, to query those DNS servers. The servers, in
- turn, might well employ multicast queries to glean information about
- the services contained within their local scope, which information
- they might then use to respond to unicast queries (proxying, in
- effect), and cache against future need. Note also that the ability
- to answer multicast queries would prove particularly useful to a DNS
- server which was resident on the same host as a NAT at the border of
- an enterprise which employed 10.0.0.0/8 or 169.254.0.0/16 unicast
- addresses internally.
-
- Implementors MAY choose to employ an optimization whereby the
- deleterious impact of large numbers of unconfigured hosts
- simultaneously attempting to locate DNS servers during the bootstrap
- process might be mitigated, and the process be made more efficient.
- Specifically, high- and low-water marks are defined for frequency of
- multicasted lookups for SRV RRs of "dns.udp.". When a
- multicast-enabled DNS server observes the frequency of such lookups
- exceeding a high-water mark (five queries per minute, perhaps), the
- server MAY begin interspersing responses transmitted via multicast,
- rather than unicast, until such time as the frequency of such lookups
- falls below a low-water mark (one query per five minutes, perhaps).
- In order for this to work, multicast-enabled resolvers would also
- need to listen on the multicast address for responses, and cache them
- briefly. Both the server and resolver portions of this optimized
- behavior are optional, and it should be stressed that this
- optimization need not be considered by implementors of stub servers
- in devices such as printers, which do not provide generalized DNS
- services. If DNS server implementors choose to employ multicast
- responses, they MUST interleave multicast responses with unicast
- responses in such a way that the multicast responses decrease over
- time, rather than flooding the network, in order that servers not be
- used to propagate denial-of-service attacks. In other words, a
- reasonable approach might be while above the high-water mark to make
- the first, second, fourth, eighth, sixteenth et cetera responses for
- each RR multicast, while all inbetween would be unicast. Note that
- this not only protects against multicast "storms," it also protects
- against the mis-match condition which occurs in the case that a
- non-optimized resolver is the presence only of optimized servers, all
- of which are temporarily in multicast-response mode.
-
- Implementors SHOULD also employ DNS Sec, or its equivalent, as soon
- as such technology is standardized, in order to minimize the
- possiblity of "spoofing" of information by nodes responding to
- multicast queries.
-
-
-6. Use & Administration Notes Appendix
-
- Administrators of networks employing this protocol are advised to
- employ fully-qualified domain names (FQDNs) as their host names where
- possible, such that the dots separating portions of the name shall be
- interpreted by the stub-server implementations as subdomain
- delimiters, and shall thus serve to remove the host from the local
- view of the root domain to its correct and appropriate
- globally-unique subdomain.
-
- Administrators of service-providing devices, such as already-deployed
- printers, which are not capable of receiving multicast DNS queries,
- may wish to inject DNS records into a local multicast-enabled DNS
- server on behalf of those devices. For example, an administrator
- might wish to create records of the following nature in order to make
- a non-multicast-capable laser printer visible to both multicast and
- unicast queriants:
-
- $ORIGIN .
- lpr.tcp 0 IN SRV 0 0 515 laser2.sales.domain.com.
-
- $ORIGIN sales.domain.com.
- laser2 0 IN A 169.254.5.28
- 0 IN TXT "Old Sales Dep't Laser Printer"
-
- $ORIGIN laser2.sales.domain.com.
- * 0 IN PTR lpr.tcp.laser2.sales.domain.com.
- lpr.tcp 0 IN SRV 0 0 515 laser2.sales.domain.com.
-
- $ORIGIN 5.254.169.in-addr.arpa.
- 28 0 IN PTR laser2.sales.domain.com.
-
- Administrators of networks which contain either multicast-capable
- resolvers or multicast-capable DNS servers MUST employ filters
- defining a contiguous border around their enterprises and prohibiting
- passage of data to and from the 239.0.0.0/8 address space, as well as
- routing information relating to the 239.0.0.0/8 prefix or any subnet
- of it. This is the mechanism by which RFC 2365 administrative
- scoping is enacted. The sole exception to this rule would be any
- explicitly-configured interconnections with other specific
- enterprises between which all involved administrators wish to share a
- single browsable network space. This is anticipated to be a very
- infrequent occurrence within the current regime of network security
- policies.
-
-References
-
- RFC 1035: Mockapetris, P., "Domain Names - Implementation and
- Specification", RFC 1035, November, 1987.
-
- RFC 2052: Gulbrandsen, A., Vixie, P., "A DNS RR for specifying the
- location of services (DNS SRV)", RFC 2052, October, 1996.
-
- RFC 2365: Meyer, D., "Administratively Scoped IP Multicast",
- RFC 2365, July, 1998.
-
- Handley, M., Thaler, D., "Multicast-Scope Zone Announcement
- Protocol (MZAP)", MBoneD Internet Draft, October, 1998.
-
- Sidhu, G.S., Andrews, R.F., and Oppenheimer, A., "Inside AppleTalk,
- Second Edition", Addison-Wesley, 1990.
-
-Security Considerations
-
- While this extension to DNS introduces no new security problems to
- DNS or Multicast, it should be emphasized that distributed
- directories, common to other networking protocols, have not hitherto
- been widely used in the IP networking community. Distributed
- directories do require that users and system administrators assume
- some conscious balance between the level of trust which they accord
- to the responding entities on their network, and the degree of
- credence which they pay to the responses they receive. The level of
- trust traditionally assumed in distributed directory environments
- does not necessarily mix well with clear-text password transmission
- such as is still found on some IP networks, for example.
-
-
-Authors' Addresses
-
- Bill Woodcock
- Zocalo
- 2355 Virginia Street
- Berkeley, CA 94709-1315
- USA
-
- Phone: +1 510 540 8000
- EMail: woody@zocalo.net
-
-
- Bill Manning
- USC/ISI
- 4676 Admiralty Way, #1001
- Marina del Rey, CA. 90292
- USA
-
- Phone: +1 310 822 1511
- EMail: bmanning@isi.edu
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). 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
-
-......
-
---------------1F985EC911030AB70E0CD7B9--
-
-
-
---
---bill
+++ /dev/null
-
-
-
-
-
-
-INTERNET-DRAFT M. Sawyer
- A. Gustafsson
- M. Graff
- Nominum
-<draft-msawyer-dnsext-edns-attributes-00.txt> 15 November 2000
-
- Handling of unknown EDNS0 attributes
-
-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
-
- This draft expires on May 15, 2001.
-
-Abstract
-
- This document provides a clarification of the EDNS0 protocol,
- specifying the behavior of servers when they receive unknown EDNS
- options.
-
-1.1 - Introduction
-
- Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms
- [RFC2671] is helpful.
-
- EDNS0 [RFC2671] specifies a general framework for extending the
- packet format used by the Domain Name System protocol. The framework
- provides for a series of additional options, identified by a 16 bit
- attribute ID and arbitrary sized payload. Any number of these
- additional options can be specified in the DNS packet. As specified,
- the current scheme has drawbacks:
-
-
-
-Expires May 2001 [Page 1]
-\f
-INTERNET-DRAFT Handling of unknown EDNS attributes October 2000
-
-
- - It provides no way for implementers to deploy test systems with
- experimental features prior to approval of the feature and assignment
- of an attribute ID.
-
- - It provides no specification on what an application should do when
- receiving unrecognized options.
-
- This draft proposes to clarify the original EDNS0 draft [RFC2671],
- addressing these drawbacks.
-
-1.2 - Requirements
-
- 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 - Protocol changes:
-
- This document updates [RFC2671]. Conformance to this specification
- is claimed by specifying EDNS version 1.
-
-2.1 - Advisory and Required Options:
-
-
- Some potential uses of EDNS options are advisory in nature, For
- example, a hypothetical option indicating that "I understand frobozz
- compression in responses" can be safely ignored by the recipient,
- which will then simply not use frobozz compression. Others uses of
- options, such as a hypothetical "send only cryptographically verified
- data in responses" option, cannot be safely ignored, and should cause
- the request to fail if not understood by the receiver.
-
- This suggests that we need two types of options, "advisory" options
- (that can be ignored) and "required" options (that can not). Because
- a server needs to classify options as advisory or required even if
- they were not yet defined when the server was implemented, the type
- of an option must be evident without knowing its internal structure.
- This is achieved by splitting the option type codes into two ranges:
- options with type code 0x0000-0x7FFF are considered "advisory", and
- options with type code 0x8000-0xFFFF are considered "required".
-
-2.2 - Handling of Unknown and Unsupported EDNS Option Types
-
- When a server receives an unknown or unsupported advisory option in a
- request or response message, it MUST ignore the unknown option and
- process the message as if the option was not present. In the reply,
- it SHOULD include an advisory UNSUPPORTED option (TBD).
-
-
-
-
-Expires May 2001 [Page 2]
-\f
-INTERNET-DRAFT Handling of unknown EDNS attributes October 2000
-
-
- When a server receives an unknown or unsupported required option in a
- request message, it MUST NOT act on the request, and it MUST return
- an error response with the extended result code BADOPT (TBD). In the
- reply, it SHOULD include an advisory UNSUPPORTED option.
-
- When a server receives an unknown or unsupported required option in a
- response message, it MUST ignore the response. The server SHOULD
- continue to parse options after the unknown option, including a list
- of all unsupported options in the UNSUPPORTED option in the reply.
-
- Servers MAY include SUPPORTED options in replies to messages, listing
- option codes which they understand. This message SHOULD contain all
- option codes the server understands. This facility MAY NOT be used
- in place of the UNSUPPORTED option to identify unsupported options in
- replies.
-
- Clients MAY include SUPPORTED or UNSUPPORTED options in queries.
- UNSUPPORTED options SHOULD only list those option codes which the
- client has received in previous replies from the server, not an
- inclusive list of all unsupported option codes.
-
-2.3 - Use of Reserved Options for Development
-
- Option codes in the range of 0x7FF0 to 0x7FFF and 0xFFF0 to 0xFFFF
- are considered "reserved" and shall not be assigned to new protocols.
- Software vendors SHOULD use these options for testing of protocols
- under development, provided the following conditions are met:
-
- - Vendors MUST NOT ship any versions of the software which use option
- codes in this range. They MUST delay shipping software with the new
- options until IANA has assigned permanent option codes.
-
- - Vendors MUST NOT place development servers on the live internet
- which send options in this range to remote servers or which
- understand options in this range as having any meaning.
-
-3.1 - SUPPORTED and UNSUPPORTED options
-
- The SUPPORTED and UNSUPPORTED options contain a list of option codes
- which the server or client does or doesn't support. The list
- contains, in network byte order, the supported or unsupported 16 bit
- option codes:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | SUPPORTED or UNSUPPORTED (TBD) |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-
-Expires May 2001 [Page 3]
-\f
-INTERNET-DRAFT Handling of unknown EDNS attributes October 2000
-
-
- | LENGTH (number of options * 2) |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / OPTION CODE(s) /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- Sending a SUPPORTED option with a zero-length payload indicates that
- the server or client supports no EDNS options, so none should be
- used. UNSUPPORTED options with zero-length payloads SHOULD NOT be
- sent, as such a message is meaningless.
-
-4 - IANA considerations
-
- When allocating EDNS Option Codes, the IANA shall henceforth require
- the RFC defining the new option to specify whether the option is an
- "advisory" or a "required" option. The option code for an advisory
- option shall be allocated from the range 0x0000-0x7FEF, and the code
- for a required option shall be allocated from the range
- 0x8000-0xFFEF.
-
- Option codes in the ranges of 0x7FF0 to 0x7FFF and 0xFFF0 to 0xFFFF
- are considered "reserved."
-
- The IANA is hereby requested to assign EDNS Version Number 1 to this
- specification, to assign a new extended RCODE value for BADOPT, and
- to assign advisory option codes for UNSUPPORTED and SUPPORTED.
-
-
-5 - Security considerations
-
- This document provides a mechanism for users to override the default
- behavior of the server when accessing data from its internal zone
- databases. Software developers and administrators should use some
- care when enabling these options, as they may provide outside users
- the ability to retrieve information otherwise not available.
-
-6 - Acknowledgments
-
- The authors would like to thank Olafur Gudmundsson for his input on
- this draft.
-
-7 - References
-
- [RFC2119] S. Brander, ``Key words for use in RFCs to Indicate
- Requirement Levels,'' RFC 2119, ISI, November 1997.
-
- [RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC
- 2671, ISI, August, 1999
-
-
-
-Expires May 2001 [Page 4]
-\f
-INTERNET-DRAFT Handling of unknown EDNS attributes October 2000
-
-
-Author's Address
-
- Michael Sawyer
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- Phone: +1-650-779-6021
- michael.sawyer@nominum.com
-
- Andreas Gustafsson
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- Phone: +1-650-779-6004
- andreas.gustafsson@nominum.com
-
- Michael Graff
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- Phone: +1-650-779-6034
- michael.graff@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires May 2001 [Page 5]
-\f
+++ /dev/null
-
-
-Independent submission M. Richardson
-Internet-Draft SSW
-Expires: August 24, 2003 February 23, 2003
-
-
- A method for storing IPsec keying material in DNS.
- draft-richardson-ipsec-rr-02.txt
-
-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.
-
- This Internet-Draft will expire on August 24, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document describes a new resource record for DNS. This record
- may be used to store public keys for use in IPsec systems.
-
- This record replaces the functionality of the sub-type #1 of the KEY
- Resource Record, which has been proposed to be obsoleted by [1].
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 1]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 5
- 3.1 RDATA format - algo type . . . . . . . . . . . . . . . . . . . 5
- 3.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 5
- 3.3 RDATA format - RSA public key . . . . . . . . . . . . . . . . 5
- 3.4 RDATA format - DSA public key . . . . . . . . . . . . . . . . 6
- 3.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 6
- 4. Presentation formats . . . . . . . . . . . . . . . . . . . . . 7
- 4.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 7
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
- 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
- Normative references . . . . . . . . . . . . . . . . . . . . . 10
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 2]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-1. Introduction
-
-1.1 Overview
-
- Overview.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 3]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-2. Storage formats
-
- The IPSECKEY resource record (RR) is used to publish a public key
- that is to be associated with a Domain Name System (DNS) name. It
- will be a public key as only public keys are stored in the DNS. This
- can be the public key of a host, network, or application (in the case
- of per-port keying).
-
- An IPSECKEY RR is, like any other RR, authenticated by a SIG RR.
-
- It is expected that there will often be multiple resource records of
- the IPSECKEY type. This will be due to the need to rollover keys,
- and due to the presence of multiple gateways.
-
- The type number for the IPSECKEY RR is 45 (IANA TBD).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 4]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-3. IPSECKEY RDATA format
-
- The RDATA for an IPSECKEY RR consists of a precedence value, a public
- key (and algorithm type), and an optional gateway address.
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | RESV | algo | precedence | public key length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | /
- / public key
- / /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
- ~ gateway ~
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-3.1 RDATA format - algo type
-
- The algorithm type ("algo") field indicates the type of key that is
- present in the public key field. Valid values are:
-
- 0 No key is present.
-
- 1 A RSA key is present, in the format defined in
-
- 2 A DSA key is present, in the format defined in
-
-
-3.2 RDATA format - precedence
-
- This is an 8-bit precedence for this record. This is interpreted in
- a similar way to the PREFERENCE field described in section 3.3.9 of
- [3].
-
-3.3 RDATA format - RSA public key
-
- If the algorithm type has the value 1, then public key portion
- contains an RSA public key, encoded as described in secion 2 of [8],
- and repeated here:
-
- 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | pub exp length| public key exponent /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | /
-
-
-
-Richardson Expires August 24, 2003 [Page 5]
-\f
-Internet-Draft ipsecrr February 2003
-
-
- +- modulus /
- | /
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
-
- RFC2065 limited the exponent and modulus to 2552 bits in length, and
- RFC3110 to 4096 bits. No such limit is specified here for the
- purposes of encoding and decoding. The length in octets of the
- public exponent length is represented as one octet if it is in the
- range of 1 to 255 and by a zero octet followed by a two octet
- unsigned length if it is longer than 255 bytes. The public key
- modulus field is a multiprecision unsigned integer. The length of
- the modulus can be determined from the RDLENGTH and the preceding
- RDATA fields including the exponent.
-
- Leading zero bytes are prohibited in the exponent and modulus.
-
-3.4 RDATA format - DSA public key
-
- If the algorithm type has the value 2, then public key portion
- contains an DSA public key, encoded as described in [7].
-
-3.5 RDATA format - gateway
-
- The gateway field indicates a gateway to which an IPsec tunnel may be
- created in order to reach the entity holding this resource record.
- The length of this field is the size of the data portion minus the
- public key length, and the 4 bytes of header. The gateway field may
- be absent.
-
- The gateway field is a string. It is most commonly a simple fully
- qualified domain name (FQDN). IP version 4 and IP version 6
- addresses may be represented using names from in-addr.arpa. and
- ip6.arpa.
-
- The gateway field may also include a @-character in it. Either in
- the form @FQDN, or user@FQDN. In this context, it does not reference
- a single destination, but just an identifier that will be used when
- doing key negotiations. This may be used in the context where the
- gateway does not have a permanent IP address, but has permanent
- address space behind it, and will be initiating connections only.
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 6]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-4. Presentation formats
-
-4.1 Representation of IPSECKEY RRs
-
- IPSECKEY RRs may appear as lines in a zone data master file. The
- precedence field is mandatory. While both the gateway and public key
- fields are optional, it is illegal for neither to be present.
-
- As the IPv4, IPv6 and FQDN references to the gateway are mutually
- exclusive, they can share a position. If no gateway is to be
- indicated, then the special tokens of either "-" or "none" may be
- used.
-
- IPv4 addresses are to be represented as a dotted decimal quad, with
- no leading zeroes. IPv6 addresses are to be presented as specified
- in section 2.2 of [4].
-
-
- 38.46.139.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 192.139.46.38
- RSA: AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
- Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
- 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
- 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
- MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
- cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
- fejrfi1H )
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 7]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-5. IANA Considerations
-
- IANA is asked to assign resource record 45 to this resource record.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 8]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-6. Acknowledgments
-
- People who pushed me to write this.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 9]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-Normative references
-
- [1] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
- Record (RR)", RFC 3445, December 2002.
-
- [2] Mockapetris, P., "Domain names - concepts and facilities", STD
- 13, RFC 1034, November 1987.
-
- [3] Mockapetris, P., "Domain names - implementation and
- specification", STD 13, RFC 1035, November 1987.
-
- [4] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 1884, December 1995.
-
- [5] Thomson, S. and C. Huitema, "DNS Extensions to support IP
- version 6", RFC 1886, December 1995.
-
- [6] Eastlake, D., "Domain Name System Security Extensions", RFC
- 2535, March 1999.
-
- [7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
- (DNS)", RFC 2536, March 1999.
-
- [8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
- System (DNS)", RFC 3110, May 2001.
-
-
-Author's Address
-
- Michael C. Richardson
- Sandelman Software Works
- 470 Dawson Avenue
- Ottawa, ON K1Z 5V7
- CA
-
- EMail: mcr@sandelman.ottawa.on.ca
- URI: http://www.sandelman.ottawa.on.ca/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 10]
-\f
-Internet-Draft ipsecrr February 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Richardson Expires August 24, 2003 [Page 11]
-\f
+++ /dev/null
-INTERNET-DRAFT M. Sawyer
- B. Wellington
- M. Graff
- Nominum
-<draft-sawyer-dnsext-edns0-zone-option-00.txt> 9 October 2000
-
- ZONE and VIEW option records in DNS messages
-
-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
-
- This draft expires on April 9, 2001.
-
-Abstract
-
- This document defines two new EDNS option codes used to specify what
- zone and view should be used in query messages to a remote DNS
- server.
-
-1 - Introduction
-
- Familiarity with DNS [RFC1034, RFC1035] and DNS Extension Mechanisms
- [RFC2671] is helpful.
-
- Domain Concepts and Facilities [RFC1034] Section 3.7 shows a typical
- reply to a DNS query, containing the answer as well as additional
- data related to the answer provided. The server's zone database may
- contain out-of-zone data glue which is internally used but is never
- returned in a reply to a query. If recursion is requested by the
- client and available in the server, or if the data is available in
-
-
-
-Expires April 2001 [Page 1]
-\f
-INTERNET-DRAFT ZONE and VIEW option records October 2000
-
-
- the server's cache, the additional information will be taken from
- these sources on most servers.
-
- There is no method currently available for an administrator to query
- a server specifying that only data from a specific zone should be
- used in formulating the reply and that all available data from that
- zone's database should be used, including out-of-zone glue. As such,
- there is no mechanism for an administrator to ensure that out-of-zone
- data in the zone's database is correct except through direct
- manipulation of the zone database files. In addition, zone transfers
- via AXFR or IXFR do not include out-of-zone glue. The ZONE option
- code is provided to specify directly which zone database should be
- queried.
-
- In addition, DNS server software exists which may present different
- "views" of the DNS space to different clients. In some cases, a
- query may match the criteria of multiple views, and a user may wish
- to specify which of the acceptable views match the query. The VIEW
- option code is provided to specify which view should be searched for
- the appropriate zone database.
-
-1.2 - Requirements
-
- 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 - Protocol changes:
-
- This document updates [RFC2671]. The ZONE and VIEW option records
- are intended as optional features. Servers MAY support either or
- both of these options. Servers SHOULD provide configuration options
- to enable or disable these optional records as needed.
-
- Servers and clients SHOULD NOT use the ZONE or VIEW option codes in
- normal use.
-
- Servers SHOULD NOT use the VIEW option record in zone transfers
- unless the administrator has specifically configured the server to
- use these records. Servers MAY provide a mechanism for such
- configuration. Servers SHOULD NOT use the ZONE option record in zone
- transfers under any configuration.
-
-3 - ZONE option record
-
- The ZONE OPTION-DATA MUST contain a standard uncompressed wire-format
- name in the format specified by [RFC1035] Section 3.3. Wildcards are
- not permitted in ZONE option records.
-
-
-
-Expires April 2001 [Page 2]
-\f
-INTERNET-DRAFT ZONE and VIEW option records October 2000
-
-
- When a server receives a query with a ZONE option record, it MUST
- reply with a REFUSED reply if it understands the ZONE record but is
- not configured to allow ZONE specific requests, if the specified zone
- does not exist on the server, or if the client is not authorized to
- use the ZONE option. If the ZONE option is allowed, it MUST return a
- normally formatted reply with a ZONE optional record, containing the
- same zone as the one queried. When replying to AXFR or IXFR queries
- with ZONE options, the entire zone, including out-of-zone glue,
- should be returned to the client.
-
- Servers SHOULD treat ZONE options in zone transfer requests as an
- unauthorized request and return REFUSED.
-
-3.2 - VIEW option record
-
- The VIEW OPTION-RECORD contains an arbitrary length text field, which
- is used to match the name of the view in the server's configuration.
-
- When a server receives a query with a VIEW option record, it MUST
- reply with a REFUSED reply if it understands the VIEW record but is
- not configured to allow VIEW specific requests, the specified view
- does not exist, or the client is not authorized to access the
- specified view. If a VIEW option is allowed, it MUST return a
- normally formatted reply with a VIEW optional record containing the
- same view as the one queried. The information used in generating the
- reply should contain only information from the specified view of the
- DNS space.
-
-4 - IANA considerations
-
- We request IANA assign option codes for the ZONE and VIEW options.
-
-5 - Security considerations
-
- This document provides a mechanism for users to override the default
- behavior of the server when accessing data from its internal zone
- databases. Software developers and administrators should use some
- care when enabling these options, as they may provide outside users
- the ability to retrieve information otherwise not available.
-
-6 - References
-
- [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.
-
-
-
-
-Expires April 2001 [Page 3]
-\f
-INTERNET-DRAFT ZONE and VIEW option records October 2000
-
-
- [RFC2119] S. Brander, ``Key words for use in RFCs to Indicate
- Requirement Levels,'' RFC 2119, ISI, November 1997.
-
- [RFC2671] P. Vixie, ``Extension Mechanisms for DNS (EDNS0),'' RFC
- 2671, ISI, August, 1999
-
-
-Author's Address
-
- Michael Sawyer
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- Phone: +1-650-779-6021
- michael.sawyer@nominum.com
-
- Brian Wellington
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- Phone: +1-650-779-6022
- brian.wellington@nominum.com
-
- Michael Graff
- Nominum, Inc.
- 950 Charter St.
- Redwood City, CA 94063
- Phone: +1-650-779-6034
- michael.graff@nominum.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires April 2001 [Page 4]
-\f
+++ /dev/null
-INTERNET-DRAFT Stuart Kwan
- James Gilroy
- Levon Esibov
- Microsoft Corp.
- May 2001
-<draft-skwan-utf8-dns-06.txt> Expires November 2001
-
-
- Using the UTF-8 Character Set in the 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.
-
-
-Abstract
-
-The Domain Names standard specifies that hostnames are represented
-using the ASCII character encoding. This document expands that
-specification to allow the use of the UTF-8 character encoding, a
-superset of ASCII and a translation of the UCS-2 character encoding.
-
-
-1. Introduction
-
-The Domain Names standard [RFC1123] specifies that hostnames are
-represented using the ASCII character encoding. This document expands
-that specification to allow the use of the UTF-8 character encoding
-[RFC2044], a superset of ASCII and a translation of the UCS-2
-character encoding.
-
-Interpreting names as ASCII-only limits the utility of DNS in an
-international setting. The UTF-8 character set includes characters
-from most of the world's written languages, allowing a far greater
-range of possible names and allowing names to use characters that are
-relevant to a particular locality. UTF-8 is the recommended character
-set for protocols that are evolving beyond ASCII [RFC2130].
-
-Expires November 2001 [Page 1]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-This document defines the technology for a richer character set in
-DNS. This document specifically does not define policy for the
-characters allowed in a name when used in a particular application.
-For example, some protocols place restrictions on the characters
-allowed in a name
-
-
-2. Protocol Description
-
-2.1 Components and roles
-
-Before the description of the protocol itself authors feel a need to
-clarify which components are involved in processing the hostnames and
-describe the usage of the hostnames by these components. The following
-list contains such information.
-
-User.
-User could be a human or application. Its role is to specify (also
-known as "write") and retrieve (also known as "read") the hostname to
-and from an application. The examples of such operations include
-typing the hostname, writing it on a touch sensitive screen, reading
-the name from the monitor, listening to a voicemail, etc...
-
-Application.
-Application's role is to
-- process the hostname specified by user or other local or remote
- application.
-- return to the user (for example display on a monitor screen) the
- hostname returned by DNS resolver.
-- call DNS name resolution APIs to request resolver to perform the
- name resolution
-
-Resolver.
-Resolver's role is to
-- process the name resolution requests from an application and submit
- appropriate DNS query to the DNS servers
-- process the response from a DNS server and pass the response to the
- Application.
-
-DNS server.
-The role of the DNS server is to store and maintain the DNS data,
-process the updates to its database, update the replica copies of the
-databases and perform the DNS name resolution through responding to
-the DNS queries.
-
-
-2.2 Protocol details
-
-This section describes the modifications (if any) to each of these
-components and interfaces between the communicating components.
-
-
-
-Expires November 2001 [Page 2]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-2.2.1 Users
-
-No modifications to the users are proposed in this document. At the
-same time support of this protocol by other components specified later
-in this section may enable users to start using in hostnames
-characters from wider set than one specified in [RFC1123].
-
-
-2.2.2 Interface between users and applications
-
-User may use any character set or multiple character sets supported by
-the particular application. Specification of the allowed character
-sets supported by an application is outside of the scope of this
-document. The decision on which characters sets can be used to allow
-user to input and retrieve the hostnames is left to the implementers
-of the particular applications unless a protocol underlying specific
-application specifies the supported characters set. Thus this protocol
-does not affect the interface between users and applications.
-
-
-2.2.3 Applications
-
-Storage format of the hostnames by the applications is outside of the
-scope of this protocol.
-
-
-2.2.4 Interface between applications and resolvers
-
-This protocol does not specify the APIs that applications should use
-to request the resolver to perform the DNS name resolution of the
-internationalized hostnames. Instead it only specifies the format of
-the hostnames specified in the input and output of such APIs.
-
-The applications supporting non-ASCII characters in hostnames MUST
-pass to the resolvers a hostname in ISO/IEC 10646 encoding. If the
-response returned by the resolver to the application contains the
-hostname, then the application should expect the hostname to be
-encoded using ISO/IEC 10646.
-
-
-2.2.5 Resolvers
-
-Before sending the hostname in the query packet, the resolver MUST
-prepare each name part as specified in [NAMEPREP]. After the name
-preparation the resolver MUST convert the hostname to be encoded using
-UTF-8 as specified in [RFC2044].
-Names encoded in UTF-8 must not exceed the size limits clarified in
-[RFC2181]. Character count is insufficient to determine size, since
-some UTF-8 characters exceed one octet in length.
-
-
-
-
-Expires November 2001 [Page 3]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-When resolver receives a response to the query from a DNS server, it
-MUST convert all of the hostnames from UTF-8 encoded format to the
-ISO/IEC 10646 encoding before passing these hostnames back to the
-application.
-
-
-2.2.6 DNS servers
-
-DNS servers authoritative for the records containing the hostnames
-containing the characters not allowed by [RFC1123] MUST allow use of
-the namepreped UTF-8 format to store and transmit those parts of the
-hostnames.
-
-According to existing standards, any binary string can be used in a
-DNS name [RFC2181], but names must be compared with case-insensitivity
-[RFC1035]. At the same time DNS protocol standard states that original
-case SHOULD be preserved when possible as data is entered into the DNS
-database. This requirement is modified as follows: a DNS server
-authoritative for the internationalized hostnames MUST nameprep and
-perform UTF-8 conversion on all names containing internationalized
-characters in both record names and record data before storing these
-hostnames and transmitting those names in any message. This new
-requirement guarantees case-insensitive comparison of the
-internationalized hostnames even by those DNS servers that do not
-support this protocol.
-
-DNS servers must compare names that contain UTF-8 characters
-byte-for-byte, as opposed to using Unicode equivalency rules.
-
-
-3. Interoperability Considerations
-
-If user continues using ASCII-only characters in the hostnames, then
-there is no need to upgrade any applications and/or resolvers.
-
-As pointed in the previous section, there is no need to upgrade DNS
-servers, except possibly those that are authoritative for the zones
-containing internationalized hostnames.
-
-The following interoperability issues should be taken into account
-
-- A legacy application may not be able to process the hostnames
-containing non-ASCII characters returned by DNS resolvers. Effect of
-failure to process a name containing 7-bit needs to be separately
-investigated.
-- If other protocols decide to use the nameprep-UTF-8-encoding to
-represent internationalized hostnames in their wire packets, then a
-legacy application supporting such protocol that receives UTF-8
-encoded hostname from another application (for example, such as mail
-server or client) may fail to process such hostname. Effect of failure
-to process a name containing 7-bit needs to be separately investigate.
-
-
-Expires November 2001 [Page 4]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-Thus hostnames that are intended to be globally usable [RFC1958] on
-legacy applications should still contain ASCII-only characters per
-[RFC1123].
-
-- If an updated application runs on legacy resolver that rejects name
-resolution of the names containing any character not allowed by
-[RFC1123], then such resolvers will require an upgrade to enable name
-resolution of the internationalized hostnames.
-
-- As specified above, DNS servers authoritative for the DNS records
-containing the internationalized hostnames must be able to save and
-load the hostnames containing napepreped-UTF-8-converted characters.
-If the DNS server doesn't satisfy this requirement, but needs to host
-such resource records, then it needs to be upgraded.
-
-- Any DNS server involved in a name resolution process of the DNS
-records containing an internationalized hostname must not reject name
-resolution only because the hostname contains characters not allowed
-by [RFC1123]. This requirement does not mean that every DNS server in
-the name resolution path between the client and authoritative server
-must be able to store and load the DNS records containing the
-internationalized hostnames, but only means that the DNS server
-performing recursive resolution needs to be able to query for and
-cache such records, and that the DNS servers authoritative for the DNS
-names higher in the DNS name hierarchy than the internationalized
-names in query, need to be able to respond to such queries.
-Overwhelming majority of the DNS servers currently deployed on the
-Internet already satisfy this requirement. Authors are not aware of
-any implementation of the DNS server widely deployed on the Internet
-that doesn't satisfy this requirement.
-
-Although most of the DNS servers may be capable of accepting a zone
-transfer of a zone containing UTF-8 encoded hostnames, some of them
-may not be able to store those names in a zone file or load those
-names from a zone file. Administrators should exercise caution when
-transferring a zone containing UTF-8 encoded hostnames to such DNS
-servers.
-
-
-
-4. Security Considerations
-
-Support for internationalized hostnames introduces a possibility of a
-new type of spoofing attacks that could be based on attacker's
-knowledge of misbehaving applications or resolvers that modifies the
-internationalized hostname that needs to be resolved. For example, if
-there is an application that modifies any character containing 7-bit
-in some predictable manner (for example by simply dropping the 7-bit),
-
-
-
-
-
-Expires November 2001 [Page 5]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-then an attacker may register a DNS record mapping the derivative
-(i.e. modified by the misbehaving application or resolver) name to the
-data desired by attacker. In this scenario any user using such
-misbehaving application may receive as a result of name resolution the
-data (for example an IP address in A resource record) specified by the
-attacker without noticing that they are subjected to an attack even if
-the DNSSEC is used to verify the authenticity of the response.
-
-Because this protocol depends on the procedures described in
-[NAMEPREP] and [RFC2044], the security issues identified in these
-document are also applicable to this protocol.
-
-
-5. Acknowledgements
-
-The authors of this document would like to thank the following people
-for their contribution to this specification: John McConnell,
-Cliff Van Dyke and Bjorn Rettig.
-
-
-6. References
-
-[RFC1035] P.V. Mockapetris, "Domain Names - Implementation and
- Specification," RFC 1035, ISI, Nov 1987.
-
-[RFC2044] F. Yergeau, "UTF-8, a transformation format of Unicode
- and ISO 10646," RFC 2044, Alis Technologies, Oct 1996.
-
-[RFC1958] B. Carpenter, "Architectural Principles of the
- Internet," RFC 1958, IAB, June 1996.
-
-[RFC1123] R. Braden, "Requirements for Internet Hosts -
- Application and Support," STD 3, RFC 1123, January 1989.
-
-[RFC2130] C. Weider et. al., "The Report of the IAB Character
- Set Workshop held 29 July - 1 March 1996",
- RFC 2130, Apr 1997.
-
-[RFC2181] R. Elz and R. Bush, "Clarifications to the DNS
- Specification," RFC 2181, University of Melbourne and
- RGnet Inc, July 1997.
-
-[UNICODE 2.0] The Unicode Consortium, "The Unicode Standard, Version
- 2.0," Addison-Wesley, 1996. ISBN 0-201-48345-9.
-
-[NAMEPREP] Paul Hoffman and Marc Blanchet, "Preparation of
- Internationalized Host Names",
- draft-ietf-idn-nameprep-*.txt.
-
-
-
-
-
-Expires November 2001 [Page 6]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-7. Author's Addresses
-
-Stuart Kwan James Gilroy
-Microsoft Corporation Microsoft Corporation
-One Microsoft Way One Microsoft Way
-Redmond, WA 98052 Redmond, WA 98052
-USA USA
-skwan@microsoft.com jamesg@microsoft.com
-
-Levon Esibov
-Microsoft Corporation
-One Microsoft Way
-Redmond, WA 98052
-USA
-levone@microsoft.com
-
-
-11. Intellectual Property Statement
-
-The IETF takes no position regarding the validity or scope of any
-intellectual property or other rights that might be claimed to pertain
-to the implementation or use of the technology described in this
-document or the extent to which any license under such rights might or
-might not be available; neither does it represent that it has made any
-effort to identify any such rights. Information on the IETF's
-procedures with respect to rights in standards-track and standards-
-related documentation can be found in BCP-11. Copies of claims of
-rights made available for publication and any assurances of licenses to
-be made available, or the result of an attempt made to obtain a general
-license or permission for the use of such proprietary rights by
-implementors or users of this specification can be obtained from the
-IETF Secretariat.
-
-The IETF invites any interested party to bring to its attention any
-copyrights, patents or patent applications, or other proprietary rights
-which may cover technology that may be required to practice this
-standard. Please address the information to the IETF Executive
-Director.
-
-
-12. Full Copyright Statement
-
-Copyright (C) The Internet Society (2001). 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
-
-Expires November 2001 [Page 7]
-
-INTERNET-DRAFT UTF-8 DNS May 2001
-
-
-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 November 2001 [Page 8]
\ No newline at end of file
+++ /dev/null
-
-
-Network Working Group R. Bush
-Internet-Draft IIJ
-Expires: August 14, 2003 J. Damas
- February 13, 2003
-
-
- Delegation of 2.0.0.2.ip6.arpa
- draft-ymbk-6to4-arpa-delegation-00.txt
-
-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.
-
- This Internet-Draft will expire on August 14, 2003.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document discusses the need for delegation of the
- 2.0.0.2.ip6.arpa DNS zone in order to enable reverse lookups for 6to4
- addresses.
-
-1. 6to4 and DNS
-
- 6to4 [RFC3056] provides a mechanism for IPv6 native hosts to
- communicate over IPv4 clouds without explicit tunnel setup.
-
- 6to4 and DNS [I-D.moore-6to4-dns] describes methods to find the
- delegation path for reverse lookups of 6to4 addresses in the DNS.
- Section 3.1 of the I-D describes a simple method, using established
-
-
-
-Bush & Damas Expires August 14, 2003 [Page 1]
-\f
-Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003
-
-
- mechanisms at the RIRs, that would enable such a mechanism to be
- deployed using a minimum of additional setup.
-
- Under the described method, the holders of IPv4 address space can
- request the delegation of a sub-zone in the 2.0.0.2.ip6.arpa DNS tree
- from the party from which they obtained the corresponding IPv4
- in-addr.arpa delegation (or the holder of an even shorter IPv4 prefix
- if their immediate parent is not configured for ip6.arpa), following
- the mapping of IPv4 delegations. This sub-zone can then be populated
- by the entity deploying the 6to4 infrastructure.
-
-2. IANA Considerations
-
- This memo requests that the IANA delegate the 2.0.0.2.IP6.ARPA domain
- to the RIRs as will be described in instructions to be provided by
- the IAB. Names within this zone are to be further delegated within
- the regional IP registries and ISPs in accordance with the delegation
- of IPv4 address space.
-
-3. Security Considerations
-
- While DNS spoofing of address to name mapping has been exploited in
- IPv4, delegation of the 2.0.0.2.ip6.arpa zone creates no new threats
- to the security of the internet.
-
-Normative References
-
- [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
- via IPv4 Clouds", RFC 3056, February 2001.
-
-Informative References
-
- [I-D.moore-6to4-dns]
- Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
- in progress), October 2002.
-
-
-Authors' Addresses
-
- Randy Bush
- IIJ
- 5147 Crystal Springs
- Bainbrisge Island, WA 98110
- US
-
- Phone: +1 206 780 0431
- EMail: randy@psg.com
- URI: http://psg.com/~randy/
-
-
-
-Bush & Damas Expires August 14, 2003 [Page 2]
-\f
-Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003
-
-
- Joao Damas
- Amsterdam,
- The Netherlands
-
- Phone:
- EMail: joao@psg.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush & Damas Expires August 14, 2003 [Page 3]
-\f
-Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). 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 assignees.
-
- 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
-
-
-
-Bush & Damas Expires August 14, 2003 [Page 4]
-\f
-Internet-Draft Delegation of 2.0.0.2.ip6.arpa February 2003
-
-
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Bush & Damas Expires August 14, 2003 [Page 5]
-
projects / thirdparty / bind9.git / commitdiff
