Internet DRAFT - draft-hessing-p2p-messaging

draft-hessing-p2p-messaging







                                                         Steven Hessing 

                                                             April 2002 

   Internet-Draft                                                       

   Document: draft-hessing-p2p-messaging-00.txt                         

   Expires: October 2002                                                

    

    

                  Peer to Peer Messaging Protocol (PPMP) 

    


  Status of this Memo 

   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [1]. 

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that      
   other groups may also distribute working documents as Internet-
   Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as 'work in progress.' 

   The list of current Internet-Drafts can be accessed at 

        http://www.ietf.org/ietf/1id-abstracts.txt 

   The list of Internet-Draft Shadow Directories can be accessed at 

        http://www.ietf.org/shadow.html. 


  Copyright Notice 

   Copyright (C) The Internet Society (2002). All Rights Reserved. 




     

    
draft-hessing-p2p-messaging-00.txt                          April 2002 

  Abstract 

   The Peer to Peer Messaging Protocol supports the creation of 
   scalable, extensible and secure Peer to Peer networks leveraging 
   current practices and introducing new concepts to P2P networking 
   such as the support of multiple communities, security and 
   multicasting. The protocol is highly extensible to allow for the 
   development of additional features and applications for p2p 
   networks. 


  Table of Contents 
   1.    Overview.....................................................3 
   2.    Conventions used in this document............................4 
   3.    Introduction.................................................4 
   4.    Messages.....................................................5 
      4.1. PPMP header................................................9 
      4.2. Checksum header...........................................11 
      4.3. Message Length header.....................................12 
      4.4. Cease header..............................................12 
      4.5. Path header...............................................13 
      4.6. Path Record header........................................14 
      4.7. Connection header.........................................15 
      4.8. Authentication header.....................................16 
      4.9. Encryption header.........................................16 
      4.10. Error header.............................................17 
   5.    Message forwarding..........................................18 
      5.1. Broadcasting..............................................19 
      5.2. Routed....................................................20 
      5.3. Fully Specified Path......................................21 
      5.4. Multicasting..............................................21 
   6.    Security profiles...........................................22 
      6.1. Requirements for joining a community......................22 
      6.2. Security for the transport of messages....................23 
         6.2.1. Segment security.....................................23 
         6.2.2. Path security........................................24 
      6.3. Data security.............................................25 
   7.    Connection setup and maintenance............................25 
      7.1. Bidirectional Connections.................................27 
         7.1.1. Establishing a bi-directional transport connection...27 
         7.1.2. Negotiate bi-directional connection parameters.......28 
         7.1.3. Negotiate supported forwarding mechanisms for bi-
         directional connections.....................................29 
         7.1.4. Breaking bi-directional connection collision.........30 
         7.1.5. Keepalive messages for bi-directional connections....31 
      7.2. Multicast, unidirectional connections.....................32 

     

   Hessing   Individual submission - Expires October 2002            2 
draft-hessing-p2p-messaging-00.txt                          April 2002 

         7.2.1. Multicast Session Announcement header................32 
         7.2.2. Multicast Session Report header......................33 
         7.2.3. Sequence header......................................34 
         7.2.4. Forwarding messages over multicast transport.........34 
   8.    Communities.................................................35 
      8.1. Community Announcements...................................36 
      8.2. Community Description header..............................37 
      8.3. Community Authorization header............................40 
   9.    Out-of-band Data Transport..................................40 
   10.   Capabilities................................................41 
      10.1. Ping capability..........................................42 
      10.2. Pong capability..........................................42 
      10.3. Servent Discovery capability.............................42 
      10.4. Hello capability.........................................42 
      10.5. Connection Advise capability.............................43 
      10.6. Community Discovery capability...........................44 
      10.7. Community Invitation capability..........................45 
      10.8. XML Query capability.....................................46 
      10.9. XML Response capability..................................46 
      10.10. Resource Push Request capability........................47 
      10.11. Algorithm Request capability............................48 
      10.12. Algorithm Response capability...........................48 
      10.13. Dataset Request capability..............................49 
      10.14. Dataset Response capability.............................49 
      10.15. Dataset Result capability...............................50 
      10.16. Chat capability.........................................51 
   11.   Network management..........................................51 
   12.   Security considerations.....................................52 
   13.   IANA Considerations.........................................53 
   14.   References..................................................55 
   15.   Author's Address............................................56 
   16.   Full Copyright Statement....................................56 


  1. Overview 

   This document describes a protocol for the exchange of messages 
   between systems participating in a peer to peer (P2P) network. A 
   system participating in such a network is called a servent. The 
   protocol introduces the concepts of the addressing of servents and 
   the forwarding of messages in the P2P network between servents using 
   either unicast or multicast transport.  

   The protocol supports the membership of servents of one or more 
   communities with each community supporting one or more applications. 


     

   Hessing   Individual submission - Expires October 2002            3 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   Each application consists of a set of capabilities and a number of 
   services provided from outside the P2P network. 

   The protocol supports the specification of requirements for a 
   servent to join a community and supports for authentication and 
   encryption of messages on the P2P network both on a hop-by-hop and 
   on an end-to-end basis. 

   Finally the protocol references a number of unicast and multicast 
   protocols to be used to exchange bulk data between servents without 
   making use of the p2p network. 


  2. Conventions used in this document 

   The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 
   'SHOULD', 'SHOULD NOT', 'RECOMMENDED',  'MAY', and 'OPTIONAL' in 
   this document are to be interpreted as described in RFC 2119 [2]. 


  3. Introduction 

   In a P2P network, the key elements are servents and messages. 
   Servents send each other messages to perform functions. This 
   protocol introduces three separate layers in such a message. The 
   first layer provides for the addressing of servents and the 
   forwarding of messages, the second layer provides for the security 
   of messages while they are being transported through the p2p network 
   and the third layer supports application functionality.  

   Servents can only exchange messages with each other if there is a 
   direct connection between the two servents or they have connections 
   to other servents that can forward the message between the source 
   and destination servent. Two servents that have a direct connection 
   to each other are called peers.  

   This protocol introduces to P2P technology the concept of multiple 
   communities. A community is a group of systems that have a common 
   goal for using P2P technology. A community is defined by its 
   security profile and its supported applications. The security 
   profile describes how systems can join the community and what 
   requirements exist for the transport of messages and data between 
   the systems in the community. Applications are a combination of a 
   set of capabilities and zero or more services. A capability is a 
   functionality to be performed by one or more servents. A service is 
   some functionality that is provided by a system outside of a p2p 
   network, without using this p2p protocol.  

   Communities can be either well-known or dynamically created. Well-
   known communities are registered with IANA. Dynamically created 

     

   Hessing   Individual submission - Expires October 2002            4 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   communities are announced by servents to each other using connection 
   management messages. There are two well-known communities defined in 
   this document. There is the special-purpose connection management 
   community and the network management community. Implementations of 
   this document MUST support the former and SHOULD support the latter 
   community, next to any other community that the implementation 
   supports. Having servents that are members of different communities 
   share one network management community will allow for community 
   interaction, greater network interconnectivity and more 
   opportunities for optimalisation of the P2P network. 

   This protocol introduces a number of specifications for each of the 
   three message layers. It only describes a basic set of 
   functionalities for each of the three layers. It is anticipated that 
   other documents will provide additional specifications and build 
   upon the protocol foundation provided in this document. 


  4. Messages 

   Messages are used when one servent (the source servent) sends 
   information, a request or a response to another servent (the 
   destination servent) using one of the capabilities that are 
   supported by a community that both servents are a member of. 

   Servents establish connections to each other using a connection 
   setup mechanism described in the section 'Connection setup'. Two 
   directly connected servents are called peers. When a servent sends a 
   message to a destination servent that is not directly connected to 
   it via intermediate servents then these other servents SHOULD 
   forward the message until it reaches the destination servent. 
   Sourcing or forwarding a message to a servent is only allowed if the 
   servent that the message is being sent or forwarded to (the next-hop 
   servent) is member of the same community as specified in the 
   message. Messages thus belong to a community. Messages belonging to 
   a community MUST only be send, received, forwarded and processed by 
   servents that are member of the same community. A servent that is 
   not a member of a community MUST never receive, send, forward or 
   process messages from that community. A servent receiving a message 
   belonging to a community it is not a member of MUST discard the 
   message immediately and MUST cease the connection to the peer from 
   which it has received the message with the cease code for 
   'Connection error' with the cease sub-code for 'Invalid community'. 
   More information about cease messages can be found in the section 
   'Cease header'. 

   A servent is NOT REQUIRED to forward a message it receives. If the 
   time to live of the message is zero then the message MUST be 
   discarded. If there is a shortage of local system resources or there 
   is another local reason not to forward the message then the servent 

     

   Hessing   Individual submission - Expires October 2002            5 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   MAY discard the message. A servent sending a message to its 
   destination via one or more intermediate servents MUST NOT assume 
   that the message will be delivered to its destination. 

   Two servents establishing a direct connection negotiate the version 
   of the P2P protocol. Messages MUST be sent over a connection using 
   the protocol version negotiated for that connection. If a message is 
   received over a connection with a mismatch in the protocol version 
   then the connection MUST be ceased with the cease code 'Connection 
   error' and the sub-code of 'Invalid protocol version'. Messages 
   coming in over a connection with one protocol version MAY be sent 
   out over another connection with another protocol version. A servent 
   performing this protocol conversion for a message which contains a 
   checksum MUST verify and recalculate this checksum before forwarding 
   the message. 

   A servent SHOULD ensure that all connection management messages are 
   sent in a timely manner to its peers. 

   Messages MUST be sent using only the headers supported by the 
   community and its capabilities. Messages using a capability that is 
   not supported by the community MUST be discarded by a servent 
   receiving the message whether that message is destined for that 
   servent or not. The servent MUST either withdraw the community 
   announcement to this peer with a Community Description message or 
   cease the connection to the peer it received the message from. A 
   cease message SHOULD in the latter case be sent to the peer with the 
   cease code for 'Message error' and the error sub-code for 'Invalid 
   capability'. 

   A message is defined by the community it belongs to, the servent 
   that has sourced it and its Message-ID. This tuple SHOULD be used to 
   uniquely identify messages. If and when a Connection header is 
   defined then this header SHOULD also be used to determine whether 
   the message is a duplicate of another message it has previously 
   received or not. Whenever a servent receives a duplicate message it 
   SHOULD silently discard the duplicate. 

   A servent MUST never forward a message it has received from a peer 
   with its own Source Servent ID. 

   A servent MAY analyze the contents of a message even it is not the 
   destination of the message. The servent MAY use the information for 
   network discovery, data caching or any other purpose it sees fit. 
   There is thus no inherent or assumed privacy in a P2P network. 
   Communities wishing to have privacy features should use the 
   available security provisions in this P2P protocol as described in 
   the section 'Path Security'. 



     

   Hessing   Individual submission - Expires October 2002            6 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   A message can either be directed to a single servent or broadcasted 
   to all servents that are member of the community.  

   A message consists of: 

   - Required Protocol headers  

   - Optional Protocol headers  

   - Security headers 

   - Capability headers 

   - Payload 

   Message headers MUST follow this order. A message must start with 
   the PPMP header. This header, together with the Checksum header MUST 
   be supported by every servent. Communities specify the requirements 
   for any other capabilities that a servent MUST support. As support 
   of the Connection Management community is REQUIRED for each servent, 
   support for the capabilities defined by the Connection Management 
   community is also REQUIRED for each servent. See the section on 
   'Community Announcements' on the capability support requirements for 
   the Connection Management community. 

   Some protocol headers are required in each message, other protocol 
   headers can be optionally included. 

   Whenever the description of a value of a header field is depicted as 
   (Reserved) then this value is not available for use. All values in 
   headers are in network byte order also known as big-endian order 
   such that for any value consisting of n bytes this value can be 
   collected from the byte stream by taking: 

        value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | ... | 
        byte[n-1]; 

   The values for Message and Header length depict the length in bytes. 

    
    Header   Header   Header type  Included  Header name 
    code     length                in 
                                     checksum? 
    0x0000   N/A      N/A          N/A       (Reserved) 
    0x0001   0x0024   Required     Partial   PPMP 
                                     (2) 
    0x0002   0x0008   Required(1)  No        Checksum 
    0x0003   0x000C   Optional     Yes       Message Length 
    0x0004   0x0006   Optional     Yes       Cease 
    0x0005            Optional     Yes       Community Description 

     

   Hessing   Individual submission - Expires October 2002            7 
