From 8631cc57a95d760c510149a8490bc4cfc5158630 Mon Sep 17 00:00:00 2001 From: Bob Halley Date: Tue, 3 Aug 1999 20:46:55 +0000 Subject: [PATCH] add --- doc/rfc/rfc1706.txt | 563 +++++++++++++++++ doc/rfc/rfc2163.txt | 1459 +++++++++++++++++++++++++++++++++++++++++++ doc/rfc/rfc2230.txt | 619 ++++++++++++++++++ 3 files changed, 2641 insertions(+) create mode 100644 doc/rfc/rfc1706.txt create mode 100644 doc/rfc/rfc2163.txt create mode 100644 doc/rfc/rfc2230.txt diff --git a/doc/rfc/rfc1706.txt b/doc/rfc/rfc1706.txt new file mode 100644 index 0000000000..5b5d82194a --- /dev/null +++ b/doc/rfc/rfc1706.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group B. Manning +Request for Comments: 1706 ISI +Obsoletes: 1637, 1348 R. Colella +Category: Informational NIST + October 1994 + + + DNS NSAP Resource Records + + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + OSI lower layer protocols, comprising the connectionless network + protocol (CLNP) and supporting routing protocols, are deployed in + some parts of the global Internet. Maintenance and debugging of CLNP + connectivity is greatly aided by support in the Domain Name System + (DNS) for mapping between names and NSAP addresses. + + This document defines the format of one new Resource Record (RR) for + the DNS for domain name-to-NSAP mapping. The RR may be used with any + NSAP address format. + + NSAP-to-name translation is accomplished through use of the PTR RR + (see STD 13, RFC 1035 for a description of the PTR RR). This paper + describes how PTR RRs are used to support this translation. + + This document obsoletes RFC 1348 and RFC 1637. + + + + + + + + + + + + + + + + + + +Manning & Colella [Page 1] + +RFC 1706 DNS NSAP RRs October 1994 + + +1. Introduction + + OSI lower layer protocols, comprising the connectionless network + protocol (CLNP) [5] and supporting routing protocols, are deployed in + some parts of the global Internet. Maintenance and debugging of CLNP + connectivity is greatly aided by support in the Domain Name System + (DNS) [7] [8] for mapping between names and NSAP (network service + access point) addresses [6] [Note: NSAP and NSAP address are used + interchangeably throughout this memo]. + + This document defines the format of one new Resource Record (RR) for + the DNS for domain name-to-NSAP mapping. The RR may be used with any + NSAP address format. + + NSAP-to-name translation is accomplished through use of the PTR RR + (see RFC 1035 for a description of the PTR RR). This paper describes + how PTR RRs are used to support this translation. + + This memo assumes that the reader is familiar with the DNS. Some + familiarity with NSAPs is useful; see [1] or Annex A of [6] for + additional information. + +2. Background + + The reason for defining DNS mappings for NSAPs is to support the + existing CLNP deployment in the Internet. Debugging with CLNP ping + and traceroute has become more difficult with only numeric NSAPs as + the scale of deployment has increased. Current debugging is supported + by maintaining and exchanging a configuration file with name/NSAP + mappings similar in function to hosts.txt. This suffers from the lack + of a central coordinator for this file and also from the perspective + of scaling. The former describes the most serious short-term + problem. Scaling of a hosts.txt-like solution has well-known long- + term scaling difficiencies. + +3. Scope + + The methods defined in this paper are applicable to all NSAP formats. + + As a point of reference, there is a distinction between registration + and publication of addresses. For IP addresses, the IANA is the root + registration authority and the DNS a publication method. For NSAPs, + Annex A of the network service definition, ISO8348 [6], describes the + root registration authority and this memo defines how the DNS is used + as a publication method. + + + + + + +Manning & Colella [Page 2] + +RFC 1706 DNS NSAP RRs October 1994 + + +4. Structure of NSAPs + + NSAPs are hierarchically structured to allow distributed + administration and efficient routing. Distributed administration + permits subdelegated addressing authorities to, as allowed by the + delegator, further structure the portion of the NSAP space under + their delegated control. Accomodating this distributed authority + requires that there be little or no a priori knowledge of the + structure of NSAPs built into DNS resolvers and servers. + + For the purposes of this memo, NSAPs can be thought of as a tree of + identifiers. The root of the tree is ISO8348 [6], and has as its + immediately registered subordinates the one-octet Authority and + Format Identifiers (AFIs) defined there. The size of subsequently- + defined fields depends on which branch of the tree is taken. The + depth of the tree varies according to the authority responsible for + defining subsequent fields. + + An example is the authority under which U.S. GOSIP defines NSAPs [2]. + Under the AFI of 47, NIST (National Institute of Standards and + Technology) obtained a value of 0005 (the AFI of 47 defines the next + field as being two octets consisting of four BCD digits from the + International Code Designator space [3]). NIST defined the subsequent + fields in [2], as shown in Figure 1. The field immediately following + 0005 is a format identifier for the rest of the U.S. GOSIP NSAP + structure, with a hex value of 80. Following this is the three-octet + field, values for which are allocated to network operators; the + registration authority for this field is delegated to GSA (General + Services Administration). + + The last octet of the NSAP is the NSelector (NSel). In practice, the + NSAP minus the NSel identifies the CLNP protocol machine on a given + system, and the NSel identifies the CLNP user. Since there can be + more than one CLNP user (meaning multiple NSel values for a given + "base" NSAP), the representation of the NSAP should be CLNP-user + independent. To achieve this, an NSel value of zero shall be used + with all NSAP values stored in the DNS. An NSAP with NSel=0 + identifies the network layer itself. It is left to the application + retrieving the NSAP to determine the appropriate value to use in that + instance of communication. + + When CLNP is used to support TCP and UDP services, the NSel value + used is the appropriate IP PROTO value as registered with the IANA. + For "standard" OSI, the selection of NSel values is left as a matter + of local administration. Administrators of systems that support the + OSI transport protocol [4] in addition to TCP/UDP must select NSels + for use by OSI Transport that do not conflict with the IP PROTO + values. + + + +Manning & Colella [Page 3] + +RFC 1706 DNS NSAP RRs October 1994 + + + |--------------| + | <-- IDP --> | + |--------------|-------------------------------------| + | AFI | IDI | <-- DSP --> | + |-----|--------|-------------------------------------| + | 47 | 0005 | DFI | AA |Rsvd | RD |Area | ID |Sel | + |-----|--------|-----|----|-----|----|-----|----|----| + octets | 1 | 2 | 1 | 3 | 2 | 2 | 2 | 6 | 1 | + |-----|--------|-----|----|-----|----|-----|----|----| + + IDP Initial Domain Part + AFI Authority and Format Identifier + IDI Initial Domain Identifier + DSP Domain Specific Part + DFI DSP Format Identifier + AA Administrative Authority + Rsvd Reserved + RD Routing Domain Identifier + Area Area Identifier + ID System Identifier + SEL NSAP Selector + + Figure 1: GOSIP Version 2 NSAP structure. + + + In the NSAP RRs in Master Files and in the printed text in this memo, + NSAPs are often represented as a string of "."-separated hex values. + The values correspond to convenient divisions of the NSAP to make it + more readable. For example, the "."-separated fields might correspond + to the NSAP fields as defined by the appropriate authority (RARE, + U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for + readability. The "."s do not appear in DNS packets and DNS servers + can ignore them when reading Master Files. For example, a printable + representation of the first four fields of a U.S. GOSIP NSAP might + look like + + 47.0005.80.005a00 + + and a full U.S. GOSIP NSAP might appear as + + 47.0005.80.005a00.0000.1000.0020.00800a123456.00. + + Other NSAP formats have different lengths and different + administratively defined field widths to accomodate different + requirements. For more information on NSAP formats in use see RFC + 1629 [1]. + + + + + +Manning & Colella [Page 4] + +RFC 1706 DNS NSAP RRs October 1994 + + +5. The NSAP RR + + The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22 + (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP + mapping in the DNS using the NSAP RR operates analogously to IP + address lookup. A query is generated by the resolver requesting an + NSAP RR for a provided domain name. + + NSAP RRs conform to the top level RR format and semantics as defined + in Section 3.2.1 of RFC 1035. + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / / + / NAME / + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TYPE = NSAP | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CLASS = IN | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TTL | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RDLENGTH | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / RDATA / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + * NAME: an owner name, i.e., the name of the node to which this + resource record pertains. + + * TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal). + + * CLASS: two octets containing the RR IN CLASS code of 1. + + * TTL: a 32 bit signed integer that specifies the time interval in + seconds that the resource record may be cached before the source + of the information should again be consulted. Zero values are + interpreted to mean that the RR can only be used for the + transaction in progress, and should not be cached. For example, + SOA records are always distributed with a zero TTL to prohibit + caching. Zero values can also be used for extremely volatile data. + + + +Manning & Colella [Page 5] + +RFC 1706 DNS NSAP RRs October 1994 + + + * RDLENGTH: an unsigned 16 bit integer that specifies the length in + octets of the RDATA field. + + * RDATA: a variable length string of octets containing the NSAP. + The value is the binary encoding of the NSAP as it would appear in + the CLNP source or destination address field. A typical example of + such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is + 20 (decimal); "."s have been omitted to emphasize that they don't + appear in the DNS packets. + + 39840f80005a0000000001e13708002010726e00 + + NSAP RRs cause no additional section processing. + +6. NSAP-to-name Mapping Using the PTR RR + + The PTR RR is defined in RFC 1035. This RR is typically used under + the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names. + + Similarly, the PTR RR is used to map from NSAPs to domain names under + the "NSAP.INT" domain. A domain name is generated from the NSAP + according to the rules described below. A query is sent by the + resolver requesting a PTR RR for the provided domain name. + + A domain name is generated from an NSAP by reversing the hex nibbles + of the NSAP, treating each nibble as a separate subdomain, and + appending the top-level subdomain name "NSAP.INT" to it. For example, + the domain name used in the reverse lookup for the NSAP + + 47.0005.80.005a00.0000.0001.e133.ffffff000162.00 + + would appear as + + 0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \ + 0.8.5.0.0.0.7.4.NSAP.INT. + + [Implementation note: For sanity's sake user interfaces should be + designed to allow users to enter NSAPs using their natural order, + i.e., as they are typically written on paper. Also, arbitrary "."s + should be allowed (and ignored) on input.] + +7. Master File Format + + The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files + conforms to Section 5, "Master Files," of RFC 1035. Below are + examples of the use of these RRs in Master Files to support name-to- + NSAP and NSAP-to-name mapping. + + + + +Manning & Colella [Page 6] + +RFC 1706 DNS NSAP RRs October 1994 + + + The NSAP RR introduces a new hex string format for the RDATA field. + The format is "0x" (i.e., a zero followed by an 'x' character) + followed by a variable length string of hex characters (0 to 9, a to + f). The hex string is case-insensitive. "."s (i.e., periods) may be + inserted in the hex string anywhere after the "0x" for readability. + The "."s have no significance other than for readability and are not + propagated in the protocol (e.g., queries or zone transfers). + + + ;;;;;; + ;;;;;; Master File for domain nsap.nist.gov. + ;;;;;; + + + @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. ( + 1994041800 ; Serial - date + 1800 ; Refresh - 30 minutes + 300 ; Retry - 5 minutes + 604800 ; Expire - 7 days + 3600 ) ; Minimum - 1 hour + IN NS emu.ncsl.nist.gov. + IN NS tuba.nsap.lanl.gov. + ; + ; + $ORIGIN nsap.nist.gov. + ; + ; hosts + ; + bsdi1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00 + IN A 129.6.224.161 + IN HINFO PC_486 BSDi1.1 + ; + bsdi2 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00 + IN A 129.6.224.162 + IN HINFO PC_486 BSDi1.1 + ; + cursive IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00 + IN A 129.6.224.171 + IN HINFO PC_386 DOS_5.0/NCSA_Telnet(TUBA) + ; + infidel IN NSAP 0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00 + IN A 129.6.55.164 + IN HINFO PC/486 BSDi1.0(TUBA) + ; + ; routers + ; + cisco1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00 + IN A 129.6.224.151 + + + +Manning & Colella [Page 7] + +RFC 1706 DNS NSAP RRs October 1994 + + + IN A 129.6.225.151 + IN A 129.6.229.151 + ; + 3com1 IN NSAP 0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00 + IN A 129.6.224.111 + IN A 129.6.225.111 + IN A 129.6.228.111 + + + + + ;;;;;; + ;;;;;; Master File for reverse mapping of NSAPs under the + ;;;;;; NSAP prefix: + ;;;;;; + ;;;;;; 47.0005.80.005a00.0000.0001.e133 + ;;;;;; + + + @ IN SOA emu.ncsl.nist.gov. root.emu.ncsl.nist.gov. ( + 1994041800 ; Serial - date + 1800 ; Refresh - 30 minutes + 300 ; Retry - 5 minutes + 604800 ; Expire - 7 days + 3600 ) ; Minimum - 1 hour + IN NS emu.ncsl.nist.gov. + IN NS tuba.nsap.lanl.gov. + ; + ; + $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT. + ; + 0.0.1.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi1.nsap.nist.gov. + ; + 0.0.2.6.1.0.0.0.f.f.f.f.f.f IN PTR bsdi2.nsap.nist.gov. + ; + 0.0.1.7.1.0.0.0.f.f.f.f.f.f IN PTR cursive.nsap.nist.gov. + ; + 0.0.4.6.1.0.0.0.f.f.f.f.f.f IN PTR infidel.nsap.nist.gov. + ; + 0.0.1.5.1.0.0.0.a.a.a.a.a.a IN PTR cisco1.nsap.nist.gov. + ; + 0.0.1.1.1.0.0.0.a.a.a.a.a.a IN PTR 3com1.nsap.nist.gov. + +8. Security Considerations + + Security issues are not discussed in this memo. + + + + + +Manning & Colella [Page 8] + +RFC 1706 DNS NSAP RRs October 1994 + + +9. Authors' Addresses + + Bill Manning + USC/Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA. 90292 + USA + + Phone: +1.310.822.1511 + EMail: bmanning@isi.edu + + + Richard Colella + National Institute of Standards and Technology + Technology/B217 + Gaithersburg, MD 20899 + USA + + Phone: +1 301-975-3627 + Fax: +1 301 590-0932 + EMail: colella@nist.gov + +10. References + + [1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines + for OSI NSAP Allocation inh the Internet", RFC 1629, NIST, + Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May + 1994. + + [2] GOSIP Advanced Requirements Group. Government Open Systems + Interconnection Profile (GOSIP) Version 2. Federal Information + Processing Standard 146-1, U.S. Department of Commerce, National + Institute of Standards and Technology, Gaithersburg, MD, April + 1991. + + [3] ISO/IEC. Data interchange - structures for the identification of + organization. International Standard 6523, ISO/IEC JTC 1, + Switzerland, 1984. + + [4] ISO/IEC. Connection oriented transport protocol specification. + International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986. + + [5] ISO/IEC. Protocol for Providing the Connectionless-mode Network + Service. International Standard 8473, ISO/IEC JTC 1, + Switzerland, 1986. + + + + + + +Manning & Colella [Page 9] + +RFC 1706 DNS NSAP RRs October 1994 + + + [6] ISO/IEC. Information Processing Systems -- Data Communications -- + Network Service Definition. International Standard 8348, ISO/IEC + JTC 1, Switzerland, 1993. + + [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD + 13, RFC 1034, USC/Information Sciences Institute, November 1987. + + [8] Mockapetris, P., "Domain Names -- Implementation and + Specification", STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Manning & Colella [Page 10] + diff --git a/doc/rfc/rfc2163.txt b/doc/rfc/rfc2163.txt new file mode 100644 index 0000000000..00fcee7c88 --- /dev/null +++ b/doc/rfc/rfc2163.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group C. Allocchio +Request for Comments: 2163 GARR-Italy +Obsoletes: 1664 January 1998 +Category: Standards Track + + + Using the Internet DNS to Distribute + MIXER Conformant Global Address Mapping (MCGAM) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + This memo is the complete technical specification to store in the + Internet Domain Name System (DNS) the mapping information (MCGAM) + needed by MIXER conformant e-mail gateways and other tools to map + RFC822 domain names into X.400 O/R names and vice versa. Mapping + information can be managed in a distributed rather than a centralised + way. Organizations can publish their MIXER mapping or preferred + gateway routing information using just local resources (their local + DNS server), avoiding the need for a strong coordination with any + centralised organization. MIXER conformant gateways and tools located + on Internet hosts can retrieve the mapping information querying the + DNS instead of having fixed tables which need to be centrally updated + and distributed. + + This memo obsoletes RFC1664. It includes the changes introduced by + MIXER specification with respect to RFC1327: the new 'gate1' (O/R + addresses to domain) table is fully supported. Full backward + compatibility with RFC1664 specification is mantained, too. + + RFC1664 was a joint effort of IETF X400 operation working group + (x400ops) and TERENA (formely named "RARE") Mail and Messaging + working group (WG-MSG). This update was performed by the IETF MIXER + working group. + + + + + + +Allocchio Standards Track [Page 1] + +RFC 2163 MIXER MCGAM January 1998 + + +1. Introduction + + The connectivity between the Internet SMTP mail and other mail + services, including the Internet X.400 mail and the commercial X.400 + service providers, is assured by the Mail eXchanger (MX) record + information distributed via the Internet Domain Name System (DNS). A + number of documents then specify in details how to convert or encode + addresses from/to RFC822 style to the other mail system syntax. + However, only conversion methods provide, via some algorithm or a set + of mapping rules, a smooth translation, resulting in addresses + indistinguishable from the native ones in both RFC822 and foreign + world. + + MIXER describes a set of mappings (MIXER Conformant Global Address + Mapping - MCGAM) which will enable interworking between systems + operating the CCITT X.400 (1984/88/92) Recommendations and systems + using using the RFC822 mail protocol, or protocols derived from + RFC822. That document addresses conversion of services, addresses, + message envelopes, and message bodies between the two mail systems. + This document is concerned with one aspect of MIXER: the mechanism + for mapping between X.400 O/R addresses and RFC822 domain names. As + described in Appendix F of MIXER, implementation of the mappings + requires a database which maps between X.400 O/R addresses and domain + names; in RFC1327 this database was statically defined. + + The original approach in RFC1327 required many efforts to maintain + the correct mapping: all the gateways needed to get coherent tables + to apply the same mappings, the conversion tables had to be + distributed among all the operational gateways, and also every update + needed to be distributed. + + The concept of mapping rules distribution and use has been revised in + the new MIXER specification, introducing the concept of MIXER + Conformant Global Address Mapping (MCGAM). A MCGAM does not need to + be globally installed by any MIXER conformant gateway in the world + any more. However MIXER requires now efficient methods to publish its + MCGAM. + + Static tables are one of the possible methods to publish MCGAM. + However this static mechanism requires quite a long time to be spent + modifying and distributing the information, putting heavy constraints + on the time schedule of every update. In fact it does not appear + efficient compared to the Internet Domain Name Service (DNS). More + over it does not look feasible to distribute the database to a large + number of other useful applications, like local address converters, + e-mail User Agents or any other tool requiring the mapping rules to + produce correct results. + + + + +Allocchio Standards Track [Page 2] + +RFC 2163 MIXER MCGAM January 1998 + + + Two much more efficient methods are proposed by MIXER for publication + of MCGAM: the Internet DNS and X.500. This memo is the complete + technical specification for publishing MCGAM via Internet DNS. + + A first proposal to use the Internet DNS to store, retrieve and + maintain those mappings was introduced by two of the authors of + RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record + (RR) types: TO-X400 and TO-822. This proposal now adopts a more + complete strategy, and requires one new RR only. The distribution of + MCGAMs via DNS is in fact an important service for the whole Internet + community: it completes the information given by MX resource record + and it allows to produce clean addresses when messages are exchanged + among the Internet RFC822 world and the X.400 one (both Internet and + Public X.400 service providers). + + A first experiment in using the DNS without expanding the current set + of RR and using available ones was deployed by some of the authors of + RFC1664 at the time of its development. The existing PTR resource + records were used to store the mapping rules, and a new DNS tree was + created under the ".it" top level domain. The result of the + experiment was positive, and a few test applications ran under this + provisional set up. This test was also very useful in order to define + a possible migration strategy during the deployment of the new DNS + containing the new RR. The Internet DNS nameservers wishing to + provide this mapping information need in fact to be modified to + support the new RR type, and in the real Internet, due to the large + number of different implementations, this takes some time. + + The basic idea is to adopt a new DNS RR to store the mapping + information. The RFC822 to X.400 mapping rules (including the so + called 'gate2' rules) will be stored in the ordinary DNS tree, while + the definition of a new branch of the name space defined under each + national top level domain is envisaged in order to contain the X.400 + to RFC822 mappings ('table1' and 'gate1'). A "two-way" mapping + resolution schema is thus fully implemented. + + The creation of the new domain name space representing the X.400 O/R + names structure also provides the chance to use the DNS to distribute + dynamically other X.400 related information, thus solving other + efficiency problems currently affecting the X.400 MHS service. + + In this paper we will adopt the MCGAM syntax, showing how it can be + stored into the Internet DNS. + + + + + + + + +Allocchio Standards Track [Page 3] + +RFC 2163 MIXER MCGAM January 1998 + + +1.1 Definitions syntax + + The definitions in this document is given in BNF-like syntax, using + the following conventions: + + | means choice + \ is used for continuation of a definition over several lines + [] means optional + {} means repeated one or more times + + The definitions, however, are detailed only until a certain level, + and below it self-explaining character text strings will be used. + +2. Motivation + + Implementations of MIXER gateways require that a database store + address mapping information for X.400 and RFC822. This information + must be made available (published) to all MIXER gateways. In the + Internet community, the DNS has proven to be a practical mean for + providing a distributed name service. Advantages of using a DNS based + system over a table based approach for mapping between O/R addresses + and domain names are: + + - It avoids fetching and storing of entire mapping tables by every + host that wishes to implement MIXER gateways and/or tools + + - Modifications to the DNS based mapping information can be made + available in a more timely manner than with a table driven + approach. + + - It allows full authority delegation, in agreement with the + Internet regionalization process. + + - Table management is not necessarily required for DNS-based + MIXER gateways. + + - One can determine the mappings in use by a remote gateway by + querying the DNS (remote debugging). + + Also many other tools, like address converters and User Agents can + take advantage of the real-time availability of MIXER tables, + allowing a much easier maintenance of the information. + +3. The domain space for X.400 O/R name addresses + + Usual domain names (the ones normally used as the global part of an + RFC822 e-mail address) and their associated information, i.e., host + IP addresses, mail exchanger names, etc., are stored in the DNS as a + + + +Allocchio Standards Track [Page 4] + +RFC 2163 MIXER MCGAM January 1998 + + + distributed database under a number of top-level domains. Some top- + level domains are used for traditional categories or international + organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand + any country has its own two letter ISO country code as top-level + domain (FR, DE, GB, IT, RU, ...), including "US" for USA. The + special top-level/second-level couple IN-ADDR.ARPA is used to store + the IP address to domain name relationship. This memo defines in the + above structure the appropriate way to locate the X.400 O/R name + space, thus enabling to store in DNS the MIXER mappings (MCGAMs). + + The MIXER mapping information is composed by four tables: + + - 'table1' and 'gate1' gives the translation from X.400 to RFC822; + - 'table2' and 'gate2' tables map RFC822 into X.400. + + Each mapping table is composed by mapping rules, and a single mapping + rule is composed by a keyword (the argument of the mapping function + derived from the address to be translated) and a translator (the + mapping function parameter): + + keyword#translator# + + the '#' sign is a delimiter enclosing the translator. An example: + + foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us# + + Local mappings are not intended for use outside their restricted + environment, thus they should not be included in DNS. If local + mappings are used, they should be stored using static local tables, + exactly as local static host tables can be used with DNS. + + The keyword of a 'table2' and 'gate2' table entry is a valid RFC822 + domain; thus the usual domain name space can be used without problems + to store these entries. + On the other hand, the keyword of a 'table1' and 'gate1' entry + belongs to the X.400 O/R name space. The X.400 O/R name space does + not usually fit into the usual domain name space, although there are + a number of similarities; a new name structure is thus needed to + represent it. This new name structure contains the X.400 mail + domains. + + To ensure the correct functioning of the DNS system, the new X.400 + name structure must be hooked to the existing domain name space in a + way which respects the existing name hierarchy. + + A possible solution was to create another special branch, starting + from the root of the DNS tree, somehow similar to the in-addr.arpa + tree. This idea would have required to establish a central authority + + + +Allocchio Standards Track [Page 5] + +RFC 2163 MIXER MCGAM January 1998 + + + to coordinate at international level the management of each national + X.400 name tree, including the X.400 public service providers. This + coordination problem is a heavy burden if approached globally. More + over the X.400 name structure is very 'country oriented': thus while + it requires a coordination at national level, it does not have + concepts like the international root. In fact the X.400 international + service is based on a large number of bilateral agreements, and only + within some communities an international coordination service exists. + + The X.400 two letter ISO country codes, however, are the same used + for the RFC822 country top-level domains and this gives us an + appropriate hook to insert the new branches. The proposal is, in + fact, to create under each national top level ISO country code a new + branch in the name space. This branch represents exactly the X.400 + O/R name structure as defined in each single country, following the + ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed + under each country top-level domain, and hence the national X.400 + name space derives its own structure: + + . (root) + | + +-----------------+-----------+--------+-----------------+... + | | | | + edu it us fr + | | | | + +---+---+... +-----+-----+... +-----+-----+... +--+---+... + | | | | | | | | | | + ... ... cnr X42D infn va ca X42D X42D inria + | | | | + +------------+------------+... ... ... +----+-------+... + | | | | | + ADMD-PtPostel ADMD-garr ADMD-Master400 ADMD-atlas ADMD-red + | | | | + +----------+----+... ... +-------+------+... ... + | | | | + PRMD-infn PRMD-STET PRMD-Telecom PRMD-Renault + | | | | + ... ... ... ... + + + The creation of the X.400 new name tree at national level solves the + problem of the international coordination. Actually the coordination + problem is just moved at national level, but it thus becomes easier + to solve. The coordination at national level between the X.400 + communities and the Internet world is already a requirement for the + creation of the national static MIXER mapping tables; the use of the + Internet DNS gives further motivations for this coordination. + + + + +Allocchio Standards Track [Page 6] + +RFC 2163 MIXER MCGAM January 1998 + + + The coordination at national level also fits in the new concept of + MCGAM pubblication. The DNS in fact allows a step by step authority + distribution, up to a final complete delegation: thus organizations + whishing to publish their MCGAM just need to receive delegation also + for their branch of the new X.400 name space. A further advantage of + the national based solution is to allow each country to set up its + own X.400 name structure in DNS and to deploy its own authority + delegation according to its local time scale and requirements, with + no loss of global service in the mean time. And last, placing the new + X.400 name tree and coordination process at national level fits into + the Internet regionalization and internationalisation process, as it + requires local bodies to take care of local coordination problems. + + The DNS name space thus contains completely the information required + by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a + simple query to the nearest nameserver provides it. Moreover there is + no more any need to store, maintain and distribute manually any + mapping table. The new X.400 name space can also contain further + information about the X.400 community, as DNS allows for it a + complete set of resource records, and thus it allows further + developments. This set of RRs in the new X.400 name space must be + considered 'reserved' and thus not used until further specifications. + + The construction of the new domain space trees will follow the same + procedures used when organising at first the already existing DNS + space: at first the information will be stored in a quite centralised + way, and distribution of authority will be gradually achieved. A + separate document will describe the implementation phase and the + methods to assure a smooth introduction of the new service. + +4. The new DNS resource record for MIXER mapping rules: PX + + The specification of the Internet DNS (RFC1035) provides a number of + specific resource records (RRs) to contain specific pieces of + information. In particular they contain the Mail eXchanger (MX) RR + and the host Address (A) records which are used by the Internet SMTP + mailers. As we will store the RFC822 to X.400 mapping information in + the already existing DNS name tree, we need to define a new DNS RR in + order to avoid any possible clash or misuse of already existing data + structures. The same new RR will also be used to store the mappings + from X.400 to RFC822. More over the mapping information, i.e., the + MCGAMs, has a specific format and syntax which require an appropriate + data structure and processing. A further advantage of defining a new + RR is the ability to include flexibility for some eventual future + development. + + + + + + +Allocchio Standards Track [Page 7] + +RFC 2163 MIXER MCGAM January 1998 + + + The definition of the new 'PX' DNS resource record is: + + class: IN (Internet) + + name: PX (pointer to X.400/RFC822 mapping information) + + value: 26 + + The PX RDATA format is: + + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | PREFERENCE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / MAP822 / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + / MAPX400 / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + where: + + PREFERENCE A 16 bit integer which specifies the preference given to + this RR among others at the same owner. Lower values + are preferred; + + MAP822 A element containing , the + RFC822 part of the MCGAM; + + MAPX400 A element containing the value of + derived from the X.400 part of + the MCGAM (see sect. 4.2); + + PX records cause no additional section processing. The PX RR format + is the usual one: + + [] [] + + When we store in DNS a 'table1' or a 'gate1' entry, then will + be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we + store a 'table2' or a 'gate2' table entry, will be an RFC822 + mail domain name, including both fully qualified DNS domains and mail + only domains (MX-only domains). All normal DNS conventions, like + default values, wildcards, abbreviations and message compression, + apply also for all the components of the PX RR. In particular , + MAP822 and MAPX400, as elements, must have the final + "." (root) when they are fully qualified. + + + + +Allocchio Standards Track [Page 8] + +RFC 2163 MIXER MCGAM January 1998 + + +4.1 Additional features of the PX resource record + + The definition of the RDATA for the PX resource record, and the fact + that DNS allows a distinction between an exact value and a wildcard + match for the parameter, represent an extension of the MIXER + specification for mapping rules. In fact, any MCGAM entry is an + implicit wildcard entry, i.e., the rule + + net2.it#PRMD$net2.ADMD$p400.C$it# + + covers any RFC822 domain ending with 'net2.it', unless more detailed + rules for some subdomain in 'net2.it' are present. Thus there is no + possibility to specify explicitly a MCGAM as an exact match only + rule. In DNS an entry like + + *.net2.it. IN PX 10 net2.it. PRMD-net2.ADMD-p400.C-it. + + specify the usual wildcard match as for MIXER tables. However an + entry like + + ab.net2.it. IN PX 10 ab.net2.it. O-ab.PRMD-net2.ADMDb.C-it. + + is valid only for an exact match of 'ab.net2.it' RFC822 domain. + + Note also that in DNS syntax there is no '#' delimiter around MAP822 + and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not + allow the (ASCII decimal 32) character within these fields, + making unneeded the use of an explicit delimiter as required in the + MIXER original syntax. + + Another extension to the MIXER specifications is the PREFERENCE value + defined as part of the PX RDATA section. This numeric value has + exactly the same meaning than the similar one used for the MX RR. It + is thus possible to specify more than one single mapping for a domain + (both from RFC822 to X.400 and vice versa), giving as the preference + order. In MIXER static tables, however, you cannot specify more than + one mapping per each RFC822 domain, and the same restriction apply + for any X.400 domain mapping to an RFC822 one. + + More over, in the X.400 recommendations a note suggests than an + ADMD= should be reserved for some special cases. Various + national functional profile specifications for an X.400 MHS states + that if an X.400 PRMD is reachable via any of its national ADMDs, + independently of its actual single or multiple connectivity with + them, it should use ADMD= to advertise this fact. Again, if a + PRMD has no connections to any ADMD it should use ADMD=0 to notify + its status, etc. However, in most of the current real situations, the + ADMD service providers do not accept messages coming from their + + + +Allocchio Standards Track [Page 9] + +RFC 2163 MIXER MCGAM January 1998 + + + subscribers if they have a blank ADMD, forcing them to have their own + ADMD value. In such a situation there are problems in indicating + properly the actually working mappings for domains with multiple + connectivity. The PX RDATA 'PREFERENCE' extension was introduced to + take in consideration these problems. + + However, as these extensions are not available with MIXER static + tables, it is strongly discouraged to use them when interworking with + any table based gateway or application. The extensions were in fact + introduced just to add more flexibility, like the PREFERENCE value, + or they were already implicit in the DNS mechanism, like the + wildcard specification. They should be used very carefully or just + considered 'reserved for future use'. In particular, for current use, + the PREFERENCE value in the PX record specification should be fixed + to a value of 50, and only wildcard specifications should be used + when specifying values. + +4.2 The DNS syntax for an X.400 'domain' + + The syntax definition of the MCGAM rules is defined in appendix F of + that document. However that syntax is not very human oriented and + contains a number of characters which have a special meaning in other + fields of the Internet DNS. Thus in order to avoid any possible + problem, especially due to some old DNS implementations still being + used in the Internet, we define a syntax for the X.400 part of any + MCGAM rules (and hence for any X.400 O/R name) which makes it + compatible with a element, i.e., + + ::= | " " + ::=