home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-exp-rupp-03.txt < prev    next >
Text File  |  1997-09-16  |  24KB  |  623 lines
  1.  
  2. INTERNET DRAFT        EXPIRES MARCH 1998    INTERNET DRAFT
  3.  
  4. Network Working Group                                     Heiko W.Rupp
  5. Request for Comments: nnnn
  6. Experimental                                                16.09.1997
  7.  
  8.  
  9.          A Protocol for the Transmission of Net News Articles
  10.                            over IP multicast
  11.                  <draft-rfced-exp-rupp-03.txt> 
  12.  
  13. Status of This Memo
  14.  
  15. This document is an Internet-Draft.  Internet-Drafts are working
  16. documents of the Internet Engineering Task Force (IETF), its
  17. areas, and its working groups.  Note that other groups may also
  18. distribute working documents as Internet-Drafts.
  19.  
  20. Internet-Drafts are draft documents valid for a maximum of six
  21. months and may be updated, replaced, or obsoleted by other
  22. documents at any time.  It is inappropriate to use Internet-
  23. Drafts as reference material or to cite them other than as
  24. "work in progress."
  25.  
  26. To learn the current status of any Internet-Draft, please check
  27. the "1id-abstracts.txt" listing contained in the Internet-
  28. Drafts Shadow Directories on ftp.is.co.za (Africa),
  29. nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  30. ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  31.  
  32. Distribution of this document is unlimited.
  33.  
  34.  
  35. Abstract
  36.  
  37.    Mcntp (Multicast News Transfer Protocol) provides a way to use the IP
  38.    multicast infrastructure to transmit NetNews articles between news
  39.    servers. Doing so will reduce the bandwidth that is actually needed
  40.    for transmission of articles which is mostly done via NNTP. This does
  41.    not affect how news reading clients communicate with servers.
  42.  
  43. Overview and Rationale
  44.  
  45.    NetNews are bulk data that are produced in large quantities every day
  46.    around the world. Distribution of NetNews on the Internet are usually
  47.    distributed with NNTP[1]. In order to get a fast and redundant
  48.    distribution many news servers communicate with many others, thus
  49.    imposing a higher load on the underlying network than necessary.
  50.  
  51.    Assume the following scenario:
  52.  
  53.                              +---------  R1
  54.                             /
  55.              S -- A ------- B  --------  R2
  56.                             \
  57.                               +--------- R3
  58.  
  59.    A sender S which wants to transmit articles via NNTP to receivers
  60.    R1...R3 will thus transmit them three times across the link from A to
  61.    B.
  62.  
  63.    With IP Multicast[2], an efficient way to distribute datagrams to
  64.    groups of users exists in the Internet. Thus articles would traverse
  65.    the link A to B only once, thus reducing load on that link.
  66.  
  67.    This cannot be done with existing news transfer technology, as it is
  68.  
  69.  
  70.  
  71. Rupp                                                            [Page 1]
  72.  
  73.  
  74. I/D               NETNEWS OVER IP MULTICAST       16 September 1997
  75.  
  76.  
  77.    based on TCP[10] which cannot be multicasted.  The protocol described
  78.    in this memo is designed to put news articles into datagrams and
  79.    distribute them via IP multicast to receivers that are interested in
  80.    the specific newsgroup. For more information about NetNews, refer to
  81.    [7] and [1].
  82.  
  83. Protocol overview
  84.  
  85.    This paragraph will show how news articles are propagated with Mcntp.
  86.    Basically, three parties are involved:
  87.  
  88.  
  89.    +    Multicast directory service, MD, coordinates the assignment
  90.         between multicast and news groups.
  91.  
  92.    +    A Multicast sender, MS, that sends news articles over an
  93.         IP multicast infrastructure
  94.  
  95.    +    A Multicast receiver, MR, gets packets from the IP multicast
  96.         infrastructure and processes them further.
  97.  
  98.    So this can be seen as follows:
  99.  
  100.                directory       +---------+    directory
  101.              +------------- >  |         | ----------------+
  102.             \|/                |   MD    |                \|/
  103.          +---------+           |         |             +--------+
  104.          |         |           +---------+             |        |
  105.          |   MS    |                                   |   MR   |
  106.          |         | ------------ articles ------->    |        |
  107.          +---------+                                   +--------+
  108.  
  109.    MS and MR can be implemented into existing news server software, or
  110.    can be implemented as separate processes that communicate with the
  111.    news servers (e.g. via NNTP); this does not matter to the protocol.
  112.  
  113.    MD can either be implemented within MS, or as separate processes that
  114.    communicate with each other. A practical way is to have on MD per
  115.    sender host so that communication between MD and MS is fast and
  116.    reliable, while not too many resources are needed.
  117.  
  118.    The protocol itself consist of two parts that will be presented in
  119.    the next two chapters -- Distribution of articles and the directory
  120.    service.
  121.  
  122. Packet format -- Distribution of articles
  123.  
  124.    To send articles via IP multicast, they have to be encapsulated into
  125.  
  126.  
  127.  
  128. Rupp                                                            [Page 2]
  129.  
  130.  
  131. I/D               NETNEWS OVER IP MULTICAST       16 September 1997
  132.  
  133.  
  134.    UDP packets. The following diagram shows how this can be done:
  135.  
  136.          +---------------------------------------+
  137.          |                 Magic                 |
  138.          +----+----+----+----+---------+---------+
  139.          | Ver|Rev |Comp|Cryp|Reserved |  Offset |
  140.          +----+----+----+----+---------+---------+
  141.          |            Original length            |
  142.          +---------------------------------------+
  143.          |             Length as sent            |
  144.          +---------------------------------------+
  145.          |               Sender-ID               |
  146.          +---------------------------------------+
  147.          |              Message-id               |
  148.          +---------------------------------------+
  149.          |               Data                    |
  150.          +---------------------------------------+
  151.  
  152.    All entries are in network byte order.  The fields have the following
  153.    meaning and types:
  154.  
  155.  
  156.     +    Magic (32-bit): The String ``McNt''
  157.  
  158.     +    Ver (4-bit): Protocol version -- currently 1
  159.  
  160.     +    Rev (4-bit): Protocol revision -- currently 1
  161.  
  162.     +    Comp (4-bit): Compression method used. Currently are only 2
  163.          methods defined:
  164.  
  165.           0    Article is not compressed
  166.  
  167.           1    Article is compressed via zlib [8]
  168.  
  169.     +    Cryp (4-bit): Encryption method used. See below
  170.  
  171.     +    Reserved (8-bit): Reserved for future extensions.
  172.  
  173.     +    Offset (8-bit): Offset of article data from packet start
  174.  
  175.     +    Original length (32-bit): Length of article before compression,
  176.          encryption and signing.
  177.  
  178.     +    Length as sent (including digital signature) (32-bit): Size of
  179.          the ``Data'' field (see below)
  180.  
  181.     +    Sender-ID: Identification of the sender host terminated by a
  182.  
  183.  
  184.  
  185. Rupp                                                            [Page 3]
  186.  
  187.  
  188. I/D               NETNEWS OVER IP MULTICAST       16 September 1997
  189.  
  190.  
  191.          null byte (see below).
  192.  
  193.     +    Message-ID: The message id of the article in the form it is
  194.          defined in RFC 1036 [7], terminated by a null byte.
  195.  
  196.     +    Data: The signed article data after possible compression and
  197.          encryption.
  198.  
  199.    This memo does not specify a encryption method for the case that the
  200.    field ``Crypt'' is set to anything other than 0; the involved parties
  201.    (i.e. the senders of encrypted news and their receivers) have to
  202.    agree on a method they want to use. If encryption and compression is
  203.    used then the article data is first to be compressed and then the
  204.    result to be encrypted.
  205.  
  206.    All articles must be signed before sending them off the net. This is
  207.    accomplished by running the RIPEMD-160 message digest [11] algorithm
  208.    over the (possibly compressed and encrypted) article and then RSA-
  209.    encrypting the message digest with the private key that is suitable
  210.    for sender-id.  The receiver decrypts the signature of the article
  211.    with the public key of sender-id and runs RIPEMD-160 over the data to
  212.    see if it has been altered on the way. An article with an invalid
  213.    signature or a non matching message digest has to be thrown away. The
  214.    sender-id can be the path entry or the hostname of the sending site;
  215.    there can also be more than one key pair per site e.g. to have
  216.    different keys for different newsgroups.  The sender-id has to be
  217.    treated in a case independent manner.
  218.  
  219.    Encryption of the message digest is done the following way. The 20
  220.    Bytes RIPEMD-160 message digest and the first 28 bytes of the
  221.    (possibly compressed and encrypted) message are tacked together to
  222.    form a 48 Bytes buffer. This buffer is then encrypted with the right
  223.    RSA private key and prepended to the original message without the
  224.    first 28 bytes:
  225.  
  226.          +----------------+---------------------------------+
  227.          | Message digest | message                         |
  228.          +----------------+-----------+---------------------+
  229.                            1         28                     n
  230.          |                    \
  231.  
  232.          +-----------------------+----------------------------------+
  233.          | Signature             |  message without first 28 Bytes  |
  234.          +-----------------------+----------------------------------+
  235.  
  236.    To send an article off, it is encapsulated and then just sent to the
  237.    appropriate multicast group. There is no feedback from the receiver
  238.    to the sender when an article is received.
  239.  
  240.  
  241.  
  242. Rupp                                                            [Page 4]
  243.  
  244.  
  245. I/D               NETNEWS OVER IP MULTICAST       16 September 1997
  246.  
  247.  
  248. Directory service
  249.  
  250.    In order to get a relation between newsgroups and multicast groups, a
  251.    directory service exists; this has been referenced as MD above.  When
  252.    a sender MS wants to propagate a news group, it asks the directory
  253.    service for a multicast group it can use to distribute articles,
  254.    waits for the reply, and starts to send. The directory server
  255.    registers this group in its tables and periodically distributes this
  256.    table over IP multicast. For this purpose, the multicast group
  257.    ``mcntp-directory.mcast.net'' has been officially been assigned by
  258.    the IANA. The UDP port which announcements are sent to, has
  259.    officially been assigned by the IANA as UDP port number 5418 with the
  260.    name ``mcntp''.
  261.  
  262.    Announcements should not be sent too often to keep traffic low, but
  263.    often enough that new receivers don't have to wait to long to be able
  264.    to receive articles. Once a minute is assumed to be a good value
  265.    here.  Announcements can be sent less often if they are transmitted
  266.    immediately after a change in the directory.
  267.  
  268.    If more than one directory server is involved (e.g. if there is more
  269.    than one sender site), the directory servers have to listen to
  270.    announcement packets on ``mcntp-directory.mcast.net''. If it does not
  271.    receive a packet after five times the waiting period (e.g., five
  272.    minutes) it can consider itself alone on the net and can choose the
  273.    multicast groups as it wishes. See below on usage scenarios which
  274.    further explain this.
  275.  
  276.    Groups that are local to an organisation (e.g. an ISP) or should stay
  277.    within their bounds, must be transported within the range of the
  278.    administratively scoped multicast addresses [12].
  279.  
  280.    When a receiver (MR) wants to receive a newsgroup, it listens on
  281.    ``mcntp-directory.mcast.net'' for announcements, parses them, and
  282.    then joins the appropriate multicast groups.
  283.  
  284.    Multicast groups that are no longer in use (e.g. because the sender
  285.    has stopped working) must be removed from the announcement.
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299. Rupp                                                            [Page 5]
  300.  
  301.  
  302. I/D               NETNEWS OVER IP MULTICAST       16 September 1997
  303.  
  304.  
  305.    The format of those announcement packets is:
  306.  
  307.          +-----------+------+-----+--------+
  308.          |   Magic   | Vers | Rev | Offset |
  309.          +-----------+------+-----+--------+
  310.          |             Length              |
  311.          +---------------------------------+
  312.          |            rmd160               |
  313.          +---------------------------------+------+
  314.          |            Sender-ID            | pad1 |
  315.          +-----------------+------+---+-----------+---+      -+
  316.          | Multicast group | Port |TTL| Newsgroup |pad|       |
  317.          +-----------------+------+---+-----------+---+       |
  318.           ...  repeat ...                                     |  NG lines
  319.          +-----------------+------+---+-----------+---+       |
  320.          | Multicast group | Port |TTL| Newsgroup |pad|       |
  321.          +-----------------+------+---+-----------+---+      -+
  322.  
  323.    All numbers are in network byte order.  The fields have the following
  324.    meaning and types:
  325.  
  326.  
  327.        +    Magic (16-bit): The Bytes 0xabba.
  328.  
  329.        +    Vers (4-bit): Protocol version (see below).
  330.  
  331.        +    Rev (4-bit): Protocol revision (currently 1).
  332.  
  333.        +    Offset (8-bit): Offset of NG-lines from packet start.
  334.  
  335.        +    Length (32-bit): Total packet length.
  336.  
  337.        +    rmd160 (160-bit): RIPEMD-160 message digest over the rest of
  338.             the packet.
  339.  
  340.        +    Sender-ID  : Identification of sender host, terminated by a
  341.             null byte (see below).
  342.  
  343.        +    Pad1: Padding to next 4-Byte boundary filled with null
  344.             bytes.
  345.  
  346.        +    Multicast group (32-bit *): The associated multicast group.
  347.  
  348.        +    Port (16-bit): UDP Port to use for this group.
  349.  
  350.        +    TTL (8-bit): Time to live for multicast packets.
  351.  
  352.        +    Newsgroup: Name of the Newsgroup(s), terminated by a null
  353.  
  354.  
  355.  
  356. Rupp                                                            [Page 6]
  357.  
  358.  
  359. I/D               NETNEWS OVER IP MULTICAST       16 September 1997
  360.  
  361.  
  362.             byte. See also below.
  363.  
  364.        +    Pad: Padding of the string to the next 4-bytes boundary
  365.             filled with null bytes.
  366.  
  367.    The protocol version (Vers) is currently 1 for IPv4 and 11 for IPv6.
  368.    The multicast group field (*) is 32 bit in size for IPv4 and 128-bit
  369.    for IPv6 in size.
  370.  
  371.    The length field is 32 bit in size to support IPv6 jumbo datagrams.
  372.  
  373.    The sender-ID is normally the fully qualified domain name of the
  374.    hosts that sends the announcement. As is common practice with
  375.    NetNews, this can also be the (possibly shorter) entry that the host
  376.    puts in the ``Path:'' header when an article passes through it. This
  377.    entry has to be treated in a case independent manner.
  378.  
  379.    The rmd160 is computed over the sender-id field and all lines with
  380.    newsgroup to multicast group relations in the packet with the
  381.    RIPEMD-160 message digest algorithm.
  382.  
  383.    The lines with newsgroup to multicast group relations are repeated as
  384.    often as needed to announce all groups. The TTL can be used by
  385.    clients to find out if packets that come from this source can reach
  386.    them, or if the sender is too far away.  Note that all entries have
  387.    to fit into one UDP packet.
  388.  
  389.    The sender-id and the newsgroups entries are padded to the next
  390.    4-bytes boundary in order to make processing easier.
  391.  
  392.    TTL values of articles have to be chosen, especially for use on the
  393.    MBONE, in a way that newsgroups that are only of local relevance
  394.    (e.g. campus groups or groups local to a town) are not distributed
  395.    out of their normal distribution area. As already mentioned above,
  396.    articles that are only of a local meaning or of local relevance, must
  397.    be distributed within the administratively scoped group range [12].
  398.  
  399.    The relation between multicast and newsgroups can range from one
  400.    multicast group per newsgroup over one multicast group per news
  401.    hierarchy (e.g. comp.*) to all articles in only one group. As current
  402.    implementations of kernels and routers get inefficient with too many
  403.    multicast groups, the use of one multicast group per newsgroup is
  404.    deprecated.
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413. Rupp                                                            [Page 7]
  414.  
  415.  
  416. I/D               NETNEWS OVER IP MULTICAST       16 September 1997
  417.  
  418.  
  419. Reliability Considerations
  420.  
  421.    As UDP is a unreliable service, provisions for reliable distribution
  422.    of articles are needed. There exist some approaches to reliable
  423.    multicast (XTP [4], KLG [5] RMTP [6] and others) which all suffer
  424.    from some problem or other. Specifically, additional hard- or
  425.    software is needed and usually requires kernel modification.
  426.  
  427.    As there is already a reliable transport of NetNews via NNTP, there
  428.    is no need for a reliable transport via IP multicast: articles need
  429.    not be in order, so it is no problem if one is missing in the
  430.    multicast. Since articles need not arrive in order, lost or missing
  431.    articles can easily be transmitted via an additional NNTP feed.
  432.  
  433.    As UDP packets can be at maximum 64kBytes in size and every Mcntp
  434.    packet has to fit in one UDP packet, there is no provision given to
  435.    distribute news articles larger than about 63kBytes in size (other
  436.    than compressing them). This does not matter much in practise as
  437.    recent research has shown that more than 95% off all news articles
  438.    are smaller 64kBytes [9]. The remaining 5% can still be transferred
  439.    via NNTP. Some hosts may have problems in receiving UDP packets as
  440.    large as 64kBytes, so in practical use article sizes of 16kBytes
  441.    would be appropriate. These are still over 90% of all articles.
  442.  
  443. Usage Scenarios
  444.  
  445.    These scenarios show how mcntp can be used in daily use. The main
  446.    difference between local and MBone wide usage are the multicast
  447.    groups that are used for distribution as stated above.
  448.  
  449.    For a local use within an organisation there could be one central
  450.    sending site that redistributes all news articles it receives via
  451.    mcntp. No further action is needed.
  452.  
  453.    When more than one directory server (MD) gets involved, directory
  454.    servers must wait on startup for announcement packets from other MD
  455.    processes, register the contained groups in its tables and make
  456.    decisions involving that tables. Decisions can be divided into the
  457.    following:
  458.  
  459.    Use
  460.  
  461.       If the group in which the sender (MS) wants to send is already
  462.       distributed over multicast, then the articles are distributed in
  463.       the existing group else a new multicast group is used. For
  464.       example:  if de.* is already distributed over multicast group
  465.       a.b.c.d then use that group.
  466.  
  467.  
  468.  
  469.  
  470. Rupp                                                            [Page 8]
  471.  
  472.  
  473. I/D               NETNEWS OVER IP MULTICAST       16 September 1997
  474.  
  475.  
  476.    New
  477.  
  478.       Always create own multicast groups that don't clash with the ones
  479.       that are already existing. For example: if comp.* is already
  480.       distributed on group a.b.c.e and the sender (MS) wants to
  481.       distribute comp.foo, don't use group a.b.d.e, but create a new
  482.       one.
  483.  
  484.    Standby
  485.  
  486.       Only send articles for a specified newsgroup when no one other is
  487.       doing it.  This can be used to implement backup functionality. For
  488.       example: Sender A is sending comp.*. If now a directory packet
  489.       arrives at site B, which no longer has comp.* in it, B can start
  490.       to send comp.*. When it sees again announcements from A, then it
  491.       stops the distribution of comp.*.
  492.  
  493.    For use in an environment, where multiple organisations are involved
  494.    (e.g. on the MBone), the following could deployed: everyone that is
  495.    participating utilizes the ``use'' method described above. It only
  496.    sends articles that are locally produced (e.g. customers) and which
  497.    are not distributed via mcntp by another site. No articles received
  498.    from news peers should be distributed that way. After some delay (at
  499.    least 10 seconds), articles which are distributed via mcntp are
  500.    offered to peers over nntp as usual.  The set of groups that is
  501.    distributed must be negotiated between the involved organisations.
  502.    With the current Usenet groups this could be:
  503.  
  504.          - rec.*
  505.          - comp.*,news.*,gnu.*
  506.          - talk.*,misc.*
  507.          - humanities.*,sci.*,soc.*
  508.          - alt.*
  509.  
  510. Summary
  511.  
  512.    The distribution of NetNews articles via IP multicast can be a way to
  513.    decrease the network bandwidth used to distribute them.  Articles are
  514.    delivered fast via a nonreliable protocol; later, the holes are
  515.    filled via a reliable, already existing protocol. Compression of
  516.    articles can further reduce the network Load. With encryption private
  517.    news groups can be established on a public IP multicast
  518.    infrastructure. A prototype of a reference implementation already
  519.    shows that Mcntp is fast and can be used as an alternative to
  520.    classical transports. The use of zlib for compressing articles shows
  521.    a reduction of transferred volume (including protocol headers) to
  522.    about 65% of the original article volumes..
  523.  
  524.  
  525.  
  526.  
  527. Rupp                                                            [Page 9]
  528.  
  529.  
  530. I/D               NETNEWS OVER IP MULTICAST       16 September 1997
  531.  
  532.  
  533. Security Considerations
  534.  
  535.    With the classical NNTP based distribution, every host on the path of
  536.    an article keeps track of it in the logfiles, making it possible to
  537.    find the sender of forged or abusive articles with the aid of the
  538.    administrators of the newshosts along the path.  For the distribution
  539.    of NetNews over IP multicast, this is no longer true: routers don't
  540.    log packets flowing by and as the sender address of IP packets can be
  541.    forged, a sender can't be traced. This fact can be used to inject
  542.    forged news articles without being traceable.
  543.  
  544.    To prevent the unnoticed injection of articles, a mcntp receiver only
  545.    accepts articles from senders that it trusts. This trust is build by
  546.    digitally signing the article with the private key of the sender and
  547.    verifying the signature at the receiver site.  Receivers have to
  548.    accept only articles with good signatures
  549.  
  550.    The RIPEMD-160 message digest algorithm has been chosen, as it is
  551.    more secure than MD5 while still being fast enough. The RSA
  552.    encryption algorithm has been chosen as there exist reference
  553.    implementations for usage inside US (from RSA Inc.) and outside
  554.    (rsaeuro by J.S.A.Kapp).
  555.  
  556.    The key size for the RSA algorithm must be at least 512 bit in size
  557.    to prevent cracking of the key.
  558.  
  559. References
  560.  
  561.  
  562. [1]  RFC 977 -- B. Kantor, P. Lapsley, "Network News Transfer Protocol:
  563.      A Proposed Standard for the Stream-Based Transmission of News".
  564.  
  565. [2]  RFC 1112 -- S. Deering, "Host extensions for IP multicasting",
  566.      08/01/1989.
  567.  
  568. [3]  RFC 768 -- J. Postel, "User Datagram Protocol", 08/28/1980.
  569.  
  570. [4]  XTP -- W. T. Strayer, D.J. Dmepsey, B.C. Weaver, "XTP: The Xpress
  571.      Transfer Protocol", Addison-Wesley
  572.  
  573. [5]  KLG -- M. Hofmann, "Zuverlaessige Kommunikation in heterogenen
  574.      Netzen", Thesis at "Institut fuer Telematik, CS Dept. Univ
  575.      Karlsruhe"
  576.  
  577. [6]  RMTP -- Lin, John C., Paul Sanjoy, "RMTP: A Reliable Multicast
  578.      Transport Protocol".
  579.  
  580.  
  581.  
  582.  
  583.  
  584. Rupp                                                           [Page 10]
  585.  
  586.  
  587.  
  588.  
  589.  
  590. I/D               NETNEWS OVER IP MULTICAST       16 September 1997
  591.  
  592.  
  593. [7]  RFC 1036 -- M. Horton, R. Adams, "Standard for interchange of
  594.      USENET messages", 12/01/1987.
  595.  
  596. [8]  RFC 1950 -- L. Deutsch, J. Gailly, "ZLIB Compressed Data Format
  597.      Specification version 3.3", 05/23/1996.
  598.  
  599. [9]  http://www.xlink.net/~hwr/histo/ -- Some Statistics about size
  600.      distribution of NetNews
  601.  
  602. [10] RFC 793 -- J. Postel, "Transmission Control Protocol", 09/01/1981.
  603.  
  604. [11] H. Dobbertin, A. Bosselaers, B. Preneel, "RIPEMD-160: A
  605.      Strengthened Version of RIPEMD" 04/18/1996. An earlier version
  606.      appeared in "Fast Software Encryption,LNCS 1039" Springer Verlag,
  607.      1996, pp. 71-82.
  608.  
  609. [12] [draft-ietf-mboned-admin-ip-space-04.txt/number of rfc] David
  610.      Meyer, "Administratively Scoped IP Multicast", [date of rfc]
  611.  
  612. Author's Address
  613.  
  614.    Heiko W.Rupp
  615.    Gerwigstr. 5
  616.    D-76131 Karlsruhe
  617.  
  618.    Phone: +49 721 9661524
  619.  
  620.    EMail: hwr@pilhuhn.de
  621.  
  622. INTERNET DRAFT        EXPIRE MARCH 1998    INTERNET DRAFT
  623.