draft-hessing-p2p-messaging-00.txt                          April 2002 

    0x0006            Optional     Yes       Community Authorization 
    0x0007   0x000C   Optional     Yes       Path header 
    0x0008   0x000C   Optional     Yes       Path Record header 
    0x0009   undef    Undef        Undef     Connection header  
    0x000A   0x000C   Optional     Yes       Multicast Session 
                                                Announcement 
    0x000B   0x0006   Optional     Yes       Error 
    0x000C   0x0004   Optional     Yes       Multicast Session Report 
    0x000D   >=       Optional     Yes       Authentication 
              0x0004 
    0x000E   0x001C   Optional     Yes       Encryption 
    0x000F   0x0008   Optional     Yes       Sequence header 
    0xFF00            N/A          N/A       (Experimental use) 
    - 
    0xFFFF 

   (1): Optional if the connection over which the message is being sent 
   is detects transmission errors. 

   (2): The 'Time to Live' and 'Hop count' fields are not included in 
   the checksum of the PPMP header. 

   If at any time there is a message processing error for which there 
   is no known cause then the message MUST be discarded and an error 
   message SHOULD be sent with the error code for 'Message error' and 
   the error sub-code for 'Unspecified error'. 

   A message with a header that has an invalid length MUST be 
   discarded. An error message SHOULD be sent with the error code for 
   'Message error' and the error sub-code 'Invalid header length' 





















     

   Hessing   Individual submission - Expires October 2002            8 
draft-hessing-p2p-messaging-00.txt                          April 2002 

     4.1.       PPMP header 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0001)      |     Header length (0x0024)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |  Protocol v.  |   Forw. Mech. |        Message Length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |          Message ID           |      Flags    |SegmentSecurity| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                            Community ID                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Source Servent ID (0)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Source Servent ID (1)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                    Destination Servent ID (0)                 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                    Destination Servent ID (1)                 | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |         Time to Live          |           Hop count           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   - Source/Destination Servent ID: Randomly-chosen 64 bit ID. For now 
   the first eight bits MUST have the value 0x00. A servent MAY have 
   multiple IDs. A community MAY define a requirement that a servent is 
   only to use one ID for both joining the community and for sending 
   and forwarding messages. A servent SHOULD use only one Servent ID 
   for all its connections and messages unless there are privacy 
   reasons in a supported community not to use a single Servent ID. A 
   servent ID is not guaranteed to be unique as there is no 
   coordination between servents in selecting servent IDs.  

   - A message with a Source Servent ID of all zeros is an anonymous 
   message.  

   - A message with a Destination Servent ID of all ones is a broadcast 
   message, to be received and processed by all servents. 

   - Protocol version: as negotiated during the setup of the connection 
   over which the message has been received or is to be send. 

   - Forwarding mechanism: see the section 'Message forwarding'. 

   - Message Length: 16 bit value. If the message length field contains 
   the value 0x0000 then the message MUST include the Message Length 
   header to indicate the length of the message. This method is used 
   when messages are longer then 2 ^ 16 Ż 1 bytes. If the message 
   length value in the PPMP header is 0x0000 and the message does not 
   include the Message Length header then the message MUST be discarded 

     

   Hessing   Individual submission - Expires October 2002            9 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   and an error message SHOULD be sent with the error code for 'Message 
   Error' and the Error sub-code 'Message length unknown'. See the 
   section on the 'Message Length header' for more details. 

   - Message ID: 16 bit value unique to the servent sourcing the 
   message. 

   - Flags: 8 bits 
     Bit  Value 
     0    Reliable transport between peers required. The 
          connection MUST ensure that the message is received 
          and is error-free. 
     1    Multicast transport allowed 
     2    Record route requested 
     3    Source Servent does not receive incoming connections 
     4-7  (Reserved) 

   A servent sending a message MUST set the value of bits 4 to 7 to 0. 
   If the flags are inconsistent with the community attributes then the 
   message MUST be discarded. An error message SHOULD be sent with the 
   error code for 'Message error' with the error sub-code for 'Invalid 
   flags'.  

   A message that has bit 0 of the flags set MUST NOT be send over a 
   connection that does not validate whether the message was 
   transported without errors. 

   A servent which suspects it is behind a firewall and/or may not be 
   able to accept incoming connections from other servents SHOULD set 
   bit 3. 

   - Segment Security: The Segment Security Code that is required for 
   the transport of the message between two peers. 

   - Time to live: 8 bits, number of hops that this message can be 
   forwarded to before it should be discarded. The Source servent 
   should set this value to the preferred time to live. Each servent 
   that sends the message (including the Source servent) SHOULD reduce 
   this time to live with one when sending the message. Messages 
   received with a time to live of 0 MUST NOT be forwarded to other 
   servents but SHOULD be processed locally.  

   Hop count: 8 bits, number of times the message has been sent from 
   one servent to another, when a servent receives a message it 
   increases the hop count. The source servent thus sends the message 
   with a hop count of 0. After the servent has received the message 
   and incremented the hop count, the hop count plus the time to live 
   SHOULD always match the original time to live as specified by the 
   source servent. 


     

   Hessing   Individual submission - Expires October 2002           10 
draft-hessing-p2p-messaging-00.txt                          April 2002 

     4.2.       Checksum header 

   The Checksum header allows errors to be detected by servents 
   receiving a message. The checksum is calculated using the SHA1 
   algorithm as described in [3]. 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0002)      |     Header length (0x0008)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                            Checksum                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   When the checksum of a message does not match the locally calculated 
   checksum then the message MUST be discarded. An error message SHOULD 
   be sent with the error code for 'Message error' with the error sub-
   code for 'Checksum error'.  

   Whenever a servent sends a message over a connection that does not 
   validate the correct transmission of a message then the checksum 
   header MUST be included even if that servent received the message 
   without a checksum header. 

   When a servent receives a message over a connection that does not 
   validate the correct transmission of a message then the servent MUST 
   verify the checksum. It MUST NOT remove the header when forwarding 
   the header, even if this forwarding occurs over a connection that 
   validates the correct transmission of a message. If a servent 
   receives a message that does not have a checksum header over a 
   connection that does not validate the correct transmission of a 
   message then the message MUST be discarded.  

   When a community defines capability specific headers it MUST specify 
   whether these MUST be included in the checksum. Headers that have 
   values that do not change per hop SHOULD be included in the 
   checksum. Values that may change per hop MUST NOT be included in the 
   checksum. 

   The payload of a message is always used for computing the checksum 
   unless the capability in the message that has provided the 
   specification of the payload has defined that the payload should not 
   be included in the checksum.  

   The verification of a checksum is OPTIONAL if the message has been 
   received over a connection that validates the error-free transport 
   of the message. 





     

   Hessing   Individual submission - Expires October 2002           11 
draft-hessing-p2p-messaging-00.txt                          April 2002 

     4.3.       Message Length header 

   The Message Length header is used to indicate the length of the 
   message when this message exceeds 2 ^ 16 - 1 bytes. 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0003)      |     Header length (0x0008)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        Message Length (0)                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                        Message Length (1)                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The Message Length value is a 64 bit value. 

   If the message length is less then 0x30 (the length of the PPMP 
   header plus the message length header) then the message MUST be 
   discarded and an error message SHOULD be sent with the error code 
   for 'Message error' and the error sub-code for 'Invalid header 
   length'. 

     4.4.       Cease header 

   Whenever a critical error occurs in the connection between peers 
   then this connection MUST be terminated by the peer that noticed the 
   error. This peer SHOULD send a message with only the PPMP header, 
   the CEASE header described in this section and a Checksum header if 
   the connection over which the message is to be sent does not 
   validate that the message is transported error-free. A message which 
   contains a Cease header is called a Cease message. After sending the 
   Cease message, the peer SHALL immediately close the connection to 
   the peer causing the critical error and SHALL NOT process any 
   messages forwarded by that peer which were still waiting to be 
   processed. 

   An error message MUST NOT be generated in response to a message that 
   includes the Cease header.  

   The Cease message MUST always use the Connection Management 
   Community and MUST use the header values as specified for this 
   community in the 'Connection setup and maintenance' section. 

    







     

   Hessing   Individual submission - Expires October 2002           12 
draft-hessing-p2p-messaging-00.txt                          April 2002 

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0004)      |     Header length (0x0006)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |  Cease code   | Cease Subcode | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The following Cease Codes and Sub-codes are defined: 
     Cease Cease Message code       Message sub-code 
     Code  Sub-
           code 
     1     0     Unknown error       
     2     0     Connection denied  Unspecified error 
     2     1     Connection denied  Administratively prohibited 
     2     1     Connection denied  Servent ID unacceptable 
     2     2     Connection denied  Protocol Version not supported 
     2     3     Connection denied  Time out value unacceptable 
     2     4     Connection denied  Connection collision detected 
     3     0     Connection error   Unknown error 
     3     1     Connection error   Invalid Source Servent ID 
     3     2     Connection error   Invalid Destination Servent ID 
     3     3     Connection error   Invalid Forwarding mechanism 
     3     4     Connection error   Invalid Time-to-Live 
     3     5     Connection error   Invalid Protocol Version 
     3     6     Connection error   Invalid community 
     3     7     Connection error   Time out timer expired 
     4     0     Connection info    Unknown information 
     4     1     Connection info    Better connection available 
     5     0     Message error      Unspecified error 
     5     1     Message error      Invalid capability 
     5     2     Message error      Invalid checksum 

    

     4.5.       Path header 

   The Path header is used to specify the route which a message should 
   take through a P2P network 












     

   Hessing   Individual submission - Expires October 2002           13 
draft-hessing-p2p-messaging-00.txt                          April 2002 

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0007)      |     Header length (0x0008)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Servent ID (0)                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Servent ID (1)                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Path headers can OPTIONALLY be used with all forwarding mechanisms. 
   See the section on 'Fully Defined Path' on how to process this 
   header when using this forwarding mechanism. The chapter on 
   Forwarding Mechanisms defines how message forwarding should be 
   performed for messages with one or more Path headers for the other 
   forwarding mechanisms. 

   The Path headers in the message are in the order of the servents the 
   message should be sent past. A servent MUST remove the first Path 
   header of a message if the Servent ID in that Path header matches 
   one of its own Servent IDs. Whenever a servent removes a Path header 
   from a message that has a checksum header, it MUST always verify the 
   original checksum before removing the Path header and discard the 
   message of the checksum is not correct. If the checksum does match 
   the servent MUST remove the Path header and recalculate the 
   checksum. 

   When a Path header is present in a message it SHOULD NOT be 
   considered to determine whether a message is a duplicate of another 
   message. 

   The normal rules for increasing the hop count and decreasing the 
   time to live apply. The message SHOULD be not be forwarded when the 
   time to live is 0 even if there are additional Path headers present 
   in the message. 

     4.6.       Path Record header 

   The Path Record header is used to record the route a message takes 
   through a P2P network 











     

   Hessing   Individual submission - Expires October 2002           14 
