/FAQServer от 2:5025/38.12@fidonet/Сеть Фидо/IP-nodes in the nodelist

* Forwarded by Vitaly Lunyov (2:5030/818)
* From : NC5030, 2:5030/0 (12 Nov 98 18:59)
* Subj : ip nodes
* Crossposted in SPB.SYSOP.INFO

вот. ждем-с.

From: Denis Saveliev 

Date: 12 Nov 98  00:27:46
From: Lothar Behet (2:2446/301)
To  : All
Subj: IP-nodes in the nodelist

* Crossposted in WWB_COORD
* Crossposted in WWB_SYSOP

Hello All!

FYI :)

Regards Lothar

* Weitergeleitet von Lothar Behet (2:2446/301)
* Area  : mymail-lb (MyMail-lb)
* Von   : Ward Dossche, 2:292/854 (12 Nov 98 00:12)
* An    : Lothar Behet
* Thema : IP-nodes in the nodelist

Since it's largely your work, you are the 1st-one to know ... this is going
to be distributed in a few minutes. Basically it means a 100% implementation
of your proposal.

Congratulations on the work that has been achieved.

BTW, have you considered the case of an ISDN-only which offers IP as well?


 + Originally to All in the REGCON.EUR echo.


As of today the nodelist in zone-2 is now open for allowing IP-nodes in the
regular nodelist along the proposal which was drawn-up and refined by our
colleague Lothar Behet and so many helpfull people to whom thanks are due as

Lothar's proposal is appended for those needing details.

The I-suite of flags from through has been implemented in
the flag-checker here and should make it to the world-nodelist, also in the
other zones, without problem as of immediately.

It is clear Lothar's text describes how IP-nodes will be noted in the nodelist, 
it does not determine how they will function. Eg IP-only nodes will have to
make arrangements to collect/drop-off their mail.

Since this signals the end of the IP-test-period it is requested that the
people carrying 2:2/3xxx-numbers will be listed in their net-segment with an
IP-entry and when this is done, inform me to remove their 2:2/3xxx-entry.

  \x/ard Dossche

************************* QUOTE *************************

> Publication:    FSP-????
> Revision:       1
> Title:          Integration of IP-Nodes in the nodelist (FTS-0005)
> Author:         Lothar Behet, 2:2446/301
> Revision Date:  25 October 1998
> Expiry Date:
> ----------------------------------------------------------------------

> Contents:
> 1. Required fields according to FTS-0005, basic flags for ip-nodes
> 2. Optional extensions
> 3. Addendum
> ----------------------------------------------------------------------

> 1.  Description of the nodelist format
> --------------------------------------

> Every node entry contains the following 8 fields:

> keyword,node_number,node_name,location,sysop_name,
> phone_number,baud_rate,flags

> Certain fields have defined values according to FTS-0005.

> 1.1.  Implementation for IP-connectivity
> Because of the limited characterset in the phone_field and
> to avoid any misinterpretion by conventional dialing, the
> ip-specific address-information is entered in another field
> and there are additional flags required.

> 1.1.1.  Field #1 (keyword) is PVT for an ip-only node without
> conventional phone number related connectivity. In this
> case, the phone field contains '-Unpublished-' according
> to FTS-0005.

> 1.1.2.  Field #2 (node_number) contains the node number within his
> net and zone.

> 1.1.3.  Field #3 (node_name) is used for the FQDN (Fully Qualified
> Domain Name) or the ip-address.

> 1.1.4.  Field #4 (location) contains the geographical location of
> the node. While some nets/regions cannot supply their
> ip-only nodes with a adequate link, these nodes may be
> collected in a seperate net or region, until their original
> net/region support additional ip-connectivity. This special
> net/region is definitely a temporary solution for routing
> within a region or zone!

> 1.1.5.  Field #5 (sysop_name) represants the name of the system
> operator.

> 1.1.6.  Field #6 (phone_number) contains the phone_number for
> conventional connectivity. In case of an ip-only node
> it must contain '-Unpublished-'.

> 1.1.7.  Field #7 (baud_rate) contains the maximum baud rate for
> conventional connectivity or 300 in case of an ip_only node.

> 1.1.8.  Field #8 (flags) represents operational definitions for the
> node.
> The ip-flags consist of two parts:
> A basic transport and an optional non-standard port,
> seperated by a colon.
> The default port may be omitted, but is listed as optional
> parameter in this document. In some cases, two flag names
> are mentioned:
> The second one is supported by some software nowadays, but
> these values may conflict with other programs, which not
> completely decode the length of each individual flag (i.e.
> TELN conflicts with the T-flag for online-time)
> Additional flags for ip-nodes are:

>  IBN[:24554] (Argus: BND[:24554])
> BinkP protocol

>  IFC[:60179]
> Raw protocol as used by ifcico

>  ITN[:23] (Argus: TEL[:23])
> Telnet protocol. Some variants of ifcico support Telnet
> on port 60177, which should be added as additional flag
> ITN:60177.

>  IVM[:3141]
> Vmodem protocol

>  IP
> General flag for special protocol specifications, if the
> flags conforming to to are not relevant.

> 1.1.9.  Comments on the proposed nodelist flags
> The additional flagnames in () are supported at this moment
> by Argus, based on the use in z2r50. But the TEL[NET]-flag
> stays in conflict with the generally in all zones and
> regions used T-flag (online time according to FSC-0062).

> 2.  Optional extensions for future use
> --------------------------------------

> While the above mentioned flags ( to define a
> minimum set of operational flags for ip-nodes, several additions
> are already foreseeable at this moment.

> 2.1.  Additional sessions_handshake parameters
> There is at least one program, which supports several
> transport protocols according to chapter 1.1.8. on a
> single port. If other programs should imitate this habit,
> then the following extension to the flag suite 1.1.8.
> (transport[:port[:handshake]])is advised:

> 2.1.1.  FTS-0001 session handshake:   1
> 2.1.2.  Yoohoo session handshake  :   Y
> 2.1.3.  EMSI sessions handshake   :   E
> 2.1.4.  BinkP sessions handshake  :   B

> 2.2.  Non-handshaking protocols
> While the definitions until this chapter describe direct
> handshaking sessions with optional password authentification,
> there are several other methods for the tunneling of fidonet
> data via the internet available.
> The setup of these connections does not rely on the nodelist
> (at this moment of writing), but we can think of standard
> setup procedures to use the nodelist for configuration of
> this additional transport methods.
> Therefore the following flags 2.2.1. to 2.2.4. are advised
> for at least informational purpose.

> 2.2.1.  IFT
> FTP (File Transfer Protocol)

> 2.2.2.  ITX
> TransX, an Email based variant

> 2.2.3.  IUC
> Uuencoded packet (one packet per message)

> 2.2.4.  IEM
> Email based (generally, without exact specification at
> this moment)

> 3.  Addendum
> ------------

> This proposal is based on a maximum compatibility to generally used
> definitions and standards within the Fidonet community.
> Future developments might make additions necessary, if they can not
> be expressed with the existing set of flags as defined by this FSP.

************************ UNQUOTE ************************

File created by Faq2Site converter. (C) 1998-2002 Edward Grebenyukov
Hosted by uCoz