home *** CD-ROM | disk | FTP | other *** search
/ Hackers Toolkit v2.0 / Hackers_Toolkit_v2.0.iso / HTML / archive / Texts / ipaddr.txt < prev    next >
Text File  |  1999-11-04  |  14KB  |  307 lines
  1. Date: Wed, 12 Nov 86 21:59:15 pst
  2. From: wally%net1.ucsd.edu@flash.bellcore.com (Wally Linstruth) (tty00)
  3.  
  4.         To: tcpgroup
  5.         Regarding: IP addressing
  6.  
  7.  
  8.              The  intent  of  this paper is to  document  the  background 
  9.         behind the current IP address assignments which I have offered to 
  10.         coordinate.   The proposed scheme has been reviewed by Phil Karn, 
  11.         Bdale Garbee and (verbally with) Mike Chepponis, all of whom have 
  12.         encouraged that it be used.
  13.  
  14.              Phil's  code  does  NOT  currently  support  the  subnetwork 
  15.         aspects of the scheme but will do so in the future.   There is no 
  16.         real  reason  for  any national coordination of  these  addresses 
  17.         until  actual  networks or at  least  geographically  coordinated 
  18.         groups of experimenters are formed.
  19.  
  20.              I  have offered to issue and keep track of SUBNET  addresses 
  21.         and  their  "owners"  who are  presumably  responsible  *NETWORK* 
  22.         implementors and managers.
  23.  
  24.              The  basic premise behind the proposed plan is that  amateur 
  25.         radio  networks will be politically defined.   The plan is  based 
  26.         upon  the  presumption  that current voice networks  serve  as  a 
  27.         proper  analog by which to predict general characteristics of the 
  28.         as yet unconstructed digital networks.   Political entities  will 
  29.         build networks; funded, controlled, maintained and used primarily 
  30.         by their own members and guests.
  31.  
  32.              Each  of these separately managed networks should be  viewed 
  33.         as  a  subnetwork  of AMPRNET (with the  idea  being  to  somehow 
  34.         rationally  partition the 044.xxx.xxx.xxx AMPRNET address space).  
  35.         Each  subnetwork within AMPRNET will maintain routing tables  for 
  36.         its  own  constituents.   Each will provide its own hosts  (TACs, 
  37.         Gateways, i.e. the mechanism by which users with simple terminals 
  38.         and AX25 level 2 boxes will access network resources),  switches, 
  39.         rules  (network  administration),  security  measures  and  quite 
  40.         possibly its own link level protocols.
  41.  
  42.              The  natural  limitations on span of control  will  probably 
  43.         limit  the  service  area of each of  these  networks.   This  is 
  44.         another factor leading to the partitioning of the AMPRNET address 
  45.         space with respect to separate subnetworks.
  46.  
  47.              This  partitioning  of  the  address space  will  allow  for 
  48.         much  simplified  routing tables in each  host.   Internetworking 
  49.         gateways will connect these independently controlled subnetworks. 
  50.         Each  gateway will maintain routing tables only for  local  hosts 
  51.         and for gateways to other networks.  Hosts and  relay switches on 
  52.         a   given  subnet  will  need  to  maintain  routing  information 
  53.         regarding  only  members  of that subnet and  gateways  to  other 
  54.         networks.   The  required routing tables should prove to be  very 
  55.         manageable  and make any kind of geographically  based  hueristic 
  56.         addressing schemes such as ZIP codes, area codes etc. moot.
  57.  
  58.  
  59.  
  60.  
  61.                                         1
  62.  
  63.  
  64.  
  65.              I  would  also  like to propose that we  coordinate  logical 
  66.         network  names and their corresponding addresses based  on  these 
  67.         political   network  subdivisions.    The  concept  of  a  naming 
  68.         convention  which maps directly into an IP address is purely  for 
  69.         the  convenience  of  network developers and  is  not  considered 
  70.         necessary.  There is,  however, some good reasoning behind making 
  71.         network and host names hierarchical and meaningful to end  users.  
  72.         It  will  considerably aid in bootstrapping the initial  networks 
  73.         and in being comprehensible to the non-network folks who will  be 
  74.         the  primary  users  of these networks.   The  naming  convention 
  75.         proposed   is  of  the   form   USERID@HOST.SUBNET[.AMPRNET.RES].  
  76.         WESTNET,  SBARCnet  (Santa  Barbara ARC) and  GFRN-net  represent 
  77.         three  hypothetical  networks  with which this  writer  could  be 
  78.         involved, perhaps as a provider of gateway and/or host services.
  79.  
  80.              Each  of  these  subnetwork entities could have  a  distinct 
  81.         address  and  perhaps several internally  administered  host/user 
  82.         addresses.
  83.  
  84.              [NOTE:  Throughout this paper,  Host or Host/User represents 
  85.              any  host  or any user running IP protocols that has  direct 
  86.              network  access.  Also,  for the purposes of  the  following 
  87.              example,   WA6JPR  is  not  a  network  address,  rather  it 
  88.              represents  a user-id on a local host.   It is the  writer's 
  89.              opinion that the majority of packet users for the forseeable 
  90.              future  will  be using simple TNCs connected  to  hosts  via 
  91.              AX.25 level 2 protocols.]
  92.  
  93.              WA6JPR  may  be "a user" on hosts on more than  one  network 
  94.         such  that  a station in Washington D.C.,logged onto  an  AMPRNET 
  95.         host,    may    send    internet    traffic    successfully    to 
  96.         WA6JPR@JPRHOST.WESTNET  (this traffic would be routed to  Westnet 
  97.         via various AMPRNET gateways and subnetwork level relays and then 
  98.         to  a  Santa  Barbara  host known internally  by  Westnet  to  be 
  99.         reachable  via  the  W6AMT-2  switch).   Traffic  could  also  be 
  100.         directed  to  Wally@SBARC   (presuming  that  the  Santa  Barbara 
  101.         Amateur  Radio Club maintains a message server host gatewayed  to 
  102.         the AMPRNET catenet).
  103.  
  104.              Based  upon  the  presumption  of  the   AMPRNET/SUBNET/HOST 
  105.         hierarchy,  it  would  seem  that we could easily decide  how  to 
  106.         allocate  the 044.xxx.xxx.xxx 24 bit IP address field  such  that 
  107.         there  are bits allocated for a sufficient number of individually 
  108.         managed  subnetworks  while leaving  a  correspondingly  adequate 
  109.         number  of  assignable bits for the internal addressing needs  of 
  110.         each individual subnetwork.
  111.  
  112.              Accordingly,   the  following  is  proposed  as  an  initial 
  113.         addressing  scheme and methodology for address assignment.   [Bit 
  114.         numbering is per RFC-960 Pg.2]
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.                                         2
  123.  
  124.  
  125.  
  126.         Bit  8  to  be 0 for USA stations and  1  for  non-USA  stations.  
  127.         [Note.   This  is  not  meant  to imply a  geographic  basis  for 
  128.         assignments.   It  is  meant to provide a very  quick  means  for 
  129.         segregating FCC controlled participants from non-FCC stations.]
  130.  
  131.         Bits  9 - 18 to represent politically separate subnetworks within 
  132.         AMPRNET.   These  bits  are to be assigned in an  inverse  binary 
  133.         sequence   (see   example   below)  beginning  with   the   *MOST 
  134.         SIGNIFICANT* bit first.
  135.  
  136.         Bits 19 - 23 to be unassigned and reserved for future  allocation 
  137.         as  network addresses,  to network administrations for internally 
  138.         assigned  host  and/or user addresses,  to a combination  of  the 
  139.         above or to a completely new intermediate class of addresses.
  140.  
  141.         Bits  24  - 31  to be used within  politically  separate  AMPRNET 
  142.         subnetworks for individual hosts,  switches, workstations etc. as 
  143.         determined  by  local  network  administration.    It  would   be 
  144.         recommended  that these bits be assigned in binary sequence  with 
  145.         the *LEAST SIGNIFICANT* bits being assigned first.
  146.  
  147.              The  resulting  network  addresses would be as follows:
  148.  
  149.         AMPRNET
  150.         ||
  151.         || SUBNET----+
  152.         || |         |
  153.         || |         | HOST--+
  154.         || |         | |     |
  155.         44:0...127:000:0...255------- 32,768 addresses assignable
  156.         44:0...127:001:0...255--+
  157.                     |           +- 1,015,808 addresses reserved
  158.         44:0...127:031:0...255--+
  159.         44:0...127:032:0...255------- 32,768 addresses assignable
  160.         44:0...127:033:0...255--+
  161.                     |           +- 1,015,808 addresses reserved
  162.         44:0...127:063:0...255--+
  163.         44:0...127:064:0...255------- 32,768 addresses assignable
  164.         44:0...127:065:0...255--+
  165.                     |           +- 1,015,808 addresses reserved
  166.         44:0...127:095:0...255--+
  167.         44:0...127:096:0...255------- 32,768 addresses assignable
  168.         44:0...127:097:0...255--+
  169.                     |           +- 1,015,808 addresses reserved
  170.         44:0...127:127:0...255--+
  171.         44:0...127:128:0...255------- 32,768 addresses assignable
  172.         44:0...127:129:0...255--+
  173.                     |           +- 1,015,808 addresses reserved
  174.         44:0...127:159:0...255--+
  175.         44:0...127:160:0...255------- 32,768 addresses assignable
  176.         44:0...127:161:0...255--+
  177.                     |           +- 1,015,808 addresses reserved
  178.         44:0...127:191:0...255--+
  179.         44:0...127:192:0...255------- 32,768 addresses assignable
  180.  
  181.  
  182.  
  183.                                         3
  184.  
  185.  
  186.  
  187.         44:0...127:193:0...255--+
  188.                     |           +- 1,015,808 addresses reserved
  189.         44:0...127:223:0...255--+
  190.         44:0...127:224:0...255------- 32,768 addresses assignable
  191.         44:0...127:225:0...255--+
  192.                     |           +- 1,015,808 addresses reserved
  193.         44:0...127:255:0...255--+
  194.  
  195.         44:128:xxx:xxx----------+
  196.             |                   +- 8,388,608 addresses assignable (non USA)
  197.         44:255:xxx:xxx----------+
  198.  
  199.  
  200.              The  above  allocation and assignment scheme allows  network 
  201.         (subnet)  and  intranet  (host/user) addresses  to  begin  to  be 
  202.         immediately assigned to experimenters while retaining the largest 
  203.         possible  contiguous  block of unassigned bits whose  assignments 
  204.         can  be  defined  in  the future with  little  or  no  impact  on 
  205.         previously   allocated   addresses.    The  USER  @  HOSTNAME   . 
  206.         SUBNET/ADMINISTRATION  naming scheme represents a  human-friendly 
  207.         network  naming  convention  which  maps  easily  into  numerical 
  208.         network  addresses.   I  believe that the above  approach  is  in 
  209.         general  conformance with the requirements of RFC-950,  "Internet 
  210.         Standard Subnetting Procedure."
  211.  
  212.              The  numbering scheme as initially proposed allows for up to 
  213.         1024  AMPRNET  subnetworks  of up to 256 hosts in the  USA  while 
  214.         retaining  five  bits  for  future  expansion.    That's  262,144 
  215.         individual AMPRNET addressable entities.   If the proposed method 
  216.         of  address  assignment is followed and we run out  of  Host/User 
  217.         addresses before we run out of network addresses,  we can  simply 
  218.         pick  up  the  least  significant reserved bit  and  assign  more 
  219.         Host/User addresses.   Conversely,  if network addresses are more 
  220.         popular  we  could easily expand by taking the  most  significant 
  221.         reserved  bit and allocating it for network  addressing.
  222.  
  223.         If it should become clear that every user on a network needs  his 
  224.         or her own IP address, each network could allocate user blocks in 
  225.         256  user  increments from the least significant  reserved  bits.  
  226.         Possible  combinations  are  1024 networks each with up  to  8192 
  227.         individually  addressable units or 2048 networks each  with  4096 
  228.         hosts/users (8,388,608 individually addressable entities).
  229.  
  230.              The  writer presumes that 8 million plus addresses ought  to 
  231.         last the US amateur population for some time to come. All we need 
  232.         to  do to avoid painting ourselves in a corner is to assign  them 
  233.         in a logical sequence rather than randomly.
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.                                         4
  245.  
  246.  
  247.  
  248.              The  following table serves as an example of the  "high  bit 
  249.         first"  network  address  assignment table and  some  actual  and 
  250.         requested initial networking assignments.
  251.  
  252.              "this"         44.000.000.xxx      ;special case
  253.              KARNnet        44.064.000.xxx      ;network admin: KA9Q
  254.              BDALEnet       44.032.000.xxx      ;network admin: N3EUA
  255.              DCnet1         44.096.000.xxx      ;network admin: WB6RQN
  256.              SOCALnet1      44.016.000.xxx      ;network admin: WB5EKU
  257.              DCnet2         44.080.000.xxx      ;network admin: WB6RQN
  258.              SOCALnet2      44.048.000.xxx      ;network admin: WA6JPR
  259.              PITTNET        44.112.000.xxx      ;network admin: N3CVL
  260.              next           44.008.000.xxx
  261.              next           44.072.000.xxx
  262.                                 .
  263.                                 .
  264.                                 .
  265.              last           44.063.000.xxx
  266.              "all"          44.127.000.xxx      ;special case
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.  
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.                                         5
  306.  
  307.