draft-hessing-p2p-messaging-00.txt                          April 2002 

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0008)      |     Header length (0x0008)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Servent ID (0)                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Servent ID (1)                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Path Record headers MAY be used with all Forwarding Mechanisms. A 
   servent receiving a message with the Path Record flag set SHOULD 
   append a Path Record header to the list of already present Path 
   Record headers. If no Path Record headers are present then it should 
   put in the header directly after the PPMP header. 

   The servent MUST put in the Path Record header the Servent ID it 
   used during the establishment of the connection over which it is 
   forwarding the message. This implies that for each connection it may 
   need to add a different Path Record header if it has used different 
   Servent Ids for setting up these connections. 

   If the message also has a checksum header then the checksum MUST 
   always be verified. Before forwarding the message over a connection 
   but after adding the Path Record header the servent MUST recalculate 
   the checksum and add it to the message. 

   Path Record headers are only sent by servents forwarding a message. 
   The servent sourcing the message MUST NOT include a Path Record 
   header. 

   The last servent processing a message with one or more Path Record 
   headers present SHOULD send a message back to the Source Servent ID 
   belonging to the same community, without the Record Route flag set 
   but with the Path Record headers that are present in the message. 
   This last servent can either be the destination servent or one or 
   more servents that receive the message with a Time-To-Live of zero. 

     4.7.       Connection header 

   The p2p protocol is in itself connectionless. Although TCP [4] is 
   one of the transport mechanisms specified as a means for the 
   transport messages between two peers, servents can exchange messages 
   by using the forwarding services of other servents and these 
   intermediate servents do not guarantee the delivery of the message.  

   At this time the need for a connection mechanism on top of the 
   message transport facilities is unclear. Whenever such a mechanism 
   would be implemented, servents would need to take into account that 
   when one or more Connection headers are present in a message that 

     

   Hessing   Individual submission - Expires October 2002           15 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   these headers should also be used to determine whether or not a 
   message is a duplicate message.  

   It is anticipated that a messages sent over an end-to-end connection 
   between servents would be using two Connection headers, one for 
   indicating which information is being sent in the message and one 
   header to indicate which information has already been received by 
   the other servent. 

     4.8.       Authentication header 

   The Authentication header MUST be included in a message when: 
     . A message is sent that uses the Authentication for Path 
        Security (see the section on Path security for more 
        information) 
     . A message contains a Community Description header for a 
        community with a Community Join Requirement of AUTHENTICATED 
        (see the sections on Community announcements and Joining a 
        Community for more information) 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x000D)      |         Header length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Fingerprint (0 .. 19)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          String (0 .. n)                      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The fingerprint is the 20 byte SHA1 hash of the public key packet-
   tag followed by the 2 byte value of the length of the public key 
   followed by the entire public key packet. 

   The string contains the result of the authentication algorithm over 
   the public key SHA1 hash of the message contents. All message 
   content that is used to compute the Checksum header is also used to 
   calculate the SHA1 hash.  

     4.9.       Encryption header 

   A message using encryption for Path Security (see the section on 
   Path security for more information) MUST include the Encryption 
   header in the message. 








     

   Hessing   Individual submission - Expires October 2002           16 
draft-hessing-p2p-messaging-00.txt                          April 2002 

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x000E)      |       Header length (0x1C)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Fingerprint (0 .. 19)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   All the capability headers and the message payload MUST be 
   encrypted. The protocol headers MUST NOT be encrypted. The 
   fingerprint allows the destination servent to select the right 
   public key to decrypt the message. 

   The fingerprint is the 20 byte SHA1 hash of the public key packet-
   tag followed by the 2 byte value of the length of the public key 
   followed by the entire public key packet. 

     4.10.      Error header 

   A servent SHOULD send an error message, that is, a message with an 
   Error header, in response to a message that has generated an error. 
   It should send this Error message only if the error has not caused 
   the connection over which the message was received to be ceased. The 
   servent uses the Source Servent ID of the message that has caused 
   the error as the Destination Servent ID in the Error message. The 
   Error message is send via the community to which the original 
   message belonged. 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x000B)      |     Header length (0x0006)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Error code  | Error Subcode | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   An Error message MUST NOT be send if the Source Servent ID of the 
   original message used the anonymous Servent ID of 0x0000. 

   An error message MUST consist of the PPMP header, the Error header 
   and a Checksum header if the message is send over a transported 
   mechanism which does not validate the correct transmission of the 
   message. An error message SHOULD include in its payload the headers 
   of the message that generated the error. No other headers SHOULD be 
   included in the message. The total length of the Error message 
   SHOULD NOT exceed 1000 bytes. 

   The following Error Codes and Sub-codes are defined: 
     Error  Error Message code    Message sub-code 
     Code   Sub-
            code 

     

   Hessing   Individual submission - Expires October 2002           17 
draft-hessing-p2p-messaging-00.txt                          April 2002 

     1      0     Unknown error   N/A 
     2      0     Message error   Unspecified reason 
     2      1     Message error   Checksum error 
     2      2     Message error   Malformed PPMP header 
     2      3     Message error   Undefined header type 
     2      4     Message error   Invalid header length 
     2      5     Message error   Message length unknown 
     2      6     Message error   Invalid flags 
     2      7     Message error   Invalid header type 
     2      8     Message error   'Source Servent does not receive 
                                   incoming connections' flag should 
                                   not be set 


  5. Message forwarding 

   Each community MUST define a set of supported message forwarding 
   mechanisms out of a list of forwarding mechanisms that are defined 
   in this protocol and possible future extensions to this protocol. 
   The source servent selects the forwarding mechanism for a message 
   from the list supported by the community to which the message will 
   belong. It encodes the forwarding mechanism to be used in the 
   Forwarding Mechanism field in the PPMP header of the message. The 
   rules for forwarding the message for that forwarding mechanism MUST 
   then be followed by each servent forwarding the message.  

   A servent that receives a message with a forwarding mechanism that 
   is not listed in the set of forwarding mechanisms supported by the 
   community MUST discard the message. A servent MAY NOT change the 
   forwarding mechanism of a message it has received.  

   The currently defined forwarding mechanism codes (FMC) are: 
    FMC        Name 
    0x00       (Reserved) 
    0x01       Direct connected only 
    0x02       Broadcast 
    0x03       Routed 
    0x04       Fully Defined Path 
    0x05       Multicast 
    0xF8-0xFF  (Experimental use) 

   Messages received with a time-to-live of zero MUST NOT be forwarded 
   to other peers regardless of the forwarding mechanism. When a 
   message has a time-to-live greater then zero then a servent MUST 
   decrease the time-to-live in the message before it sends the message 
   to one or more of its peers. 

   A servent receiving a message with one of its own Servent IDs as 
   Destination Servent ID and one or more Path headers MUST ignore the 


     

   Hessing   Individual submission - Expires October 2002           18 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   Path headers and process the message as it would have done if the 
   Path headers are not present. 

   Messages that do not use the 'Fully Defined Path' forwarding 
   mechanism but do have one or more Path headers SHOULD be forwarded 
   based on the value of the first Path header. A servent that receives 
   one of these messages with the Servent ID in the first Path header 
   matching one of its own Servent IDs MUST strip this Path header from 
   the message before forwarding it. The servent SHOULD forward the 
   message based on the Servent ID value of the next Path header or, if 
   there are no more Path headers, the value of the Destination Servent 
   ID.  

   A message that uses the 'Direct connected only' forwarding mechanism 
   MUST NOT be forwarded, even if it has a time to live greater than 
   one or one or more Path headers exist in the message. Servents in 
   communities that specify 'Direct connected only' as only forwarding 
   mechanism will have to learn about other servents using services, 
   capabilities of other communities or out-of-band means. 'Direct 
   connected only' forwarding mechanism MUST be supported in all 
   servent implementations as it is used during connection 
   establishment. 

     5.1.       Broadcasting 

   Broadcasting is the traditional forwarding mechanism in p2p 
   networks. A servent receiving a message from peer A for community X 
   SHOULD forward that message to all of its peers that have announced 
   community X to it except peer A if the message upon receipt has a 
   time to live greater then 0. For more information on community 
   announcements see the section 'Communities'. 

   It is obvious that this forwarding mechanism leads to great scaling 
   problems in any p2p network with a large number of servents. If we 
   take into account however that servents are not required to forward 
   messages to all its peers but should provide a best effort service 
   to deliver the message to its destination then there are several 
   optimalisations possible that reduce the amount of messages on a p2p 
   network. 

   A servent is SHOULD optimize its broadcasting algorithm. There are a 
   number of ways to perform this optimalisation:  

   - Maintaining a message cache to avoid duplicate messages and to 
   match 'request' and 'response' messages. As discussed in the section 
   'Messages' it is possible that a servent receives a message 
   belonging to the same Community, from the same Source Servent ID 
   with the same Message-ID and without a Connection header multiple 
   times. In that case it MUST silently discard all duplicates. This 
   avoids duplication of messages on the network. The second 

     

   Hessing   Individual submission - Expires October 2002           19 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   application of a message cache is to match request and response 
   messages as will be discussed in the section 'Capabilities'. A 
   servent receiving a response message for which it earlier received 
   the corresponding request message from the same Community, with the 
   same Message ID and where the Source Servent ID of the request 
   message equals the Destination Servent ID of the response message 
   SHOULD forward the message only to the peer from which it received 
   the request message the first time, if there is no Path header 
   present in the response message. If the servent has never seen the 
   corresponding request message then it SHOULD forward the message 
   using the normal broadcasting algorithm. 

   - Maintaining a servent cache by monitoring messages that it 
   receives from other peers, whether these messages are destined for 
   it or not. Each time a servent receives a message it should examine 
   the Source Servent ID and the hop-count. If a message sourced by 
   servent A has a lower hop-count then any other message sourced by 
   servent A then it should note the peer B from which it has received 
   the message as having the shortest path to servent A. It should then 
   forward messages destined for servent A only to peer B. Care should 
   be taken that messages that have one or more Path headers should not 
   be used to build up the servent cache as their specified routing may 
   be different then the optimal routing of messages on the p2p 
   network. 

   Other message forwarding optimalisations MAY include hierarchical 
   servent relationships or proxying response messages.  Hierarchical 
   servent relations introduce a client-server relationship into the 
   p2p model. This can reduce the burden of message forwarding on the 
   servents acting as a client. Message proxying allows a servent to 
   provide a response for another servent. This other servent will then 
   see less messages and this would reduce load on that servent. 
   Message proxying depends on the capability that is used in the 
   message. Message proxying techniques are thus defined in the 
   definition of the capability.  

     5.2.       Routed 

   It may be possible to develop a routing protocol for p2p networks 
   although making it scalable will be a complex task. It may be 
   possible to flood peer information of only a limited number of hops 
   between peers. Assuming that p2p networks will automatically select 
   communication between peers that are in close network proximity then 
   this limited depth flooding may provide sufficient information to 
   provide significant performance benefits but this is for further 
   study. 

   A routing table would need to be maintained for each community as 
   different community memberships may cause the routing of messages 


     

   Hessing   Individual submission - Expires October 2002           20 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   belonging to different communities between two peers may take 
   different path. 

     5.3.       Fully Specified Path 

   The Fully Specified Path forwarding Mechanism uses Path headers to 
   specify every hop in the path between the source and the destination 
   servents. 

   A servent receiving a message using the Fully Specified Path 
   forwarding mechanism MUST first verify that there are one or more 
   Path headers in the message. If there are no Path headers then the 
   message MUST be discarded. Otherwise if there are one or more Path 
   headers in the message then the servent MUST compare the servent ID 
   of the first Path header of the message with its own Servent IDs. If 
   the servent ID in the Path header does not match one of its own 
   Servent IDs then it MUST discard the message. Otherwise it MUST 
   strip the first Path header from the message and base its message 
   forwarding on the next Path header. 

   If there are no more Path headers and the Destination Servent ID 
   matches one of the Servent Ids of the servent then the servent 
   SHOULD process the message locally. 

   If there are more Path headers then it SHOULD forward the message 
   based on the next Path header. It MUST only forward the message to a 
   peer if the Servent ID in the Path header matches the Servent ID 
   announced by the peer during the establishment of the connection to 
   the peer.  

     5.4.       Multicasting 

   Messages using the multicast forwarding mechanism MUST be sent using 
   technologies that allow one to many communication. One such 
   technology is IP multicast but other technologies are being 
   researched as well. 

   There is a difference between multicast forwarding and multicast 
   transport connections. Multicast forwarding can use IP multicast to 
   transport messages but other techniques could also be introduced. 
   Multicast transport can be performed for any message that is 
   eligible for forwarding and that has the Multicast transport allowed 
   flag set in the PPMP header. 

   See the section 'Uni-directional IP multicast connections' on how 
   messages can be transported using a multicast transport connection. 





     

   Hessing   Individual submission - Expires October 2002           21 
