As per Relevance of the word additional, we have this rfc below:
Network Working Group K. van den
Request for Comments: 2322 HvU/HIP-
Category: Informational A.
UUnet NL/HIP-
R. van
University of Twente/HIP-
1 April 1998
Management of IP numbers by peg-
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This RFC describes a protocol to dynamically hand out ip-numbers
field networks and small events that don't necessarily have a
organisational body
It can also provide some fixed additional fields global for
clients like netmask and even autoproxyconfigs. It does not depend
a particular ip-stack
History of the protocol
The practice of using pegs for assigning IP-numbers was first used
the HIP event (http://www.hip97.nl/). HIP stands for Hacking
Progress, a large three-day event where more then a thousand
from all over the world gathered. This event needed to have a TCP/
lan with an Internet connection. Visitors and participants of
HIP could bring along computers and hook them up to the HIP network
During preparations for the HIP event we ran into the problem of
to assign IP-numbers on such a large scale as was predicted for
event without running into troubles like assigning duplicate
or skipping numbers. Due to the variety of expected computers
associated IP stacks a software solution like a Unix DHCP
would probably not function for all cases and create
technical problems
van den Hout, et. al. Informational [Page 1]
RFC 2322 Management of IP numbers by peg-dhcp 1 April 1998
So a way of centrally administrating IP-numbers and giving them
to people to use on their computers had to be devised. After
discussion, the idea came up of using wooden clothes-pegs. Using
has the following advantages in respect to other methods
-
- a peg is a 'token' and represents one IP-number,
making the status of the IP-number (allocated or not allocated
visible
- a peg can be clipped to a network cable giving a very
view of where a given IP-number is in use
Credits for the original idea of using wooden pegs go to
Ockeloen
The server
The server can have many appearances. At HIP it was a large
situated at the central field where all the activities were. It
also be a small table in the corner of a terminalroom
The server can hand out two parts to the client, the peg and a
with additional fields fixed for the site the server is running for
We will describe both here
The peg
On the peg the IP-number is mentioned. The text on the peg can
described according to the following BNF
Total ::== IP |
IP ::== num.num.num.num | num.num |
Net ::== num.num.num/mask | num.num/mask | num/
num ::== {1..255}
mask ::== {8..31}
The Net-method of writing larger nets is an optional part of
protocol, it doesn't have to be implemented. If it is implemented,
requires more administration at the server (see below).
The short versions of the IP-number with only 1 or 2 chunks are
for large servers where writing the whole number on the peg is
boring and time-consuming. It requires the prefix to be mentioned
the additional field paper, but that can be produced in
van den Hout, et. al. Informational [Page 2]
RFC 2322 Management of IP numbers by peg-dhcp 1 April 1998
convenient ways. It is not recommended to work with more prefixes.
is better to write more numbers on the peg and use a smaller prefix
If the network to be numbered is rather large and some kind
subnetting has to be implemented it is possible to give the pegs
the different subnets different colors. This has proven to be a
convenient way at HIP
The additional vendorfield paper
This part is meant for information that is fixed for the whole site
It can either be implemented as small printed notes handed out
the peg or as a large paper billboard hung at a convenient
where everybody can read it
The information can be described with the following BNF
Network ::== num.num.num.
Netmask ::== num.num.num.num |
Gateway ::== num.num.num.num | num.num |
Proxy ::== num.num.num.num:port | num.num:port | num:
Paper ::== Network Netmask Gateway Proxy | Network Netmask
num ::== {0..255}
port ::== {1..65535}
The paper and the peg are of course one part, if two numbers are
on the peg, two numbers are used on the paper
Because it is fixed information, it can be produced with means
mass-production (printing, copying).
The IP-
Due to the nature of the peg, the repository can be quite simple
Just a clothes-line with all the pegs that are ready to be handed
attached to it. If you work with different subnets, it is
to group the pegs for the different subnets (colors).
At large networks where it is not really known how many IP-
are needed, a first set of pegs can be made in advance, and
administration of produced pegs kept on paper so it is known
which numbers pegs have already been made. If use is made of
van den Hout, et. al. Informational [Page 3]
RFC 2322 Management of IP numbers by peg-dhcp 1 April 1998
net-extension on the pegs, numbers given out that way can
administrated this way too
Issuing IP-numbers
The pegs and the IP-numbers are issued at the server to the client
Normally the client has to visit the server personally. Depending
how secure and controlled you want the process, the client has to
for a peg to a responsible person, or he or she can just get a
from store himself
If someone could apply for a networkrange, and he net-extension isn'
used, coat-hangers can be prepared with sets of pegs attached
them
The vendorfields paper doesn't have to be issued with every peg,
is only needed when wanted
Reclaiming and reusing IP-numbers
It is not easy to implement a TTL in this protocol. One obvious
is the duration of the event after which the IP-numbers are not
anymore
However, if a client decides that it doesn't need an IP-
anymore it can bring the peg back to the server
The server should at that point decide what to do, if desired, it
bring the peg back into the pool (attach it to the clothes-
again).
If the server is not manned (the client has to help themselves),
only thing possible is that the client just places the peg back
the pool
The client side
The optimum location for the peg is clipped to the network cable
the NIC of the device needing an IP-number allocated. This ensures
clear visual connection between the device and the IP-
allocated and makes it an easy task to see which IP-number
allocated
Transfer of the IP information from the peg and the
vendorfield paper note to the settings in the IP stack is done
human transfer. A person reads the information from the peg and
the additional information and enters this in the configuration
the used IP stack. This transfer is not completely free
van den Hout, et. al. Informational [Page 4]
RFC 2322 Management of IP numbers by peg-dhcp 1 April 1998
corruption of the information or loss of the information contained
the peg
A certain amount of knowledge of the logic of IP settings is
assumed on the part of the person transferring the information
Other information on the vendorfield paper note has to be
to the settings within specific application programs
Use with other
This protocol could be combined with avian carriers as described
RFC 1149 to hand out IP-numbers remote
At the first avian carrier, the peg is clipped to the leg of
carrier after rolling the additional vendorfield paper around it
The remote site can take the peg on arrival of the avian carrier
use the information on it
This part of the protocol is still experimental and requires
additional research on topics like the weight of the peg and loss
the peg/whole carrier
Security
Some remarks about security can be made
Pegs are small devices and can be lost. At that time, the IP-
which was lost can't be used anymore because someone else can
the peg and use the information stored on it. But, once the peg
attached to a network cable, the chance to loose the peg
minimized
All the information on both the peg and on the additional 'fixed
fields on the paper record are plain text and readable for everyone
Private information should not be exchanged through this protocol
On the client side all sorts of clients exist and cooperate freely
Due to the human factor of the clients transferring information
peg to IP stack, the information can be misinterpreted, which
cause network troubles. In the field test at HIP this
perfectly clear when someone mixed up the numbers and used
address from the default router as his IP-number, rendering
network useless for a period of time
van den Hout, et. al. Informational [Page 5]
RFC 2322 Management of IP numbers by peg-dhcp 1 April 1998
Authors'
Koos van den
Hogeschool van Utrecht / Expertisecentrum
P.O. box 85029
3508 AA
The
Phone: +31-30-2586287
Fax: +31-30-2586292
EMail: koos@cetis.hvu.
Andre
UUnet
P.O. box 12954
1100 AZ
The
Phone: +31-20-4952727
Fax: +31-20-4952737
EMail: andre@NL.
Remco van
Van Mook
Calslaan 10-31
7522 MA
The
Phone: +31-53-4895267
EMail: remco@sateh.
van den Hout, et. al. Informational [Page 6]
RFC 2322 Management of IP numbers by peg-dhcp 1 April 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
van den Hout, et. al. Informational [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
