From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1664.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc1664.txt (limited to 'doc/rfc/rfc1664.txt') diff --git a/doc/rfc/rfc1664.txt b/doc/rfc/rfc1664.txt new file mode 100644 index 0000000..82b036c --- /dev/null +++ b/doc/rfc/rfc1664.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group C. Allocchio +Request for Comments: 1664 A. Bonito +Category: Experimental GARR-Italy + B. Cole + Cisco Systems Inc. + S. Giordano + Centro Svizzero Calcolo Scientifico + R. Hagens + Advanced Network & Services + August 1994 + + + Using the Internet DNS to Distribute + RFC1327 Mail Address Mapping Tables + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. This memo does not specify an Internet standard of any + kind. Distribution of this memo is unlimited. + +Abstract + + This memo defines how to store in the Internet Domain Name System the + mapping information needed by 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. Gateways 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 is a joint + effort of X400 operation working group (x400ops) and RARE Mail and + Messaging working group (WG-MSG). + +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. + + RFC1327 describes a set of mappings which will enable interworking + between systems operating the CCITT X.400 (1984/88) Recommendations + + + +Allocchio, Bonito, Cole, Giordano & Hagens [Page 1] + +RFC 1664 Internet DNS for Mail Mapping Tables August 1994 + + + and systems 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 RFC1327: the mechanism + for mapping between X.400 O/R addresses and RFC822 domain names. As + described in Appendix F of RFC1327, implementation of the mappings + requires a database which maps between X.400 O/R addresses and domain + names, and this database is statically defined. + + This approach requires many efforts to maintain the correct mapping: + all the gateways need to get coherent tables to apply the same + mappings, the conversion tables must be distributed among all the + operational gateways, and also every update needs to be distributed. + 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. + + A first proposal to use the Internet DNS to store, retrieve and + maintain those mappings was introduced by two of the authors (B. Cole + and R. Hagens) adopting two new DNS resource record (RR) types: TO- + X400 and TO-822. This new proposal adopts a more complete strategy, + and requires one new RR only. The distribution of the RFC1327 mapping + rules 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 in the mean time deployed by some + of the authors. 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 + + + +Allocchio, Bonito, Cole, Giordano & Hagens [Page 2] + +RFC 1664 Internet DNS for Mail Mapping Tables August 1994 + + + called 'gate' 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. 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 RFC1327 mapping rules syntax, showing + how it can be stored into the Internet DNS. + +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 RFC1327 gateways require that a database store + address mapping information for X.400 and RFC822. This information + must be disseminated to all RFC1327 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 RFC1327 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. + + + + + +Allocchio, Bonito, Cole, Giordano & Hagens [Page 3] + +RFC 1664 Internet DNS for Mail Mapping Tables August 1994 + + + - Table management is not necessarily required for DNS-based + RFC1327 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 RFC1327 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 + 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. Our proposal defines in + the above structure the appropriate way to locate the X.400 O/R name + space, thus enabling us to store in DNS the RFC1327 mapping data. + + The RFC1327 mapping information is composed by three tables: 'table1' + gives the translation from X.400 to RFC822 while 'table2' and 'gate' + 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 'gate' table entry is a valid RFC822 + domain; thus the usual domain name space can be used without problems + to store these entries. + + + + + +Allocchio, Bonito, Cole, Giordano & Hagens [Page 4] + +RFC 1664 Internet DNS for Mail Mapping Tables August 1994 + + + On the other hand, the keyword of a 'table1' 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 + 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. Our 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: + + + + + + + + + + + + + + + + + + + + +Allocchio, Bonito, Cole, Giordano & Hagens [Page 5] + +RFC 1664 Internet DNS for Mail Mapping Tables August 1994 + + + . (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 RFC1327 mapping tables; the use of + the Internet DNS gives further motivations for this coordination. + + The coordination at national level also fits in the ongoing proposal + intended to define exactly the RFC1327 Mapping Authorities. The DNS + in fact allows a step by step authority distribution, up to a final + complete delegation, which can be easily controlled at national level + accordingly with national needs and situations. 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 + + + +Allocchio, Bonito, Cole, Giordano & Hagens [Page 6] + +RFC 1664 Internet DNS for Mail Mapping Tables August 1994 + + + 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 RFC1327 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 + RFC1327 mapping rules, 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. + + 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: + + + +Allocchio, Bonito, Cole, Giordano & Hagens [Page 7] + +RFC 1664 Internet DNS for Mail Mapping Tables August 1994 + + + 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 RFC1327 mapping information; + + MAPX400 A element containing the value of + derived from the X.400 part of + the RFC1327 mapping information (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' entry, then will be an X.400 + mail domain name in DNS syntax (see sect. 4.2). When we store a + 'table2' or a 'gate' 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. + +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 RFC1327 + specification for mapping rules. In fact, any RFC1327 mapping table + 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 an RFC1327 entry 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 RFC1327 tables. However an + entry like + + ab.net2.it. IN PX 10 ab.net2.it. O-ab.PRMD-net2.ADMDb.C-it. + + + + +Allocchio, Bonito, Cole, Giordano & Hagens [Page 8] + +RFC 1664 Internet DNS for Mail Mapping Tables August 1994 + + + 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 + RFC1327 original syntax. + + Another extension to the RFC1327 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 RFC1327 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 + 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 RFC1327 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 RFC1327 mapping 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 + + + +Allocchio, Bonito, Cole, Giordano & Hagens [Page 9] + +RFC 1664 Internet DNS for Mail Mapping Tables August 1994 + + + 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 RFC1327 mapping rules (and hence for any X.400 O/R name) + which makes it compatible with a element, i.e., + + ::= | " " + ::=