draft-hessing-p2p-messaging-00.txt                          April 2002 

  6. Security profiles 

   Every community has a security profile. This profile defines the 
   requirements for servents to join a community and the requirements 
   for the transport of messages and bulk data. 

     6.1.       Requirements for joining a community 

   A servent can join a community by making a connection to one of more 
   other servents that are already member of the community and by 
   negotiating with these peers the use of the community. The initial 
   list of servents to connect to can be obtained by a service, a 
   cached list of servents or by manual configuration. Once a servent 
   has established a connection to a peer that is a member of a 
   community and has successfully negotiated the use of the community 
   through exchanging Community Description and Community Authorization 
   and/or Authentication headers with the peer then he has virtually 
   complete access to the community.  

   The community a servent is a member of defines how that servent MUST 
   validate an incoming request to join the community by another 
   servent. See the section on Communities on how communities are 
   negotiated between two peers using Community Description, Community 
   Authorization and/or Authentication headers. 

   If the Community Join Requirement is OPEN (CJR code 0x01) then it 
   SHOULD always accept incoming connections unless there are reasons 
   for the servent to deny the request, such as an internal blacklist 
   or resource constraints on the local system. 

   If the Community Join Requirement is AUTHORIZED (CJR code 0x02) then 
   the servent requesting to join the community MUST present in the 
   message with Community Description header a certificate in a 
   Community Authorization header that is signed by a Certificate 
   Authority known by both peers. 

   If the community join requirement is AUTHENTICATED (community join 
   requirement code 0x03) then the requesting peer MUST include an 
   Authentication header with a signature created using its own secret 
   key in the message with the Community Description header. The 
   receiving peer MUST use the public key it has for the requesting 
   peer to verify the signature. 

   The Authentication header does not include its own Community ID 
   field. For this reason only one community with the AUTHENTICATED 
   community join requirement can be announced per message. 

   Only one validation requirement can be supported within a community. 
   The following Community Join Requirement (CJR) codes are defined: 

    
 

   Hessing   Individual submission - Expires October 2002           22 
draft-hessing-p2p-messaging-00.txt                          April 2002 

    CJR code  Description 
    0x00        (Reserved) 
    0x01        OPEN 
    0x02        AUTHORIZED 
    0x03        AUTHENTICATED 
    0xF8-0xFF   (Experimental use) 

   Communities that are announced with a reserved or undefined CJR MUST 
   be ignored. 

     6.2.       Security for the transport of messages 

   The community can define what set of levels of security is required 
   for the transport of messages between two servents.  There are two 
   security scopes defined: 

   - Segment security: The security of sending a message between two 
   peers. The sending peer can either be sourcing the message or 
   forwarding a message it has received from another peer. 

   - Path security: The security of sending the message from the source 
   servent to the destination servent.  

       6.2.1.  Segment security 

   Messages can be transported over a connection between two peers only 
   if a connection is available between the two peers with a security 
   level that is supported by the community. It is thus possible that 
   there are multiple connections between two peers to satisfy the 
   security requirements of multiple communities. This is called 
   connection duplication between two peers. The connection between two 
   peers is called a segment in the context of the end-to-end path 
   between a source servent and a destination servent.  

   Establishing segment security is not part of this p2p protocol 
   framework. Segment security MUST be provided by the connection 
   mechanism used to establish a direct connection between two peers 
   such as TLS [5] or another mechanism able to provide such security. 

   When a servent is sending (sourcing or forwarding) a message and it 
   has multiple connections to a peer, all supported by the community 
   then it SHOULD use the connection with the least security in order 
   to optimize performance of the community. 

   The following Segment Security Codes (SSC) are currently defined for 
   the connection between two peers: 

   CLEAR (SSC 0x01): the messages are sent between peers in clear text 





   Hessing   Individual submission - Expires October 2002           23 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   AUTHENTICATED (SSC 0x02): the connection between two peers MUST 
   provide authentication of all data that is being send over this 
   connection. 

   ENCRYPTED (SSC 0x03):  the connection between two peers MUST encrypt 
   all data that is being sent over this connection.  

   The overview of Segment Security Codes (SSC): 
    SSC        Description 
    0x00       (Reserved) 
    0x01       CLEAR 
    0x02       AUTHENTICATED 
    0x03       ENCRYPTED 
    0xF8-0xFF  (Experimental use) 

   Communities that are announced with a reserved or undefined SSC MUST 
   be ignored. 

       6.2.2.  Path security 

   Path security defines the security parameters for the transport of a 
   message between the source and the destination servent.  

   The following Path Security Codes (PSC) are defined: 

   CLEAR (PSC 0x01): the messages are send in clear text 

   AUTHENTICATED (PSC 0x02): the message MUST include an Authentication 
   header. 

   ENCRYPTED (PSC 0x03): the message MUST be encrypted and MUST include 
   an Encryption header. 

   It is possible that there are multiple servents for which the 
   message is destined when multi- or broadcasting is used for the 
   transport of the message. Path security must always use the option 
   CLEAR when a message is destined to multiple servents. The options 
   AUTHENTICATED or ENCRYPTED can only selected when unicast forwarding 
   is used. This is expected to change in future revisions of this 
   specification. 

   The overview of Path Security Codes: 
    PSC        Description 
    0x00       (Reserved) 
    0x01       CLEAR 
    0x02       AUTHENTICATED 
    0x03       ENCRYPTED 
    0xF8-0xFF  (Experimental use) 



     

   Hessing   Individual submission - Expires October 2002           24 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   Messages that are received with a Path Security Code that is either 
   reserved or undefined SHOULD be discarded by the servent that 
   receives such a message. 

     6.3.       Data security 

   The transport of bulk data within messages (in-band bulk data 
   transfer) can use the security provisions that are available to the 
   transport of messages. The transport of bulk data between two 
   servents directly where the connection is made specifically for this 
   data transport and where the use of the PPMP protocol is not 
   required (out-of-band data transfer) can use the transport protocol 
   defined in the section 'Out of band data transport' or any other 
   transport protocol that a community wishes to define. This transport 
   protocol will then provide the security for the data transport. 


  7. Connection setup and maintenance 

   Connections between servents are used to transport messages from one 
   servent to another. Servents that have a direct connection to each 
   other are called peers. Connections can be made between two or more 
   peers. The servent initiating the connection is called the 
   requesting peer. The servents to which the connection is made are 
   called the receiving peers.  

   A single connection can be used for passing messages belonging to 
   different communities. This is called connection sharing. A 
   connection does thus not belong to a community. A connection is an 
   available resource that can be used by a community if it meets the 
   security requirements of the community. 

   Different technologies are supported through which the connection 
   can be established. A small number of connection mechanisms are 
   described in this document but future revisions of this document or 
   other standards can specify additional technologies. The mechanism 
   is not required to be reliable, nor are there real-time 
   requirements. It is thus possible that a message send by a peer over 
   a connection is not received by the other peer nor is it guaranteed 
   that the message will be received within a specific time frame. A 
   connection mechanism will also not need to guarantee that messages 
   are transmitted in the order they were sent. 

   A transport mechanism MUST define the maximum size of a message 
   which can be transported over the connection without the use of the 
   Connection header. It MUST also specify whether the connection will 
   be reliable and whether the connection validates that messages have 
   been transported without errors. 



     

   Hessing   Individual submission - Expires October 2002           25 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   Communities requiring reliable message transport MUST specify this 
   in their definition.  

   Communities MAY NOT specify which technology is used for the 
   transport of messages. They MUST specify the security requirements, 
   whether messages MUST use reliable transport between peers and 
   whether multicast forwarding is permitted. Messages belonging to a 
   community that has not required the use of reliable connections can 
   still be transported over reliable connections.  

   Connection Transport Codes (CTC) are 8 bit values and are amongst 
   others used in Ping messages (see the section on the Ping 
   capability). The following Connection Transport Codes are defined: 
    CTC       Description 
    0x00      (Reserved) 
    0x01      TCP  
    0x02      TLS 
    0x03      UDP [6] 
    0x04      UDP/Multicast 
    0xF8-0xFF (Experimental use) 

   CTC 0x01 uses TCP to provide reliable, error-free transport of 
   messages of unlimited length. It provides bi-directional 
   communication between two peers and connections and communities MUST 
   be negotiated. 

   CTC 0x02 uses TLS to provide reliable, error-free transport of 
   messages of unlimited length. It provides bi-directional 
   communication between two peers and connections and communities MUST 
   be negotiated. Connections over TLS work conceptually the same as 
   over TCP. The requesting peer connects to the receiving peer on the 
   appropriate port, acts like a TLS client and sends a TLS ClientHello 
   to begin the TLS handshake. When the TLS handshake is finished it 
   starts negotiating the connection. All messages MUST be sent as TLS 
   'application data'. Connections made using TLS MUST initiate an 
   exchange of closure alerts before closing a connection. 

   CTC 0x03 uses UDP to provide unreliable, error-free transport of 
   messages of up to 1400 bytes. A servent MUST ensure that UDP 
   checksums are enabled on the host it is running. CTC 0x03 provides 
   bi-directional communication between two peers and connections and 
   communities MUST be negotiated. 

   CTC 0x04 uses UDP to provide unreliable, error-free transport of 
   messages of up to 1400 bytes. A servent MUST ensure that UDP 
   checksums are enabled on the host it is running. CTC 0x04 provides 
   uni-directional community from a servent to a set of peers. 
   Connections and communities MAY NOT be negotiated. 



     

   Hessing   Individual submission - Expires October 2002           26 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   A special community is defined for messages used for connection 
   setup and maintenance: the Connection Management Community 
   (Community ID 0x0000). Messages send to this Community MUST have an 
   initial Time to Live of 1 and the forwarding mechanism MUST be 
   Direct Connected Only (see the section on forwarding mechanism 
   negotiation for the single exception to this rule). The Source 
   Servent ID MUST be the Servent ID that was used during the 
   connection setup and the Destination Servent ID MUST be the Servent 
   ID that the peer announced during the connection setup. 

     7.1.       Bidirectional Connections  

   The establishment of bi-directional connections consists of: 
     . Establishing the transport connection 
     . Negotiation the connection parameters 
     . Negotiation of supported forwarding mechanisms 
     . Breaking the connection if a connection collision has occurred 

   When peers attempt to establish a bi-directional connection they 
   exchange a sequence of connection establishment messages. The 
   connection will be in 'handshake' state during this sequence. If one 
   of the messages during the handshake is not received within a 
   specified time interval or a message is received out of sequence 
   then the connection establishment has failed and the peer 
   determining the failure MUST send a CEASE message to the other peer, 
   MUST cease the connection and SHOULD release any resources reserved 
   to establish the connection.  

   Two peers MUST agree on the following parameters before starting to 
   transmit messages over the connection: 
     . Connection mechanism 
     . Servent ID of both the requesting and the receiving peer 
     . P2P protocol version 
     . Time out value 
     . Forwarding mechanisms supported 

   When the two peers have agreed on these parameters then the 
   connection becomes operational. The peers will then start also 
   exchanging messages belonging to communities other then the 
   Connection Management Community.  

       7.1.1.  Establishing a bi-directional transport connection 

   This document defines UDP, TCP and TLS as bi-directional connection 
   mechanisms. They provide error-free transport of messages between 
   two peers. By accepting an incoming UDP, TCP or TLS connection the 
   receiving peer agrees to use it as connection mechanism. When a 
   requesting peer supports multiple connection mechanisms, it can 
   cycle through the different mechanisms in the order it prefers until 
   a connection has been successfully negotiated. It can also establish 

     

   Hessing   Individual submission - Expires October 2002           27 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   multiple connections using different connection mechanisms to 
   optimize message delivery. 

   Even though UDP is a connection-less protocol, in a P2P network it 
   is used for negotiating a bi-directional connection between two 
   servents. 

   The receiving peer MAY send a CEASE message after accepting the 
   incoming connection with the cease code for 'Connection Denied', 
   with the sub-code for 'Administratively prohibited'. 

   While the connection is in 'handshaking' state, all messages MUST 
   only consist of the following headers: 
     . Basic header.  
     . Checksum header if the connection mechanism is not error-free. 
     . CEASE header if an error occurred 

   These messages MUST use the Connection Management Community.  

       7.1.2.  Negotiate bi-directional connection parameters  

   After establishing the communication path and thus agree on the 
   transport mechanism, the peers first MUST have to agree on the 
   Servent IDs. The requesting peer MUST send a message with the 
   parameters:  
     . Source Servent ID: the servent IDs it wishes to use to 
        communicate with the receiving peer for Connection Management 
        messages. 
     . Destination Servent ID: because the requesting peer does not 
        know the Servent ID of the receiving peer, the requesting peer 
        MUST use a Destination Servent ID of all ones. 
     . Protocol Version: protocol version that the requesting servent 
        prefers to use. The only protocol version defined in this 
        document is version 1. 
     . Message-ID: This MUST be set to the proposed connection time-
        out value in seconds. A time out value of zero means that no 
        time out timer will be maintained. Only during connection 
        establishment time is this field to be allowed to be used for 
        this purpose.  

   The receiving peer MAY send one the following CEASE messages: 
     . A CEASE message with the cease code for 'Message error∆ with 
        the cease sub-code for 'Invalid checksum' if the checksum does 
        not match the contents of the message. 
     . a CEASE message with the cease code for 'Connection Denied' 
        with the sub-code for 'Servent ID unacceptable'  
     . a CEASE message with the cease code for 'Connection Denied' 
        with the sub-code for 'Protocol version not supported' if the 
        protocol version is not acceptable and it does not support or 


     

   Hessing   Individual submission - Expires October 2002           28 
