4.4BSD/usr/share/man/cat4/nsip.0

Compare this file to the similar file:
Show the results in this format:

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

NNAAMMEE
     nnssiipp - software network interface encapsulating NS packets in IP packets

SSYYNNOOPPSSIISS
     ooppttiioonnss NNSSIIPP
     ##iinncclluuddee <<nneettnnss//nnss__iiff..hh>>

DDEESSCCRRIIPPTTIIOONN
     The nnssiipp 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;
     };

DDIIAAGGNNOOSSTTIICCSS
     nnssiipp%%dd:: ccaann''tt hhaannddllee aaff%%dd..  The interface was handed a message with ad-
     dresses formatted in an unsuitable address family; the packet was
     dropped.

SSEEEE AALLSSOO
     intro(4),  ns(4)

HHIISSTTOORRYY
     The nnssiipp interface appeared in 4.3BSD.

BBUUGGSS
     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