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/rfc1802.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc1802.txt (limited to 'doc/rfc/rfc1802.txt') diff --git a/doc/rfc/rfc1802.txt b/doc/rfc/rfc1802.txt new file mode 100644 index 0000000..3d27638 --- /dev/null +++ b/doc/rfc/rfc1802.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group H. Alvestrand +Request for Comments: 1802 UNINETT +Category: Informational K. Jordan + Control Data Systems + S. Langlois + Electricite de France + J. Romaguera + NetConsult + June 1995 + + + Introducing Project Long Bud: + Internet Pilot Project for the Deployment of X.500 Directory + Information in Support of X.400 Routing + +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 + + The Internet X.400 community (i.e., GO-MHS) currently lacks a + distributed mechanism providing dynamic updating and management of + message routing information. The IETF MHS-DS Working Group has + specified an approach for X.400 Message Handling Systems to perform + message routing using OSI Directory Services. The MHS-DS approach + has been successfully tested in a number of local environments. + + This memo describes a proposed Internet Pilot Project that seeks to + prove the MHS-DS approach on a larger scale. The results of this + pilot will then be used to draw up recommendations for a global + deployment. + +1. Background + + The 1988 edition of X.400 introduces, among other extensions or + revisions, the concept of O/R Names which assumes the existence of a + widely available Directory Service. This Directory Service is needed + to support several MHS operations (support for names to identify + senders and receivers of messages in a user-friendly fashion, support + for distribution lists, authentication of MHS components, description + of MHS components capabilities...). + + The prime advantage of Directory Names, as perceived by many users, + was to release users from the remembering of complex O/R Addresses + for their correspondents. + + + +Alvestrand, et al Informational [Page 1] + +RFC 1802 Introducing Project Long Bud June 1995 + + + In the MHS infrastructure, as compared to other protocols, a name by + itself does not contain enough information to allow the Message + Transfer Agents (MTAs) to route a message to the User Agent (UA) + servicing this name. The routing process is based on information + provided by different MHS Management Domains, whether they are public + or private. + + An MHS community combines several administrative MHS domains among + which agreements for cooperative routing exist: the GO-MHS community + is the set of MTA's taking care of X.400 mail operations on the + Internet [RFC 1649]. + + In the absence of a distributed Directory Service, an interim + technique has been developed within the GO-MHS community to collect + and advertise routing information. This resulted in an experimental + IETF protocol [RFC 1465]. + +2. Rationale + + A number of routing problems are preventing the present Internet + X.400 service from expanding its number of participating message + transfer agents to a global scale. The two most critical problems + are: + + * The present mechanism of centrally maintained and advertized + MTA routing tables has been optimized as far as possible. + Increasing the number of directly connected MTAs increases also + the workload on the MHS managers. The current solution does + not scale. Routing must be a fully dynamic and distributed + process. + + * Manual propagation and installation of routing tables do not + guarantee consistency of routing information (even in a loose + fashion) when it is accessed by different MTAs scattered across + the globe. + + It is commonly accepted that a distributed mechanism providing for + dynamic updating and management of X.400 routing information is + highly desirable. The focus of the project is to establish X.500- + based support of X.400 routing, at a very large scale. + +3. Benefits + + Using the Directory as a dynamic means of information storage and + advertisement will guarantee participants in Project Long Bud that + their updated data are globally available to the community. As a + direct consequence of the above, a participating MHS manager will be + released from configuring connections to the other participants. + + + +Alvestrand, et al Informational [Page 2] + +RFC 1802 Introducing Project Long Bud June 1995 + + + Directory-capable MTAs will be able to discover more optimal and more + direct routes to X.400 destinations than are practical today. This + will enable faster delivery of messages. + + The infrastructure reliability will be improved: the information + stored in the Directory will allow automatic use of backup + connections in case of remote MTA or network problems. X.400 mail + managers in the GO-MHS Community should then be released from the + need to know the complexity of the whole mail routing infrastructure. + Providing a dynamic routing infrastructure will eliminate + inconsistencies introduced by unsynchronized static tables and + improve quality of service. + + Furthermore, besides the robustness and the optimization of the new + routing infrastructure, the Long Bud approach should bring to the + participating organizations better control over how they establish + and maintain their interconnection with the GO-MHS community. + + Participants will share in building an X.400 network which can expand + to a very large scale. They will develop experience using a global + messaging architecture which scales well and requires minimal + administrative overhead. They will be able to discuss experience + with the MHS-DS experts and architects in the ongoing standards + development cycle. + +4. Definition of project LONG BUD + + The Long Bud pilot wishes to demonstrate that the X.500 Directory is + able to provide a global-scale service to messaging applications. + + Although MHS-DS provides ways to use private routing trees, Long Bud + will focus on the Open Community Routing Tree as used by the GO-MHS + community. + +4.1 Project Goals + + Project Long Bud has the following goals: + + * Gather pilot experience of the defined framework for X.500 + support of MTA routing, as defined by the IETF MHS-DS Working + Group [Kille 94]. + + * Actively investigate migration of the existing operational + X.400 service from a routing method based upon distribution of + centrally maintained static tables, as specified in [RFC 1465], + to a method based instead upon X.500: + + + + + +Alvestrand, et al Informational [Page 3] + +RFC 1802 Introducing Project Long Bud June 1995 + + + -- Deploy X.400 MTAs which are directly capable of reading + routing information from the X.500 Directory, in + compliance with the specifications of the MHS-DS Working + Group. This type of MTA is called a directory-capable + MTA. + + -- Deploy tools which read routing information from the X.500 + Directory and use it to generate static routing tables for + MTAs which are not directory-capable. + + * specify a set of minimal operational requirements needed before + X.500-based routing of X.400 messages can be widely deployed. + +4.2 Phasing + + The first phase of Project Long Bud consists in deploying a small + number of directory-capable MTAs operated by members of the MHS-DS + Working Group and GO-MHS community. These MTAs must be capable of + using information in the X.500 directory to route messages to all + other members of the project as well as to the existing GO-MHS + community. As of this writing, an initial set of MTAs is already + operational. + + At the end of this phase, the following goals should be achieved: + + * The X.500 DIT must be populated with enough routing information + to allow the participating MTAs to route reliably messages to + each other and to the existing GO-MHS community. + + * The X.500 DSAs holding the routing information must operate at + a quality of service that is acceptable for an operational + X.400 service. + + As a prerequisite, a sufficient number of MTA managers must be + willing to participate in Project Long Bud for the first set of + results to be significant. Support for a protocol stack conforming + to [RFC 1006] is mandatory. All MTAs participating in the Long Bud + pilot need to register in the Open Tree and must be prepared to + accept connections from anyone. + + Note that in the first phase, default routes will be established in + the DIT such that messages addressed to destinations outside of the + Long Bud community will be routed to designated MTAs in the GO-MHS + community. This will allow for full connectivity between the Long + Bud community and the GO-MHS community which are related, but + distinct communities. Interworking between these two must be + established and coordinated. + + + + +Alvestrand, et al Informational [Page 4] + +RFC 1802 Introducing Project Long Bud June 1995 + + + In the second phase of Project Long Bud, a greater number of MTAs + should be added to the experiment. Cooperation with non directory- + capable communities must be addressed. + +4.3 General Approach + + No large scale resources have been committed to this project. Yet, + expedient deployment is desirable. Therefore, the pilot project + needs to be focused and relatively short-lived. The general approach + for satisfying these requirements includes: + + * Use as many existing MHS-DS tools as possible. Also, continue + to track the progress of tools being developed by project + members and facilitate their deployment as soon as they are + ready. + + * Coordinate efforts with existing GO-MHS community service. + + * Establish a core infrastructure: 4 DSAs (two in the United + States and two in Europe) are set up to serve MHS-DS + information. + + * Wherever it is technically feasable, DSA managers will + establish bilateral agreements with one (or more) of the core + DSAs in order to duplicate their routing information. For + example, the core DSAs support the replication protocol + specified in [RFC 1275] as a duplication technique. + + * the Long Bud pilot needs to cooperate actively with DANTE + NameFlow (the continuation of the PARADISE Pilot) and other + directory providers in order to promote stability and + consistency of informations. + +4.4 Tools Needed + + To facilitate widespread deployment of MHS-DS routing technology and + to foster interworking between directory-capable MTAs and MTAs which + are not directory-capable, tools providing the following + functionalities need to be developed: + + populate the Directory with routing information: such a tool must + accept routing information specified in the standard syntax + used by the GO-MHS community (see [RFC 1465]) as input, and it + will load or update entries which convey the same information + in the X.500 Directory. + + + + + + +Alvestrand, et al Informational [Page 5] + +RFC 1802 Introducing Project Long Bud June 1995 + + + downloading of routing information from the Directory: in order to + provide a migration path for organizations not using + directory-capable MTAs, a tool is needed which will read X.400 + routing information from the X.500 Directory and generate + static routing information from it. The syntax of the static + information generated will conform to the syntax defined by the + GO-MHS community, so that "classical" MTAs run as they + currently do. + + displaying route taken by a message between two end-points: this + tool should accept two parameters as input: the X.500 + distinguished name of an MTA, and an X.400 O/R name. It will + display the possible routes which may be taken in order to + deliver a message from the specified MTA to the specified X.400 + destination. This tool looks very much the same as the + traceroute facility used at the IP level. + + These tools must use standard protocols to access the Directory (such + as DAP [CCITT 88] or LDAP [RFC 1487]). Portability is encouraged. + + A note on quality + + Pilot use of this Directory information depends heavily on data + quality and availability. Although the administration of DSA + availability and global Directory data accuracy are not in the scope + of Long Bud, care must be taken that Directory resources used by Long + Bud participants are administrated well. + + If they have the technical ability to do so, Long Bud participants + are encouraged to replicate routing information in their Directory to + improve data availability. + + Directory data used by the pilot must be accurate: solutions to this + problem will be recommanded as the project matures. + +5. Participation Guide + + The existing operational X.400 service, the GO-MHS service, uses the + following method to distribute and manage X.400 routing information: + A group of MTAs is organized into a routing community. The community + keeps its routing information up to date by assigning to each MTA + manager the responsibility of determining the routing information for + his/her MTA, formalizing this routing information in the syntax + defined by the community and sending the result to the GO-MHS + coordination service. Once the information has been validated + against the other data provided by all managers in the community, the + coordination service will advertise it to the whole community. Each + manager will then have to update his/her MTA configuration with the + + + +Alvestrand, et al Informational [Page 6] + +RFC 1802 Introducing Project Long Bud June 1995 + + + verified information. + + The purpose of Project Long Bud is to allow a manager to operate an + MTA without having to perform ANY manual steps when another MTA + manager adds new or changes existing routing information. This will + facilitate efficient, dynamic, and manageable interconnection of very + large communities of MTAs. It will allow the Internet X.400 + community to overcome the limitations in scalability which it is + currently encountering. + +5.1 Prerequisites for participation + + The prerequisites for joining Project Long Bud are: + + Step 1: Participants in the pilot must have a good knowledge of + the IETF MHS-DS Working Group activities and documents: + + 1. Participants must join the MHS-DS distribution list: + + RFC-822: mhs-ds@mercury.udev.cdc.com + + X.400: PN=mhs-ds; OU=mercury; OU=OSS; + OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US + + Requests to join the MHS-DS distribution list may be sent + to the following email address: + + RFC-822: mhs-ds-request@mercury.udev.cdc.com + + X.400: PN=mhs-ds-request; OU=mercury; OU=OSS; + OU=ARH; O=CPG; P=CDC; A=ATTMail; C=US + + + 2. Participants must retrieve and become familiar with all + relevant tools and documents stored on the Project Long + Bud anonymous FTP server + + Host name: ftp.css.cdc.com + + Directory: pub/mhs-ds/long-bud + + In particular, openly available software related to Long + Bud activities will be kept up-to-date at this location. + + + + + + + + +Alvestrand, et al Informational [Page 7] + +RFC 1802 Introducing Project Long Bud June 1995 + + + 3. If not already done, participants must do one of the + following: + + * Upgrade their X.400 and X.500 software such that it + supports the MHS-DS specifications as in [Kille 94]. + + * Use the tools which extract MHS-DS information from + the directory and generate whatever local + configuration files are necessary to allow local MTA's + to use the information. This should be done + frequently (at least once per day). + + Step 2: Participants must register required entries in the + Directory so that their MTA(s) is (are) known to the + Directory. + + 1. Arrange with the appropriate DSA Manager (who can be a + local manager if the DSA is run by the participating + organization, or a manager who is in charge of running the + organization's DSA) to create an entry for the local + MTA(s) involved in the pilot. At this stage, only + connection information is required. + + 2. Check, test and verify the connection information with at + least one other participant. The mhs-ds distribution list + should be used for announcing the new registration and + asking volunteers for testing. + + 3. Participants must establish sensible default X.400 routes + to existing GO-MHS destinations for which X.500-based + routing information will not exist initially. + + Step 3: Participants can then enter their routing information in + the Directory. + + 1. Before any routing is entered in the DIT, participants + must check with the GO-MHS Coordination Service that the + routes they want to register can be properly handled by + the GO-MHS community (contact information is + mailflow@mailflow.dante.net). It is crucial for the Pilot + that any routing information entered in the Directory is + kept carefully accurate if the experiment is to be + meaningful. Participants may also consider the need for + mapping rules (see [RFC 1465] for details). + + 2. Once the above step is validated by the GO-MHS + Coordination Service, participants must record routing + information for their MTA(s) in the Internet X.500 + + + +Alvestrand, et al Informational [Page 8] + +RFC 1802 Introducing Project Long Bud June 1995 + + + directory service. This requires that a participant does + the following: + + * Arrange with the appropriate DSA Manager (who can be + either a local manager if the DSA is run by the + participating organization or a manager which is in + charge of running the organization's DSA) to enter + X.400 routing information in a routing tree held by + the participating organization. This routing tree + should contain all necessary information for the local + mail domain. + + * Check, test and verify the registered routing + information with at least one other participant. The + mhs-ds distribution list should be used for announcing + the new registration and asking volunteers for + testing. + + 3. If a participant adds new nonleaf entries to the Open + Community Routing Tree, then s/he must find at least one + other participant who will maintain a slave copy of the + children of the nonleaf entry. Send email to the mhs-ds + distribution list in order to find a partner who is + willing to do this. + + 4. If a participant adds new nonleaf ADMD or PRMD entries to + the directory, then s/he must contact the managers of the + Long Bud core DSA's and arrange to provide slave copies of + the children of the ADMD and/or PRMD entries to all of the + core DSA's. Send email to the mhs-ds distribution list in + order to contact the core DSA managers. + + 5. Once the above testing is completed, send email to the + mhs-ds distribution list announcing the establishment of + new X.500-based routes. + +6. Notes on side effects + + The Long Bud Pilot Project, with its specific scope, is investigating + a new direction in X.500 service usage. This should facilitate and + expedite the global deployment of X.500 on the Internet. + + Once the routing infrastructure illustrated by the Long Bud + experiment is in place, the routing process will be able to take into + account additional information to improve quality of service + (minimizing messages conversions, enforcing various security policies + established by MHS domains, taking advantage of recipients's + capabilities stored in the Directory, ...). While the Open Tree + + + +Alvestrand, et al Informational [Page 9] + +RFC 1802 Introducing Project Long Bud June 1995 + + + provides global connectivity, multiple private routing trees allow + the use of various routing trees. + +7. Acknowledgements + + The authors would like to thank Urs Eppenberger (SWITCH) and Allan + Cargille (University of Wisconsin) for their constructive comments on + earlier drafts of this document. + +References + + [CCITT 88] International Telegraph and Telephone + Consultative Committee. X.500 Recommendations + series. December 1988. + + [RFC 1649] Hagens, R., and A. Hansen, "Operational + Requirements for X.400 Management Domains in the + GO-MHS Community", RFC 1649, ANS, UNINETT, + July 1994. + + [Kille 94] Kille, S., "MHS Use of the X.500 Directory to + Support MHS Routing", RFC 1801, ISODE Consortium, + June 1995. + + [RFC 1006] Rose, M., and D. Cass, "ISO Transport Service on + top of the TCP Version: 3", STD 35, RFC 1006, + Northrop Research and Technology Center, + May 1987. + + [RFC 1275] Hardcastle-Kille, S., "Replication Requirements + to provide an Internet Directory using X.500", + RFC 1275, University College London, + November 1991. + + [RFC 1465] Eppenberger, U., "Routing Coordination for X.400 + MHS Services Within a Multi Protocol / Multi + Network Environment Table Format V3 for Static + Routing", RFC 1465, SWITCH, May 1993. + + [RFC 1487] Yeong, W., Howes, T., and S. Kille, "X.500 + Lightweight Directory Access Protocol", + RFC 1487, Performance Systems International, + University of Michigan, ISODE Consortium, + July 1993. + + + + + + + +Alvestrand, et al Informational [Page 10] + +RFC 1802 Introducing Project Long Bud June 1995 + + +8. Security Considerations + + Security issues are not discussed in this memo. + +Authors' Addresses + + Harald T. Alvestrand + UNINETT + P.O. box 6883 Elgeseter + N-7002 Trondheim, Norway + + Phone: +47-73-59-70-94 + EMail: Harald.T.Alvestrand@uninett.no + + + Kevin E. Jordan + Control Data Systems, Inc. + 4201 Lexington Avenue North + Arden Hills, MN 55126, USA + + Phone: +1-612-482-6835 + EMail: Kevin.E.Jordan@cdc.com + + + Sylvain Langlois + Electricite de France + Direction des Etudes et Recherches + 1, avenue du General de Gaulle + 92141 Clamart Cedex, France + + Phone: +33-1-47-65-44-02 + EMail: Sylvain.Langlois@der.edf.fr + + + James A. Romaguera + NetConsult AG + Morgenstrasse 129 3018 Bern, Switzerland + + Phone: +41-31-9984141 + EMail: Romaguera@NetConsult.ch + X.400: S=Romaguera;O=NetConsult;P=switch;A=arcom;C=ch + + + + + + + + + + +Alvestrand, et al Informational [Page 11] + -- cgit v1.2.3