draft-hessing-p2p-messaging-00.txt                          April 2002 

        does not wish to announce the support of another protocol 
        version. 
     . a CEASE message with the cease code for 'Connection Denied' 
        with the sub-code for 'Time out value unacceptable' 

   If no error occurred the receiving peer SHOULD send a message 
   consisting of the parameters: 
     . Source Servent ID: the Server ID it wishes to use to 
        communicate with the requesting peer for connection management 
        messages. 
     . the Destination Servent ID it has just received as Source 
        Servent ID from the requesting peer. 
     . Protocol Version: either the protocol version proposed by the 
        requesting peer or the protocol version that it prefers itself. 
     . Message-ID: either the time out value proposed by the 
        requesting peer or the time out value that it is proposing 
        itself. A time out value of zero means that no time out timer 
        will be maintained. 

   On receiving the message, the requesting peer MUST validate: 
     . The checksum and send a CEASE message with the cease code for 
        'Message error' and the sub-code for 'Invalid checksum' if the 
        checksum does not match the contents of the message. 
     . The Destination Servent ID, if it does not matches its own 
        announced Servent ID it MUST send a CEASE message with the 
        cease code for 'Connection Denied' and the sub-code for 
        'Servent ID unacceptable' 
     . The Protocol Version, it does not match its own announced 
        Protocol Version then it MUST evaluate whether the Protocol 
        Version announced by the receiving peer is acceptable. If not 
        then it MUST send a CEASE message with the cease code for 
        'Connection Denied' with the sub-code for 'Protocol version not 
        supported'. If the proposed Protocol Version is acceptable then 
        this protocol version MUST be used for all further 
        communication over this connection. 
     . The time-out value specified in the Message-ID. If it does not 
        match its own announced time-out value then it MUST either 
        accept the received time-out value or send a CEASE message with 
        the cease code 'Connection Denied' with the sub-code for 'Time 
        out value unacceptable'. 

       7.1.3.  Negotiate supported forwarding mechanisms for bi-
           directional connections 

   If the two peers agree on the values for the Source and Destination 
   Servent IDs, Protocol Version and Time out value then they start 
   announcing which forwarding mechanisms they support. For each 
   forwarding mechanism a peer supports it will send a message 
   belonging to the Connection Management Community. The PPMP header 
   MUST be used to indicate which forwarding mechanism is supported. 

     

   Hessing   Individual submission - Expires October 2002           29 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   This behavior is only allowed during the connection handshake, all 
   other messages belonging to the Connection Management Community MUST 
   use the Direct Connected Only forwarding mechanism as described in 
   the beginning of this chapter. 

   Each peer MUST compute the subset of its own supported forwarding 
   mechanisms and the supported forwarding mechanisms as announced by 
   the other peer.  This is the set of forwarding mechanisms supported 
   by this connection. Only messages using one of these forwarding 
   messages are eligible to be sent over this connection. 

   The Direct Connected Only forwarding mechanism must be announced as 
   the last forwarding mechanism. Servents MUST always announce this 
   forwarding mechanism because it is required to be implemented. This 
   message will indicate the end of the negotiation of forwarding 
   mechanisms. 

       7.1.4.  Breaking bi-directional connection collision 

   At this time connection collision can be detected.  There are three 
   possibilities: 
     . There is no connection collision. 
     . There are two or more connections between two identical 
        servents with the same IP address pair, and the same Servent 
        IDs but either the connection transport or the Protocol Version 
        does not match. In this case there is no connection collision 
        but care SHOULD be taken that messages are only sent over one 
        of the two connections. 
     . There are two connections between two identical servents, both 
        with the same IP address pair, the same Servent IDs, the same 
        connection transport, the same Protocol Version and where the 
        set of supported forwarding mechanisms of one connection is 
        equal to or a subset of the set of supported forwarding 
        mechanisms of the other connection. In this case a connection 
        collision has occurred. When this occurs the requesting peer 
        MUST select the connection with the smallest set of supported 
        forwarding mechanisms and send a CEASE message with the cease 
        code 'Connection Denied' with the cease sub-code for 
        'Connection collision detected' and CEASE the connection. If 
        the two sets of supported forwarding mechanisms are equal then 
        the servent MUST cease the connection that has been established 
        the shortest time. 

   If there is no connection collision then the connection becomes 
   operational and is available for general use.  

   When a new bi-directional connection is established that has the 
   same IP address pair, the same Servent IDs, the same connection 
   transport, the same Protocol Version and where the set of supported 
   forwarding mechanisms is a superset of an existing connection then 

     

   Hessing   Individual submission - Expires October 2002           30 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   this existing connection SHOULD be ceased with the cease code for 
   'Connection info' with the cease sub-code for 'Better connection 
   available'. 

       7.1.5.  Keepalive messages for bi-directional connections 

   If peers have negotiated a time-out value larger then 0 for a bi-
   directional connection then they MUST maintain a timer that SHOULD 
   be reset every time a message is received over the connection. A 
   peer SHOULD cease the connection if no messages have been received 
   over the connection from the other peers during the duration of the 
   time-out value. The CEASE message MUST use the cease code for 
   'Connection error' with the sub-code for 'Time out timer expired'. 
   When a message is received over a connection, it is not relevant 
   whether it is a duplicate or whether its checksum is valid for 
   resetting the timer. 

   A servent MUST also maintain a timer per bi-directional connection 
   to ensure that it sends at least one message over the connection 
   during the time-out interval. If no regular messages are available 
   for sending over the connection then a peer SHOULD generate a 
   Keepalive message. A Keepalive message MUST belong to the Connection 
   Management community and MUST only include the PPMP header and the 
   Checksum header if the connection over which the message is send is 
   does not validate the error-free transport of a message. 

   Keepalive messages are also used to monitor the performance of the 
   connection. They are used to measure the amount of packet loss and 
   delay between two peers. A servent MAY send a Keepalive to the other 
   peer for performance management. This message MUST belong to the 
   Connection Management community and use a unique Message-ID. The 
   peer recognizes that the message was not initiated by itself through 
   the Message-ID and MUST respond immediately with a Keepalive message 
   with the same Message-ID. The servent that originated the Keepalive 
   recognizes the Message-ID of the Keepalive message as one that it 
   has generated itself and calculates the delay between sending the 
   original Keepalive and receiving the response.  

   The servent MAY use the message delay and message loss values to 
   trim its set of peers to the best performing and cease the 
   connections to the worst performing peers. 

   A servent MUST of course take into account that connections using a 
   reliable transport mechanism will not experience message loss. 

   Keepalive messages with a Message-ID of 0x00 are not intended for 
   performance management. Servents SHOULD NOT respond to these 
   Keepalives with a Keepalive message with the same Message ID.  



     

   Hessing   Individual submission - Expires October 2002           31 
draft-hessing-p2p-messaging-00.txt                          April 2002 

     7.2.       Multicast, unidirectional connections 

   The establishment of a multicast uni-directional connection by a 
   servent consists of the following steps: 
     . Determining whether the servent should start forwarding 
        messages using multicast for a community 
     . Announcing that the servent is forwarding messages to a 
        multicast group 
     . Receiving feedback that there are listeners on the multicast 
        group 

   A servent MAY forward messages for a community using multicast if: 
     . It is a member of the community. 
     . The community has not specified that reliable transport is 
        required 
     . The community has specified that multicast forwarding is 
        permitted. 
     . The community join requirement code is OPEN (0x0001). 
     . The community does not have asymmetric key encryption as only 
        option for segment or path security. 
     . It is not already receiving messages for that community using 
        multicast even though it has attempted to do so. 
     . It has sufficient bandwidth available to forward messages. 
     . If does not have reasons to believe that its messages send via 
        multicast are not received by a significant group of servents. 

   The last requirement is kept vague intentionally. As IP multicast 
   groups may become a scarce resource the number of IP multicast 
   groups should remain limited. A servent should thus be confident 
   that its use of IP multicast adds significant value to the 
   community. 

       7.2.1.  Multicast Session Announcement header 

   The servent using multicast to forward messages for a community MUST 
   periodically announce this forwarding channel to the community using 
   the Multicast Session Announcement header in a message sent to the 
   community for which it is using multicast: 













     

   Hessing   Individual submission - Expires October 2002           32 
draft-hessing-p2p-messaging-00.txt                          April 2002 

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x000A)      |     Header length (0x000C)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       Multicast IP Address                    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      CTC      |            Port               |  Interval (0) | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |  Interval(1)  |          Bandwidth            | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Multicast IP address: class D address. 

   CTC: Connection Transport used for this session. 

   Port: port used for the connection transport. 

   Bandwidth: Maximum bandwidth in Kbit/s that the servent will forward 
   messages using this multicast transport session. 

   Interval: a servent receiving messages using multicast from this 
   servent SHOULD send a Multicast Session report once during every 
   interval. 

   A servent does not negotiate a community over a multicast uni-
   directional connection as it would over a bi-directional connection. 
   The originating servent can assume that servents listening to the 
   multicast connection already are a member of the community because 
   the originating servent MUST only announce the multicast session 
   using a message belonging to the community it will multicast. The 
   servents listening to the multicast session thus know about the 
   specification of the community and can validate the messages against 
   this specification. 

   Servents MUST consider the expected bandwidth requirements before 
   joining a multicast session. 

       7.2.2.  Multicast Session Report header 

   Servents receiving messages belonging to a community using a 
   multicast connection SHOULD send a report back to the servent 
   transmitting the community once during every interval specified in 
   the Interval field in the Multicast Session Announcement header. 
   These servents MUST use the Multicast Session Report header in a 
   message belonging to the community and MUST send that message to the 
   originator of the multicast session. The originator of the multicast 
   session can be determined by the received Multicast Session 
   Announcement messages. 


     

   Hessing   Individual submission - Expires October 2002           33 
