usr/share/man/cat4/nsip.0

NSIP(4)                     BSD Programmer's Manual                    NSIP(4)

N\bNA\bAM\bME\bE
     n\bns\bsi\bip\bp - software network interface encapsulating NS packets in IP packets

S\bSY\bYN\bNO\bOP\bPS\bSI\bIS\bS
     o\bop\bpt\bti\bio\bon\bns\bs N\bNS\bSI\bIP\bP
     #\b#i\bin\bnc\bcl\blu\bud\bde\be <\b<n\bne\bet\btn\bns\bs/\b/n\bns\bs_\b_i\bif\bf.\b.h\bh>\b>

D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
     The n\bns\bsi\bip\bp interface is a software mechanism which may be used to transmit
     Xerox NS(tm) packets through otherwise uncooperative networks.  It func-
     tions by prepending an IP header, and resubmitting the packet through the
     UNIX IP machinery.

     The super-user can advise the operating system of a willing partner by
     naming an IP address to be associated with an NS address.  Presently, on-
     ly specific hosts pairs are allowed, and for each host pair, an artifi-
     cial point-to-point interface is constructed.  At some future date, IP
     broadcast addresses or hosts may be paired with NS networks or hosts.

     Specifically, a socket option of SO_NSIP_ROUTE is set on a socket of fam-
     ily AF_NS, type SOCK_DGRAM, passing the following structure:

     struct nsip_req {
             struct sockaddr rq_ns;  /* must be ns format destination */
             struct sockaddr rq_ip;  /* must be ip format gateway */
             short rq_flags;
     };

D\bDI\bIA\bAG\bGN\bNO\bOS\bST\bTI\bIC\bCS\bS
     n\bns\bsi\bip\bp%\b%d\bd:\b: c\bca\ban\bn'\b't\bt h\bha\ban\bnd\bdl\ble\be a\baf\bf%\b%d\bd.\b.  The interface was handed a message with ad-
     dresses formatted in an unsuitable address family; the packet was
     dropped.

S\bSE\bEE\bE A\bAL\bLS\bSO\bO
     intro(4),  ns(4)

H\bHI\bIS\bST\bTO\bOR\bRY\bY
     The n\bns\bsi\bip\bp interface appeared in 4.3BSD.

B\bBU\bUG\bGS\bS
     It is absurd to have a separate pseudo-device for each pt-to-pt link.
     There is no way to change the IP address for an NS host once the the en-
     capsulation interface is set up.  The request should honor flags of
     RTF_GATEWAY to indicate remote networks, and the absence of RTF_UP should
     be a clue to remove that partner.  This was intended to postpone the ne-
     cessity of rewriting reverse ARP for the en(4) device, and to allow pass-
     ing XNS packets through an Arpanet-Milnet gateway, to facilitate testing
     between some co-operating universities.

4.3 Berkeley Distribution        June 5, 1993                                1