draft-hessing-p2p-messaging-00.txt                          April 2002 

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x000C)      |     Header length (0x0004)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Servents receiving a Multicast Session Report destined for another 
   servent SHOULD check whether they already have sent or forwarded a 
   Multicast Session Report message to this destination servent for the 
   same multicast session during the last reporting interval. If that 
   is the case then the servent SHOULD drop or delay the message to 
   ensure that it only sends or forwards one Multicast Session Report 
   per interval towards the servent originating the multicast 
   connection. If a servent receives a Multicast Session Report for a 
   multicast session it has not previously received a Multicast Session 
   Announcement then it SHOULD forward the message to the destination 
   servent without using the inverse proxying algorithm described 
   above. 

       7.2.3.  Sequence header 

   Every message that is send using multicast transport MUST include 
   the Sequence header. The Sequence header is included in the Checksum 
   header and the servent sending a message over a multicast transport 
   MUST calculate the checksum if a checksum header is included in the 
   message and/or the message is using a transport mechanism that does 
   not support error detection. The Sequence header length is 8 bytes. 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x000F)      |     Header length (0x0008)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         Sequence Number                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   Every time a servent forwards a message using multicast transport 
   for a certain community it MUST increment the sequence number for 
   that community by one. This increment allows receiving servents to 
   notice when message loss occurs. A servent noticing significant loss 
   of messages MUST leave the multicast session. 

       7.2.4.  Forwarding messages over multicast transport 

   Messages using the forwarding mechanism 'Multicasting∆ can be send 
   over multicast connections. Messages using other forwarding 
   mechanisms that have the 'Multicast transport allowed∆ flag set in 
   the PPMP header SHOULD be forwarded according to the rules of the 
   forwarding mechanism and MAY be forwarded using a multicast 
   connection. If a servent forwards such a message using a multicast 
   connection then it MUST NOT change the forwarding mechanism value in 
   the PPMP header. 

     

   Hessing   Individual submission - Expires October 2002           34 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   A servent receiving a message using multicast transport MUST NOT 
   further forward that message even if that message would otherwise be 
   eligible for forwarding. 


  8. Communities 

   In the context of p2p networks, communities are defined by: 
     . Their membership requirements, i.e. open, authorized by well-
        known entity, authenticated by direct peers 
     . Security requirements for the transport of messages and data 
     . Capabilities: supported message headers 
     . Services: key servers, network management servers 
     . Message forwarding mechanisms: directly connected only, 
        broadcast, routed, multicast, specified path 
     . Connection types: uni- or bi-directional, reliable, error-free, 
        real-time, multicast 

   Peers MAY exchange messages belonging to a community only if the 
   peers sharing the connection agree on the attributes of the 
   community. 

   The Community ID values are grouped as follows: 
    Community ID  Community             Remarks 
    0x00000000    Connection             
                   Management Community 
    0x00000001    Network Management     
                   Community 
    0x00000002 -  (reserved)            Well-known communities 
    0x01FFFFFF                          MUST be registered with 
                                         IANA before use 
    0x02000000 -                        Dynamically assigned, 
    0x09FFFFFF                          globally unique 
    0x0A000000 -                        Dynamically assigned, 
    0x0A999999                          locally scoped 
    0x0B000000 -  (reserved)            Applications to be defined 
    0xFFFEFFFF 
    0xFFFF0000 -  (Experimental use)     
    0xFFFFFFFF  

   Well-known communities MUST be registered with IANA before they can 
   be used. Dynamically assigned, globally unique communities MAY be 
   initiated by a servent that wishes to start a (semi-) permanent 
   community available to all servents using this protocol. Dynamically 
   assigned, locally scoped communities MAY be created by servents 
   wishing to initiate a community with a limited time of existence and 
   a limited number of communities. 




     

   Hessing   Individual submission - Expires October 2002           35 
draft-hessing-p2p-messaging-00.txt                          April 2002 

     8.1.       Community Announcements 

   After a connection that supports community negotiation has become 
   operational, peers MAY exchange messages to announce that they are 
   willing to accept messages for a community, as long the peers agree 
   on the attributes of the community and the community join 
   requirements are met. These messages use the Community Description 
   and the Community Authorization headers, as discussed in the next 
   two sections. 

   A servent MAY create a community with a specific Community ID if 
   that Community ID is in the range of dynamically assigned Community 
   IDs and the servent has no knowledge of communities using the same 
   Community ID. When the servent creates the community, it also 
   defines the community attributes. It SHOULD then send a message with 
   a Community Description header and possibly a Community 
   Authorization header or an Authentication header for the newly 
   created community over each of its operational connections. The 
   servent may then receive announcements for the community back from 
   one or more of its peers if a peer has accepted the community. The 
   servent MAY then start sending messages to each peer that has 
   accepted the community. 

   Each servent MUST support the Community Description capability. The 
   support for the Community Authorization- and the Authentication 
   capabilities is optional. A servent that does not support either of 
   these capabilities but receives a message with such a capability 
   MUST ignore the capability and the Community Description header to 
   which the unsupported capability references. 

   When a servent finds that the attributes of a community it receives 
   through a Community Description message do not match the attributes 
   it has stored itself for that community then this is called a 'split 
   community'. The servent MUST reject the Community Announcement 
   message for such a community from its peer. The peers MUST NOT 
   exchange messages belonging to the community over that connection. 
   This should never happen with well-known communities. It can happen 
   with dynamically assigned Community IDs and it can be expected to 
   happen with dynamically assigned locally scoped Community IDs. 

   Upon receipt of a Community Announcement message for a community of 
   which it had no prior information a servent MAY accept this 
   announcement. If the servent accepts the community then it MUST send 
   a message with a Community Description header matching the original 
   announcement to the peer from which it received the announcement. 
   The servent MAY also send Community Announcement messages for the 
   community over some or all of its operational connections to 
   propagate the information about the community to its other peers. 



     

   Hessing   Individual submission - Expires October 2002           36 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   Starting communities which have a Community Join Requirement other 
   then OPEN will require some external means of establishing 
   authentication. For communities that use the AUTHORIZED join 
   requirement the HTTP URL in the Community Description header could 
   point to a web site where users can establish an identity and have 
   the certificate authority used by that community validate that 
   identify.   

   The Connection Management community MUST never be announced over a 
   connection. 

   A servent MAY indicate that it no longer wants to receive messages 
   belonging to a community by sending a Community Description header 
   to its peers withdrawing that community. A servent receiving a 
   message over a connection from a peer with a Community Description 
   header withdrawing a community MUST stop sending messages belonging 
   to that community to that peer over that connection.  

   Communities with a Community ID out of the dynamically assigned 
   range SHOULD be removed by a servent when the community is not 
   statically configured in the servent, it has not created the 
   community itself and it does not have any operational connections 
   over which it has received announcements for the community. This can 
   occur when: 
     . Its peers have not announced the community (back) to it 
     . Its peers have sent it a message with a Community Description 
        header withdrawing the community. 
     . All the connections over which it has received an announcement 
        for the community have been terminated 

   A peer SHOULD keep a timer on when it has last received a message 
   belonging to a community that uses a dynamically assigned Community 
   ID. This timer SHOULD also be reset whenever it receives a Community 
   Description message for that community. The peer SHOULD send a 
   message with a Community Description header withdrawing the 
   community over all its connections which it has previously announced 
   the community if it has not received any messages for that community 
   for twenty-four hours.  

   A servent MAY send duplicate announcements for a community to a peer 
   to avoid that the community will time-out on that peer. 

     8.2.       Community Description header 

   A Servent MAY send a message with one or more Community Description 
   headers for one or more communities over an operational connection 
   that supports community negotiation. By sending a Community 
   Description header, the servent announces that it is willing to 
   accept messages for the community specified in the header, as long 
   as the attributes of the community matches with the information 

     

   Hessing   Individual submission - Expires October 2002           37 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   about the community of the peer that is receiving the Community 
   Description header and the Community Join Requirements are met. A 
   Community Description header can only be used together with the PPMP 
   header, the Checksum header, the Authentication header, other 
   Community Description headers and Community Authorization headers. 
   The message containing the Community Description header(s) MUST 
   belong to the Connection Management Community (0x00000000). 

   A Community Description message for a community that has a Community 
   Join Requirement of AUTHORIZED MUST include a Community 
   Authorization header. A Community Description message for a 
   community that has a Community Join Requirement of AUTHENTICATED 
   MUST include an Authentication header. 

   The Community Description header is a variable length header and has 
   the following lay-out: 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0005)      |          Header length        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Community ID                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   | Status|         Flags         |    Join Req.  |  Attributes(0)| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         Attributes (1 .. n)                   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          URI (0 .. n)                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   There are currently three different community status values defined: 
   (Reserved) (0x00), Active (0x01) and Withdrawn (0x02). The Values 
   0x06 and 0x07 are for experimental use. 

   The bits in the Community Description flags field have the following 
   meaning: 
     Bit   Value 
     0     0 = Messages can be send both over reliable and unreliable 
           connections 
           1 = Reliable transport between peers is required for any 
           message belonging to this community 
     1     0 = Real-time transport is allowed 
           1 = Real-time transport is required 
     2     0 = Multicast transport is not allowed 
           1 = Multicast transport is allowed 
     3     0 = Record route requests are not allowed 
           1 = Record route requests are allowed 
     4     0 = Payload is not included in the checksum 
           1 = Payload is included in the checksum 
     5     0 = A servent MUST use only one Servent ID for both 

     

   Hessing   Individual submission - Expires October 2002           38 
draft-hessing-p2p-messaging-00.txt                          April 2002 

           joining the community and sending messages to it 
           1 = A servent MAY use different Servent IDs for joining 
           and sending messages to the community. 
     6     0 = Messages with the anonymous (0x00) Source Servent ID 
           are not allowed. 
           1 = Anonymous messages are allowed 
     7-11  (reserved) 

   The Join Requirement field specifies the Join Requirement Code for 
   the community. 

   The attributes supported by the community are announced sequentially 
   in the header. Attribute sequences thus have a variable length. Each 
   sequence of attributes is terminated by a null value. This null 
   value has the same bit length as the attribute which sequence it 
   terminates. Attribute sequences are sent in a specific order so that 
   the receiving servent can parse the header. 
     Attribute                                        Representation 
     Supported Forwarding mechanisms                  8 bits 
     Supported Segment security codes                 8 bits 
     Supported Path security codes                    8 bits 
     Supported out-of-band data transport mechanisms  8 bits 
     Capability                                       24 bits 

   The Capability attribute is a tuple consisting of a 16 bit 
   Capability value followed by an 8 bit Capability Support Requirement 
   (CSR). A 16 bit Capability value of null terminates the list of 
   capabilities that are supported by the community. The Capability 
   Support Requirement values are defined to:  
     . (Reserved) 0x00 
     . Processing Required (0x01): A servent that can't process and 
        forward this capability MUST reject the Community 
     . Forwarding Required (0x02): A servent that doesn't support the 
        forwarding of messages with this capability according to the 
        forwarding rules for this Capability MUST reject this 
        community. 
     . Optional (0x03): A servent does not need to support this 
        capability, the capability is optional  
     . 0xF8-0xFF: (Experimental use) 

   A servent receiving a Community Description message that lists 
   attributes that it considers undefined MUST reject the community.  

   A servent receiving a Community Description message that doesn't 
   list a forwarding mechanism it supports MUST reject the community. 

   A servent receiving a Community Description message that doesn't 
   list a segment security code it supports MUST reject the community. 



     

   Hessing   Individual submission - Expires October 2002           39 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   A servent receiving a Community Description message that doesn't 
   list an out-of-band data transport mechanism it supports MAY accept 
   the community. 

   An optional URI describing the community can be appended to the 
   header after the last community attribute is terminated with a null 
   value. The length of the URI can be determined by taking the header 
   length value and decrementing that by the number of bytes read up to 
   the start of the URI. The use of the URI information is not formally 
   defined but could be used to direct the servent to an out-of-band 
   authentication service or other resource. A community may specify 
   the exact use of the URI. 

     8.3.       Community Authorization header 

   If the community has a community join requirement of AUTHORIZED 
   (0x02) then a Community Authorization header MUST accompany the 
   Community Description header in the message.  
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0006)      |          Header length        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Community ID                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         String (0 .. n)                       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The string is a DER encoded X509 [7] certificate which includes the 
   public key of the requesting peer signed by a Certificate Authority 
   known by both peers. The digital signature is over the PPMP header 
   excluding the hop-count and time-to-live fields and the Community 
   Description header for the community. 

   If the signed certificate is not valid then Community Description 
   header and the Community Authorization header for the community MUST 
   be discarded. 


  9. Out-of-band Data Transport 

   Servents wishing to exchange resources that require a significant 
   amount of bandwidth MAY chose to do so using Out-of-band Data 
   Transport (ODT). This section lists a number of available ODT 
   mechanisms with references to their protocol definitions. Each 
   community MUST define which ODT mechanisms it supports. 
     ODT code  Protocol 
     0x00      (reserved) 
     0x01      HTTP [8] GET 
     0x02      HTTP PUT 

     

   Hessing   Individual submission - Expires October 2002           40 
draft-hessing-p2p-messaging-00.txt                          April 2002 

     0x03      HTTP over TLS [9] GET 
     0x04      HTTP over TLS PUT 
     0x05      IP MULTICAST  
     0xF8-0xFF (Experimental use) 

   Currently Reliable Multicast Transport (RMT) is being defined the 
   RMT working group in the Transport Area of the IETF. This working 
   group is in the process of defining the building blocks of RMT. 
   These building blocks can be used to specify multicast transport 
   suitable for p2p networks. This specification can either occur in 
   this work in progress or in a separate document.  


  10.  Capabilities 

   A capability is some functionality that is supported by a community. 
   A capability consists of a capability-specific header and optionally 
   an interpretation of the message payload. 

   Each capability MUST define: 
     . Capability header, its header code, its header length (fixed or 
        variable), is the header included in the checksum and 
        authentication or encryption headers? 
     . Does the capability have to be fully supported by a servent 
        joining the community? 
     . Does the header provide a specification for the message 
        payload, and if so, is the payload included in the checksum and 
        authentication or encryption headers? 
     . Is this a Request message, and if so what are the Response 
        capabilities? 
     . Is this a Response message, and if so, to what Request 
        capabilities 

   Messages that are a response to another message MUST use the same 
   Community and the same Message-ID as used in the corresponding 
   Request message. The Response message MUST use as Destination 
   Servent ID the Source Servent ID of the corresponding Request 
   message. A Capability can be a combination of both a Response to 
   another message and a Request to one or more Servents. A capability 
   can be Response message but can also be send without a corresponding 
   Request message. 

   Headers defined by capabilities MUST come after any headers as 
   defined in the previous chapters. Multiple capability headers can be 
   grouped in one message as long as at most one capability header 
   provides a specification for the message payload. 





     

   Hessing   Individual submission - Expires October 2002           41 
draft-hessing-p2p-messaging-00.txt                          April 2002 

     10.1.      Ping capability 

   The Ping header MUST be included in the checksum and any 
   authentication or encryption headers. The message length is fixed at 
   0x0004 bytes. The header does not specify the message payload. 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0100)      |     Header length (0x0004)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Pings can either be sent to a specific Servent ID or to the 
   broadcast address. A ping message MAY NOT use the anonymous servent 
   ID as source servent ID. A Ping message is a request for a Pong 
   message. 

     10.2.      Pong capability 

   The Pong header MUST be included in the checksum and any 
   authentication or encryption headers. The message length is fixed at 
   0x0004 bytes. The header does not specify the message payload. 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0101)      |     Header length (0x0004)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The Pong message is a response to a Ping message. The Pong message 
   MAY be send anonymously but this is not advisable as it will then 
   only provide limited information to the requesting Servent. 

     10.3.      Servent Discovery capability 

   The Servent Discovery header MUST be included in the checksum and 
   any authentication or encryption headers. The message length is 
   fixed at 0x0004 bytes. The header does not specify the message 
   payload. 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0102)      |     Header length (0x0004)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The Pong message is a request for a Hello message.  

     10.4.      Hello capability 

   The Hello header MUST be included in the checksum and any 
   authentication or encryption headers. The message length is variable 


     

   Hessing   Individual submission - Expires October 2002           42 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   with a minimum length of 0x000C. The header does not specify the 
   message payload. 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0103)      |         Header length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                 Uptime                        | Phy. If. speed| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          IP address                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     CTC (0)   |         Port (0)              |       ..      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       ..      |     CTC (n)   |            Port (n)           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The uptime value SHOULD contain a 24-bit number of seconds that have 
   elapsed since the host started providing services using this p2p 
   protocol specification. The physical interface speed value MUST use 
   the class value of the following 'interface speed' table that 
   matches closest the physical interface with the highest capacity 
   over which it accepts incoming P2P connections. A physical interface 
   speed value of '0' indicates that the servent sending the hello does 
   not want to announce this information. 
     Class 0         1          2         3            4 
     Speed N/A       56.1Kbit   256Kbit/s 512Kbit/s    1.5/2Mbit/s 
     Class 5         6          7         8            9 
     Speed 10Mbit/s  45Mbit/s   100Mbit/s 155Mbit/s    620Mbit/s 
     Class 10        11         12        13           14 
     Speed 1Gbit/s   2.4Gbit/s  10Gbit/s  40Gbit/s     160Gbit/s 

   A servent SHOULD use the IP address of the interface over which it 
   accepts incoming p2p connection supporting the highest bandwidth in 
   the IP address field. A servent MAY use 0.0.0.0 as IP address to 
   indicate it wants to keep its IP address private. 

   Each CTC/Port pair specifies which connection transport mechanisms 
   are supported on which ports. 

   Hellos can either be sent to a specific Servent ID or to the 
   broadcast address. By including information about its uptime and 
   physical interface speed it allows the other servents in the p2p 
   network that receive the message to learn about it. The Hello 
   message is a response to a Servent Discovery message.  

     10.5.      Connection Advise capability 

   The Connection Advice header MUST be included in the checksum and 
   any authentication or encryption headers. The message length is 
   variable with a minimum length of 0x000C bytes. The header does not 

     

   Hessing   Individual submission - Expires October 2002           43 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   specify the message payload. It is neither a Request nor a Response 
   header. 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0104)      |         Header length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                 Uptime                        | Phy. If. speed| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          IP address                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     CTC (0)   |         Port (0)              |       ..      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     CTC (n)   |            Port (n)           | Pref. Len (0) | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                         IP prefix (0)                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |      ..       | Pref. Len (m) |         IP prefix (m)         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The Connection Advise message MAY be send with an anonymous Source 
   Servent ID. The servent sending out the request MUST use its own IP 
   address in the IP address field. The uptime, phy. if. speed, CTC and 
   Port fields use the same encoding as in the Hello header. The 
   CTC/Port sequence is terminated by two bytes with a null value. 

   The servent sending a Connection Advice message does so to optimize 
   connectivity on a transport network level. It advices other servents 
   that it is providing good p2p connectivity to servents with an IP 
   address in one of the IP address prefixes included in the header. 

   A Connection Advice header MUST NOT be included in a message with 
   the 'Source Servent does not receive incoming connections' bit set 
   in the PPMP header 

     10.6.      Community Discovery capability 

   The Community Discovery header MUST be included in the checksum and 
   any authentication or encryption headers. The message length is 
   fixed at eighth bytes. The header does not specify the message 
   payload. It is a Request for a Community Invitation message. 










     

   Hessing   Individual submission - Expires October 2002           44 
draft-hessing-p2p-messaging-00.txt                          April 2002 

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x010F)      |    Header length (0x0008)     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Community ID                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   A servent can send the Community Discovery capability to a community 
   like the Network Management community to find out servents that 
   support a certain community. This can be used to establish 
   connections to servents that carry a certain community that is not 
   supported by the current peers of a servent. 

     10.7.      Community Invitation capability 

   The Community Invitation header MUST be included in the checksum and 
   any authentication or encryption headers. The message length is 
   variable with a minimum length of 0x0010 bytes. The header does not 
   specify the message payload. It is neither a Request nor a Response 
   header. 
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0105)      |         Header length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Community ID                         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                 Uptime                        | Phy. If. speed| 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          IP address                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     CTC (0)   |         Port (0)              |       ..      | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |       ..      |     CTC (n)   |            Port (n)           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The encoding of the Uptime, Phy. If. speed, IP address, CTC and Port 
   fields is the same as in the Hello capability. 

   The Community Invite capability is used to invite another servent to 
   join a community by making a connection to the servent using the IP 
   address of the IP address field using one of the Connection 
   Transport mechanisms listed in CTC/Port pairs.  

   The Community Invite capability can be used stand-alone or as a 
   Response to a Community Discovery message. 

   Only servents that can receive incoming connections MAY send the 
   Community Invite header. A Community Invite header MUST NOT be 

     

   Hessing   Individual submission - Expires October 2002           45 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   included in a message with the 'Source Servent does not receive 
   incoming connections' bit set in the PPMP header.  

     10.8.      XML Query capability 

   The XML Query header MUST be included in the checksum and any 
   authentication or encryption headers. The message length is variable 
   with a minimum length of 0x0004 bytes. The header does not specify 
   the message payload.  
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0106)      |         Header length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       XML string (0 .. n)                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The XML string is the XML compliant [10] ASCII string representing a 
   query. A community supporting this capability MUST define which 
   Docbooks may be used in these queries. 

   The XML Query message is a Request message and the XML Response 
   message is its response message. 

     10.9.      XML Response capability 

   The XML Response header MUST be included in the checksum and any 
   authentication or encryption headers. The message length is variable 
   with a minimum length of 0x0004 bytes. The header does not specify 
   the message payload.  
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0107)      |         Header length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    ODTC (0)   |    Port (0)   |       ..      |    ODTC (n)   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    Port (n)   |                 URI (0..m)                    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                       XML string (0 .. n)                     | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The ODTC/Port tuple fields are a list of Out-of-band Data Transport 
   mechanisms that can be used to retrieve a resource. This list is 
   terminated by two bytes with the null value. 

   The URI field is a null-terminated ASCII string providing the 
   location where the resource is available for retrieval. 



     

   Hessing   Individual submission - Expires October 2002           46 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   The XML string is the XML compliant ASCII string representing a 
   response to an XML Query header. A community supporting this 
   capability MUST define which Docbooks may be used in these 
   responses. 

   The XML Response header is a response to the XML Request header. 

     10.10.     Resource Push Request capability 

   The Resource Push Request header MUST be included in the checksum 
   and any authentication or encryption headers. The message length is 
   variable with a minimum length of 0x000C bytes. The header does not 
   specify the message payload.  
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0108)      |         Header length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          IP address                           | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    ODTC (0)   |    Port (0)   |       ..      |    ODTC (n)   | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |    Port (n)   | 
   +-+-+-+-+-+-+-+-+ 

   If servent A has received a XML Response message from servent B with 
   the 'Source Servent does not receive incoming connections∆ flag set 
   in the PPMP header then it MAY send a Resource Push Request message 
   to servent B. Servent A lists in this message the Out-of-band Data 
   Transport mechanisms it supports together with the ports it is using 
   for these transport mechanisms. It also provides the IP address on 
   which it can receive the out-of-band data transport. 

   Servent B MAY then initiate the resource exchange by using the out-
   of-band transport mechanism to servent A. It will use as identifier 
   for the resource the string consisting of the community ID and the 
   Message ID of the Resource Push Request message.  

   A servent that does not receive incoming connections MUST not send 
   Resource Push Requests as the receiving servent will not be able to 
   establish a connection to it. A servent receiving a Resource Push 
   Request message with the 'Source Servent does not receive incoming 
   connections' flag set in the PPMP header MUST discard this message 
   and SHOULD send an error message with the error code for 'Message 
   error' and the error sub-code for 'Source Servent does not receive 
   incoming connections' flag should not be set'. 





     

   Hessing   Individual submission - Expires October 2002           47 
draft-hessing-p2p-messaging-00.txt                          April 2002 

     10.11.     Algorithm Request capability 

   The Algorithm Request header MUST be included in the checksum and 
   any authentication or encryption headers. The message length is 
   variable with a minimum length of 0x0005 bytes. The header does not 
   specify the message payload.  
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x0109)      |          Header length        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Language    | 
   +-+-+-+-+-+-+-+-+ 

   The Language field MUST use one of the following codes: 
    Code         Description 
    0x00         (Reserved) 
    0x01         Perl 
    0x02         Phyton 
    0x03         Java 
    0x04         C 
    0x05         C++ 
    0x06         C# 
    0x07         Win32 binary 
    0x08         Linux ELF Intel-32bit binary 
    0x09         Sun/Solaris binary 
    0xF8 - 0xFF  (Experimental use) 

   The Algorithm Request message is a Request message to which the 
   Algorithm Response message is the Response. 

     10.12.     Algorithm Response capability 

   The Algorithm Response header MUST be included in the checksum and 
   any authentication or encryption headers. The message length is 
   variable with a minimum length of 0x0005 bytes. The header does not 
   specify the message payload.  
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x010A)      |         Header length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |   Language    |         Algorithm ID          | Code (0 .. n) | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   A header length of 0x0005 indicates that there is no source code 
   available for the algorithm in the language selected in the 
   Algorithm Request message. 



     

   Hessing   Individual submission - Expires October 2002           48 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   The Algorithm ID field is an identifier for the algorithm provided 
   in this Algorithm Response message. 

   The Code field is a null terminated string which includes the source 
   code for the algorithm. 

   Servents receiving an algorithm MUST ensure that executing the 
   received code will bring no damage to the host the servent is 
   running on. 

   The Algorithm Response message is a Response to an Algorithm Request 
   message. 

     10.13.     Dataset Request capability 

   The Dataset Request header MUST be included in the checksum and any 
   authentication or encryption headers. The message length is fixed at 
   0x0006 bytes. The header does not specify the message payload.  
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x010B)      |     Header length (0x0006)    | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |         Algorithm ID          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The Algorithm ID MUST have been received in a previous Algorithm 
   Response message. 

   The Dataset Request message is a Request message for which the 
   Dataset Response message is the Response. 

     10.14.     Dataset Response capability 

   The Dataset Response header MUST be included in the checksum and any 
   authentication or encryption headers. The message length is variable 
   with a minimum length of 0x0008 bytes. The header does not specify 
   the message payload.  













     

   Hessing   Individual submission - Expires October 2002           49 
draft-hessing-p2p-messaging-00.txt                          April 2002 

    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x010C)      |         Header length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                           Dataset ID                          | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |                          Data (0 .. n)                        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   A header length of 0x0008 indicates that there is no data available 
   for processing using the algorithm specified in the Dataset Request 
   message.  

   The data field is a null-terminated ASCII string that can be fed to 
   the algorithm for processing. 

   The Dataset Response message is a Response to the Dataset Request 
   message. It is also a Request for a Dataset Result message. 

     10.15.     Dataset Result capability 

   The Dataset Result header MUST be included in the checksum and any 
   authentication or encryption headers. The message length is variable 
   with a minimum length of 0x000A bytes. The header does not specify 
   the message payload.  
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x010D)      |         Header length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |         Algorithm ID          |        Dataset ID (0,1)       | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |        Dataset ID (2,3)       |        Result (0 .. n)        | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The Algorithm ID MUST have been received in a previous Algorithm 
   Response message. 

   The Dataset ID MUST have been received in a previous Dataset 
   Response message. 

   The Result field is a null-terminated ASCII string with the output 
   from the algorithm with the dataset as input. 

   The Dataset Result message is a Response to a Dataset Response 
   message. 




     

   Hessing   Individual submission - Expires October 2002           50 
draft-hessing-p2p-messaging-00.txt                          April 2002 

     10.16.     Chat capability 

   The Dataset Result header MUST be included in the checksum and any 
   authentication or encryption headers. The message length is variable 
   with a minimum length of 0x0006 bytes. The header does not specify 
   the message payload.  
    0                   1                   2                   3  
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Header type (0x010E)      |         Header length         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |        Sender (0 .. m)        |         Text (0 .. n)         | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   The Sender field is a null-terminated ASCII string identifying the 
   person sending the chat message. The text field is a null-terminated 
   ASCII string with the chat message. 


  11.  Network management  

   The goal of network management of a p2p network is to keep the 
   network operational and efficient as to maximize the performance and 
   usability for the end users. Network management occurs at three 
   levels: 
     . Connection Management with the Connection Management community, 
        using Keepalive and Community Description messages. 
     . The Network Management community  
     . Community-defined network management capabilities 

   The Network Management community requires a servent to support the 
   capabilities: Ping, Pong, Hello, Servent Discovery, Community 
   Discovery, Community Invitation and Connection Advice. Servents MUST 
   support the processing and forwarding of these capabilities when 
   they are in a message with CLEAR Path Security. Servents MUST 
   support the forwarding of these messages with the Path Security 
   options AUTHENTICATED and ENCRYPTED.  

   Messages belonging to this community MAY be sent both over reliable 
   and un-reliable connections, MAY use multicast transport. Real-time 
   transport of messages is not required. Record Route requests are 
   allowed, a servent MAY use multiple Servent IDs when originating 
   messages for this community. A servent MAY also use the anonymous 
   Servent ID when originating messages for this community. The Payload 
   is included in the checksum. The supported forwarding mechanisms are 
   'Direct Connected Only' and 'Broadcasting'. There is no out-of-band 
   data transfer method supported. The Community Join Requirement is 
   'OPEN'. Messages MAY be transported over CLEAR, AUTHENTICATED and 
   ENCRYPTED segments. 


     

   Hessing   Individual submission - Expires October 2002           51 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   The network can be optimized at two levels: matching the p2p network 
   optimally with the underlying transport network and by providing 
   optimal connectivity between servents. Connection Advice messages 
   can be used to improve the matching between the p2p network and the 
   underlying transport network. Network Discovery and Hello messages 
   can be used to match servents with similar interface speeds and to 
   find potential peers that are stable. 

   Some p2p networks implement hierarchical mesh construction and 
   indeed this would also be possible to do with p2p networks build 
   using this protocol specification. However, the requirements of such 
   a mesh is dependent on the goals of the community. It is thus left 
   up to the community definition to specify how hierarchy within the 
   community is established. 


  12.  Security considerations 

   P2P networking is open to a number of well known attacks and is 
   introduces a number of new potential attacks.  

   At the application level, the servent will introduce the delivery of 
   services on some computers which traditionally would not provide 
   service to other computers. The users of these computers may not 
   have experience with running a computer that provides services to 
   other computers and the inherent security risks included.  

   At the protocol level, the security measurements available in this 
   protocol should be used to prevent man-in-the-middle and 
   eavesdropping attacks and ensure that only authorized users can 
   connect to a community. At no time should a servent rely solely on 
   the Source Servent ID field to establish the identity of another 
   servent. It is trivially easy to spoof this ID. If broadcasting is 
   used as forwarding mechanism then spoofing is also more effective 
   then in traditional IP networks because the spoofing client is very 
   likely to receive any response message for the spoofed Servent ID. 

   The protocol ensures that existing communities are protected from 
   peers trying to remove or to modify the specifications of these 
   communities. A servent should however limit the amount of new 
   communities a peer may introduce to prevent starvation of Community 
   ID space and to limit impact when a peer introduces bogus community 
   descriptions for existing communities of which the servent is not 
   yet a member of. 

   Denial of Service attacks are possible against individual servents 
   and indeed the p2p network. Servents should implement rate-limiting 
   to control the amount of messages it will accept from a peer. 
   Similarly, it should implement queuing algorithms for outgoing 


     

   Hessing   Individual submission - Expires October 2002           52 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   messages that prioritize control messages over other messages to 
   ensure that the network keeps running during a DoS attack.  

   Communities need to carefully balance security requirements with p2p 
   network performance. The hop-by-hop authentication or encryption of 
   messages does increase computations on intermediate servents but it 
   will allow the servents to analyze the message and learn about the 
   p2p network from it.  

   Running applications or code that is received through Application 
   Response headers brings risk. The code may contain viruses or trojan 
   horses. Application Response headers should use authenticated or 
   encrypted transport or servents should use other means of protecting 
   the host it is running on, for example those used to run client-side 
   code using java in web-browsers. 


  13.  IANA Considerations 

   This section uses the terminology as defined in the RFC 2434 [11]. 

   The 'Community ID' namespace uses 32 bit numbers. This address space 
   is carved up as: 
     . 0x00: Connection management community 
     . 0x01: Network management community 
     . 0x00000002 - 0x01FFFFFF: to be assigned by IANA after expert 
        review or specification. 
     . 0x02000000 - 0x0A999999: no assignment by IANA required, freely 
        usable. 
     . 0x0B000000 - 0xFFFEFFFF: reserved, assignment by IANA only to 
        commence after IETF consensus on the use of this address space 
     . 0xFFFF0000 - 0xFFFFFFFF: private use 

   Both the PPMP and the Community Description header have their own 
   flags field with several bits not given an interpretation. The 
   interpretation of these bits is to be assigned by IANA after 
   specification. 

   The Status namespace is used in the Community Description header and 
   contains 4-bit values. Values for the Status namespace can be 
   assigned by IANA after specification. 

   The Capability Support Requirement is used in the Community Support 
   Description and containts 8-bit values. Values for this namespace 
   can be assigned by IANA after specification. 

   The Header Type namespace contains 16 bit values. The values 0x0000 
   up to and including 0x008F are to be used for protocol headers, the 
   values 0x0100 up to 0xFFF0 are to be used for capability headers. 
   The values 0xFFF0 up to and including 0xFFFF are to be used for 

     

   Hessing   Individual submission - Expires October 2002           53 
draft-hessing-p2p-messaging-00.txt                          April 2002 

   private use. Values from the protocol header and capability header 
   ranges can be assigned by IANA after expert review or specification. 

   The following namespaces all contain 8 bit values. This document 
   specifies a number of values in each of these namespaces, please see 
   the appropriate section. Each of these namespaces has a range of 
   values that is defined as experimental which translates to 'private 
   use' in RFC 2434 terminology. Additional values can be assigned by 
   IANA after expert review or specification. The namespaces are: 
     . Segment Security  
     . Path Security 
     . Community Join Requirement  
     . Connection Transport  
     . Out-of-band data transport 
     . Language  

   Each registration of the namespaces listed in this section can be 
   amended by the author and the IESG has the right to re-assign 
   ownership of the registration. 
































     

   Hessing   Individual submission - Expires October 2002           54 
draft-hessing-p2p-messaging-00.txt                          April 2002 



  14.  References 

    

   1 RFC 2026, Bradner, S., 'The Internet Standards Process -- Revision 
      3', BCP 9, October 1996 

   2 RFC 2119, Bradner, S., 'Key words for use in RFCs to Indicate 
      Requirement Levels', BCP 14, RFC 2119, March 1997 

   3 FIPS PUB 180-1, 'Secure Hash Standard', National Institute of 
      Standards and Technology, April 1995 

   4 RFC 793, Postel, J., 'Transmission Control Protocol', September 
      1981. 

   5 RFC 2246, T. Dierks, C. Allen. 'The TLS Protocol Version 1.0', 
      January 1999 

   6 RFC 768, J. Postel, 'User Datagram Protocol'. Aug-28-1980 

   7 CCITT, Recommendation X.509, The Directory-Authentication 
      Framework, Consultation Committee, International Telephone and 
      Telegraph, International Telecommunications Union, Geneva, 1989. 

   8 RFC 2616, 'Hypertext Transfer Protocol Ż HTTP/1.1'. 

   9 RFC 2818, E. Rescorla, 'HTTP Over TLS', May 2000 

   10 Extensible Markup Language (XML) 1.0 (Second Edition), W3C 
      Recommendation. eds. Tim Bray, Jean Paoli, C. M. Sperberg-McQueen 
      and Eve Maler. 6 October 2000. http://www.w3.org/TR/REC-xml 

   11 RFC 2434, Narten & Alvestrand, 'Guidelines for IANA 
      Considerations', October 1998 














     

   Hessing   Individual submission - Expires October 2002           55 
  15.  Author's Address 

   Steven Hessing 

   steven@xs4all.nl 

   Two mailing-lists have been set up for this specification:  
     . ppmp-announce@lists.sourceforge.net for announcements about the 
        PPMP protocol  
     . ppmp-spec@lists.sourceforge.net for discussion about the 
        specification of the protocol 


  16.  Full Copyright Statement 

   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implmentation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph 
   are included on all such copies and derivative works. However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the  purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 

   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 

   This document and the information contained herein is provided on an 
   'AS IS' basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.'